Basculement d’objets de compte¶

Prerequisites¶

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

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

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

4. 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 Réplication d’objets de compte et de bases de données.

Promouvoir un compte cible pour qu’il serve de compte source¶

Vous pouvez promouvoir un compte cible pour qu’il serve de compte source (basculement) en utilisant l”Snowsight ou SQL.

For more information about the kinds of objects you can specify in a failover group, see Groupes de réplication et groupes de basculement.

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;

Voir la phase actuelle d’une opération d’actualisation en cours¶

Une opération d’actualisation peut être annulée en toute sécurité pendant la plupart des phases de l’opération d’actualisation. Toutefois, l’annulation d’une opération d’actualisation au cours de la phase SECONDARY_DOWNLOADING_METADATA ou SECONDARY_DOWNLOADING_DATA peut entraîner un état incohérent sur le compte cible. Si l’opération d’actualisation a démarré l’une de ces phases, elle se poursuit jusqu’à son terme, quelle que soit la disponibilité du compte source. En laissant la phase se terminer avant de basculer, vous vous assurez que les répliques sont dans un état cohérent. Une fois que les répliques sont dans un état cohérent, vous pouvez reprendre ou rejouer vos pipelines d’ingestion et de transformation pour mettre à jour les répliques à l’état actuel.

Pour voir la phase actuelle d’une opération d’actualisation en cours pour un groupe de basculement, utilisez la fonction de table Information Schema REPLICATION_GROUP_REFRESH_PROGRESS, REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB, REPLICATION_GROUP_REFRESH_PROGRESS_ALL.

Par exemple, pour voir la phase actuelle d’une opération d’actualisation en cours pour le groupe de basculement myfg, exécutez l’instruction suivante :

SELECT phase_name, start_time, end_time
  FROM TABLE(
    INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_PROGRESS('myfg')
  );

Pour obtenir la liste des phases des opérations d’actualisation, consultez les notes sur l’utilisation de la fonction.

Annuler une opération d’actualisation en cours qui n’a pas été automatiquement planifiée¶

Pour annuler une opération d’actualisation en cours qui n’a pas été déclenchée automatiquement par une planification de réplication, vous devez utiliser la fonction SYSTEM$CANCEL_QUERY :

1. Recherchez l’ID ou l’JOB_UUID de requête pour exécuter les opérations d’actualisation en utilisant l’une des options suivantes :

   1. Recherchez les IDs de requête pour toutes les opérations d’actualisation en cours :

      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

      Utilisez la colonne QUERY_TEXT pour identifier dans l’QUERY_ID pour les opérations d’actualisation du groupe de basculement.

   2. Trouvez l’JOB_UUID pour une opération d’actualisation en cours pour un groupe de basculement spécifique 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. Annulez l’opération d’actualisation en utilisant la fonction SYSTEM$CANCEL_QUERY et la fonction QUERY_ID ou JOB_UUID :

   SELECT SYSTEM$CANCEL_QUERY('<QUERY_ID | JOB_UUID>');
   

   Copy

   Renvoie les résultats suivants :

   query [<QUERY_ID>] terminated.
   

3. Après avoir annulé l’opération d’actualisation en cours, passez aux étapes suivantes.

Rouvrir des canaux actifs pour Snowpipe Streaming dans le nouveau compte source promu¶

Les tables d’une base de données primaire qui sont alimentées par Snowpipe Streaming sont répliquées dans les bases de données secondaires. Après le basculement, rouvrez les canaux Snowpipe Streaming actifs pour les tables et réinsérez toutes les lignes de données manquantes pour les canaux :

1. Rouvrez les canaux actifs de la table en appelant l’API openChannel.

2. Récupérer les jetons de décalage :

   1. Appelez l’API getLatestCommittedOffsetToken ou

   2. Exécutez la commande SHOW CHANNELS pour récupérer la liste des canaux actifs de la table.

3. Réinsérez les lignes de données pour le canal à partir des jetons de décalage récupérés.