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 (réplique) du groupe de basculement principal dans un ou plusieurs comptes et actualisez (synchronisez) régulièrement 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.
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.
Pour plus d’informations sur le basculement, voir Groupes de réplication et groupes de basculement.
Promouvoir un compte cible en tant que compte source à l’aide de Snowsight¶
Note
Seuls les administrateurs de comptes peuvent modifier un groupe de réplication ou de basculement à l’aide de Snowsight (reportez-vous à Limites de l’utilisation de Snowsight pour la configuration de la réplication).
Pour promouvoir un compte cible en tant que compte source, vous devez être connecté au compte cible.
Connectez-vous à Snowsight et naviguez jusqu’à Admin » Accounts.
Sélectionnez Replication, puis sélectionnez Groups.
Localisez le groupe de basculement que vous souhaitez promouvoir et sélectionnez le menu More (…) dans la dernière colonne de la ligne.
Sélectionnez Fail over, puis Fail over dans la fenêtre de confirmation.
Promouvoir un compte cible pour qu’il serve de compte source à l’aide de SQL¶
Pour promouvoir un compte cible en tant que compte source à l’aide de SQL, vous devez vous connecter au compte cible 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;
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;
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.
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;
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;
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';
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';
Vous pouvez maintenant promouvoir le groupe de basculement secondaire
myfg
en groupe de basculement principal :ALTER FAILOVER GROUP myfg PRIMARY;
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;
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')
);
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 :
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;
Utilisez la colonne QUERY_TEXT pour identifier dans l’QUERY_ID pour les opérations d’actualisation du groupe de basculement.
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';
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>');
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 :
Appelez l’API getLatestCommittedOffsetToken ou
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.
Note
Ces étapes s’appliquent uniquement à Snowpipe Streaming avec le SDK Snowflake Ingest ; elles ne s’appliquent pas à Snowpipe Streaming avec le connecteur Kafka. Suivez les étapes ci-dessous pour redémarrer Kafka Connector après le basculement.
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 à :