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 ?¶
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 plateforme Cloud ou sur une plateforme Cloud différente.
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 |
✔ |
||
Flux |
Prévision : pour une future version de la réplication de base de données. |
||
Tâches |
Prévision : pour une future version de la réplication de base de données. |
||
UDFs SQL et JavaScript |
✔ |
||
Politiques |
Accès aux rangées et sécurité au niveau des colonnes (masquage) |
✔ |
L’opération de réplication est bloquée dans l’un des cas d’utilisation suivants : . La base de données principale se trouve dans un compte Enterprise (ou supérieur) et contient une politique, mais un ou plusieurs des comptes approuvés pour la réplication se trouvent sur des éditions inférieures. . Une politique contenue dans la base de données principale a une référence à une politique dans une autre base de données. |
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¶
Actuellement, la réplication est prise en charge pour les bases de données uniquement. Les autres types d’objets d’un compte ne peuvent pas être répliqués. Cette liste comprend :
Utilisateurs
Rôles
Entrepôts
Moniteurs de ressources
Partages
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.
Paramètres¶
Les paramètres de compte ne sont pas répliqués.
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
schéma, table
schéma, table
schéma, table
schéma, canal
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.