Remarques relatives à la réplication¶

Objets de base de données et de partage¶

Les contraintes suivantes s’appliquent aux objets de base de données et de partage :

• Un objet ne peut faire partie que d’un seul groupe de basculement.

• Un objet peut faire partie de plusieurs groupes de réplication, à condition que chaque groupe soit répliqué vers un compte cible différent.

• Un objet ne peut pas être à la fois dans un groupe de basculement et dans un groupe de réplication.

• Les objets secondaires (réplicas) ne peuvent pas être ajoutés à un groupe de réplication ou de basculement principal.

Vous ne pouvez répliquer que des partages sortants. La réplication des partages entrants (partages provenant des fournisseurs) n’est pas prise en charge.

Objets de compte¶

Un compte ne peut avoir qu’un seul groupe de réplication ou de basculement qui contient des objets de compte autres que des bases de données ou des partages.

Politiques de session et rôles secondaires¶

Pour plus de détails, voir Politiques de session avec rôles secondaires

Références pendantes et politiques réseau¶

Les références pendantes dans les politiques réseau peuvent faire échouer la réplication avec le message d’erreur suivant :

Dangling references in the snapshot. Correct the errors before refreshing again.
The following references are missing (referred entity <- [referring entities])

Afin d’éviter les références pendantes, spécifiez les types d’objets suivants dans la liste OBJECT_TYPES lors de l’exécution de la commande CREATE ou ALTER pour le groupe de réplication ou de basculement :

• Si une politique réseau utilise une règle réseau, incluez la base de données qui contient le schéma où la règle réseau a été créée.

• Si une politique de réseau est associée au compte, incluez NETWORK POLICIES et ACCOUNT PARAMETERS dans la liste OBJECT_TYPES.

• Si une politique réseau est associée à un utilisateur, incluez NETWORK POLICIES et USERS dans la liste OBJECT_TYPES.

Pour plus de détails, voir Réplication des politiques réseau.

Références pendantes et politiques de paquets¶

Si une politique de paquets est définie sur le compte, l’erreur de références pendantes suivante se produit lors de l’opération d’actualisation d’un groupe de réplication ou de basculement contenant des objets de compte :

003131 (55000): Dangling references in the snapshot. Correct the errors before refreshing again.
The following references are missing (referred entity <- [referring entities]):
POLICY '<policy_db>.<policy_schema>.<packages_policy_name>' <- [ACCOUNT '<account_locator>']

Pour éviter les références pendantes, répliquez la base de données qui contient la politique de paquets dans le compte cible. La base de données contenant la politique peut se trouver dans le même groupe de réplication ou de basculement ou dans un groupe différent.

Références pendantes et secrets¶

Pour plus de détails, voir Réplication et secrets.

Références pendantes et flux¶

Les références pendantes pour les flux entraînent l’échec de la réplication avec le message d’erreur suivant :

Primary database: the source object ''<object_name>'' for this stream ''<stream_name>'' is not included in the replication group.
Stream replication does not support replication across databases in different replication groups. Please see Streams Documentation
https://docs.snowflake.com/en/user-guide/account-replication-considerations#replication-and-streams for options.

Pour éviter les erreurs de référence pendante :

• La base de données primaire doit inclure à la fois le flux et son objet de base ou

• La base de données qui contient le flux et la base de données qui contient l’objet de base référencé par le flux doivent être incluses dans le même groupe de réplication ou de basculement.

Objets recréés dans les comptes cibles¶

Si un objet existant dans le compte source est remplacé à l’aide d’une instruction CREATE OR REPLACE, l’objet existant est supprimé, puis un nouvel objet portant le même nom est créé en une seule transaction. Par exemple, si vous exécutez une instruction CREATE OR REPLACE pour une table existante t1, la table t1 est supprimée et une nouvelle table t1 est créée. Pour plus d’informations, voir les notes sur l’utilisation de CREATE TABLE.

Lorsque des objets sont remplacés sur le compte cible, les instructions DROP et CREATE ne s’exécutent pas de manière atomique lors d’une opération d’actualisation. Cela signifie que l’objet peut disparaître brièvement du compte cible pendant qu’il est recréé sous forme de nouvel objet.

Politiques d’authentification, de mot de passe et de session¶

Les références aux politiques d’authentification, de mot de passe et de session des utilisateurs sont répliquées lorsque l’on spécifie la base de données contenant la politique (ALLOWED_DATABASES = policy_db) et USERS dans un groupe de réplication ou un groupe de basculement.

Si la base de données de politique ou les utilisateurs ont déjà été répliqués sur un compte cible, mettez à jour le groupe de réplication ou de basculement du compte source afin d’inclure les bases de données et les types d’objets nécessaires à la réplication réussie de la politique. Exécutez ensuite une opération d’actualisation pour mettre à jour le compte cible.

Si les politiques de niveau utilisateur ne sont pas utilisées, USERS n’a pas besoin d’être inclus dans le groupe de réplication ou de basculement.

Politiques de confidentialité¶

Tenez compte des éléments suivants lors de la réplication des politiques de confidentialité et des tables et vues protégées associées à la Confidentialité différentielle :

• Si une politique de confidentialité est attribuée à une table ou à une vue dans le compte source, la politique doit être répliquée dans le compte cible.

• La perte cumulée de confidentialité pour un budget de confidentialité n’est pas répliquée.

• Les pertes cumulées de confidentialité dans les comptes cible et source sont suivies séparément.

• Les administrateurs du compte cible ne peuvent pas ajuster le budget de confidentialité répliqué. Le budget de confidentialité est synchronisé avec celui du compte source.

• Si un analyste a accès à la table ou à la vue protégée à la fois dans le compte source et dans le compte cible, il peut encourir deux fois le montant de perte de confidentialité avant d’atteindre la limite du budget de confidentialité.

• Les domaines de confidentialité définis dans les colonnes sont également répliqués.

Politiques de session avec rôles secondaires¶

Si vous utilisez des politiques de session avec des rôles secondaires, vous devez spécifier la base de données de politiques dans le même groupe de réplication qui contient les rôles. Par exemple :

CREATE REPLICATION GROUP myrg
  OBJECT_TYPES = DATABASES, ROLES, USERS
  ALLOWED_DATABASES = session_policy_db
  ALLOWED_ACCOUNTS = myorg.myaccount
  REPLICATION_SCHEDULE = '10 MINUTE';

Si vous spécifiez la base de données de politique de session qui référence les rôles secondaires dans un autre groupe de réplication ou de basculement (rg2) que le groupe de réplication ou de basculement qui contient des objets au niveau du compte (myrg) et que vous répliquez ou basculez rg2 en premier, une référence pendante s’affiche. Un message d’erreur indique de placer la base de données de politique de session dans le groupe de réplication ou de basculement qui contient les rôles. Ce comportement se produit lorsque la politique de session est définie sur le compte ou les utilisateurs.

Si la politique de session ou les objets au niveau du compte se trouvent dans des groupes de réplication différents et que la politique de session n’est pas définie sur le compte ou les utilisateurs, vous pouvez répliquer et actualiser le compte cible. Assurez-vous d’actualiser d’abord le groupe de réplication qui contient les objets au niveau du compte.

Si vous actualisez le compte cible après avoir répliqué ou basculé la politique de session avec des rôles secondaires et des objets de rôle, le compte cible reflète la politique de session et le comportement des rôles secondaires dans le compte source.

De plus, lorsque vous actualisez la base de données dans le compte cible et que la base de données contient une politique de session qui fait référence à des rôles secondaires, ALLOWED_SECONDARY_ROLES correspond toujours à [ALL].

Réplication logique des clones¶

Si la table originale et la table clonée sont incluses dans le même groupe de basculement ou de réplication, la table clonée peut être répliquée logiquement sur le compte cible.

Par exemple, si la table t2 de la base de données db2 est un clone de la table t1 de la base de données db1, et que les deux bases de données sont incluses dans le groupe de réplication rg1, la table t2 est créée en tant que clone logique dans le compte cible.

Un objet cloné peut être cloné pour créer d’autres clones de l’objet d’origine. L’objet original et les objets clonés font partie du même groupe de clones. Par exemple, si la table t3 de la base de données db3 est créée en tant que clone de t2, elle fait partie du même groupe de clonage que la table d’origine t1 et la table clonée t2.

Si la base de données db3 est ajoutée ultérieurement au groupe de réplication rg1, la table t3 est créée dans le compte cible en tant que clone logique de la table t1.

CREATE REPLICATION GROUP myrg
    OBJECT_TYPES = DATABASES
    ALLOWED_DATABASES = db1, db2
    ALLOWED_ACCOUNTS = myorg.myaccount2
    REPLICATION_SCHEDULE = '10 MINUTE';

Tables dynamiques et groupes de réplication¶

Une base de données contenant une table dynamique peut être répliquée à l’aide d’un groupe de réplication. Le ou les objets sources dont elle dépend n’ont pas l’exigence d’être dans le même groupe de réplication.

Les objets répliqués dans chaque compte cible sont appelés objets secondaires et sont des réplications des objets primaires du compte source. Les objets secondaires sont en lecture seule dans le compte cible. Si un groupe de réplication secondaire est abandonné dans un compte cible, les bases de données qui étaient incluses dans le groupe deviennent en lecture/écriture. Cependant, toutes les tables dynamiques incluses dans un groupe de réplication restent en lecture seule même après la suppression du groupe secondaire dans le compte cible. Aucune actualisation DML ou de table dynamique ne peut avoir lieu sur ces tables dynamiques en lecture seule.

Tables dynamiques et groupes de basculement¶

Une base de données contenant une table dynamique peut être répliquée à l’aide d’un groupe de basculement. Si une table dynamique fait référence à des objets sources situés en dehors du groupe de basculement ou de la réplication de base de données, elle peut toujours être répliquée. Après un basculement, la table dynamique résout les objets sources à l’aide de la résolution de noms lors de l’actualisation. L’actualisation peut réussir ou échouer, en fonction de l’état des objets sources. En cas de succès, la table dynamique est réinitialisée avec les données les plus récentes des objets sources.

Les tableaux dynamiques secondaires sont en lecture seule et ne sont pas actualisés. Après un basculement et la promotion d’une table dynamique secondaire en table dynamique principale, la première actualisation est une réinitialisation suivie d’actualisations incrémentielles si la table dynamique est configurée pour une actualisation incrémentielle des données.

Exemple : Échec de l’actualisation en raison d’objets sources manquants

Si une table dynamique dépend d’une table source située en dehors du groupe de basculement, elle ne peut pas être actualisée après un basculement. Dans le diagramme ci-dessus, la table dynamique dt du compte principal est répliquée sur le compte secondaire. dt dépend de source_table, qui ne fait pas partie du même groupe de basculement que le compte principal. Après le basculement, l’actualisation du compte secondaire échoue car source_table ne peut pas être résolu.

Exemple : Rafraîchissement réussi lorsque les objets sources existent dans le compte secondaire via une réplication séparée

Dans le diagramme ci-dessus, la table dynamique dt dépend de source_table. dt et source_table dans le compte principal sont répliquées sur le compte secondaire par l’intermédiaire de groupes de basculement indépendants. Après la réplication et le basculement, lorsque dt est actualisé dans le compte secondaire, l’actualisation réussit car source_table peut être trouvé par la résolution de noms.

Exemple : Actualisation réussie lorsque les objets sources existent localement dans le compte secondaire

Dans le schéma ci-dessus, la table dynamique dt dépend de source_table et est répliquée par un groupe de basculement du compte principal vers le compte secondaire. Un site source_table est créé localement dans le compte secondaire. Après le basculement, lorsque dt1 est actualisé dans le compte secondaire, l’actualisation peut réussir parce que source_table peut être trouvé par la résolution de noms.

Prévention de la perte de données¶

Pour éviter toute perte de données en cas de basculement, la durée de conservation des données pour les lignes insérées avec succès dans votre source de données en amont doit être supérieure à la planification de réplication. Si des données sont insérées dans une table d’une base de données primaire et que le basculement se produit avant que les données puissent être répliquées dans la base de données secondaire, les mêmes données devront être insérées dans la table de la base de données primaire qui vient d’être promue. Voici un exemple de scénario :

1. La table t1 dans la base de données primaire repl_db est alimentée en données par Snowpipe Streaming et le connecteur Kafka.

2. Le offsetToken est 100 pour le canal 1 et 100 pour le canal 2 pour t1 dans la base de données primaire.

3. Une opération d’actualisation se termine avec succès dans le compte cible.

4. Le offsetToken est 100 pour le canal 1 et 100 pour le canal 2 pour le t1 dans la base de données secondaire.

5. D’autres lignes sont insérées dans t1 dans la base de données primaire.

6. Le offsetToken est maintenant 200 pour le canal 1 et 200 pour le canal 2 pour le t1 dans la base de données primaire.

7. Un basculement se produit avant que les lignes supplémentaires et les nouveaux décalages de canaux puissent être répliqués dans la base de données secondaire.

Dans ce cas, il manque 100 décalages dans chaque canal pour la table t1 dans la base de données primaire venant d’être promue. Pour insérer les données manquantes, voir Rouvrir des canaux actifs pour Snowpipe Streaming dans le nouveau compte source promu.

Exigences¶

La prise en charge de la réplication Snowpipe Streaming nécessite les versions minimales suivantes :

• Snowflake Ingest SDK versions 1.1.1 et ultérieures

• Si vous utilisez le connecteur Kafka : connecteur Kafka version 1.9.3 et ultérieure

La durée de conservation des données pour les lignes insérées avec succès dans votre source de données en amont doit être supérieure à la fréquence de réplication. Si vous utilisez le connecteur Kafka, assurez-vous que votre configuration log.retention est définie avec un tampon suffisant.

Procédures stockées, UDFs et zones de préparation¶

Si une procédure stockée ou une UDF dépend de fichiers dans une zone de préparation (par exemple, si la procédure stockée est définie dans un code Python qui est chargé à partir d’une zone de préparation), vous devez répliquer la zone de préparation et ses fichiers vers la base de données secondaire. Pour plus d’informations sur la réplication des zones de préparation, voir Réplication des zones de préparation, des canaux et de l’historique des chargements.

Par exemple, si une base de données principale possède une UDF Python en ligne qui importe tout code stocké dans une zone de préparation, l’UDF ne fonctionne pas tant que la zone de préparation et le code importé ne sont pas répliqués dans la base de données secondaire.

Procédures stockées, UDFs et accès réseau externe¶

Si une procédure stockée ou une UDF dépend de l’accès à un emplacement réseau externe, vous devez répliquer les objets suivants :

• Les EXTERNALACCESSINTEGRATIONS doivent être incluses dans la liste allowed_integration_types pour le groupe de réplication ou de basculement.

• La base de données qui contient la règle réseau.

• La base de données qui contient le secret qui stocke les identifiants de connexion permettant l’authentification auprès de l’emplacement réseau externe.

• Si l’objet secret fait référence à une intégration de sécurité, vous devez inclure SECURITY INTEGRATIONS dans la liste allowed_integration_types pour le groupe de réplication ou de basculement.

Objets sources pris en charge pour les flux¶

Les flux répliqués peuvent suivre avec succès les données de modification pour les tables et les vues dans la même base de données.

Actuellement, les types d’objets sources suivants ne sont pas pris en charge :

• Tables externes

• Tables ou vues dans des bases de données distinctes des bases de données de flux, sauf si la base de données de flux et la base de données qui stocke l’objet source sont incluses dans le même groupe de réplication ou de basculement.

• Tables ou vues dans des bases de données partagées (c’est-à-dire des bases de données partagées entre des comptes de fournisseurs et votre compte).

La réplication de flux sur les tables de répertoire est prise en charge lorsque vous activez Réplication des zones de préparation, des canaux et de l’historique des chargements.

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.

Éviter la duplication des données¶

La duplication des données se produit lorsque les opérations DML écrivent plusieurs fois les mêmes données de modification d’un flux sans contrôle d’unicité. Cela peut se produire si un flux et une table de destination pour les données de modification de flux sont stockés dans des bases de données distinctes, et que ces bases de données ne sont pas répliquées et basculées dans le même groupe.

Par exemple, supposons que vous insérez régulièrement des données de modification provenant du flux s dans la table dt. (Pour cet exemple, l’objet source du flux n’a pas d’importance). Des bases de données distinctes stockent le flux et la table de destination.

1. À l’horodatage t1, une ligne est insérée dans la table source pour le flux s, créant ainsi une nouvelle version de la table. Le flux stocke le décalage pour cette version de la table.

2. À l’horodatage t2, la base de données secondaire qui stocke le flux est actualisée. Le flux répliqué s stocke maintenant le décalage.

3. À l’horodatage t3, les données de modification du flux s sont insérées dans la table dt.

4. À l’horodatage t4, la base de données secondaire qui stocke le flux s est basculée.

5. À l’horodatage t5, les données de modification du flux s sont à nouveau insérées dans la table dt.

Pour éviter cette situation, répliquez et basculez ensemble les bases de données qui stockent les flux et leurs tables de destination.

Références de flux dans la tâche WHEN Clause¶

Pour éviter tout comportement inattendu lors de l’exécution de tâches répliquées qui font référence à des flux dans la clause WHEN boolean_expr nous vous recommandons soit de :

• créer les tâches et les flux dans la même base de données, ou

• Si les flux sont stockés dans une base de données différente de celle des tâches qui les référencent, incluez les deux bases de données dans le même groupe de basculement.

Si une tâche fait référence à un flux dans une base de données distincte, et que les deux bases de données ne sont pas incluses dans le même groupe de basculement, la base de données qui contient la tâche peut être basculée sans la base de données qui contient le flux. Dans ce scénario, lorsque la tâche est reprise dans la base de données basculée, elle enregistre une erreur lorsqu’elle tente de s’exécuter et ne trouve pas le flux référencé. Ce problème peut être résolu soit en basculant la base de données qui contient le flux, soit en recréant la base de données et le flux dans le même compte que la base de données basculée qui contient la tâche.

Obsolescence des flux¶

Si un flux dans la base de données principale est devenu obsolète, le flux répliqué dans une base de données secondaire est également obsolète et ne peut pas être interrogé ou ses données de modification consommées. Pour résoudre ce problème, recréez le flux dans la base de données principale (en utilisant CREATE OR REPLACE STREAM). Lorsque la base de données secondaire est actualisée, le flux répliqué est à nouveau lisible.

Notez que le décalage pour un flux recréé est la version actuelle de la table par défaut. Vous pouvez recréer un flux qui pointe vers une version antérieure de la table en utilisant Time Travel ; cependant, le flux répliqué resterait illisible. Pour plus d’informations, voir Réplication de flux et Time Travel (dans cette rubrique).

Réplication de flux et Time Travel¶

Après le basculement d’une base de données principale, si un flux de la base de données utilise Time Travel pour lire une version de la table pour l’objet source à partir d’un moment antérieur au dernier horodatage d’actualisation, le flux répliqué ne peut pas être interrogé ou les données de modification consommées. De même, l’interrogation des données de modification d’un objet source à partir d’un moment antérieur au dernier horodatage d’actualisation à l’aide de la clause CHANGES pour les instructions SELECT échoue avec une erreur.

En effet, une opération d’actualisation réduit l’historique de la table à une seule version de la table. Les versions de tables itératives créées avant l’horodatage de l’opération d’actualisation ne sont pas conservées dans l’historique des tables pour les objets sources répliqués.

Prenons l’exemple suivant :

1. La table t1 est créée dans la base de données principale avec le suivi des modifications activé (version de la table tv0). Les transactions DML suivantes créent des versions de table tv1 et tv2.

2. Une base de données secondaire qui contient la table t1 est actualisée. La version de la table pour cette table répliquée est tv2 ; cependant, l’historique de la table n’est pas répliqué.

3. Un flux est créé dans la base de données principale avec son décalage défini sur la version de table tv1 en utilisant Time Travel.

4. La base de données secondaire est basculée et devient la base de données principale.

5. L’interrogation du flux s1 renvoie une erreur, car la version de la table tv1 ne figure pas dans l’historique de la table.

Notez que lorsqu’une transaction DML ultérieure sur la table t1 itère la version de la table vers tv3, le décalage pour le flux s1 est avancé. Le flux est à nouveau lisible.

Éviter la perte de données¶

Une perte de données peut se produire lorsque l’opération d’actualisation la plus récente d’une base de données secondaire n’est pas terminée avant l’opération de basculement. Nous vous recommandons d’actualiser fréquemment vos bases de données secondaires pour réduire le risque.

Scénarios de réplication¶

Le tableau suivant décrit différents scénarios de tâches et précise si les tâches sont répliquées ou non. Sauf indication contraire, les scénarios concernent à la fois les tâches autonomes et les tâches dans un graphique des tâches :

État repris ou suspendu des tâches répliquées¶

Si toutes les conditions suivantes sont réunies, une tâche est répliquée vers une base de données secondaire dans un état repris :

• Une tâche autonome ou racine est dans un état repris dans la base de données principale lorsque l’opération de réplication ou d’actualisation commence jusqu’à ce que l’opération soit terminée. Si une tâche est dans un état repris pendant une partie seulement de cette période, elle peut encore être répliquée dans un état repris.

  Une tâche enfant est dans un état repris dans la dernière version de la tâche.

• La base de données parent a été répliquée sur le compte cible avec des objets de rôle dans le même groupe de réplication ou de basculement , ou dans un groupe différent.

  Une fois les rôles et la base de données répliqués, vous devez actualiser les objets du compte cible en exécutant soit ALTER REPLICATION GROUP … REFRESH ou ALTER FAILOVER GROUP … REFRESH, respectivement. Si vous actualisez la base de données en exécutant ALTER DATABASE … REFRESH, l’état des tâches dans la base de données devient suspendu.

  Une opération de réplication ou d’actualisation inclut les attributions de privilèges pour une tâche qui étaient en cours lorsque la dernière version de la table a été validée. Pour plus d’informations, voir Tâches répliquées et attributions de privilèges (dans cette rubrique).

Si ces conditions ne sont pas remplies, la tâche est répliquée dans une base de données secondaire dans un état suspendu.

Tâches répliquées et attributions de privilèges¶

Si la base de données parent est répliquée sur un compte cible avec des objets de rôle dans le même groupe de réplication ou de basculement, ou dans un groupe différent, les privilèges accordés aux tâches de la base de données sont également répliqués.

La logique suivante détermine quels privilèges de tâche sont répliqués lors d’une opération de réplication ou d’actualisation :

• Si le propriétaire actuel de la tâche (c’est-à-dire le rôle qui a le privilège OWNERSHIP sur une tâche) est le même rôle que lors de la dernière reprise de la tâche, tous les privilèges actuels sur la tâche sont répliqués dans la base de données secondaire.

• Si le propriétaire actuel de la tâche n’est pas le même rôle que lors de la dernière reprise de la tâche, alors seul le privilège OWNERSHIP accordé au rôle de propriétaire dans la version de la tâche est répliqué dans la base de données secondaire.

• Si le rôle actuel de propriétaire de tâche n’est pas disponible (par exemple, une tâche enfant est détruite, mais une nouvelle version du graphique de tâches n’est pas encore validée), seul le privilège OWNERSHIP accordé au rôle de propriétaire dans la version de tâche est répliqué dans la base de données secondaire.

Exécution des tâches après un basculement¶

Après qu’un groupe de basculement secondaire a été promu pour servir de groupe principal, toutes les tâches reprises dans les bases de données du groupe de basculement sont programmées progressivement. Le temps nécessaire pour rétablir la programmation normale de l’ensemble des tâches autonomes et graphiques de tâches repris dépend du nombre de tâches reprises dans une base de données.