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

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 :

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.

Réplication d’intégration¶

La réplication de compte prend en charge la réplication des intégrations 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 d’informations sur les intégrations de sécurité, voir Réplication des intégrations de sécurité et des politiques réseau sur plusieurs comptes.

• Intégrations API.

  Après avoir répliqué les intégrations API vers un compte cible, vous devez accorder l’accès au service distant aux fonctions externes répliquées. Pour plus d’informations, consultez Mise à jour du service distant pour les intégrations API.

• Intégrations de notification des types suivants :

  • TYPE = EMAIL

  • TYPE = QUEUE avec DIRECTION = OUTBOUND

  • TYPE = WEBHOOK

• Intégrations de stockage.

  Lorsque vous répliquez une intégration de stockage, vous devez établir une nouvelle relation de confiance pour votre stockage Cloud dans les comptes cibles. Pour en savoir plus, voir Configurer l’accès au stockage Cloud pour les intégrations de stockage secondaire.

• Intégrations d’accès externes

  Pour plus d’informations sur les intégrations d’accès externe, voir Vue d’ensemble de l’accès au réseau externe.

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

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 :

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

Pour plus d’informations sur la réplication des rôles secondaires et les politiques de session, voir Politiques de session avec rôles secondaires.

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.

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, voir ALTER FAILOVER GROUP.