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.

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 que ela sirva como conta de origem, você deve entrar na conta de destino que deseja promover para servir como a nova conta de origem e executar 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.

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;
```
Copy
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;
```
Copy
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.
1. 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;
  Copy
2. 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;
  Copy
  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';

Copy

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';

Copy

Agora você pode promover o grupo de failover secundário myfg para o grupo de failover primário:
```
ALTER FAILOVER GROUP myfg PRIMARY;
```
Copy

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;

Copy

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.

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')
  );

Copy

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:
1. 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;
  Copy
  Use a coluna QUERY_TEXT para identificar o QUERY_ID para operações de atualização de grupo de failover da lista.
2. 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';
  Copy
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>');
```
Copy
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:
1. Chame a getLatestCommittedOffsetToken API ou
2. 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: