Usar a replicação entre regiões e a recuperação de desastres

O Lakehouse para Apache Iceberg oferece suporte à replicação entre regiões e à recuperação de desastres para metadados de catálogo.

Essa configuração exige catálogos com suporte de buckets de região dupla ou multirregião do Cloud Storage.

Antes de começar

  1. Verifique se o faturamento está ativado para o Google Cloud projeto.

  2. Ative a API BigLake.

    Funções necessárias para ativar APIs

    Para ativar as APIs, é necessário ter a permissão serviceusage.services.enable. Se você criou o projeto, provavelmente já tem essa permissão com o papel de proprietário (roles/owner). Caso contrário, é possível receber essa permissão com o papel de administrador de uso do serviço (roles/serviceusage.serviceUsageAdmin). Saiba como conceder papéis.

    Ativar a API

Funções exigidas

Para ter as permissões necessárias para usar o endpoint do catálogo REST do Iceberg no catálogo do ambiente de execução do Lakehouse, peça ao administrador para conceder a você os seguintes papéis do IAM:

  • Realizar tarefas administrativas, como gerenciar o acesso do usuário ao catálogo, o acesso ao armazenamento e o modo de fornecimento de credenciais do catálogo:
  • Ler dados da tabela no modo de fornecimento de credenciais: Leitor do BigLake (roles/biglake.viewer) no projeto
  • Gravar dados da tabela no modo de fornecimento de credenciais: Editor do BigLake (roles/biglake.editor) no projeto
  • Ler recursos de catálogo e dados de tabela no modo de fornecimento de não credenciais:
  • Gerenciar recursos de catálogo e gravar dados de tabela no modo de fornecimento de não credenciais:

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias com papéis personalizados ou outros papéis predefinidos.

Fluxo de trabalho de replicação e recuperação de desastres

Para usar a replicação entre regiões e a recuperação de desastres, siga estas etapas gerais:

  1. Conferir o status da replicação:identifique suas regiões primárias e secundárias atuais para determinar a região de destino do failover.
  2. Verificar o status da sincronização:verifique o estado atual das regiões primárias e secundárias para garantir que elas estejam prontas para uma transição.
  3. Escolher um modo de failover: decida entre um failover flexível (melhor para manutenção planejada) ou um failover rígido (melhor para recuperação de emergência ).
  4. Iniciar o failover:execute o comando correspondente ao modo escolhido para alternar as regiões primárias e secundárias.

Preparar para o failover

Identifique sua região primária atual e verifique o status de sincronização da região secundária. Em seguida, inicie o failover.

Conferir o status da replicação

Para determinar as regiões em que o catálogo é replicado, execute o seguinte gcloud biglake iceberg catalogs describe comando.

gcloud biglake iceberg catalogs describe CATALOG_NAME

Substitua CATALOG_NAME pelo nome do catálogo.

Verificar o status da sincronização

Antes de iniciar um failover, verifique o status de sincronização da sua réplica secundária com o gcloud biglake iceberg catalogs failover comando:

gcloud biglake iceberg catalogs failover CATALOG_NAME \
    --validate_only \
    --primary-replica PRIMARY_REPLICA_REGION

Substitua:

  • CATALOG_NAME: o nome do catálogo.
  • PRIMARY_REPLICA_REGION: a região a ser designada como a nova réplica primária.

Iniciar um failover

O recurso de recuperação de desastres usa a replicação de metastore para designar regiões primárias e secundárias. Todos os metadados de confirmação da tabela são veiculados da região primária e replicados para a região secundária. É possível alternar as regiões primárias e secundárias do catálogo usando a operação de failover.

Failover flexível

Para iniciar um failover flexível, execute o seguinte gcloud biglake iceberg catalogs failover comando:

gcloud biglake iceberg catalogs failover CATALOG_NAME \
    --primary-replica PRIMARY_REPLICA_REGION

Substitua:

  • CATALOG_NAME: o nome do catálogo.
  • PRIMARY_REPLICA_REGION: a região a ser designada como a nova réplica primária.

Failover rígido

Para iniciar um failover rígido, execute o seguinte gcloud biglake iceberg catalogs failover comando:

gcloud biglake iceberg catalogs failover CATALOG_NAME \
    --primary-replica PRIMARY_REPLICA_REGION \
    --conditional-failover-replication-time=REPLICATION_TIMESTAMP

Substitua:

  • CATALOG_NAME: o nome do catálogo.
  • PRIMARY_REPLICA_REGION: a região a ser designada como a nova réplica primária.
  • REPLICATION_TIMESTAMP: um carimbo de data/hora RFC 3339 que atua como um ponto de verificação para replicação. O processo de replicação verifica se a réplica contém todos os dados confirmados até esse momento. Se a réplica não contiver todos os dados confirmados antes desse carimbo de data/hora, o comando falhará. Para forçar o processo de failover, independentemente de qualquer atraso de replicação, defina esse carimbo de data/hora para uma data muito antiga. Observação: enquanto esse recurso estiver na visualização, o REPLICATION_TIMESTAMP vai rastrear apenas os metadados do catálogo, e não os arquivos do Cloud Storage. Para manter a perda de dados com um limite inferior, consulte a documentação Disponibilidade e durabilidade de dados do Cloud Storage.

A seguir