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

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

Essa configuração requer catálogos apoiados por 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, se ainda não tiver feito isso.

    Funções necessárias para ativar APIs

    Para ativar APIs, você precisa da permissão serviceusage.services.enable. Se você criou o projeto, provavelmente já tem essa permissão pelo papel de proprietário (roles/owner). Caso contrário, é possível conseguir essa permissão pelo papel de administrador do Service Usage (roles/serviceusage.serviceUsageAdmin). 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 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 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 de catálogo e dados de tabela no modo de venda sem credenciais:
  • Gerenciar recursos de catálogo e gravar dados de tabela no modo de venda sem 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. Confira 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 principal 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 o catálogo é replicado, execute o seguinte comando gcloud biglake iceberg catalogs describe.

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 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 de metastore para designar regiões primárias e secundárias. Todos os metadados de commit da tabela são disponibilizados na região primária e replicados para a região secundária. É possível alternar as regiões principal 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 atua como um checkpoint para 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, independentemente de qualquer atraso na replicação, defina esse carimbo de data/hora como uma data muito antiga. Observação: enquanto esse recurso estiver em pré-lançamento, 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 de disponibilidade e durabilidade de dados do Cloud Storage.

A seguir