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.
Note
Snowflake recommande d’utiliser la Présentation de la réplication et du basculement à travers plusieurs comptes pour répliquer les bases de données. Les groupes de réplication et de basculement permettent la réplication de plusieurs bases de données et d’autres objets de compte avec une cohérence ponctuelle pour les objets du groupe. Pour une liste complète de la disponibilité des fonctionnalités et des objets pris en charge, reportez-vous à Présentation de la réplication et du basculement à travers plusieurs comptes.
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 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 de base de données¶
Pour la liste complète des objets de base de données répliqués, voir Objets de base de données répliqués.
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
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 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.
Limites actuelles de la réplication de base de données¶
Les bases de données créées à partir de partages ne peuvent pas être répliquées.
L’opération d’actualisation échoue si une base de données principale contient l’un des éléments suivants :
Table des événements
Table externe
Une opération de réplication ou d’actualisation de la base de données échoue si la base de données principale inclut un flux avec un objet source non pris en charge. L’opération échoue également si l’objet source d’un flux a été détruit.
Les flux d’ajout uniquement ne sont pas pris en charge sur les objets sources répliqués.
La commande CREATE DATABASE … AS REPLICA ne prend pas en charge la clause WITH TAG.
Cette clause n’est pas prise en charge, car la base de données secondaire est en lecture seule. Si votre base de données principale spécifie la clause WITH TAG, supprimez la clause avant de créer la base de données secondaire. Pour vérifier si votre base de données possède la clause WITH TAG, appelez la fonction GET_DDL dans votre compte Snowflake et spécifiez la base de données principale dans l’argument de la fonction. Si une balise est définie dans la base de données, la sortie de la fonction comprendra une instruction ALTER DATABASE… SET TAG.
La réplication des zones de préparation et des canaux n’est pas prise en charge. Vous pouvez répliquer les zones de préparation et les tuyaux à l’aide de la réplication des comptes. Pour plus d’informations, consultez Réplication des zones de préparation, des canaux et de l’historique des chargements.
Les secrets ne sont pas pris en charge. Vous pouvez répliquer le secret à l’aide d’un groupe de réplication ou de basculement.