Basculement d’objets de compte¶

Prerequisites¶

1. Activez la réplication dans un ensemble de comptes au sein de la même organisation, dans plusieurs régions d’un fournisseur de services Cloud ou entre différents fournisseurs de services Cloud.

2. Créez un groupe de basculement principal qui définit les types d’objets à répliquer et spécifie les comptes cibles vers lesquels effectuer la réplication. Vous pouvez éventuellement répartir les objets répliqués sur plusieurs groupes de basculement, par exemple si certaines bases de données doivent être répliquées plus fréquemment que d’autres.

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

4. Actualisez (synchronisez) chaque réplique avec les dernières mises à jour des objets du groupe de basculement. Effectuez une actualisation initiale et mettez en place un calendrier pour apporter régulièrement les dernières modifications à chaque compte secondaire.

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.