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.

Dans ce chapitre :

Conditions préalables
Promotion d’un compte cible en tant que compte source
- Promouvoir un groupe de basculement secondaire en groupe de basculement principal
- Reprise de la réplication programmée dans les comptes cibles
Réouverture des canaux actifs pour Snowpipe Streaming dans le compte source venant d’être promu
- Snowpipe Streaming et le connecteur Kafka

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 objets du compte.

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

Pour promouvoir un compte cible en tant que compte source, exécutez 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.

Pour obtenir des instructions sur la création d’un rôle personnalisé avec un ensemble spécifique de privilèges, voir Création de rôles personnalisés.

Pour des informations générales sur les rôles et les privilèges accordés pour effectuer des actions SQL sur des objets sécurisables, voir Aperçu du contrôle d’accès.

L’exemple suivant promeut myaccount2 dans l’organisation myorg actuelle pour servir de compte source pour la réplication des objets spécifiés dans le groupe de basculement myfg.

Exécution depuis le compte myaccount2 :
ALTER FAILOVER GROUP myfg PRIMARY;
Copy

Reprise de 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

Réouverture des canaux actifs pour Snowpipe Streaming dans le compte source venant d’être 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 à :