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 do catálogo.

Essa configuração exige catálogos com suporte de buckets birregionais ou multirregionais do Cloud Storage.

Antes de começar

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

  2. Ative a API BigLake.

    Funções necessárias para ativar APIs

    Para ativar as APIs, é necessário ter o papel do IAM de administrador de uso do serviço (roles/serviceusage.serviceUsageAdmin), que contém a permissão serviceusage.services.enable. Saiba como conceder papéis.

    Ativar a API

Funções exigidas

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

  • Realize tarefas administrativas, como gerenciar o acesso de usuários ao catálogo, o acesso ao armazenamento e o modo de venda de credenciais do catálogo:
  • Ler dados da tabela no modo de venda de credenciais: Leitor do BigLake (roles/biglake.viewer) no projeto
  • Gravar dados de tabela no modo de venda de credenciais: Editor do BigLake (roles/biglake.editor) no projeto
  • Ler recursos do catálogo e dados da tabela no modo sem venda de credenciais:
  • Gerencie recursos de catálogo e grave dados de tabela no modo sem venda de 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 usando 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. Verificar o status da replicação:identifique as regiões primária e secundária atuais para determinar a região de destino do failover.
  2. Verifique o status da sincronização:confira o estado atual das regiões principal e secundária para garantir que elas estejam prontas para uma transição.
  3. Escolha um modo de failover:decida entre um failover suave (melhor para manutenção planejada) ou um failover forçado (melhor para recuperação de emergência).
  4. Inicie o failover:execute o comando correspondente ao modo escolhido para alternar as regiões primária e secundária.

Preparar para failover

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

Ver o status da replicação

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

gcloud biglake iceberg catalogs describe CATALOG_NAME

Substitua CATALOG_NAME pelo nome do seu catálogo.

Verificar o status da sincronização

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

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 principal.

Iniciar um failover

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

Failover flexível

Para iniciar um failover suave, execute o seguinte comando gcloud biglake iceberg catalogs failover:

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 principal.

Failover rígido

Para iniciar um failover forçado, execute o seguinte comando gcloud biglake iceberg catalogs failover:

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 principal.
  • REPLICATION_TIMESTAMP: um carimbo de data/hora RFC 3339 que funciona como um ponto de verificação para a replicação. O processo de replicação verifica se a réplica contém todos os dados confirmados até o momento. Se a réplica não contiver todos os dados confirmados antes desse carimbo de data/hora, o comando vai falhar. Para forçar o processo de failover, independente de um possível atraso na replicação, defina esse carimbo de data/hora para uma data muito antiga. Observação: enquanto esse recurso estiver em prévia, o REPLICATION_TIMESTAMP rastreará apenas os metadados do catálogo, e não os arquivos do Cloud Storage. Para manter a perda de dados em um limite inferior, consulte a documentação do Cloud Storage sobre Disponibilidade e durabilidade de dados.

A seguir