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.

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.

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.

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 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 USERS dans la liste OBJECT_TYPES.

Pour plus de détails, reportez-vous à Politiques réseau dans la rubrique Réplication des intégrations de sécurité et des politiques de réseau à travers plusieurs comptes.

Politiques de mot de passe et de session¶

Les références de politiques de mot de passe et de session pour les 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.

Tables externes dans une base de données principale¶

Les tables externes d’une base de données principale provoquent actuellement l’échec de l’opération de réplication ou d’actualisation avec le message d’erreur suivant :

003906 (55000): SQL execution error:
Primary database contains an external table '<database_name>'. Replication of a database with external table is not supported

Pour éviter cette erreur, déplacez les tables externes dans une base de données distincte qui n’est pas répliquée. Par ailleurs, si vous migrez vos bases de données vers un autre compte, vous pouvez cloner la base de données principale, détruire la table externe du clone, puis répliquer la base de données clonée. Après avoir promu la base de données secondaire dans le compte cible, vous devrez recréer les tables externes dans la base de données.

Tables externes dans une base de données secondaire¶

Les tables externes peuvent exister dans une base de données secondaire si celle-ci était la base de données primaire à un moment passé et que les tables externes ont été créées durant cette période. Une fois qu’une autre base de données est promue au rang de base de données primaire désignée, elle devient une base de données secondaire. Les tables externes dans une base de données secondaire font actuellement échouer l’opération de rafraîchissement avec l’erreur suivante :

003958 (55000): SQL execution error:
Secondary database contains an external table '<table_name>'. Replication of a database with external table is not supported.

Pour éviter cette erreur, déplacez la table externe dans une base de données distincte qui n’est pas une base de données secondaire répliquée.

Éviter 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 fréquence 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, reportez-vous à Réouverture des canaux actifs pour Snowpipe Streaming dans le compte source venant d’être 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

Limites¶

La réplication avec des flux sur des tables Snowflake alimentées par Snowpipe Streaming n’est pas activée. Si vous souhaitez répliquer des flux sur des tables Snowflake alimentées par Snowpipe Streaming, contactez le Support Snowflake.

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 de répertoire

• Tables externes

• Tables ou vues dans des bases de données distinctes des bases de données de flux.

  Notez que cette conception fonctionne 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).

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.

É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 des tâches autonomes et des tâches dans un DAG :

É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 la tâche n’est pas disponible (par exemple, une tâche enfant est détruite mais une nouvelle version de la tâche DAG n’est pas encore validée), 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.

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 toutes les tâches autonomes reprises et des DAGs dépend du nombre de tâches reprises dans une base de données.