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

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

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

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.

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

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;

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

SHOW REPLICATION ACCOUNTS;

+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| 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        |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+

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

É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;

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

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;

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

Étape 6. Accorder le privilège FAILOVER sur le groupe de basculement au rôle — Facultatif¶

Pour exécuter la commande de basculement d’un groupe de basculement secondaire dans un compte cible, vous devez utiliser un rôle doté du privilège FAILOVER sur le groupe de basculement. Le privilège FAILOVER est n’est actuellement pas répliqué et doit être accordé dans chaque compte source et cible.

Pour plus d’informations, voir Réplication de rôles et d’accords de privilèges.

Par exemple, pour accorder le privilège FAILOVER au rôle my_failover_role sur le groupe de basculement my_fg, exécutez l’instruction suivante dans le compte cible à l’aide d’un rôle doté du privilège OWNERSHIP sur le groupe :

GRANT FAILOVER ON FAILOVER GROUP myfg TO ROLE my_failover_role;

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.

Utiliser SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME() pour appliquer des IDs globaux¶

Vous pouvez éviter la perte de certains types d’objets en liant les objets correspondants portant le même nom dans les comptes source et cible. La fonction SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME ajoute un identificateur global aux objets du compte cible.

Appliquer des identificateurs globaux aux objets du compte cible des types inclus dans la liste object_types pour le groupe de basculement myfg :

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

SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('myfg');

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.

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

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.

• Si vous utilisez les notifications d’événement Amazon S3 avec Amazon Simple Queue Service (SQS), suivez les instructions dans Étape 4 : Configuration des notifications d’événement.

  Important

  Pour s’assurer que le canal n’a manqué aucune notification, il convient d’actualiser le canal après avoir effectué un basculement vers la nouvelle file d’attente SQS.

  Vous pouvez également migrer de SQS vers SNS. Pour plus d’informations, voir Migration vers Amazon Simple Notification Service (SNS).

• Si vous utilisez Amazon Simple Notification Service (SNS), consultez Abonnement à la file d’attente Snowflake SQS à votre sujet SNS.

• Si vous utilisez Amazon EventBridge, consultez Option 3 : Configuration d’Amazon EventBridge pour automatiser Snowpipe.

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 :

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.

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 :

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.

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.

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 (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 (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 :

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.

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

Affichage de l’historique de réplication¶

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

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

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

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

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 :

• Vue REPLICATION_GROUP_USAGE_HISTORY (dans Account Usage).

• la fonction de table REPLICATION_GROUP_USAGE_HISTORY (dans Schéma d’information de Snowflake).

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

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

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.

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.

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

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

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¶

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.

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

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

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

Vous ne pouvez pas ajouter un partage à un groupe.¶

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