Présentation de la réplication et du basculement à travers plusieurs comptes

Cette fonction active la réplication d’objets d’un compte source vers un ou plusieurs comptes cible de la même organisation. Les objets répliqués dans chaque compte cible sont appelés objets secondaires et sont des répliques des objets principaux du compte source. La réplication est prise en charge à travers les régions et les plates-formes Cloud.

Dans ce chapitre :

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

Toutes les régions Snowflake sur Amazon Web Services, Google Cloud Platform et Microsoft Azure prennent en charge la réplication.

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érents (c’est-à-dire d’une région commerciale Snowflake vers une région Snowflake gouvernementale ou Virtual Private Snowflake), veuillez contacter le support Snowflake.

Groupes de réplication et groupes de basculement

Un groupe de réplication est une collection définie d’objets dans un compte source qui sont répliqués comme une unité vers un ou plusieurs comptes cibles. Les groupes de réplication fournissent un accès en lecture seule pour les objets répliqués.

Un groupe de basculement est un groupe de réplication qui peut également basculer. Un groupe de basculement secondaire dans un compte cible fournit un accès en lecture seule pour les objets répliqués. Lorsqu’un groupe de basculement secondaire est promu pour devenir le groupe de basculement principal, l’accès en lecture-écriture est disponible. Tout compte cible spécifié dans la liste des comptes autorisés dans un groupe de basculement peut être promu pour servir de groupe de basculement principal.

Les groupes de réplication et de basculement assurent la cohérence ponctuelle des objets sur le compte cible. Les objets qui peuvent être inclus dans un groupe de réplication ou de basculement sont répertoriés ci-dessous dans Objets répliqués.

Matrice des fonctionnalités de réplication/éditions

Notez que certaines fonctions de réplication ne sont disponibles que pour Business Critical Edition (ou une version supérieure). Le tableau suivant répertorie la disponibilité des fonctions de réplication pour chaque édition Snowflake :

Fonctionnalité

Standard

Entreprise

Business Critical

VPS

Réplication de base de données

Réplication de partages

Groupe de réplication

Réplication d’objets de compte (autres que la base de données et le partage)

Groupe de basculement

Données protégées avec Tri-Secret Secure

Objets répliqués

Cette fonction prend en charge la réplication des objets énumérés ci-dessous. La réplication des bases de données et la réplication des partages sont disponibles sur toutes les éditions. La réplication de tous les autres objets n’est disponible que pour Business Critical Edition (ou supérieure). Pour plus de détails sur la disponibilité des fonctionnalités, voir Matrice des fonctionnalités de réplication/éditions.

Objet

Type ou fonctionnalité

Répliqué

Remarques

Bases de données

La réplication de certaines bases de données n’est pas prise en charge ou peut faire échouer l’opération d’actualisation. Pour plus d’informations, consultez Limites actuelles de la réplication.

Intégrations

Sécurité, API, notification, stockage [1], accès externe [2]

Pour des mises en garde supplémentaires et des détails sur les types pris en charge, reportez-vous à Réplication d’intégration.

Politiques réseau

Paramètres (au niveau du compte)

Moniteurs de ressources

Les notifications du moniteur de ressources pour les utilisateurs non administrateurs sont répliquées si vous incluez users dans le groupe, mais les paramètres de notification de l’administrateur du compte ne sont pas répliqués. Pour plus d’informations, voir Réplication des paramètres de notification par e-mail du moniteur de ressources.

Rôles

  • Inclut les rôles de compte et de base de données.

  • Comprend les privilèges accordés aux rôles, ainsi que les rôles accordés aux rôles (c’est-à-dire les hiérarchies de rôles).

  • Si des utilisateurs et des rôles sont répliqués, les rôles accordés aux utilisateurs sont également répliqués.

  • Les privilèges REPLICATE et FAILOVER ne sont pas répliqués.

Partages

La réplication des partages entrants (partages provenant des fournisseurs) n’est pas prise en charge.

Utilisateurs

Entrepôts

Réplication de base de données

Cette fonction prend en charge la réplication des bases de données. Un instantané inclut les modifications apportées aux objets et aux données. Si des roles sont répliqués (dans le même groupe de réplication ou de basculement ou dans un groupe différent), l’actualisation de la base de données synchronise également les accords de privilèges sur la base de données secondaire et les objets de la base de données (schémas, tables, vues, etc.) avec les rôles du compte. Reportez-vous à Accords de privilèges pour des objets de base de données pour plus de détails.

La réplication de certaines bases de données n’est pas prise en charge ou peut faire échouer l’opération d’actualisation. Pour plus d’informations, consultez Limites actuelles de la réplication.

Objets de base de données répliqués

Lorsqu’une base de données principale est répliquée, un instantané de ses objets et données de base de données est transféré vers la base de données secondaire. Cependant, certains objets de base de données ne sont pas répliqués. Le tableau suivant indique les objets de base de données répliqués dans une base de données secondaire.

Pour plus d’informations sur l’utilisation de ces objets, voir Remarques relatives à la réplication.

Objet

Type ou fonctionnalité

Répliqué

Remarques

Tables

Tables permanentes

Tables transitoires

Tables temporaires

Clustering automatique des tables en cluster

Tables externes

La création ou l’actualisation d’une base de données secondaire est bloquée s’il existe une table externe dans la base de données primaire. . Prévision : pour une future version.

Tables dynamiques

Pour plus d’informations, consultez Réplication et tables dynamiques.

Contraintes de tables

Sauf si une clé étrangère dans la base de données fait référence à une clé primaire/unique dans une autre base de données. .

Tables d’événements

L’actualisation d’une base de données secondaire est bloquée s’il existe une table d’événement dans la base de données primaire.

Séquences

Vues

Vues

Si une vue fait référence à un objet d’une autre base de données (par exemple, colonnes de table, autres vues, UDFs ou zones de préparation), . les deux bases de données doivent être répliquées.

Vues matérialisées

Vues sécurisées

Formats de fichier

Zones de préparation

Zones de préparation

Pris en charge uniquement pour les groupes de réplication et de basculement. Non pris en charge pour la réplication de base de données. . Pour plus d’informations, voir Réplication des zones de préparation, des canaux et de l’historique des chargements.

Zones de préparation temporaires

Canaux

Pris en charge uniquement pour les groupes de réplication et de basculement. Non pris en charge pour la réplication de base de données. . Pour plus d’informations, voir Réplication des zones de préparation, des canaux et de l’historique des chargements.

Procédures stockées

Pour plus d’informations, consultez Réplication de procédures stockées et de fonctions définies par l’utilisateur (UDFs).

Flux

Pour plus d’informations, consultez Réplication et flux.

Tâches

Pour plus d’informations, consultez Réplication et tâches.

UDFs

Pour plus d’informations, consultez Réplication de procédures stockées et de fonctions définies par l’utilisateur (UDFs).

Politiques

Sécurité au niveau des colonnes (masquage)

Pour les politiques de masquage, d’accès aux lignes et de masquage basé sur les balises, reportez-vous aux considérations de réplication des politiques.

Politiques d’accès aux lignes

Politiques de masquage basées sur les balises

Politiques de session

Pour les politiques de session, de mot de passe et d’authentification, voir politiques de réplication et de sécurité.

Politiques de mots de passe

Politiques d’authentification

Balises

Balisage d’objets

Pour les balises, voir Réplication et balises.

Alertes

Secrets

Secrets pour l’authentification External API

Vous pouvez répliquer des secrets en utilisant un groupe de réplication et un groupe de basculement. Pour plus de détails, voir Réplication et secrets.

Règles de réseau

Pour la réplication des politiques réseau qui utilisent des règles réseau, consultez Réplication des politiques réseau.

Classes et instances

Les instances des classes de Snowflake (par exemple, une instance de la classe ANOMALY_DETECTION ou de la classe BUDGET) ne sont pas répliquées. Pour la liste complète des classes Snowflake, voir Classes disponibles.

Politiques de paquets

Procédures Python UDF, UDTF, stockées

S’il existe une politique de paquets définie sur le compte source, afin de répliquer correctement les objets du compte, la base de données contenant la politique de paquets doit être répliquée dans le compte cible dans le même groupe de réplication ou de basculement ou dans un groupe différent. Sinon, l’opération d’actualisation échoue avec une erreur de références pendantes.

Réplication de base de données et chiffrement

Snowflake protège les métadonnées et les ensembles de données au repos et en transit entre les comptes source et cible. La clé master du compte (AMK) chiffre la hiérarchie des clés au sein du compte, comme indiqué dans le modèle de clé hiérarchique. Snowflake chiffre les données répliquées dans le compte cible à l’aide de la clé master du compte et de la hiérarchie des clés dans le compte cible, que vous activiez ou non Tri-Secret Secure dans le compte cible.

Lorsque vous activez Tri-Secret Secure dans le compte cible, Snowflake utilise la clé master composite et la hiérarchie de clés correspondante dans le compte cible pour chiffrer les données. Notez que les comptes cibles n’ont pas Tri-Secret Secure activé par défaut. Vous devez activer cette fonctionnalité.

Pour plus d’informations sur le chiffrement des données dans Snowflake, voir Comprendre le chiffrement de bout en bout dans Snowflake.

Réplication d’intégration

La réplication de compte prend en charge la réplication des intégrations pour les fonctionnalités suivantes :

Réplication de politiques réseau

Cette fonction prend en charge la réplication de politiques réseau.

Pour plus d’informations, consultez Réplication des intégrations de sécurité et des politiques réseau sur plusieurs comptes.

Réplication de paramètres

Cette fonction permet de répliquer les paramètres de niveau compte et les paramètres d’objet. Les paramètres d’objet sont répliqués lorsque l’objet est inclus dans le groupe de réplication. Par exemple, si WAREHOUSES sont répliqués, les paramètres spécifiques à l’entrepôt (par exemple, STATEMENT_TIMEOUT_IN_SECONDS) sont répliqués. Pour une liste complète, voir Paramètres d’objet.

La réplication des paramètres au niveau du compte comprend tous les paramètres Paramètres du compte et définis sur le compte. Les paramètres de niveau compte (par exemple DATA_RETENTION_TIME_IN_DAYS) sont répliqués lorsque ACCOUNT PARAMETERS est inclus dans la liste des types d’objets pour un groupe de réplication.

Réplication de moniteurs de ressources

Cette fonctionnalité prend en charge la réplication de moniteurs de ressources et de privilèges accordés sur des moniteurs de ressources à des rôles. Un moniteur de ressources secondaire suit la même planification de réinitialisation des quotas que le moniteur de ressources principal. Par exemple, si le quota du moniteur de ressources principal est réinitialisé le premier jour du mois et que le secondaire est répliqué pour la première fois le 15e jour du mois, son quota sera réinitialisé le premier jour du mois suivant en même temps que le principal.

Réplication des paramètres de notification par e-mail du moniteur de ressources

Les paramètres de notification par e-mail des moniteurs de ressources ne sont pas inclus avec la réplication des moniteurs de ressources. Les notifications par e-mail des utilisateurs non administrateurs peuvent être répliquées avec les moniteurs de ressources. Cependant, les paramètres de notification de l’administrateur du compte ne sont actuellement pas répliqués :

  • Si users et resource monitors sont inclus dans la liste object_types du groupe de réplication ou de basculement, les paramètres de notification des utilisateurs non administrateurs sont répliqués :

  • Si resource monitors est inclus dans la liste object_types du groupe de réplication ou de basculement, mais que users ne l’est pas, la liste notify_users d’un moniteur de ressources au niveau de l’entrepôt secondaire est vide.

  • Les paramètres de notification de l’administrateur du compte ne sont pas répliqués :

    • Un administrateur de compte doit activer les notifications par e-mail dans chaque compte via l’interface Web.

    • Les notifications des moniteurs de ressources sont envoyées aux administrateurs de comptes s’ils ont activé les notifications par e-mail dans les comptes sources et/ou cibles.

Réplication de rôles

Cette fonction permet de répliquer des rôles, y compris des hiérarchies de rôles. Les objets de rôle doivent être répliqués pour répliquer les privilèges d’accès. Les privilèges d’accès répliqués sont répertoriés dans Réplication de rôles et d’accords de privilèges ci-dessous.

Note

Tous les rôles sont répliqués, y compris le rôle ORGADMIN.

Réplication de partages

Cette fonctionnalité prend en charge la réplication d’objets de partage ainsi que des privilèges d’accès accordés à des partages sur des objets de base de données.

La réplication des partages entrants (partages provenant des fournisseurs) n’est pas prise en charge.

Réplication d’utilisateurs

Cette fonctionnalité prend en charge la réplication des utilisateurs et de leurs propriétés vers des comptes cibles, les méthodes d’authentification des utilisateurs suivantes et le provisionnement des utilisateurs et des groupes avec SCIM :

Méthode d’authentification

Fonctionne dans les comptes cibles

Remarques

Mot de passe

Mot de passe avec MFA (authentification multifactorielle)

Les utilisateurs qui sont inscrits à MFA dans le compte source doivent s’inscrire séparément à MFA lorsqu’ils se connectent à chaque compte cible.

Authentification multifactorielle (MFA)

Les utilisateurs qui sont inscrits à MFA dans le compte source doivent s’inscrire séparément à MFA lorsqu’ils se connectent à chaque compte cible.

Authentification par paire de clés

Authentification fédérée

Voir Réplication des intégrations de sécurité et des politiques réseau sur plusieurs comptes pour plus de détails sur la réplication des intégrations de sécurité SSO fédérées (c’est-à-dire SAML2).

Snowflake OAuth

Voir Réplication des intégrations de sécurité et des politiques réseau sur plusieurs comptes pour plus de détails sur la réplication des intégrations de sécurité OAuth.

External OAuth

Voir Réplication des intégrations de sécurité et des politiques réseau sur plusieurs comptes pour plus de détails sur la réplication des intégrations de sécurité OAuth.

SCIM

Voir Réplication des intégrations de sécurité et des politiques réseau sur plusieurs comptes pour plus de détails sur la réplication des intégrations de sécurité SCIM.

Note

Si les objets USERS et ROLES sont répliqués sur un compte cible, ces types d’objets sont en lecture seule dans le compte cible et ne peuvent pas être modifiés. Les utilisateurs et les rôles doivent être créés dans le compte source, puis répliqués dans chaque compte cible. Reportez-vous à Réplication et objets secondaires en lecture seule.

Réplication d’entrepôts

Cette fonctionnalité prend en charge la réplication d’entrepôts et de privilèges accordés sur des entrepôts à des rôles (si des roles sont répliqués). L’état de l’entrepôt principal n’est pas répliqué. Les entrepôts sont répliqués à l’état suspendu vers chaque compte cible et peuvent être repris dans le compte cible.

Réplication de rôles et d’accords de privilèges

Afin de répliquer les accords de privilèges sur des objets à des rôles, les rôles doivent être répliqués du compte source au compte cible. Pour répliquer les rôles dans un groupe de réplication ou de basculement, vous devez inclure roles dans la liste object_types. Les rôles peuvent se trouver dans un groupe de réplication ou de basculement distinct des objets de données sur lesquels les privilèges sont accordés.

Lorsque des roles sont répliqués, les accords de privilèges sur des objets sont répliqués sur un compte cible uniquement si :

  • Le privilège a été accordé par le propriétaire de l’objet ou indirectement par un rôle auquel le propriétaire de l’objet a accordé le privilège avec le paramètre WITH GRANT OPTION.

  • Le rôle du concessionnaire et celui du concédant d’un accord de privilège sont tous deux situés dans le compte cible.

  • L’objet est répliqué (c’est-à-dire que le type d’objet est inclus dans la liste object_types).

Sinon, l’accord sur l’objet n’est pas répliqué.

Note

  • Si un rôle est détruit alors qu’il possède le privilège OWNERSHIP sur un canal actif du compte cible, l’opération d’actualisation échoue.

  • Les privilèges sur les groupes de réplication et les groupes de basculement ne sont pas répliqués. Si le privilège REPLICATE ou FAILOVER a été accordé sur des groupes de réplication ou des groupes de basculement, ces privilèges doivent être accordés dans les comptes source et cible. Voir Privilèges de réplication pour plus de détails sur ces privilèges.

Accords de privilèges pour des objets de base de données

Si des roles et des databases sont répliqués sur un compte cible (dans le même groupe de réplication ou de basculement ou dans un groupe différent), l’actualisation d’une base de données secondaire synchronise les accords de privilèges sur la base de données et les objets de la base de données (schémas, tables, vues, etc.) avec des rôles existants dans le compte cible (c’est-à-dire des rôles qui ont été répliqués sur le compte cible). Notez que seuls les accords de privilèges sur les objets pris en charge par la réplication de la base de données sont synchronisés. Pour obtenir la liste des objets pris en charge, voir Objets de base de données répliqués.

Les tables externes ne sont actuellement pas prises en charge pour la réplication. Par conséquent, les accords de privilèges sur les tables externes ne sont pas non plus répliqués.

Accords de privilèges futurs pour des objets

Si les rôles sont répliqués sur le compte cible, les accords de privilèges futurs accordés au niveau de la base de données ou du schéma sont répliqués sur le compte cible. Cela inclut également les accords de privilèges futurs sur les objets non pris en charge par la réplication. Par exemple, la réplication de tables externes n’est pas encore prise en charge, mais les autorisations futures sur les tables externes sont répliquées. Lorsque vous créez une table externe dans un compte cible, les privilèges accordés sur les futures tables externes se matérialisent comme prévu.

Création et appartenance d’objets

Si de nouveaux objets sont créés dans un compte cible lors d’une actualisation à partir du compte source, et que les rôles ne sont pas répliqués sur le compte cible, le privilège OWNERSHIP pour les nouveaux objets est accordé au rôle ACCOUNTADMIN.

Si les rôles sont répliqués sur le compte cible, le privilège OWNERSHIP est accordé au même rôle sur le compte cible que le rôle doté du privilège OWNERSHIP sur le compte source lors de la réplication suivante des rôles. Les rôles peuvent être répliqués en même temps que les nouveaux objets sont créés dans le compte cible si les objets et les rôles sont dans le même groupe de réplication (ou de basculement).

Accords de privilèges pour les partages

Afin d’activer un partage sécurisé des données, les accords de privilèges sur les objets aux partages sont répliqués même si les roles ne sont pas répliqués sur les comptes cibles. Cette section fournit des informations sur la façon dont les accords de privilèges sur les objets aux partages sont répliqués.

Si les roles sont répliqués du compte source au compte cible, les accords de privilèges aux objets sur les partages sont répliqués si :

  • Le rôle de concédant existe dans le compte cible ou

  • Le rôle de concédant du compte source possède le privilège OWNERSHIP sur l’objet principal.

Si les roles ne sont pas répliqués du compte source au compte cible, alors :

  • Les attributions d’objets aux partages sont répliqués.

  • Le rôle de concédant pour les accords de privilèges sur les objets répliqués vers les partages est le rôle avec le privilège OWNERSHIP sur l’objet.

Utilisateur qui actualise les objets dans un compte cible

Un utilisateur qui exécute la commande ALTER FAILOVER GROUP … REFRESH pour actualiser des objets dans un compte cible à partir du compte source doit utiliser un rôle avec le privilège REPLICATE sur le groupe de basculement. Snowflake protège cet utilisateur dans le compte cible en échouant dans les scénarios suivants :

  • Si l’utilisateur n’existe pas dans le compte source, l’opération d’actualisation échoue.

  • Si l’utilisateur existe dans le compte source, mais qu’un rôle avec le privilège REPLICATE n’a pas été accordé à l’utilisateur, l’opération d’actualisation échoue.

Planification de réplication

En tant que meilleure pratique, Snowflake recommande de programmer des actualisations automatiques en utilisant le paramètre REPLICATION_SCHEDULE. La planification peut être définie lors de la création d’un nouveau groupe de réplication ou de basculement avec CREATE <objet> ou plus tard (avec ALTER <objet>).

Lorsqu’un groupe de réplication ou de basculement secondaire est créé, une actualisation initiale est automatiquement exécutée. L’actualisation suivante est planifiée en fonction de la date de début de l’actualisation précédente et de l’intervalle de planification, ou de la prochaine heure valide en fonction de l’expression cron. Par exemple, si l’intervalle de planification de l’actualisation est de 10 minutes et que l’opération d’actualisation précédente (qu’il s’agisse d’une actualisation planifiée ou d’une actualisation déclenchée manuellement) commence à 12:01, la prochaine actualisation est prévue pour 12:11.

Snowflake garantit qu’une seule actualisation est exécutée à un moment donné. Si une actualisation est toujours en cours d’exécution lorsque l’actualisation suivante est planifiée, cette dernière est retardée pour démarrer lorsque l’actualisation en cours d’exécution se termine. Par exemple, si une actualisation est planifiée pour s’exécuter 15 minutes après l’heure, toutes les heures, et que l’actualisation précédente se termine à 12:16, l’actualisation suivante est planifiée pour s’exécuter lorsque l’actualisation précédente est terminée.

Suspendre et reprendre la réplication planifiée

Un groupe de basculement secondaire ne peut pas être promu au groupe principal pendant l’exécution d’une actualisation. Pour effectuer un basculement en douceur, suspendez la réplication planifiée dans le compte cible. Une fois le basculement terminé, reprenez la réplication planifiée. Pour plus d’informations sur la syntaxe, voir ALTER FAILOVER GROUP.

Note

La suspension de la réplication planifiée ne suspend pas une opération d’actualisation en cours. Elle suspend la planification de sorte qu’aucune actualisation supplémentaire ne soit prévue après la fin de l’actualisation en cours.

Réplication vers des comptes sur des éditions inférieures

Si l’une des conditions suivantes est remplie, Snowflake affiche un message d’erreur :

  • Le groupe de réplication principal avec seulement des objets de partage et/ou de base de données se trouve dans un compte Business Critical (ou supérieur), mais un ou plusieurs des comptes approuvés pour la réplication se trouvent sur des éditions inférieures. Business Critical Edition est destiné aux comptes Snowflake contenant des données extrêmement sensibles.

  • Un groupe de réplication ou de basculement primaire avec tout type d’objet se trouve dans un compte Business Critical (ou supérieur) et un accord d’associé commercial signé est en place pour stocker les données PHI dans le compte conformément aux réglementations HIPAA et HITRUST CSF. Cependant, aucun accord de ce type n’est en place pour un ou plusieurs des comptes activés pour la réplication, qu’il s’agisse ou non de comptes Business Critical (ou supérieurs).

Ce comportement est implémenté dans le but d’empêcher les administrateurs de comptes Business Critical (ou supérieurs) de répliquer par inadvertance des données sensibles vers des comptes sur des éditions inférieures.

Un administrateur de compte (un utilisateur ayant le rôle ACCOUNTADMIN) ou un utilisateur ayant un rôle avec le privilège CREATE REPLICATION GROUP/CREATE FAILOVER GROUP ou OWNERSHIP peut remplacer ce comportement par défaut en incluant la clause IGNORE EDITION CHECK lors de l’exécution des instructions CREATE <objet> ou ALTER <objet>. Si IGNORE EDITION CHECK est défini, le groupe de réplication ou de basculement principal peut être répliqué vers les comptes spécifiés sur une édition Snowflake inférieure dans ces scénarios spécifiques.

Note

Les groupes de basculement ne peuvent être créés que dans un compte Business Critical Edition (ou supérieur). Par conséquent, les groupes de basculement peuvent seulement être répliqués sur un compte qui est un compte Business Critical Edition (ou supérieur).

Limites actuelles de la réplication

  • Les bases de données créées à partir de partages ne peuvent pas être répliquées.

  • L’opération d’actualisation échoue si une base de données principale contient l’un des éléments suivants :

    • Table des événements

    • Table externe [3]

    • Table Iceberg [4]

    • Table hybride

Une opération de réplication ou d’actualisation de la base de données échoue si la base de données principale inclut un flux avec un objet source non pris en charge. L’opération échoue également si l’objet source d’un flux a été détruit.

Les flux d’ajout uniquement ne sont pas pris en charge sur les objets sources répliqués.