Introduction à la réplication de base de données sur plusieurs comptes¶

Cette fonctionnalité permet la réplication de bases de données entre comptes Snowflake (au sein de la même entreprise) tout en conservant la synchronisation des objets de base de données et des données stockées. La réplication de base de données est prise en charge à travers les régions et les plates-formes Cloud.

Dans ce chapitre :

Qu’est-ce qu’une base de données principale ?
Vue d’ensemble de la réplication
Réplication de base de données et chiffrement
Réplication de base de données vers des comptes sur des éditions inférieures
Limitations actuelles de la réplication

Qu’est-ce qu’une base de données principale ?¶

La réplication peut être activée pour toute base de données permanente ou transitoire existante. L’activation de la réplication désigne la base de données en tant que base de données principale. Un nombre quelconque de bases de données dans un compte peut être désigné comme base de données principale. De même, une base de données principale peut être répliquée sur un nombre quelconque de comptes de votre entreprise. Cela implique la création d’une base de données secondaire en tant que réplique d’une base de données principale spécifiée dans chacun des comptes cibles. Ces comptes se trouvent généralement dans d’autres régions, sur la même plate-forme Cloud ou sur une plate-forme Cloud différente. Ils peuvent également se trouver dans la même région que le compte source.

Toutes les opérations DML/DDL sont exécutées sur la base de données principale. Chaque base de données secondaire en lecture seule peut être actualisée périodiquement avec un instantané de la base de données principale, en répliquant toutes les données ainsi que des opérations DDL sur des objets de base de données (schémas, tables, vues, etc.).

Vue d’ensemble de la réplication¶

Cette section fournit une vue d’ensemble de haut-niveau des objets et paramètres disponibles pour 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 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 flux.
UDFs		✔	Pour plus de détails, voir Réplication des procédures stockées et des fonctions définies par l’utilisateur (UDFs).
Politiques	Accès aux rangées et sécurité au niveau des colonnes (masquage)	✔	Pour plus de détails, lire ces considérations sur la réplication des politiques.
Politiques de masquage basées sur les balises	Politiques de masquage basées sur les balises	✔	Pour plus de détails, lire ces considérations sur la réplication des politiques.
Balises	Balisage d’objets	✔	Le comportement de la réplication des balises est le même que celui de la réplication des politiques.

Autres objets d’un compte¶

La réplication est prise en charge pour les bases de données uniquement. D’autres types d’objets dans un compte peuvent être répliqués avec la réplication de compte. Pour la liste complète des objets pris en charge pour la réplication de compte, voir Objets répliqués.

Contrôle d’accès¶

Les privilèges accordés sur les objets de base de données ne sont pas répliqués dans une base de données secondaire. Cela inclut les autorisations de privilèges sur les objets de base de données existants ainsi que les autorisations sur les objets futurs (c’est-à-dire les autorisations futures).

Les octrois de privilèges peuvent être répliqués avec la réplication de compte.

Paramètres¶

Les paramètres de compte ne sont pas répliqués avec la réplication de base de données. Les paramètres de compte peuvent être répliqués avec la réplication du compte.

Les paramètres d’objet qui sont définis au niveau du schéma ou de l’objet de schéma sont répliqués :

Paramètre

Objets

DATA_RETENTION_TIME_IN_DAYS

schéma, table

DEFAULT_DDL_COLLATION

schéma, table

MAX_DATA_EXTENSION_TIME_IN_DAYS

schéma, table

PIPE_EXECUTION_PAUSED ^[1]

schéma, canal

QUOTED_IDENTIFIERS_IGNORE_CASE

schéma, table

La réplication des paramètres n’est applicable qu’aux objets de la base de données (schéma, table) et uniquement si le paramètre est explicitement défini à l’aide de CREATE <objet> <paramètre> ou ALTER <objet> …. SET <paramètre>. Les paramètres au niveau de la base de données ne sont pas répliqués.

Les paramètres définis explicitement sur les objets de la base de données primaire écrasent les paramètres définis sur les objets de la base de données secondaire. Par exemple, si la base de données primaire a un schéma s1 avec DATA_RETENTION_TIME_IN_DAYS défini sur 10 et que la base de données secondaire a DATA_RETENTION_TIME_IN_DAYS défini sur 1 au niveau de la base de données, DATA_RETENTION_TIME_IN_DAYS pour le schéma s1 dans la base de données secondaire est défini sur 10 après la réplication.

Les paramètres explicitement définis au niveau de la base de données sur les bases de données secondaires ne sont pas écrasés. Par exemple, si le paramètre DATA_RETENTION_TIME_IN_DAYS de la base de données secondaire est explicitement défini sur 1 et que le paramètre DATA_RETENTION_TIME_IN_DAYS de la base de données principale est explicitement défini sur 10, DATA_RETENTION_TIME_IN_DAYS de la base de données secondaire reste défini sur 1 après la réplication.

^[1] Notez que les objets PIPE ne sont pas répliqués. Si le paramètre PIPE_EXECUTION_PAUSED est défini au niveau du schéma dans la base de données principale, il est répliqué dans la base de données secondaire. Lorsque la base de données secondaire est promue en base de données principale dans le cas d’un basculement et qu’un canal est créé, le paramètre prend effet.

Réplication de base de données et chiffrement¶

Lorsqu’une base de données est répliquée sur un autre compte (à la fois lors de la réplication initiale et ultérieurement, lorsqu’une base de données secondaire est actualisée), Snowflake chiffre les fichiers de base de données (c’est-à-dire les métadonnées d’objets de base de données et les ensembles de données) en transit du compte source vers le compte cible. Snowflake chiffre les fichiers pour les opérations de réplication de base de données en utilisant une clé unique et aléatoire pour chaque tâche de réplication.

De plus, si Tri-Secret Secure est activé pour les comptes de réplication (c’est-à-dire les comptes source et cible), les fichiers sont chiffrés à l’aide de la clé publique d’une paire de clés de chiffrement protégée par la clé maîtresse de compte (AMK) pour votre compte cible. Le niveau de sécurité supplémentaire fourni par Tri-Secret Secure protège le AMK. Cette protection s’applique donc également aux fichiers de données en transit.

Notez que les garanties Tri-Secret sont également valables pour les fichiers de données en transit. La révocation de l’accès à la clé gérée par le client (dans le service de gestion de clés du fournisseur de Cloud hébergeant votre compte Snowflake) empêche Snowflake de déchiffrer les fichiers de données en transit.

Lors de la réplication entre des comptes activés par Tri-Secret Secure, la même clé n’est pas requise pour les comptes source et cible.

Pour plus d’informations sur le chiffrement des données dans Snowflake, voir Chiffrement des données.

Réplication de base de données vers des comptes sur des éditions inférieures¶

Si l’une des conditions suivantes est remplie, Snowflake affiche un message d’erreur lorsqu’une base de données locale est désignée comme base de données principale :

La base de données principale 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.
La base de données principale se trouve dans un compte Business Critical (ou supérieur) et un accord de partenariat commercial signé est en place pour stocker des données PHI dans le compte conformément aux réglementations HIPAA et HITRUST CSF, mais aucun accord de ce type n’est en place pour un ou plusieurs des comptes approuvé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 peut remplacer ce comportement par défaut en incluant la clause IGNORE EDITION CHECK lors de l’exécution de l’instruction ALTER DATABASE … ENABLE REPLICATION TO ACCOUNTS. Si IGNORE EDITION CHECK est défini, la base de données primaire peut être répliquée vers les comptes spécifiés sur une édition Snowflake quelconque.

Limitations actuelles de la réplication¶

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.
Les bases de données créées à partir de partages ne peuvent pas être répliquées.