Présentation de la réplication et du basculement de compte

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

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 (dans cette rubrique).

Notez que certaines fonctions de réplication d’objets 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 d’objets de comptes et de bases de données 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

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

Objet

Type ou fonctionnalité

Répliqué

Remarques

Bases de données

Intégrations

Sécurité, API

Les intégrations de stockage sont prévues dans une prochaine version.

Politiques réseau

Paramètres (niveau du compte)

Moniteurs de ressources

Rôles

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.

La réplication des rôles de base de données est prévue pour une prochaine étape de cette fonctionnalité.

Partages

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. Voir Accord de privilèges pour des objets de base de données pour plus de détails.

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 de base de données.

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 principale. . Prévision : pour une future version de la réplication de base de données.

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

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

Prévision : pour une future version de la réplication de base de données.

Zones de préparation temporaires

Canaux

Prévision : pour une future version de la réplication de base de données.

Procédures stockées

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

Flux

Pour plus de détails, voir Réplication et flux.

Tâches

Pour plus de détails, voir Réplication et tâches.

UDFs

Pour plus de détails, voir Réplication des procédures stockées et des 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 et de mot de passe, reportez-vous aux politiques de réplication et de sécurité.

Politiques de mots de passe

Balises

Balisage d’objets

Le comportement de la réplication des balises est le même que celui de la réplication des politiques.

Réplication d’intégration

Cette fonction permet de répliquer les intégrations de sécurité pour les intégrations SAML2, SCIM, Snowflake OAuth, External OAuth et les intégrations d’API. Les intégrations de stockage ne sont pas prises en charge pour le moment, mais sont prévues pour une version ultérieure.

Pour plus de détails sur les intégrations de sécurité, voir Réplication des intégrations de sécurité et des politiques de réseau à travers plusieurs comptes.

La réplication de l’intégration API nécessite une configuration supplémentaire après la réplication de l’intégration vers un compte cible. L’accès au service distant doit être accordé à des fonctions répliquées. Pour plus de détails, voir Mettre à jour le service distant pour les intégrations API.

Réplication des politiques réseau

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

Pour plus de détails, voir Réplication des intégrations de sécurité et des politiques de réseau à travers plusieurs comptes.

Réplication des 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.

La configuration des notifications par e-mail n’est pas répliquée et les administrateurs de comptes devront configurer les notifications par e-mail sur chaque compte cible. Voir Activation de la réception des notifications pour les administrateurs de comptes. La réplication de la configuration des notifications sera ajoutée dans une prochaine version.

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 Reproduction des rôles et des 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.

Réplication d’utilisateurs

Cette fonctionnalité prend en charge la réplication d’utilisateurs et de leurs propriétés vers des comptes cibles, ainsi que des méthodes d’authentification des utilisateurs suivantes :

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.

Paire de clés

Authentification fédérée et SSO

Voir Réplication des intégrations de sécurité et des politiques de réseau à travers 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 de réseau à travers plusieurs comptes pour plus de détails sur la réplication des intégrations de sécurité OAuth.

OAuth externe

Voir Réplication des intégrations de sécurité et des politiques de réseau à travers 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 de réseau à travers 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. Voir Réplication et objets secondaires en lecture seule (dans cette rubrique).

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.

Reproduction des rôles et des 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 (voir Privilèges de réplication dans cette rubrique) 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.

Accord 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 objets de base de données suivants ne sont pas pris en charge actuellement pour la réplication. Par conséquent, les accords de privilèges sur ces objets ne sont pas non plus répliqués :

  • Zones de préparation

  • Canaux

  • Tables externes

Accords de privilèges futurs pour les 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 des zones de préparation n’est pas encore prise en charge, mais les accords de privilèges futurs sur les zones de préparation sont répliqués. Lorsque vous créez une zone de préparation dans un compte cible, les privilèges accordés sur les zones de préparation futures se matérialisent comme prévu.

Création et propriété des 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).

Revenir au début