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.
For information about the purpose of the failover mechanism and when to use it, see Introdução à continuidade dos negócios e recuperação de desastres.
Prerequisites¶
Enable replication in a set of accounts within the same organization, across multiple regions in one cloud service provider or across different cloud service providers.
Create a primary failover group that defines the kinds of objects to replicate, and specifies the target accounts to which to replicate. You can optionally divide the replicated objects across multiple failover groups, for example if some databases should be replicated more frequently than others.
Create at least one secondary failover group (replica) of each primary failover group in one or more secondary accounts.
Refresh (synchronize) each replica with the latest updates to the objects in the failover group. Perform an initial refresh, and set up a schedule to regularly bring the latest changes to each secondary account.
For instructions, see Replicação de objetos de conta e bancos de dados.
Promoção de uma conta de destino para servir como conta de origem¶
É possível promover uma conta de destino para servir como conta de origem (failover) usando o Snowsight ou SQL.
For more information about the kinds of objects you can specify in a failover group, see Grupos de replicação e grupos de failover.
Promote a target account to serve as the source account using Snowsight¶
Nota
Only account administrators can edit a replication or failover group using Snowsight (see Limitações do uso do Snowsight para configuração de replicação).
For the most consistent and reliable failover experience, select all the applicable failover groups and connections and promote them all at the same time. We refer to this operation as a bulk failover.
To promote a target account to serve as the source account using Snowsight, follow these steps:
Sign in to Snowsight. Make sure to sign in using the target account.
No menu de navegação, selecione Admin » Accounts.
Select Replication, then select Initiate failover. Doing so brings up a dialog where you make the remaining choices.
Select any failover groups to promote. After the failover, the objects specified in those failover groups become writable on the newly promoted primary account. Those objects become read-only on the account that formerly was the primary and is now a secondary account.
Select Next.
Select any connections to promote. After the failover, those connections connect to the account that you’re promoting to be the new primary account.
Select Next.
Select Fail over in the confirmation window.
If any refresh operations are in progress for the failover groups you selected, you can wait for those refreshes to complete, or choose an alternative approach if your failover is urgent and should take priority.
The default action is to wait for the refreshes to complete. That way, the primary and secondary systems are all in a consistent state when the bulk failover runs. Snowflake uses your currently selected warehouse to poll the status of the ongoing refreshes. If you don’t have a selected warehouse, you select one now using the Select warehouse option.
Or, you can proceed with the failover immediately by selecting Show advanced options.
To fail over only the failover groups that aren’t currently being refreshed, select Exit with current progress. In that case, you perform additional refreshes later for the groups that were skipped during the bulk failover.
To cancel the refresh operations and continue the failover, select Cancel refreshes and force failover. In that case, you might need to clean up any inconsistencies on the secondary system from the interrupted refreshes.
If the failover operation didn’t complete for all failover groups, you can perform another bulk failover. Or you can fail over the remaining failover groups one at a time, using the procedure in Promote a single failover group to serve as the primary using Snowsight.
Promote a single failover group to serve as the primary using Snowsight¶
Nota
Only account administrators can edit a replication or failover group using Snowsight (see Limitações do uso do Snowsight para configuração de replicação).
To promote a single failover group to be the primary using Snowsight, follow these steps:
Sign in to Snowsight. Make sure to sign in using the target account.
No menu de navegação, selecione Admin » Accounts.
Selecione Replication e depois selecione Groups.
Localize o grupo de failover que deseja promover e selecione o menu More (…) na última coluna da linha.
Selecione Fail over e selecione Fail over na janela de confirmação.
Dica
You typically use this procedure if you encounter a problem failing over one group, and you need to retry the failover only for that group. To promote an entire account to be the primary, select multiple failover groups and connections and perform a bulk failover. For more information, see Promote a target account to serve as the source account using Snowsight.
Promoção de uma conta de destino para servir como a conta de origem usando SQL¶
To promote a target account to serve as the source account using SQL, you sign in to the target account and execute the ALTER FAILOVER GROUP … PRIMARY command.
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.
O exemplo a seguir promove myaccount2 na organização myorg atual para servir como a conta de origem.
Entre na conta de destino
myaccount2.Liste os grupos de failover na conta:
SHOW FAILOVER GROUPS;
Execute a seguinte instrução para cada grupo de failover secundário que deseje promover para servir como o grupo de failover primário:
ALTER FAILOVER GROUP myfg PRIMARY;
Nota
Durante uma interrupção parcial em sua região de origem, o serviço de replicação pode continuar disponível e pode continuar atualizando os grupos de failover secundários nas regiões de destino.
Para garantir a integridade dos dados, o Snowflake evita o failover se uma operação de atualização estiver em andamento. Isso significa que você não pode promover um grupo de failover secundário para servir como primário se ele estiver sendo atualizado por uma operação de replicação. O comando ALTER FAILOVER GROUP … PRIMARY retorna um erro neste cenário.
Resolução de falha de instrução de failover devido a uma operação de atualização em andamento¶
Se houver uma operação de atualização em andamento para o grupo de failover secundário que você está tentando promover, a instrução de failover resultará no seguinte erro:
Replication group "<GROUP_NAME>" cannot currently be set as primary because it is being
refreshed. Either wait for the refresh to finish or cancel the refresh and try again.
Para executar o failover com sucesso, você deve concluir as seguintes etapas.
Selecione e complete uma das seguintes opções:
Importante
Suspender uma operação de atualização na fase SECONDARY_DOWNLOADING_METADATA ou SECONDARY_DOWNLOADING_DATA pode resultar em um estado inconsistente na conta de destino. Para obter mais informações, consulte Visualização da fase atual de uma operação de atualização em andamento.
Suspenda futuras operações de atualização para o grupo de failover. Se houver uma operação de atualização em andamento, você deverá aguardar sua conclusão antes de poder realizar o failover:
ALTER FAILOVER GROUP myfg SUSPEND;
Suspenda futuras operações de atualização e cancele uma operação de atualização agendada em andamento (se houver).
Se a operação de atualização em andamento foi acionada manualmente, consulte Cancelamento de uma operação de atualização em andamento que não foi agendada automaticamente.
ALTER FAILOVER GROUP myfg SUSPEND IMMEDIATE;
Nota
Você pode perceber um pequeno atraso entre o momento em que a instrução retorna e o momento em que o cancelamento da operação de atualização é concluído.
Verifique se não há nenhuma operação de atualização em andamento para o grupo de failover
myfg. A consulta a seguir não deve retornar resultados:SELECT phase_name, start_time, job_uuid FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_HISTORY('myfg')) WHERE phase_name <> 'COMPLETED' and phase_name <> 'CANCELED';
Para consultar as operações de atualização canceladas para o grupo de failover
myfg, você pode executar a seguinte instrução:SELECT phase_name, start_time, job_uuid FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_HISTORY('myfg')) WHERE phase_name = 'CANCELED';
Agora você pode promover o grupo de failover secundário
myfgpara o grupo de failover primário: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;
Visualização da fase atual de uma operação de atualização em andamento¶
Uma operação de atualização pode ser cancelada com segurança durante a maioria das fases da operação de atualização. No entanto, cancelar uma operação de atualização na fase SECONDARY_DOWNLOADING_METADATA ou SECONDARY_DOWNLOADING_DATA pode resultar em um estado inconsistente na conta de destino. Se a operação de atualização tiver iniciado uma dessas fases, ela prosseguirá até a conclusão, independentemente da disponibilidade da conta de origem. Permitir que a fase seja concluída antes do failover garante que as réplicas estejam em um estado consistente. Depois que as réplicas estiverem em um estado consistente, você pode retomar ou reproduzir seus pipelines de ingestão e transformação para atualizar as réplicas para o estado atual.
Para visualizar a fase atual de uma operação de atualização em andamento para um grupo de failover, use a função de tabela do Information Schema REPLICATION_GROUP_REFRESH_PROGRESS, REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB, REPLICATION_GROUP_REFRESH_PROGRESS_ALL.
Por exemplo, para visualizar a fase atual de uma operação de atualização em andamento para um grupo de failover myfg, execute a seguinte instrução:
SELECT phase_name, start_time, end_time
FROM TABLE(
INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_PROGRESS('myfg')
);
Para obter uma lista das fases das operações de atualização, consulte as notas de uso para a função.
Cancelamento de uma operação de atualização em andamento que não foi agendada automaticamente¶
Para cancelar uma operação de atualização em andamento que não tenha sido acionada automaticamente por um cronograma de replicação, você deve usar a função SYSTEM$CANCEL_QUERY:
Encontre o ID ou JOB_UUID da consulta para executar operações de atualização usando uma das seguintes opções:
Encontre os IDs da consulta para todas as operações de atualização em execução:
SELECT query_id, query_text FROM TABLE(INFORMATION_SCHEMA.QUERY_HISTORY()) WHERE query_type = 'REFRESH REPLICATION GROUP' AND execution_status = 'RUNNING' ORDER BY start_time;
Use a coluna QUERY_TEXT para identificar o QUERY_ID para operações de atualização de grupo de failover da lista.
Encontre o JOB_UUID para uma operação de atualização em andamento para um grupo de failover específico
myfg:SELECT phase_name, start_time, job_uuid FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_HISTORY('myfg')) WHERE phase_name <> 'COMPLETED' and phase_name <> 'CANCELED';
Cancele a operação de atualização usando a função SYSTEM$CANCEL_QUERY e o QUERY_ID ou JOB_UUID:
SELECT SYSTEM$CANCEL_QUERY('<QUERY_ID | JOB_UUID>');
A seguinte saída é retornada:
query [<QUERY_ID>] terminated.Após cancelar a operação de atualização em andamento, prossiga para as próximas etapas.
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.
Nota
Essas etapas se aplicam apenas ao Snowpipe Streaming com o Snowflake Ingest SDK; não se aplicam ao Snowpipe Streaming com o conector Kafka. Siga as etapas abaixo para reiniciar o Kafka Connector após o failover.
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.
For more information, see: