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

O metastore do BigLake oferece replicação entre regiões e recuperação de desastres para melhorar a disponibilidade e a resiliência do seu catálogo.

Esse recurso melhora a disponibilidade e a capacidade de recuperação do catálogo, garantindo acesso contínuo, protegendo contra interrupções regionais, evitando perda de dados e permitindo failover para tabelas do Apache Iceberg que usam um catálogo REST do Iceberg.

Como funciona

O BigLake Metastore seleciona automaticamente as regiões primária e secundária para metadados do catálogo. A região principal processa todos os metadados de confirmação da tabela e os replica para a região secundária para backup.

A qualquer momento, principalmente durante um desastre, é possível trocar as regiões principal e secundária do catálogo usando a operação de failover. Essa ação troca o primário do catálogo e de todos os namespaces e tabelas contidos.

Replicação entre regiões

A replicação entre regiões envolve dois componentes principais: replicação de dados e do metastore. O recurso de recuperação de desastres se baseia na replicação entre regiões para ativar o failover.

  • Replicação de dados: o Cloud Storage replica automaticamente os dados do catálogo em várias regiões quando você usa um bucket birregional ou multirregional. Se ocorrer uma interrupção regional, seus dados vão continuar acessíveis sem alterações nos caminhos de armazenamento.

  • Replicação do metastore: para catálogos REST do Iceberg, o metastore do BigLake replica automaticamente seu metastore quando você usa um bucket birregional (ou birregional personalizado). A replicação do metastore começa quando você cria o catálogo. O metastore do BigLake seleciona uma região primária e secundária das regiões definidas na sua configuração do Cloud Storage. A região principal atende a todos os metadados de confirmação da tabela e os replica para a região secundária para backup.

Recuperação de desastres com failover

Com o recurso de recuperação de desastres, é possível trocar as regiões primária e secundária de um catálogo. A operação de failover troca a região principal do catálogo e todos os namespaces e tabelas dele. Os failovers têm dois modos: failover leve e failover grave.

  • Failover suave: evita a perda de dados. Nesse modo, a nova região principal começa a aceitar gravações somente depois que todos os dados anteriores são sincronizados da região principal anterior. Use um failover suave para testes de recuperação de desastres ou outros cenários planejados.

  • Failover forçado: prioriza a disponibilidade em vez da consistência dos dados e foi projetado para restaurar o serviço. Nesse modo, a região principal sempre assume o controle e aceita o tráfego de gravação, independente do estado atual da região principal. Por exemplo, ao usar um failover forçado, a nova região primária pode assumir o controle mesmo que a primária anterior esteja inacessível.

Limitações

Enquanto esse recurso estiver em prévia, 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 do Cloud Storage sobre Disponibilidade e durabilidade dos dados.

A seguir