Failover de objetos de conta¶
Este tópico descreve as etapas necessárias para fazer o failover de objetos de conta replicados em múltiplas contas em diferentes regiões para a recuperação de desastres.
Neste tópico:
Pré-requisitos¶
Habilite a replicação para um grupo de failover primário em um conjunto de contas.
Crie pelo menos um grupo de failover secundário (ou seja, réplica) do grupo de failover primário em uma ou mais das contas e atualize regularmente (ou seja, sincronize) a réplica com as últimas atualizações dos objetos no grupo de failover.
Para obter instruções, consulte Replicação de bancos de dados e objetos de conta em diversas contas.
Promoção de uma conta de destino para servir como conta de origem¶
Para promover uma conta de destino para servir como conta de origem, execute o comando ALTER FAILOVER GROUP … PRIMARY.
Promoção de um grupo secundário de failover para um grupo primário de failover¶
Nota
O exemplo nesta seção deve ser executado por uma função com o privilégio FAILOVER.
Para instruções sobre como criar uma função personalizada com um conjunto específico de privilégios, consulte Criação de funções personalizadas.
Para informações gerais sobre concessões de funções e privilégios para executar ações de SQL em objetos protegíveis, consulte Visão geral do controle de acesso.
O exemplo a seguir promove myaccount2
na organização myorg
atual para servir como a conta de origem para replicação dos objetos especificados no grupo de failover myfg
.
Executado a partir da conta
myaccount2
:ALTER FAILOVER GROUP myfg PRIMARY;
Retomada de replicação programada em contas de destino¶
No failover, as atualizações programadas em todos os grupos de failover secundários são suspensas. ALTER FAILOVER GROUP … RESUME deve ser executado em cada conta de destino com um grupo de failover secundário para retomar as atualizações automáticas.
ALTER FAILOVER GROUP myfg RESUME;
Reabertura de canais ativos para Snowpipe Streaming na conta de origem recém-promovida¶
Tabelas em um banco de dados primário que são preenchidas pelo Snowpipe Streaming são replicadas para bancos de dados secundários. Após o failover, reabra os canais do Snowpipe Streaming ativos para tabelas e insira novamente todas as linhas de dados ausentes para os canais:
Reabra canais ativos da tabela chamando a API openChannel.
Buscar tokens de compensação:
Chame a getLatestCommittedOffsetToken API ou
Execute o comando SHOW CHANNELS para recuperar uma lista dos canais ativos da tabela.
Reinsira as linhas de dados para o canal dos tokens offset buscados.
Snowpipe Streaming e o conector Kafka¶
Se você estiver usando o conector Kafka e o Snowpipe Streaming, siga estas etapas após o failover:
Atualize a configuração do conector Kafka para apontar para a conta de origem recém-promovida.
Execute o comando SHOW CHANNELS para recuperar a lista de canais ativos e os tokens offset. Cada canal pertence a uma única partição no tópico Kafka.
Redefina manualmente os offsets no tópico Kafka para cada uma dessas partições (canais).
Reinicie o conector Kafka.
Para obter mais informações, consulte: