Gerenciar recuperação de desastres

nota

A recuperação de desastres está em Private Preview. Durante a prévia privada, ele está disponível para replicação entre regiões somente na AWS, e você o gerencia nas configurações do projeto na interface do usuário. Para habilitá-lo para sua account, peça ao administrador do seu Workspace para entrar em contato com o representante de sua account Databricks.

Durante a Prévia Privada, a recuperação de desastres não se destina ao uso em produção.

Este guia aborda a habilitação da recuperação de desastres para um projeto, o Trigger de um failover ou failback e a inspeção de Branch de recuperação. Para obter informações sobre como a recuperação de desastres funciona e como ela difere da alta disponibilidade, consulte Recuperação de desastres.

Apenas um administrador de projeto do Lakebase (alguém com a CAN_MANAGE Lista de Controle de Acesso (ACL)) pode habilitar ou desabilitar a recuperação de desastres ou Trigger um failover. Para ver quem tem CAN_MANAGE, verifique a seção Permissões do projeto das configurações do projeto.

A recuperação de desastres abrange dois Workspaces, então cada tarefa é executada em um específico:

Tarefa	Onde você o executa
Ativar ou desativar	O projeto primário, no Workspace primário
Trigger um failover	O projeto secundário, no Workspace Secundário
Fail back	O projeto primário original, no Workspace Principal original (agora o Secundário)
Inspecione as Branch de recuperação	O projeto primário original, no Workspace Primário original, após o failback

Tarefa	Onde você o executa
Ativar ou desativar	O projeto primário, no Workspace primário
Trigger um failover	O projeto secundário, no Workspace Secundário
Fail back	O projeto primário original, no Workspace Principal original (agora o Secundário)
Inspecione as Branch de recuperação	O projeto primário original, no Workspace Primário original, após o failback

Pré-requisitos

• Um projeto Lakebase Autoscaling. Projetos criados com Lakebase Provisionado devem ser migrados para o Autoscaling antes que a recuperação de desastres possa ser ativada. Consulte Atualizar para o Lakebase autoscale.
• Dois Workspaces em regiões diferentes. Workspaces na mesma região não são suportados como um par de replicação.
• O Workspace Secundário como um destino de replicação elegível. O Workspace Secundário deve estar na lista de destinos de replicação elegíveis da sua account. Durante a Prévia Privada, seu representante da account Databricks configura isso quando eles habilitam a recuperação de desastres.

nota

Durante a Prévia Privada, forneça as seguintes informações ao representante da sua conta para que ele possa configurar seu grupo de replicação:

• ID da account: encontre-o no console da account.
• ID do Workspace Primário: o Workspace onde o projeto Lakebase primário está localizado
• ID do Workspace secundário: o Workspace onde o projeto Lakebase secundário é executado
• ID do projeto Lakebase: o projeto já deve existir antes que a recuperação de desastres possa ser habilitada

Para encontrar um ID de Workspace, consulte Obter identificadores para objetos do workspace. O ID do Projeto Lakebase é o project_id do projeto, mostrado na lista de projetos no console do Lakebase.

A recuperação de desastres funciona com chaves gerenciadas pelo cliente (CMK): projetos criptografados com CMK se replicam entre regiões como qualquer outro projeto.

Habilitar recuperação de desastres

Um administrador de projeto ativa a replicação do **projeto primário**, no Workspace que o hospeda.

1. No Workspace Primário, abra seu projeto e selecione Configurações .
2. Na seção Replicação entre workspaces , confirme o Workspace primário . Isso é definido para o Workspace que hospeda o projeto e não pode ser alterado.
3. Em Secundário , selecione o Workspace onde o projeto secundário é executado.
4. Selecione **Salvar e Habilitar**.

Lakebase cria o grupo de replicação e inicia a replicação periódica do primário para o secundário.

No Workspace Secundário, o Lakebase cria um projeto secundário com o mesmo nome do Primário. Para encontrá-lo, alterne para o Workspace Secundário e abra o console do Lakebase. O novo projeto aparece na lista Autoscaling Database Projects .

O projeto secundário inclui todas as branches do projeto primário, e cada branch tem seus próprios endpoints regionais. Durante a replicação periódica, este projeto secundário é somente leitura. Seu compute permanece parado e não é possível conectar-se a ele até que um failover o promova. A configuração da branch, incluindo intervalos de compute e alta disponibilidade, é copiada do Primário para que o compute correspondente possa começar imediatamente no failover.

Trigger um failover

Um Administrador de Projeto inicia um failover do Workspace Secundário, para que você possa começá-lo mesmo quando a região principal estiver indisponível. O failover é imediato: o Lakebase promove o secundário a ser o novo principal e para de aceitar gravações no principal original.

Para Trigger um failover:

1. No Workspace Secundário, abra o projeto secundário e vá para o seu painel do projeto.
2. Em **Configurações do projeto**, selecione **Promover secundário**.
3. Na caixa de diálogo Promover , selecione Failover . O failover promove esta cópia imediatamente. As transações que ainda não haviam se replicado para este Workspace não são promovidas com ele. O Lakebase as preserva como uma branch de recuperação que você reconcilia mais tarde, após o failback.
4. Selecione Confirmo que desejo promover este projeto e esta operação pode causar tempo de inatividade e, em seguida, selecione Promover .

O failover envolve tempo de inatividade. O primário original para de aceitar gravações imediatamente, e o novo primário fica indisponível até que inicie o compute e se torne consultável. Seu aplicativo permanece inativo até que você o configure para se conectar ao novo primário usando a string de conexão do novo primário. Especificamente, após um failover:

• O projeto secundário se torna o novo Primário. O Lakebase ativa seus Endpoint regionais e começa o compute para cada Branch, usando a configuração da Branch copiada do Primário original.
• O primário original para de aceitar gravações. Quando seu Workspace está disponível, o Lakebase desliga seu compute. Quaisquer tabelas sincronizadas ou pipelines CDF do Lakebase nele são terminados.
• Seu aplicativo deve se reconectar ao endpoint do novo principal. Cada região tem seus próprios endpoints, então atualize a configuração de conexão do seu aplicativo e obtenha um novo token de autenticação antes de retomar o tráfego. Obtenha a string de conexão e o token do novo principal na caixa de diálogo **Conectar** no projeto secundário. Consulte Conectar-se ao seu banco de dados.

É possível trigger um failover a qualquer momento, não apenas durante uma interrupção real. Use isso para executar simulados de DR e ensaiar seu processo de reconexão, atualizando a string de conexão do seu aplicativo e obtendo um novo token, para que seja comprovado antes de uma interrupção real.

Fail back para sua região original

O failback retorna sua workload à sua região original após a recuperação dessa região. No ciclo de vida da recuperação de desastres, o failover é a movimentação de emergência que o coloca em execução na região secundária durante uma interrupção; o failback é a movimentação planejada de retorno quando a região original estiver saudável novamente, para que você possa retomar sua topologia normal. O failback é opcional. Faça isso quando desejar que a região original volte a ser a Primária.

O Failback não é uma operação separada: é uma execução de failover na direção oposta. Assim que a região primária original se recupera, seu projeto reintegra o grupo de replicação como um Secundário e a replicação reinicia do Primário atual de volta para ele. Como você executa o failback como uma operação planejada, e não durante uma interrupção, você pode permitir que a replicação se atualize completamente primeiro, e depois fazer failback sem perda de dados (RPO=0). Para fazer isso, interrompa as gravações no Primário atual e aguarde o atraso de replicação atingir zero antes de promover, conforme descrito nos passos seguintes.

O diálogo Promover também lista a Comutação como uma opção em breve. A Comutação interromperá as gravações no Primário atual, aguardará a replicação de todas as transações e promoverá em um único o passo, assim, não será necessário interromper as gravações e fazer o failover como os passos separados.

Para fazer o fail back:

1. Interrompa o tráfego de gravação no primário atual para que nenhuma nova transação seja criada enquanto a região original se atualiza. Isso é feito a partir de sua aplicação, por exemplo, pausando o serviço de gravação ou colocando a aplicação em modo somente leitura ou manutenção. O Lakebase não impede gravações para você.
2. Monitore o atraso de replicação até atingir zero, confirmando que todas as transações foram replicadas para a região original.
3. No Workspace primário original, abra o projeto (agora atuando como secundário) e selecione Promover secundário no painel, a mesma ação que você usou para o failover. Na caixa de diálogo Promover , selecione Failover e confirme.
4. Configure seu aplicativo para conectar-se ao Primário original usando sua string de conexão e um novo token de autenticação. Obtenha-os na caixa de diálogo Conectar no projeto primário original. Consulte Conectar-se ao seu banco de dados.

Após o failback:

• A região original é novamente a Primária, e a outra região volta a ser um Secundário parado.
• Se alguma transação não foi replicada antes da interrupção original, o Lakebase as apresenta como Branch de recuperação no Primário original. Consulte Inspecionar e reconciliar Branch de recuperação.

Inspecione e concilie Branch de recuperação

Os Branch de recuperação vivem no projeto primário original, então você os inspeciona no Workspace primário original. Quando um projeto tem branches de recuperação, sua página de Branches mostra um banner informando quantos branches de recuperação existem de um failover recente, com um aviso para inspecionar sua divergência de dados. Selecione View project branches para vê-los. Os Branch de recuperação são exibidos apenas quando uma divergência é detectada.

Na página Branches , um branch de recuperação aparece com o nome do branch do qual divergiu, mais um sufixo -recovery. Sua tag de status mostra onde ela está no processo de sincronização:

• **Sincronização doméstica pendente**: a branch ainda não replicou de volta para sua região de origem, então a divergência não pode ser determinada. Passar o mouse sobre a tag explica que a inspeção é prematura. Este é o estado logo após um failover, antes do failback. Aguarde a branch sincronizar.
• Inspecionar : a Branch foi sincronizada de volta à sua região de origem e está pronta para ser reconciliada.

Uma vez que um Branch de recuperação mostra Inspecionar :

1. No projeto primário original, abra a página Branches .
2. Consulte a branch de recuperação para encontrar as transações que não replicaram para o secundário antes da interrupção. Uma Branch de recuperação é uma Branch comum, então você a query da mesma forma que query qualquer outra Branch.
3. Reconcilie os dados manualmente. O Lakebase não faz merge automaticamente de uma branch de recuperação de volta para sua branch de produção, porque só você sabe como os dados divergiram. Consulte Como reconciliar.
4. Exclua a branch de recuperação quando você terminar.

Branch de recuperação nunca são excluídas automaticamente. Lakebase preserva a história de divergência até que você exclua a Branch por conta própria.

Como reconciliar

Uma branch de recuperação contém seus dados como existiam no Primário original no momento do failover, incluindo as transações que ainda não haviam sido replicadas. Sua branch de produção contém os dados que foram replicados e quaisquer gravações feitas após o failover. Reconciliação significa encontrar o que está apenas na branch de recuperação e decidir o que fazer com isso.

A Branch de recuperação e sua Branch de produção são bancos de dados separados com seus próprios Endpoints, para que você os compare em vez de query-los. Algumas maneiras de encontrar os dados divergentes:

• Observe as linhas mais recentes. As transações não replicadas são as últimas gravadas antes da interrupção, então as linhas recentes são onde a divergência se concentra. Se suas tabelas tiverem uma coluna de Timestamp, faça uma query na Branch de recuperação para linhas gravadas nos minutos que antecedem o failover.
• Compare as marcas d'água mais altas. Para tabelas com uma sequência ou ID de incremento, compare o valor máximo na Branch de recuperação com a sua Branch de produção. Um valor mais alto na Branch de recuperação aponta para linhas que nunca foram replicadas.
• **Compare as contagens de linha.** Uma tabela com mais linhas na branch de recuperação do que na de produção possui inserções não replicadas para investigar.

Depois de identificar as linhas divergentes, decida por tabela como reconciliá-las: reinserir linhas ausentes na produção, reaplicar atualizações ou descartar intencionalmente as alterações que você não deseja.

Desabilitar a recuperação de desastres

Um administrador de projeto desativa a recuperação de desastres do projeto primário, no Workspace Primário, no mesmo local onde você a ativou.

1. No Workspace Primário, abra seu projeto e selecione Configurações .
2. Na seção **Replicação entre Workspace**, selecione **Desativar replicação**.

A desativação exclui o grupo de replicação e interrompe a replicação. Posteriormente, você mantém o acesso ao projeto somente no Workspace Primário. O projeto secundário é removido do Workspace Secundário.

Mais recursos

• Recuperação de desastres — conceitos, comportamento de failover e o que não é compatível.
• Alta disponibilidade — failover automático na região
• Gerenciar permissões de projeto — a CAN_MANAGE ACL necessária para gerenciar a recuperação de desastres.