Failover de objetos de conta¶

Prerequisites¶

1. Habilite a replicação em um conjunto de contas dentro da mesma organização, em várias regiões em um provedor de serviços em nuvem ou em diferentes provedores de serviços em nuvem.

2. Crie um grupo de failover primário que defina os tipos de objetos a serem replicados e especifique as contas de destino para as quais replicar. Opcionalmente, você pode dividir os objetos replicados em vários grupos de failover, por exemplo, se alguns bancos de dados precisarem ser replicados com mais frequência do que outros.

3. Create at least one secondary failover group (replica) of each primary failover group in one or more secondary accounts.

4. Atualize (sincronize) cada réplica com as atualizações mais recentes dos objetos no grupo de failover. Execute uma atualização inicial e configure um cronograma para trazer regularmente as alterações mais recentes para cada conta secundária.

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.

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.

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:

1. 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

2. 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.
   

3. 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:

1. Reabra canais ativos da tabela chamando a API openChannel.

2. 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.

3. Reinsira as linhas de dados para o canal dos tokens offset buscados.