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.
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).
Matrice des fonctionnalités de réplication/éditions¶
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 |
✔ |
✔ |
||
Données protégées avec Tr-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 ce tableau.
Objet |
Type ou fonctionnalité |
Répliqué |
Remarques |
---|---|---|---|
Bases de données |
✔ |
||
Intégrations |
Sécurité, API, notification |
✔ |
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 (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.
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 |
✔ |
Pour les balises, voir Réplication et balises. |
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, reportez-vous à 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 de sécurité pour les fonctionnalités suivantes :
Intégrations de sécurité des types suivants :
Authentification fédérée et SSO (c’est-à-dire SAML2)
SCIM
Snowflake OAuth
OAuth externe
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.
API integrations.
After replicatiing API integrations to a target account, you must grant access to the remote service to the replicated external functions. For details, see Mettre à jour le service distant pour les intégrations API.
Intégrations de notification des types suivants :
TYPE = EMAIL
TYPE = QUEUE avec DIRECTION = OUTBOUND
Les intégrations de stockage ne sont pas prises en charge pour le moment, mais sont prévues pour une version ultérieure.
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 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. |
✔ |
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 |
✔ |
|
✔ |
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). |
|
✔ |
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. |
|
✔ |
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. |
|
✔ |
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).
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).