Réplication des bases de données et des objets de compte sur plusieurs comptes

Cette rubrique décrit les étapes nécessaires pour répliquer les objets et les données de compte entre les comptes Snowflake de la même organisation, et maintenir la synchronisation des objets et des données. La réplication de comptes peut se produire entre des comptes Snowflake dans différentes régions et entre des plateformes Cloud.

Note

Lorsque vous mettez à niveau un compte vers Business Critical Edition (ou une version supérieure), il peut s’écouler jusqu’à 12 heures avant que les fonctionnalités de basculement ne soient disponibles.

Dans ce chapitre :

Prise en charge de la région pour la réplication et le basculement/la récupération

Les clients peuvent répliquer dans toutes les régions d’un groupe de régions. Pour effectuer une réplication entre des régions de Groupes de régions différentes (par exemple, d’une région commerciale Snowflake à une région gouvernementale Snowflake), veuillez contacter l’assistance de Snowflake afin d’autoriser l’accès.

Transition de la réplication de base de données à la réplication par groupe

Les bases de données pour lesquelles la réplication a été activée à l’aide de ALTER DATABASE doivent avoir la réplication désactivée avant qu’elles puissent être ajoutées à un groupe de réplication ou de basculement.

Note

Exécutez les instructions SQL de cette section en utilisant le rôle ACCOUNTADMIN.

Étape 1. Désactiver la réplication pour une base de données pour laquelle la réplication a été autorisée

Exécutez la fonction SYSTEM$DISABLE_DATABASE_REPLICATION pour désactiver la réplication d’une base de données principale, ainsi que de toutes les bases de données secondaires qui lui sont liées, afin de l’ajouter à un groupe de réplication ou de basculement.

Exécutez l’instruction SQL suivante depuis le compte source avec la base de données principale :

SELECT SYSTEM$DISABLE_DATABASE_REPLICATION('mydb');
Copy

Étape 2. Ajouter la base de données à un groupe de basculement principal et créer un groupe de basculement secondaire

Une fois que vous avez réussi à désactiver la réplication pour une base de données, vous pouvez ajouter la base de données principale à un groupe de basculement dans le compte source.

Ensuite, créez un groupe de basculement secondaire dans le compte cible. Lorsque le groupe de basculement secondaire est actualisé dans le compte cible, la base de données précédemment secondaire sera automatiquement ajoutée en tant que membre du groupe de basculement secondaire et actualisée avec les modifications de la base de données principale.

Pour plus de détails sur la création de groupes de basculement principaux et secondaires, voir Workflow.

Note

Lorsque vous ajoutez une base de données précédemment répliquée à un groupe de réplication ou de basculement, Snowflake ne réplique pas à nouveau les données qui ont déjà été répliquées pour cette base de données. Seules les modifications depuis la dernière actualisation sont répliquées lorsque le groupe est actualisé.

Workflow

Les instructions SQL suivantes démontrent le flux de travail pour activer la réplication des objets de compte et de base de données et pour actualiser les objets. Chaque étape est examinée en détail ci-dessous.

Note

Les exemples suivants exigent que la réplication soit activée pour les comptes source et cible. Pour plus de détails, voir Condition préalable : activer la réplication des comptes dans l’organisation.

Exemples

Exécutez les instructions SQL suivantes dans votre client Snowflake préféré pour activer la réplication et le basculement des objets de compte et de base de données, et actualiser les objets.

Exécuter à partir du compte source

  1. Créez un rôle et accordez-lui le privilège CREATE FAILOVER GROUP. Cette étape est facultative :

    USE ROLE ACCOUNTADMIN;
    
    CREATE ROLE myrole;
    
    GRANT CREATE FAILOVER GROUP ON ACCOUNT
      TO ROLE myrole;
    
    Copy
  2. Créez un groupe de basculement dans le compte source et activez la réplication vers des comptes cibles spécifiques.

    Note

    • Si vous avez des bases de données à ajouter à un groupe de réplication ou de basculement qui ont été précédemment activées pour la réplication de base de données et le basculement à l’aide de ALTER DATABASE, suivez les instructions Transition de la réplication de base de données à la réplication par groupe (dans cette rubrique) avant de les ajouter à un groupe.

    • Pour ajouter une base de données à un groupe de basculement, le rôle actif doit avoir le privilège MONITOR sur la base de données. Pour plus de détails sur les privilèges de la base de données, voir Privilèges de base de données (dans une rubrique distincte).

    USE ROLE myrole;
    
    CREATE FAILOVER GROUP myfg
      OBJECT_TYPES = USERS, ROLES, WAREHOUSES, RESOURCE MONITORS, DATABASES
      ALLOWED_DATABASES = db1, db2
      ALLOWED_ACCOUNTS = myorg.myaccount2, myorg.myaccount3
      REPLICATION_SCHEDULE = '10 MINUTE';
    
    Copy

Exécuté sur le compte cible

  1. Créez un rôle dans le compte cible et accordez-lui le privilège CREATE FAILOVER GROUP. Cette étape est facultative :

    USE ROLE ACCOUNTADMIN;
    
    CREATE ROLE myrole;
    
    GRANT CREATE FAILOVER GROUP ON ACCOUNT
      TO ROLE myrole;
    
    Copy
  2. Créez un groupe de basculement dans le compte cible comme un réplica du groupe de basculement dans le compte source.

    Note

    S’il existe dans le compte cible des objets de compte (par exemple des utilisateurs ou des rôles) qui n’existent pas dans le compte source, reportez-vous à Réplication initiale des utilisateurs et des rôles avant de créer un groupe secondaire.

    USE ROLE myrole;
    
    CREATE FAILOVER GROUP myfg
      AS REPLICA OF myorg.myaccount1.myfg;
    
    Copy
  3. Actualisez manuellement le groupe de basculement secondaire. Il s’agit d’une étape facultative. Si le groupe de basculement primaire est créé avec un plan de réplication, le rafraîchissement initial du groupe de basculement secondaire est automatiquement exécuté lors de la création du groupe de basculement secondaire.

    1. Créez un rôle avec le privilège REPLICATE sur le groupe de basculement. Cette étape est facultative.

      Exécution dans le compte cible à l’aide d’un rôle doté du privilège OWNERSHIP sur le groupe de basculement :

      GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;
      
      Copy
    2. Exécutez l’instruction d’actualisation à l’aide d’un rôle doté du privilège REPLICATE :

      USE ROLE my_replication_role;
      
      ALTER FAILOVER GROUP myfg REFRESH;
      
      Copy

Réplication d’objets de compte et de bases de données

Les instructions de cette section expliquent comment préparer vos comptes pour la réplication, activer la réplication d’objets spécifiques du compte source vers le compte cible, et synchroniser les objets dans le compte cible.

Important

Les comptes cibles n’ont pas Tri-Secret Secure ou une connectivité privée au service Snowflake (par exemple AWS PrivateLink) activé par défaut. Si vous avez besoin de Tri-Secret Secure ou d’une connectivité privée au service Snowflake à des fins de conformité, de sécurité ou à d’autres fins, il est de votre responsabilité de configurer et d’activer ces fonctionnalités dans le compte cible.

Condition préalable : activer la réplication des comptes dans l’organisation

L’administrateur de l’organisation (rôle ORGADMIN) doit activer la réplication pour les comptes source et cible.

Pour activer la réplication pour les comptes, un utilisateur ayant le rôle ORGADMIN utilise la fonction SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER pour définir le paramètre ENABLE_ACCOUNT_DATABASE_REPLICATION sur true. Notez que plusieurs comptes dans une organisation peuvent être activés pour la réplication à partir du même compte ORGADMIN.

Connectez-vous à un compte ORGADMIN pour activer la réplication pour chaque compte source et cible de votre organisation.

USE ROLE ORGADMIN;

-- View the list of the accounts in your organization
-- Note the organization name and account name for each account for which you are enabling replication
SHOW ORGANIZATION ACCOUNTS;

-- Enable replication by executing this statement for each source and target account in your organization
SELECT SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER('<organization_name>.<account_name>', 'ENABLE_ACCOUNT_DATABASE_REPLICATION', 'true');
Copy

Bien que la fonction SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER prenne en charge l’ancien identificateur de localisateur de compte , elle donne des résultats inattendus lorsqu’une organisation possède plusieurs comptes qui partagent le même localisateur (dans différentes régions).

Étape 1 : Créer un rôle avec le privilège CREATE FAILOVER GROUP dans le compte source — Facultatif

Créez un rôle et accordez-lui le privilège CREATE FAILOVER GROUP. Cette étape est facultative. Si vous avez déjà créé ce rôle, passez à Étape 2 : Créer un groupe de basculement principal dans un compte source.

USE ROLE ACCOUNTADMIN;

CREATE ROLE myrole;

GRANT CREATE FAILOVER GROUP ON ACCOUNT
    TO ROLE myrole;
Copy

Étape 2 : Créer un groupe de basculement principal dans un compte source

Créez un groupe de basculement principal et activez la réplication et le basculement d’objets spécifiques du compte actuel (source) vers un ou plusieurs comptes cibles dans la même organisation.

Voir tous les comptes pour lesquels la réplication est activée

Pour récupérer la liste des comptes de votre organisation pour lesquels la réplication est activée, utilisez SHOW REPLICATION ACCOUNTS.

Exécutez l’instruction SQL suivante en utilisant le rôle ACCOUNTADMIN :

SHOW REPLICATION ACCOUNTS;
Copy

Renvoie :

+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| snowflake_region | created_on                    | account_name | account_locator | comment         | organization_name | is_org_admin |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_WEST_2    | 2020-07-15 21:59:25.455 -0800 | myaccount1   | myacctlocator1  |                 | myorg             | true         |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_EAST_1    | 2020-07-23 14:12:23.573 -0800 | myaccount2   | myacctlocator2  |                 | myorg             | false        |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_EAST_2    | 2020-07-25 19:25:04.412 -0800 | myaccount3   | myacctlocator3  |                 | myorg             | false        |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+

Voir la liste complète des IDs de région.

Afficher l’appartenance à un groupe de basculement et de réplication

Les objets de compte, de base de données et de partage ont des contraintes sur l’appartenance à un groupe. Avant de créer de nouveaux groupes ou d’ajouter des objets aux groupes existants, vous pouvez consulter la liste des groupes de basculement existants et les objets de chaque groupe.

Note

Seuls un administrateur de compte (utilisateur avec le rôle ACCOUNTADMIN) ou le propriétaire du groupe (rôle avec le privilège OWNERSHIP sur le groupe) peuvent exécuter les instructions SQL de cette section.

Voir tous les groupes de basculement liés au compte actuel et les types d’objets dans chaque groupe :

SHOW FAILOVER GROUPS;
Copy

Voir toutes les bases de données du groupe de basculement myfg :

SHOW DATABASES IN FAILOVER GROUP myfg;
Copy

Voir tous les partages du groupe de basculement myfg :

SHOW SHARES IN FAILOVER GROUP myfg;
Copy

Activer la réplication d’un compte source vers un compte cible

Vous pouvez créer un groupe de réplication ou de basculement en utilisant Snowsight ou SQL.

Note

Si vous avez des bases de données à ajouter à un groupe de réplication ou de basculement pour lesquelles la réplication de base de données est activée à l’aide de ALTER DATABASE, suivez les instructions Transition de la réplication de base de données à la réplication par groupe (dans cette rubrique) avant de les ajouter à un groupe.

Créer un groupe de réplication ou de basculement à l’aide de Snowsight

Note

  • Seuls les administrateurs de comptes peuvent créer 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).

  • Vous devez être connecté au compte cible en tant qu’utilisateur ayant le rôle ACCOUNTADMIN. Si ce n’est pas le cas, vous serez invité à vous connecter.

    Le compte source et le compte cible doivent tous les deux utiliser le même type de connexion (Internet public). Sinon, la connexion au compte cible échoue.

Effectuez les étapes suivantes pour créer un nouveau groupe de réplication ou de basculement :

  1. Connectez-vous à Snowsight et naviguez jusqu’à Admin » Accounts.

  2. Sélectionnez Replication, puis Groups.

  3. Sélectionnez + Add Group.

  4. Sélectionnez Target Account, puis sélectionnez Next.

  5. Dans la boîte Group Name, saisissez un nom pour le groupe qui réponde aux exigences suivantes :

    • doit commencer par un caractère alphabétique et ne peut pas contenir d’espaces ou de caractères spéciaux à moins que la chaîne d’identificateur soit délimitée par des guillemets doubles (p. ex. « Mon objet »). Les identificateurs entre guillemets doubles sont également sensibles à la casse.

      Pour plus d’informations, consultez Exigences relatives à l’identificateur.

    • Doit être unique pour tous les groupes de basculement et de réplication d’un compte.

  6. Choisissez Select Objects pour ajouter des objets de partage et de compte à votre groupe.

    Note

    Des objets de compte ne peuvent être ajoutés qu’à un seul groupe de réplication ou de basculement. Si un groupe de réplication ou de basculement comportant des objets de compte existe déjà dans votre compte, vous ne pouvez pas sélectionner ces objets.

  7. Choisissez Select Databases pour ajouter des objets de base de données à votre groupe.

  8. Sélectionnez Replication Frequency.

  9. Si le compte est de type Business Critical Edition ou supérieur, un groupe de basculement est créé par défaut. Vous pouvez choisir de créer un groupe de réplication à la place. Pour créer un groupe de réplication, sélectionnez Advanced Options, puis désélectionnez Enable Failover.

  10. Sélectionnez Start Replication pour créer le groupe de réplication.

    Si la création du groupe de réplication échoue, reportez-vous à Résoudre les problèmes liés à la création et à la modification des groupes de réplication à l’aide de Snowsight pour connaître les erreurs les plus courantes et savoir comment les résoudre.

Créez un groupe de basculement à l’aide de SQL

Créez un groupe de basculement d’objets de compte et de base de données spécifiés dans le compte source et activez la réplication et le basculement vers une liste de comptes cibles. Pour plus d’informations sur la syntaxe, voir CREATE FAILOVER GROUP.

Par exemple, activez la réplication d’utilisateurs, de rôles, d’entrepôts, de moniteurs de ressources et de bases de données db1 et db2 du compte source vers le compte myaccount2 dans la même organisation. Définissez la planification de réplication pour actualiser automatiquement myaccount2 toutes les 10 minutes.

Exécutez l’instruction suivante sur le compte source :

USE ROLE myrole;

CREATE FAILOVER GROUP myfg
    OBJECT_TYPES = USERS, ROLES, WAREHOUSES, RESOURCE MONITORS, DATABASES, INTEGRATIONS, NETWORK POLICIES
    ALLOWED_DATABASES = db1, db2
    ALLOWED_INTEGRATION_TYPES = API INTEGRATIONS
    ALLOWED_ACCOUNTS = myorg.myaccount2
    REPLICATION_SCHEDULE = '10 MINUTE';
Copy

Étape 3 : Créer un rôle avec le privilège CREATE FAILOVER GROUP dans le compte cible — Facultatif

Créez un rôle dans le compte cible et accordez-lui le privilège CREATE FAILOVER GROUP. Cette étape est facultative. Si vous avez déjà créé ce rôle, passez à Étape 4 : Créer un groupe de basculement secondaire dans le compte cible.

USE ROLE ACCOUNTADMIN;

CREATE ROLE myrole;

GRANT CREATE FAILOVER GROUP ON ACCOUNT
    TO ROLE myrole;
Copy

Étape 4 : Créer un groupe de basculement secondaire dans le compte cible

Note

S’il existe dans le compte cible des objets de compte (par exemple des utilisateurs ou des rôles) qui n’existent pas dans le compte source, reportez-vous à Réplication initiale des utilisateurs et des rôles avant de créer un groupe secondaire.

Créez un groupe de basculement secondaire dans le compte cible en tant que réplica du groupe de basculement principal dans le compte source.

Exécutez une instruction CREATE FAILOVER GROUP … AS REPLICA OF dans chaque compte cible pour lequel vous avez activé la réplication dans Étape 2 : Créer un groupe de basculement principal dans un compte source (dans cette rubrique).

Exécution à partir de chaque compte cible :

USE ROLE myrole;

CREATE FAILOVER GROUP myfg
  AS REPLICA OF myorg.myaccount1.myfg;
Copy

Étape 5 : Actualiser manuellement un groupe de basculement secondaire dans le compte cible — Facultatif

Pour actualiser manuellement les objets d’un compte cible, exécutez la commande ALTER FAILOVER GROUP … REFRESH.

Nous vous recommandons de planifier vos actualisations secondaires en définissant le paramètre REPLICATION_SCHEDULE à l’aide de CREATE FAILOVER GROUP ou ALTER FAILOVER GROUP.

Note

Si l’utilisateur qui appelle la fonction dans le compte cible a été détruit dans le compte source, l’opération d’actualisation échoue.

Accorder le privilège REPLICATE sur le groupe de basculement au rôle — Facultatif

Pour exécuter la commande d’actualisation d’un groupe de réplication ou de basculement secondaire dans le compte cible, vous devez utiliser un rôle doté du privilège REPLICATE sur le groupe de basculement. Le privilège REPLICATE est actuellement non répliqué et doit être accordé à un groupe de basculement (ou de réplication) dans les comptes source et cible.

Exécution de cette instruction à partir du compte source en utilisant un rôle doté du privilège OWNERSHIP sur le groupe :

GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;
Copy

Exécution de cette instruction à partir du compte cible en utilisant un rôle doté du privilège OWNERSHIP sur le groupe :

GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;
Copy

Actualiser manuellement un groupe de basculement secondaire

Par exemple, pour actualiser les objets du groupe de basculement myfg, exécutez l’instruction suivante à partir du compte cible :

USE ROLE my_replication_role;

ALTER FAILOVER GROUP myfg REFRESH;
Copy

Appliquer des IDs globaux à des objets créés par des scripts dans des comptes cibles

Si vous avez créé des objets de compte, par exemple des utilisateurs et des rôles, dans votre compte cible par un moyen autre que via la réplication (par exemple en utilisant des scripts), ces utilisateurs et rôles n’ont pas d’identificateur global par défaut. L’opération d’actualisation utilise des identificateurs globaux pour synchroniser ces objets avec les mêmes objets dans le compte source.

Dans la plupart des cas, lorsqu’un compte cible est actualisé à partir du compte source, l’opération d’actualisation détruit tous les objets de compte des types de la liste OBJECT_TYPES du compte cible qui n’ont pas d’identificateur global. La réplication initiale des utilisateurs et des rôles vers un compte cible peut toutefois entraîner l’échec de la première opération d’actualisation. Pour plus de détails sur ce comportement, reportez-vous à Réplication initiale des utilisateurs et des rôles.

Réplication initiale des utilisateurs et des rôles

Le comportement de l’opération d’actualisation initiale pour les types d’objets USERS et ROLES peut varier selon qu’il existe ou non des objets correspondants portant le même nom dans le compte cible.

Note

  • Le comportement décrit dans cette section ne s’applique que la première fois que ces types d’objets sont répliqués sur le compte cible.

  • Les scénarios ci-dessous décrivent la réplication de USERS. Il en va de même pour la réplication de ROLES.

  • S’il existe dans le compte cible des utilisateurs portant le même nom que des utilisateurs du compte source, l’opération d’actualisation initiale échoue et décrit les deux options à votre disposition pour continuer :

    • Forcer l’opération d’actualisation et permettre la suppression de tout utilisateur existant dans le compte cible. Les utilisateurs du compte source seront répliqués dans le compte cible.

      Pour forcer l’actualisation d’un groupe, utilisez le paramètre FORCE de la commande refresh. Par exemple, pour forcer l’actualisation d’un groupe de basculement, exécutez la commande suivante :

      ALTER FAILOVER GROUP <fg_name> REFRESH FORCE;
      
      Copy
    • Lier les objets du compte par leur nom. La fonction SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME relie les utilisateurs portant le même nom dans le compte cible et le compte source. Les utilisateurs du compte cible qui sont liés ne sont pas supprimés.

      Pour lier les comptes par leur nom, exécutez la commande suivante :

      SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('<rg_name>');
      
      Copy

      Note

      Tout utilisateur dans le compte cible qui n’a pas d’utilisateur correspondant dans le compte source avec le même nom est supprimé.

  • S’il n’y a aucun utilisateur dans le compte cible dont les noms correspondent à ceux des utilisateurs du compte source, l’opération d’actualisation initiale dans le compte cible supprime tous les utilisateurs. Cela peut entraîner les pertes de données et de métadonnées suivantes :

    • Si des USERS sont inclus dans la liste OBJECT_TYPES pour un groupe de réplication ou de basculement :

      • Les feuilles de calcul sont perdues.

      • L’historique des requêtes est perdu.

    • Si des USERS sont inclus dans la liste OBJECT_TYPES, mais pas de ROLES :

      • Les privilèges accordés aux utilisateurs sont perdus.

    • Si des ROLES sont inclus dans la liste OBJECT_TYPES :

      • Les privilèges accordés pour partager des objets sont perdus.

Pour éviter de supprimer des utilisateurs ou des rôles dans le compte cible :

  1. Dans le compte source, recréez manuellement les utilisateurs ou les rôles qui n’existent que dans le compte cible avant la réplication initiale.

  2. Dans le compte cible, reliez les objets correspondants portant le même nom dans les deux comptes à l’aide de la fonction SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME.

Configurer l’accès au stockage Cloud pour les intégrations de stockage secondaire

Si vous activez la réplication de l’intégration de stockage, vous devez prendre des mesures supplémentaires après la réplication de l’intégration de stockage sur les comptes cibles. L’intégration répliquée possède sa propre entité de gestion des identités et des accès (IAM) qui est différente de l’identité et de l’entité IAM de l’intégration principale. Par conséquent, vous devez mettre à jour les autorisations de votre fournisseur Cloud afin d’accorder à l’intégration répliquée l’accès à votre stockage sur le Cloud.

Vous ne devez configurer cette relation de confiance sur les comptes cibles qu’une seule fois.

Le processus est similaire à l’attribution d’un accès au compte source. Pour plus d’informations, consultez les pages suivantes :

Configuration de l’actualisation automatique des tables de répertoire dans les zones de préparation secondaires

Si vous répliquez une zone de préparation externe avec une table de répertoire et que vous avez configuré l’actualisation automatique pour la table de répertoire source, vous devez prendre des mesures pour configurer l’actualisation automatique de la table de répertoire secondaire.

La procédure est similaire à la mise en place de l’actualisation automatique dans votre compte source. Pour plus d’informations, voir ce qui suit :

Important

  • Après avoir effectué ces étapes de configuration dans votre compte cible, vous devez procéder à une actualisation complète de votre table de répertoire afin de vous assurer qu’aucune notification n’a été omise.

  • Pour Google Cloud Storage et Azure Blob Storage, le nom de l’intégration de notification dans chaque compte cible doit correspondre au nom de l’intégration de notification dans le compte source.

Configurer les notifications pour les canaux secondaires d’intégration automatique

Vous devez prendre des mesures supplémentaires pour configurer les notifications Cloud pour les canaux d’intégration automatique secondaires avant le basculement. Cette section explique pourquoi cette configuration supplémentaire est nécessaire et comment la compléter pour chaque fournisseur Cloud pris en charge.

Amazon S3

Le processus de configuration dépend de la manière dont vous avez configuré les notifications d’événements. Par exemple, supposons que vous ayez un canal d’intégration automatique qui s’appuie sur un sujet Amazon Simple Notification Service (SNS) pour publier des messages sur l’emplacement de la zone de préparation Snowflake.

Lorsque vous répliquez le canal vers un compte cible, Snowflake crée automatiquement une nouvelle file d’attente Amazon Simple Queue Service (SQS). Vous devez abonner cette file d’attente SQS pour votre compte cible au sujet SNS pour recevoir des notifications sur l’emplacement de la zone de préparation.

Stockage d’objets blob Microsoft Azure

Un canal qui charge automatiquement des données à partir de fichiers situés sur une zone de préparation dans le stockage blob de Microsoft Azure nécessite un abonnement Event Grid, une file d’attente de stockage et une intégration de notification liée à la file d’attente de stockage. Un canal secondaire dans un compte cible nécessite un Event Grid distinct, une file d’attente de stockage et une intégration de notification liée à la file d’attente de stockage. Event Grid des comptes source et cible doit être configuré en tant que points de terminaison pour la même source Azure Storage.

Voir le diagramme ci-dessous pour les détails de la configuration :

Réplication de canal pour Azure

Créez un nouvel abonnement Event Grid et une nouvelle file d’attente de stockage. Ensuite, créez une nouvelle intégration de notification dans le compte cible et accordez à Snowflake l’accès à votre file d’attente de stockage. Pour obtenir des instructions, voir Configuration de l’automatisation avec Azure Event Grid.

Important

Le nom de l’intégration de notification dans chaque compte cible doit correspondre au nom de l’intégration de notification dans le compte source.

Zone de préparation externe pour Google Cloud Storage

Un canal qui charge automatiquement des données à partir de fichiers situés dans Google Cloud Storage nécessite un abonnement Google Pub/Sub et une intégration de notification qui fait référence à cet abonnement. Chaque canal répliqué dans un compte cible nécessite également un abonnement Google Pub/Sub et une intégration de notification qui fait référence à cet abonnement. L’abonnement Pub/Sub de chaque compte source et cible doit être souscrit au même sujet Pub/Sub qui reçoit les notifications de la source Google Cloud Storage.

Voir le diagramme ci-dessous pour les détails de la configuration :

Réplication de canal pour GCP
Créez un nouvel abonnement à votre rubrique Pub/Sub et une nouvelle intégration de notification dans votre compte cible.

Ensuite, accordez un accès à Snowflake à l’abonnement Pub/Sub Pour obtenir des instructions, voir Configuration de l’automatisation à l’aide de Pub/Sub GCS.

Important

Le nom de l’intégration de notification dans chaque compte cible doit correspondre au nom de l’intégration de notification dans le compte source.

Mise à jour du service distant pour les intégrations API

Si vous avez activé la réplication de l’intégration API, des étapes supplémentaires sont nécessaires après la réplication de l’intégration API sur le compte cible. L’intégration répliquée possède sa propre entité de gestion des identités et des accès (IAM) qui sont différents de l’identité et de l’entité IAM de l’intégration principale. Par conséquent, vous devez mettre à jour les autorisations sur le service distant pour accorder l’accès à des fonctions répliquées. Le processus est similaire à l’octroi d’accès à des fonctions sur le compte principal. Voir les liens ci-dessous pour plus de détails :

Surveillance de la réplication

Cette section fournit des informations sur la façon de surveiller la progression, l’historique et les coûts de réplication des comptes.

Surveiller la réplication à l’aide de Snowsight

Pour surveiller la progression et le statut de la réplication pour les groupes de réplication et de basculement dans une organisation, utilisez la page Replication dans Snowsight.

Vous pouvez voir le statut et les détails des opérations d’actualisation :

  • Voir le statut actuel de la dernière opération d’actualisation.

  • Voir le temps de latence de la réplique (temps écoulé depuis la dernière opération d’actualisation).

  • Voir la distribution des temps de latence des répliques entre les groupes.

  • Date et heure de la prochaine opération d’actualisation planifiée.

Note

  • Snowsight annonce les groupes de réplication et de basculement pour lesquels votre rôle dispose du privilège MONITOR, OWNERSHIP, ou REPLICATE.

  • Les détails de l’opération d’actualisation ne sont accessibles qu’aux utilisateurs ayant le rôle ACCOUNTADMIN ou le privilège OWNERSHIP sur le groupe.

  • Vous devez être connecté au compte cible pour voir les détails de l’opération d’actualisation. Si ce n’est pas le cas, vous serez invité à vous connecter.

    Le compte source et le compte cible doivent tous les deux utiliser le même type de connexion (Internet public). Sinon, la connexion au compte cible échoue.

Pour voir le statut de réplication de chaque groupe de réplication ou de basculement, procédez comme suit :

  1. Connectez-vous à Snowsight et naviguez jusqu’à Admin » Accounts.

  2. Sélectionnez Replication puis Groups.

La page Groups affiche les détails de l’opération d’actualisation pour tous les groupes pour lesquels votre rôle dispose d’un privilège de vue. Vous pouvez utiliser les vignettes pour filtrer la vue.

  • Par exemple, si la vignette Status indique que des opérations d’actualisation ont échoué, vous pouvez sélectionner la vignette pour étudier le(s) groupe(s) présentant des échecs.

  • Le temps de latence dans la vignette Longest Replication lag fait référence à la durée écoulée depuis la dernière opération de rafraîchissement. Il s’agit de la durée pendant laquelle le groupe de réplication ou de basculement secondaire est en retard sur le groupe primaire. Le délai le plus long correspond à la durée écoulée depuis la dernière actualisation du groupe de réplication secondaire le plus ancien.

    Par exemple, si vous avez trois groupes de basculement, fg_1, fg_2, fg_3, avec des programmes de réplication indépendants de 10 minutes, 2 heures et 12 heures respectivement, le temps de latence le plus long peut atteindre 12 heures. Toutefois, si fg_3 a été récemment actualisé dans le compte cible, son temps de latence est remis à 0 et un autre groupe de basculement peut avoir un temps de latence plus long.

  • Vous pouvez sélectionner une barre individuelle dans la vignette Group Lag Distribution pour filtrer les résultats sur un groupe individuel.

Vous pouvez également filtrer les groupes en utilisant le champ de recherche ou les menus déroulants :

  • Vous pouvez effectuer une recherche par nom de groupe de réplication ou de basculement à l’aide de la boîte Icône de recherche (recherche).

  • Choisissez Type pour filtrer les résultats par groupe de réplication ou de basculement.

  • Choisissez Replicating pour filtrer par groupes primaires (sélectionnez To) ou secondaires (sélectionnez From).

  • Choisissez le menu Icône de compte (comptes) pour filtrer les résultats par nom de compte.

  • Choisissez Status pour filtrer les résultats en fonction du statut de l’opération d’actualisation :

    • Refresh Cancelled

    • Refresh Failed

    • Refresh In Progress

    • Refresh Successful

Vous pouvez consulter les détails suivants concernant vos groupes de réplication et de basculement :

Colonne

Description

Name

Nom du groupe de réplication ou de basculement.

Is Replicating

Indique si le groupe est répliqué vers un compte cible ou depuis un compte source.

Si cette colonne contient destinations disponibles, il n’y a pas de groupes de réplication ou de basculement secondaires. Le nombre de destinations disponibles indique le nombre de comptes cibles vers lesquels le groupe primaire peut être répliqué.

Status

Affiche le statut de la dernière opération d’actualisation.

Vous devez être connecté au compte cible pour accéder aux détails de la réplication. Si vous n’êtes pas connecté, sélectionnez Sign in pour voir le statut de l’opération d’actualisation pour le groupe secondaire.

Le compte source et le compte cible doivent tous les deux utiliser le même type de connexion (Internet public). Sinon, la connexion au compte cible échoue.

Replication Lag

Durée écoulée depuis la dernière opération d’actualisation. Il s’agit de la durée pendant laquelle le groupe de réplication secondaire est « en latence » par rapport au groupe de réplication primaire.

Next Refresh

Date et heure de la prochaine planification planifiée.

Vous pouvez sélectionner un groupe de réplication ou de basculement pour voir des informations détaillées sur chaque opération d’actualisation. Pour plus d’informations, consultez , la section sur l’historique de réplication dans Snowsight.

Surveiller la progression des opérations d’actualisation

Cette section fournit des informations sur la manière de surveiller la progression de la réplication pour un groupe de réplication ou de basculement spécifique.

Surveiller la progression des opérations d’actualisation à l’aide de Snowsight

Vous pouvez voir le statut d’une opération d’actualisation en cours et les détails des opérations d’actualisation historiques à l’aide de Snowsight.

  1. Connectez-vous à Snowsight et naviguez jusqu’à Admin » Accounts.

  2. Sélectionnez Replication, puis Groups.

  3. Sélectionnez le nom d’un groupe de réplication ou de basculement.

Pour plus d’informations sur la vue détaillée, consultez , la section sur l’historique de réplication dans Snowsight.

Surveiller la progression des opérations d’actualisation à l’aide de SQL

Pour surveiller la progression d’une actualisation de groupe de réplication ou de basculement, interrogez la fonction de table REPLICATION_GROUP_REFRESH_PROGRESS, REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB (dans le Schéma d’information de Snowflake).

Exemple

Visualiser la progression de l’opération d’actualisation la plus récente pour le groupe de basculement myfg :

SELECT phase_name, start_time, end_time, progress, details
  FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_PROGRESS('myfg'));
Copy

Affichage de l’historique de réplication

Vous pouvez voir l’historique de la réplication en utilisant Snowsight ou SQL.

Note

Vous pouvez voir l’historique de réplication des groupes de réplication et de basculement pour lesquels votre rôle dispose du privilège MONITOR, OWNERSHIP, ou REPLICATE.

Afficher l’historique de réplication à l’aide de Snowsight

Vous pouvez voir l’historique de la réplication et les détails de chaque opération d’actualisation pour un groupe de réplication ou de basculement spécifique dans la page de détails du groupe.

  1. Connectez-vous à Snowsight et naviguez jusqu’à Admin » Accounts.

  2. Sélectionnez Replication, puis Groups.

  3. Sélectionnez le nom d’un groupe de réplication ou de basculement.

Vous pouvez ensuite consulter les informations suivantes sur le groupe :

  • Type de groupe (groupe de réplication ou groupe de basculement).

  • Planification de la réplication (par exemple, toutes les 10 minutes).

  • Durée de chaque opération d’actualisation.

  • Temps de latence de la réplique (durée écoulée depuis la dernière opération d’actualisation).

  • Date et heure de la prochaine planification planifiée.

Vous pouvez filtrer les données de la page par statut et par période :

  • Choisissez Status pour filtrer les résultats en fonction du statut de l’opération d’actualisation :

    • Refresh Cancelled

    • Refresh Failed

    • Refresh In Progress

    • Refresh Successful

  • Choisissez Duration pour afficher les détails de l’opération d’actualisation :

    • Last hour

    • Last 24 hours

    • Last 7 days

    • All

    La sélection de All permet d’afficher les 14 derniers jours d’opérations d’actualisation.

Les détails de chaque opération d’actualisation comprennent les colonnes suivantes :

Colonne

Description

Query ID

Requête ID de l’opération d’actualisation.

Status

Affiche le statut de l’actualisation. Les valeurs valides incluent Successful, Failed, In Progress.

Ended

Date et heure de la fin de l’opération d’actualisation.

Duration

Durée de l’opération d’actualisation.

La période de durée est décomposée et codée par couleur par phase de réplication. La largeur de chaque segment coloré indique la portion de temps passée dans cette phase.

L’image ci-dessous est fournie à titre de référence uniquement. Ce graphique est disponible lorsque vous sélectionnez l’opération d’actualisation pour plus de détails.

Phase et durée de réplication codées en couleur.

Transferred

Le nombre d’octets répliqués.

Objects

Le nombre d’objets répliqués.

Sélectionnez une ligne pour voir des détails supplémentaires sur une opération d’actualisation spécifique :

  • Durée de chaque phase de réplication.

  • Message d’erreur (en cas d’échec des opérations d’actualisation).

  • Liste des objets de la base de données répliqués par type et par nombre.

  • Nombre de bases de données répliquées et noms des bases de données.

Afficher l’historique de réplication à l’aide de SQL

Pour afficher l’historique de réplication d’un groupe de réplication ou de basculement spécifique dans une période spécifiée, effectuez l’une des requêtes suivantes :

Exemples

Interrogez la fonction de table Information Schema REPLICATION_GROUP_REFRESH_HISTORY pour afficher l’historique de réplication de compte du groupe de basculement myfg au cours des 7 derniers jours :

SELECT PHASE_NAME, START_TIME, END_TIME, TOTAL_BYTES, OBJECT_COUNT
  FROM TABLE(information_schema.replication_group_refresh_history('myfg'))
  WHERE START_TIME >= current_date - interval '7 days';
Copy

Interrogez la vue REPLICATION_GROUP_REFRESH_HISTORY de Account Usage pour voir l’historique de réplication de compte pour le mois en cours :

SELECT REPLICATION_GROUP_NAME, PHASE_NAME, START_TIME, END_TIME, TOTAL_BYTES, OBJECT_COUNT
  FROM snowflake.account_usage.replication_group_refresh_history
  WHERE START_TIME >= date_trunc('month', current_date());
Copy

Surveiller les coûts de réplication

Pour surveiller l’utilisation du crédit pour la réplication, effectuez l’une des requêtes suivantes :

Exemples

Interroger la fonction de table REPLICATION_GROUP_USAGE_HISTORY pour voir les crédits utilisés pour la réplication de compte au cours des 7 derniers jours :

SELECT start_time, end_time, replication_group_name, credits_used, bytes_transferred
  FROM table(information_schema.replication_group_usage_history(date_range_start=>dateadd('day', -7, current_date())));
Copy

Interrogez la vue Account Usage REPLICATION_GROUP_USAGE_HISTORY pour voir les crédits utilisés par la réplication ou le groupe de basculement pour l’historique de réplication de compte dans le mois en cours :

SELECT start_time, 
  end_time, 
  replication_group_name, 
  credits_used, 
  bytes_transferred
FROM snowflake.account_usage.replication_group_usage_history
WHERE start_time >= DATE_TRUNC('month', CURRENT_DATE());
Copy

Surveiller les coûts de réplication des bases de données

Le coût de la réplication pour une base de données individuelle incluse dans un groupe de réplication ou de basculement peut être calculé en récupérant le nombre d’octets copiés pour la base de données et en l’associant aux crédits utilisés.

Exemples

Interrogation des vues Account Usage

Les exemples suivants calculent les coûts de la réplication de la base de données dans un groupe de réplication pour les 30 derniers jours.

  1. Interrogez la vue REPLICATION_GROUP_REFRESH_HISTORY de Account Usage et calculez la somme du nombre d’octets répliqués par base de données.

    Par exemple, pour calculer la somme du nombre d’octets répliqués pour les bases de données du groupe de réplication myrg au cours des 30 derniers jours :

    select sum(value:totalBytesToReplicate) as sum_database_bytes
    from snowflake.account_usage.replication_group_refresh_history rh,
        lateral flatten(input => rh.total_bytes:databases)
    where rh.replication_group_name = 'MYRG'
    and rh.start_time >= current_date - interval '30 days';
    
    Copy

    Notez la sortie de la somme des octets de la base de données :

    +--------------------+
    | SUM_DATABASE_BYTES |
    |--------------------|
    |              22016 |
    +--------------------+
    
    Copy
  2. Interrogez la vue REPLICATION_GROUP_USAGE_HISTORY de Account Usage et calculez la somme du nombre de crédits utilisés et la somme des octets transférés pour la réplication.

    Par exemple, pour calculer la somme du nombre de crédits utilisés et la somme des octets transférés pour la réplication du groupe de réplication myrg au cours des 30 derniers jours :

    select sum(credits_used) as credits_used, SUM(bytes_transferred) as bytes_transferred
    from snowflake.account_usage.replication_group_usage_history
    where replication_group_name = 'MYRG'
    and start_time >= current_date - interval '30 days';
    
    Copy

    Notez la sortie de la somme des crédits utilisés et de la somme des octets transférés :

    +--------------+-------------------+
    | CREDITS_USED | BYTES_TRANSFERRED |
    |--------------+-------------------|
    |  1.357923604 |             22013 |
    +--------------+-------------------+
    
    Copy
  3. Calculez les coûts de réplication pour les bases de données en utilisant les valeurs des octets transférés pour les bases de données, la somme des crédits utilisés, et la somme de tous les octets transférés pour la réplication des deux étapes précédentes :

    (<octets_de_base_de_données_transférés> / <octets_transférés>) * <crédits_utilisés>

    Par exemple :

    (22016 / 22013) * 1.357923604 = 1.35810866)

Interrogation des fonctions de table Information Schema

Pour les opérations d’actualisation effectuées au cours des 14 derniers jours, interrogez les fonctions de la table Information Schema associée.

  1. Interroger la fonction de table REPLICATION_GROUP_REFRESH_HISTORY pour voir la somme du nombre d’octets copiés pour la réplication de la base de données pour le groupe de réplication myrg :

    select sum(value:totalBytesToReplicate)
      from table(information_schema.replication_group_refresh_history('myrg')) as rh,
      lateral flatten(input => total_bytes:databases)
      where rh.phase_name = 'COMPLETED'
      and rh.start_time >= current_date - interval '14 days';
    
    Copy
  2. Interroger la fonction de la table REPLICATION_GROUP_USAGE_HISTORY pour voir la somme du nombre de crédits utilisés et la somme des octets transférés pour la réplication pour le groupe de réplication myrg :

    select sum(credits_used), sum(bytes_transferred)
      from table(information_schema.replication_group_usage_history(
          date_range_start=>dateadd('day', -14, current_date()),
          replication_group_name => 'myrg'
      ));
    
    Copy

Comparaison des ensembles de données dans les bases de données principales et secondaires

Si les objets de la base de données sont répliqués dans un groupe de réplication ou de basculement, la fonction HASH_AGG peut être utilisée pour comparer les lignes d’un ensemble aléatoire de tables dans une base de données primaire et secondaire afin de vérifier la cohérence des données. La fonction HASH_AGG renvoie une valeur de hachage globale signée de 64 bits sur l’ensemble (non ordonné) des lignes d’entrée. Interrogez cette fonction sur tout ou un sous-ensemble aléatoire de tables dans une base de données secondaire et sur la base de données principale (à partir de l’horodatage de l’instantané de la base de données principale) et comparez la sortie.

Exemple

Dans les exemples ci-dessous, la base de données mydb est incluse dans le groupe de basculement myfg. La base de données mydb contient la table mytable.

Exécuté sur le compte cible

  1. Interrogez la fonction de table REPLICATION_GROUP_REFRESH_PROGRESS (dans Schéma d’information de Snowflake). Notez-le primarySnapshotTimestamp dans la colonne DETAILS pour la phase PRIMARY_UPLOADING_METADATA. Il s’agit de l’horodatage du dernier instantané de la base de données principale.

    SELECT PARSE_JSON(details)['primarySnapshotTimestamp']
      FROM TABLE(information_schema.replication_group_refresh_progress('myfg'))
      WHERE PHASE_NAME = 'PRIMARY_UPLOADING_METADATA';
    
    Copy
  2. Interrogez la fonction HASH_AGG pour une table spécifiée d’une base de données secondaire. La requête suivante renvoie une valeur de hachage pour toutes les lignes de la table mytable :

    SELECT HASH_AGG( * ) FROM mytable;
    
    Copy

Exécuter à partir du compte source

  1. Interrogez la fonction HASH_AGG pour la même table dans la base de données principale. À l’aide de Time Travel, spécifiez l’horodatage auquel le dernier instantané a été pris pour la base de données secondaire :

    SELECT HASH_AGG( * ) FROM mytable AT(TIMESTAMP => '<primarySnapshotTimestamp>'::TIMESTAMP);
    
    Copy
  2. Comparez les résultats des deux requêtes. La sortie doit être identique.

Modification d’un groupe de réplication ou de basculement

Vous pouvez modifier le nom, les objets inclus et le calendrier de réplication d’un groupe de réplication ou de basculement en utilisant Snowsight ou SQL.

Modifier un groupe de réplication ou de basculement à 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 modifier le nom du groupe, vous devez être connecté au compte cible. Si vous n’êtes pas connecté, la colonne Status affiche un message de connexion au lieu du statut d’actualisation.

Le compte source et le compte cible doivent tous les deux utiliser le même type de connexion (Internet public). Sinon, la connexion au compte cible échoue.

  1. Connectez-vous à Snowsight et naviguez jusqu’à Admin » Accounts.

  2. Sélectionnez Replication, puis Groups.

  3. Localisez le groupe de réplication ou de basculement que vous souhaitez modifier. Sélectionnez le menu More () dans la dernière colonne de la ligne.

  4. Sélectionnez Edit.

  5. Pour modifier le nom du groupe, entrez un nouveau nom dans la boîte Group Name qui répond aux exigences suivantes :

    • doit commencer par un caractère alphabétique et ne peut pas contenir d’espaces ou de caractères spéciaux à moins que la chaîne d’identificateur soit délimitée par des guillemets doubles (p. ex. « Mon objet »). Les identificateurs entre guillemets doubles sont également sensibles à la casse.

      Pour plus d’informations, consultez Exigences relatives à l’identificateur.

    • Les identificateurs des groupes de basculement et des groupes de réplication d’un compte doivent être uniques.

  6. Choisissez Select Objects pour ajouter ou supprimer des objets de partage et de compte.

    Note

    Des objets de compte ne peuvent être ajoutés qu’à un seul groupe de réplication ou de basculement. Si un groupe de réplication ou de basculement comportant des objets de compte existe déjà dans votre compte, vous ne pouvez pas sélectionner ces objets.

  7. Choisissez Select Databases pour ajouter ou supprimer des objets de base de données.

  8. Sélectionnez l’adresse Replication Frequency pour modifier le calendrier de réplication d’un groupe.

  9. Sélectionnez Save Changes pour mettre à jour le groupe.

    Si l’enregistrement des modifications apportées au groupe échoue, reportez-vous à la page Résoudre les problèmes liés à la création et à la modification des groupes de réplication à l’aide de Snowsight pour connaître les erreurs les plus courantes et savoir comment les résoudre.

Modifier un groupe de réplication ou de basculement à l’aide de SQL

Vous pouvez modifier les propriétés d’un groupe de réplication ou de basculement à l’aide de la commande ALTER REPLICATION GROUP ou ALTER FAILOVER GROUP.

Suppression d’un groupe de réplication ou de basculement secondaire

Vous pouvez détruire une réplication secondaire ou un basculement en utilisant la commande DROP REPLICATION GROUP ou DROP FAILOVER GROUP. Seul le propriétaire du groupe de réplication ou de basculement (c’est-à-dire le rôle ayant le privilège OWNERSHIP sur le groupe) peut détruire le groupe.

Pour supprimer un groupe de réplication ou de basculement secondaire à l’aide de Snowsight, vous devez supprimer le groupe dans le compte source. Voir Supprimer un groupe de réplication ou de basculement à l’aide de Snowsight.

Suppression d’un groupe de réplication ou de basculement principal

Vous pouvez abandonner un groupe de réplication ou de basculement primaire en utilisant Snowsight ou SQL. Si vous supprimez un groupe primaire à l’aide de SQL, vous devez d’abord supprimer tous les groupes secondaires. Voir Suppression d’un groupe de réplication ou de basculement secondaire.

Supprimer un groupe de réplication ou de basculement principal à l’aide de SQL

Un groupe de réplication ou de basculement principal ne peut être détruit qu’après que toutes les répliques du groupe (c’est-à-dire les groupes de réplication ou de basculement secondaires) aient été détruites. Vous pouvez également promouvoir un groupe de basculement secondaire pour qu’il serve de groupe de basculement principal, puis supprimer l’ancien groupe de basculement principal.

Notez que seul le propriétaire du groupe peut détruire le groupe.

Supprimer un groupe de réplication ou de basculement à l’aide de Snowsight

Note

Seuls les administrateurs de comptes peuvent supprimer 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).

Vous pouvez supprimer un groupe de réplication ou de basculement primaire et tous les groupes secondaires liés.

  1. Connectez-vous à Snowsight et naviguez jusqu’à Admin » Accounts.

  2. Sélectionnez Replication, puis Groups.

  3. Localisez le groupe de réplication ou de basculement que vous souhaitez supprimer. Sélectionnez le menu More () dans la dernière colonne de la ligne.

  4. Sélectionnez Drop, puis sélectionnez Drop Group.

Résoudre les problèmes liés à la création et à la modification des groupes de réplication à l’aide de Snowsight

Les scénarios suivants peuvent vous aider à résoudre les problèmes qui peuvent survenir lors de la création ou de la modification d’un groupe de réplication ou de basculement à l’aide de Snowsight.

Vous ne pouvez pas ajouter une base de données à un groupe

Erreur

Database '<database_name>' is already configured to replicate to
account '<account_name>' by replication group '<group_name>'.

Cause

Une base de données ne peut être ajoutée qu’à un seul groupe de réplication ou de basculement. L’une des bases de données que vous avez sélectionnées pour le groupe est déjà incluse dans un autre groupe de réplication ou de basculement.

Solution

Choisissez Select Databases et désélectionnez toute(s) base(s) de données déjà incluse(s) dans un autre groupe.

Erreur

Cannot directly add previously replicated object '<database_name>' to a
replication group. Please use the provided system functions to convert
this object first.

Cause

La base de données que vous souhaitez ajouter à un groupe de réplication ou de basculement a été précédemment configurée pour la réplication de bases de données.

Solution

Désactivez la réplication de la base de données. Voir Transition de la réplication de base de données à la réplication par groupe.

Vous ne pouvez pas ajouter un partage à un groupe.

Erreur

Share '<share_name>' is already configured to replicate to
account '<account_name>' by replication group '<group_name>'.

Cause

Un partage ne peut faire partie que d’un seul groupe de réplication ou de basculement. L’un des partages que vous avez sélectionnés pour le groupe est déjà inclus dans un autre groupe de réplication ou de basculement.

Solution

Choisissez Select Objects et désélectionnez toute(s) action(s) déjà incluse(s) dans un autre groupe.

Limites de l’utilisation de Snowsight pour la configuration de la réplication

  • Seul un utilisateur ayant le rôle ACCOUNTADMIN peut créer un groupe de réplication ou de basculement à l’aide de Snowsight. Un utilisateur ayant un rôle avec le privilège CREATE REPLICATION GROUP ou CREATE FAILOVER GROUP peut créer un groupe à l’aide des commandes SQL respectives.

  • Seul un utilisateur ayant le rôle ACCOUNTADMIN peut modifier ou supprimer un groupe de réplication ou de basculement à l’aide de Snowsight. Un utilisateur ayant un rôle avec le privilège OWNERSHIP sur un groupe de réplication ou de basculement peut modifier et supprimer des groupes à l’aide des commandes SQL correspondantes.