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

  1. Activez la réplication pour un groupe de basculement principal dans un ensemble de comptes.

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

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

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.

Snowpipe Streaming et le connecteur Kafka

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

  1. Mettez à jour la configuration du connecteur Kafka pour qu’il pointe vers le compte source qui vient d’être promu.

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

  3. Réinitialisez manuellement les décalages dans le thème Kafka pour chacune de ces partitions (canaux).

  4. Redémarrez le connecteur Kafka.

Pour plus d’informations, reportez-vous à :

Langage: Français