Basculement d’objets de compte¶

Cette rubrique décrit les étapes nécessaires au basculement d’objets de compte répliqués sur plusieurs comptes appartenant à différentes régions pour la récupération après sinistre.

Conditions préalables¶

Activez la réplication pour un groupe de basculement principal dans un ensemble de comptes.
Créez au moins un groupe de basculement secondaire (c’est-à-dire une réplique) du groupe de basculement principal dans un ou plusieurs comptes et actualisez régulièrement (c’est-à-dire synchronisez) la réplique avec les dernières mises à jour des objets du groupe de basculement.

Pour obtenir des instructions, voir Réplication des bases de données et des objets de compte sur plusieurs comptes.

Promotion d’un compte cible en tant que compte source¶

Pour promouvoir un compte cible en tant que compte source, vous devez vous connecter au compte cible que vous souhaitez promouvoir en tant que nouveau compte source et exécuter la commande ALTER FAILOVER GROUP … PRIMARY.

Promouvoir un groupe de basculement secondaire en groupe de basculement principal¶

Note

L’exemple de cette section doit être exécuté par un rôle doté du privilège FAILOVER.

L’exemple suivant promeut myaccount2 dans l’organisation myorg actuelle pour servir de compte source.

Connectez-vous à votre compte cible myaccount2.
Liste des groupes de basculement du compte :
```
SHOW FAILOVER GROUPS;
```
Copy
Exécutez l’instruction suivante pour chaque groupe de basculement secondaire que vous souhaitez promouvoir pour qu’il serve de groupe de basculement principal :
```
ALTER FAILOVER GROUP myfg PRIMARY;
```
Copy
Note

Lors d’une panne partielle dans votre région source, le service de réplication peut continuer à être disponible et à actualiser les groupes de basculement secondaires dans les régions cibles.

Pour garantir l’intégrité des données, Snowflake empêche le basculement si une opération d’actualisation est en cours. Cela signifie que vous ne pouvez pas promouvoir un groupe de basculement secondaire pour qu’il serve de groupe principal s’il est rafraîchi par une opération de réplication. La commande ALTER FAILOVER GROUP … PRIMARY renvoie une erreur dans ce cas.

Résolution de l’échec de l’instruction de basculement dû à une opération d’actualisation en cours¶

Si une opération d’actualisation est en cours pour le groupe de basculement secondaire que vous essayez de promouvoir, l’instruction de basculement entraîne l’erreur suivante :

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.

Pour réussir le basculement, vous devez suivre les étapes suivantes.

Sélectionnez et complétez l’une des options suivantes :

Important

La suspension 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. Pour plus d’informations, voir Voir la phase actuelle d’une opération d’actualisation en cours.
1. Suspendez les futures opérations d’actualisation pour le groupe de basculement. Si une opération d’actualisation est en cours, vous devez attendre qu’elle se termine avant de procéder au basculement :
  ALTER FAILOVER GROUP myfg SUSPEND;
  Copy
2. Suspendez les futures opérations d’actualisation et annulez une opération d’actualisation planifiée en cours (s’il y en a une).
  
  Si l’opération d’actualisation en cours a été déclenchée manuellement, voir Annuler une opération d’actualisation en cours qui n’a pas été automatiquement planifiée.
  ALTER FAILOVER GROUP myfg SUSPEND IMMEDIATE;
  Copy
  Note
  
  Il se peut qu’il y ait un léger délai entre le moment où l’instruction est renvoyée et le moment où l’annulation de l’opération d’actualisation est terminée.

Vérifiez qu’aucune opération d’actualisation n’est en cours pour le groupe de basculement myfg. La requête suivante ne devrait donner aucun résultat :

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

Pour voir les opérations d’actualisation annulées pour le groupe de basculement myfg, vous pouvez exécuter l’instruction suivante :

SELECT phase_name, start_time, job_uuid
  FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_HISTORY('myfg'))
  WHERE phase_name = 'CANCELED';

Copy

Vous pouvez maintenant promouvoir le groupe de basculement secondaire myfg en groupe de basculement principal :
```
ALTER FAILOVER GROUP myfg PRIMARY;
```
Copy

Reprendre la réplication programmée dans les comptes cibles¶

Lors du basculement, les actualisations planifiées sur tous les groupes de basculement secondaires sont suspendues. ALTER FAILOVER GROUP … RESUME doit être exécuté sur chaque compte cible avec un groupe de basculement secondaire pour reprendre les actualisations automatiques.

ALTER FAILOVER GROUP myfg RESUME;

Copy

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.

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

Copy

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 :

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

Rouvrez les canaux actifs de la table en appelant l’API openChannel.
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.
Réinsérez les lignes de données pour le canal à partir des jetons de décalage récupérés.

Snowpipe Streaming et le connecteur Kafka¶

Si vous utilisez le connecteur Kafka et Snowpipe Streaming, suivez ces étapes après le basculement :

Mettez à jour la configuration du connecteur Kafka pour qu’il pointe vers le compte source qui vient d’être promu.
Exécutez la commande SHOW CHANNELS pour récupérer la liste des canaux actifs et les jetons de décalage. Chaque canal appartient à une seule partition du sujet Kafka.
Réinitialisez manuellement les décalages dans le thème Kafka pour chacune de ces partitions (canaux).
Redémarrez le connecteur Kafka.

Pour plus d’informations, reportez-vous à :