Nesta página, descrevemos como usar a replicação entre regiões e a recuperação de desastres do metastore do BigLake.
Esse recurso só está disponível para catálogos que usam buckets birregionais ou multirregionais do Cloud Storage.
Antes de começar
-
Verify that billing is enabled for your Google Cloud project.
-
Enable the BigLake API.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (
roles/serviceusage.serviceUsageAdmin), which contains theserviceusage.services.enablepermission. Learn how to grant roles.
Funções exigidas
Para receber as permissões necessárias para usar o catálogo REST do Iceberg no metastore do BigLake, 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:
-
Administrador do BigLake (
roles/biglake.admin) no projeto -
Administrador do Storage (
roles/storage.admin) no bucket do Cloud Storage
-
Administrador do BigLake (
-
Ler dados da tabela no modo de venda de credenciais:
Leitor do BigLake (
roles/biglake.viewer) no projeto -
Gravar dados da 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:
-
Leitor do BigLake (
roles/biglake.viewer) no projeto -
Leitor de objetos do Storage (
roles/storage.objectViewer) no bucket do Cloud Storage
-
Leitor do BigLake (
-
Gerenciar recursos do catálogo e gravar dados de tabelas no modo sem venda de credenciais:
-
Editor do BigLake (
roles/biglake.editor) no projeto -
Usuário de objetos do Storage (
roles/storage.objectUser) no bucket do Cloud Storage
-
Editor do BigLake (
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:
- Verificar o status da replicação:identifique as regiões primárias e secundárias atuais para determinar a região de destino do failover.
- Verifique o status da sincronização:confira o estado atual das regiões primária e secundária para garantir que elas estejam prontas para uma transição.
- 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).
- 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 alpha biglake iceberg catalogs describe.
gcloud alpha 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 alpha biglake iceberg failover:
gcloud alpha 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 parcial, execute o seguinte comando alpha biglake iceberg failover:
gcloud alpha 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 alpha biglake iceberg failover:
gcloud alpha 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 atraso na replicação, defina esse carimbo de data/hora para uma data muito antiga.