Remarques relatives à la réplication de base de données

Cette rubrique décrit le comportement de certaines fonctionnalités Snowflake dans des bases de données secondaires et fournit des conseils généraux pour utiliser des objets et des données répliqués.

Dans ce chapitre :

Réplication et clustering automatique

Dans la base de données principale, Snowflake surveille les tables en cluster à l’aide de Clustering automatique et effectue un reclustering au besoin. Dans le cadre d’une opération d’actualisation, les tables en cluster sont répliquées dans une base de données secondaire avec le tri en cours des micro-partitions de table. En tant que tel, le reclustering n’est pas exécuté à nouveau sur les tables en cluster de la base de données secondaire, ce qui serait redondant.

Si une base de données secondaire contient des tables en cluster et si la base de données devient la base de données principale, Snowflake démarre le clustering automatique des tables de cette base de données tout en suspendant simultanément la surveillance des tables en cluster de la base de données principale précédente.

Voir Réplication et vues matérialisées (dans cette rubrique) pour obtenir des informations sur le clustering automatique des vues matérialisées.

Réplications et vues matérialisées

Dans la base de données principale, Snowflake effectue une maintenance automatique en arrière-plan des vues matérialisées. Lorsqu’une table de base est modifiée, toutes les vues matérialisées définies sur la table sont mises à jour par un service d’arrière-plan utilisant les ressources de calcul fournies par Snowflake. En outre, si le clustering automatique est activé pour une vue matérialisée, alors celle-ci est surveillée et fait l’objet d’un reclustering selon les besoins dans la base de données principale.

Une opération d’actualisation réplique les définitions de la vue matérialisée dans une base de données secondaire ; les données de la vue matérialisée ne sont pas répliquées. La maintenance en arrière-plan automatique des vues matérialisées dans une base de données secondaire est activée par défaut. Si le clustering automatique est activé pour une vue matérialisée dans la base de données principale, la surveillance et le reclustering automatiques de la vue matérialisée dans la base de données secondaire sont également activés.

Voir aussi Références pendantes (dans cette rubrique).

Note

  • Les frais de synchronisation automatisée en arrière-plan des vues matérialisées sont facturés à chaque compte qui contient une base de données secondaire.

Réplication et tables externes

Tables externes dans la base de données primaire

Les tables externes de la 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 contourner cette limitation, nous vous recommandons de déplacer 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 contourner cette limitation, nous vous recommandons de déplacer la table externe dans une base de données distincte qui n’est pas une base de données secondaire répliquée.

Politiques de réplication et de sécurité

Politiques

Les objets de politique de masquage et de politique d’accès aux lignes ainsi que leurs affectations peuvent être répliqués à l’aide de la réplication de bases de données et de groupes de réplication.

Pour la réplication de base de données, l’opération de réplication échoue si l’une des conditions suivantes est vraie :

  • La base de données principale se trouve dans un compte Enterprise (ou supérieur) et contient une politique/balise, mais au moins un des comptes approuvés pour la réplication se trouve sur des éditions inférieures.

  • Un objet contenu dans la base de données principale a une référence pendante à une balise dans une autre base de données.

Le comportement de la référence pendante pour la réplication des bases de données peut être évité lors de la réplication de plusieurs bases de données dans un groupe de réplication.

Note

En cas d’utilisation des actions de basculement et de restauration, le compte Snowflake doit être Business Critical Edition ou supérieur.

Pour plus d’informations, voir Réplication de base de données et basculement/restauration.

Politiques de masquage basées sur les balises

Si une balise a été précédemment répliquée à l’aide de la réplication de base de données à partir de la base de données principale vers la base de données secondaire, et qu’une politique de masquage est affectée à une balise stockée dans un schéma de la base de données principal, notez ce qui suit concernant l’opération d’actualisation de la base de données secondaire :

  • Si la politique de masquage basée sur les balises est affectée à une table, une vue ou une colonne du compte secondaire, l’opération d’actualisation fonctionne.

  • Si la balise répliquée est affectée à un schéma ou à une base de données du compte secondaire, ou affectée au compte secondaire lui-même, l’opération d’actualisation de ces objets échoue.

Pour plus de détails sur cette politique, voir Politiques de masquage basées sur les balises.

Politiques réseau

Pour plus de détails, voir réplication de la politique réseau.

Mots de passe et politiques de session

Ces objets peuvent être répliqués à l’aide de la réplication de base de données et des groupes de réplication.

Pour la réplication de base de données, l’opération de réplication échoue si l’une des conditions suivantes est vraie :

  • La base de données principale se trouve dans un compte Enterprise (ou supérieur) et contient une politique, mais au moins un des comptes approuvés pour la réplication se trouve sur des éditions inférieures.

  • L’un ou l’autre de ces objets contenus dans la base de données primaire est attaché à un utilisateur du même compte. Dans ce cas, Snowflake échoue l’opération de réplication.

Pour éviter l’échec de l’opération de réplication de la base de données en raison d’une référence à un utilisateur, utilisez plutôt un groupe de réplication.

Pour plus de détails, reportez-vous à Politiques de réplication et de sécurité (dans la rubrique sur la réplication des comptes).

Réplication et flux

Cette section décrit les pratiques recommandées et les domaines de préoccupation potentiels lors de la réplication de flux dans Réplication de base de données et basculement/restauration ou Réplication de compte et basculement/restauration.

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

Note

Outre le scénario décrit dans cette section, les flux d’une base de données secondaire pourraient renvoyer des lignes en double la première fois qu’ils sont inclus dans une opération d’actualisation. Dans ce cas, lignes dupliquées fait référence à une seule ligne avec plusieurs valeurs de colonnes METADATA$ACTION.

Après l’opération initiale d’actualisation, vous ne devriez pas rencontrer ce problème spécifique dans une base de données secondaire.

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 :

Stream replication and Time Travel
  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 t1 et t2.

  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 t2 ; 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 est 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.

Activer la réplication

Pour activer l’avant-première de la réplication des flux, voir Activer l’aperçu de la réplication des flux et des tâches — Facultatif.

Réplication et balises

Les balises et leurs affectations peuvent être répliquées à l’aide de la réplication de base de données et des groupes de réplication.

Les affectations de balises du compte source sont reportées sur le compte cible. Cependant, les affectations de balises dans le compte source ne peuvent pas être modifiées dans le compte cible après la réplication. Par exemple, la mise en place d’une balise sur une base de données répliquée n’est pas autorisée. Notez que dans une opération d’actualisation de la réplication, Snowflake met à jour les affectations de balises dans le compte cible pour qu’elles correspondent aux affectations de balises dans le compte source.

Pour la réplication de base de données, l’opération de réplication échoue si l’une des conditions suivantes est vraie :

  • La base de données principale se trouve dans un compte Enterprise (ou supérieur) et contient une balise, mais au moins un des comptes approuvés pour la réplication se trouve sur des éditions inférieures.

  • Un objet contenu dans la base de données principale a une référence pendante à une balise dans une autre base de données.

Vous pouvez éviter le comportement de référence pendante avec la réplication de la base de données, ainsi que les références pendantes sur les objets au niveau du compte, en utilisant un groupe de réplication. Assurez-vous que le groupe de réplication spécifie :

  • La base de données contenant les balises de la propriété ALLOWED_DATABASES.

  • Autres objets au niveau du compte qui ont une balise dans la propriété OBJECT_TYPES (par exemple ROLES, WAREHOUSES).

    Pour plus de détails, reportez-vous à CREATE REPLICATION GROUP et CREATE FAILOVER GROUP.

Note

Lorsque vous utilisez la réplication de bases de données ou des groupes de réplication :

  • En cas d’utilisation des actions de basculement et de restauration, le compte Snowflake doit être Business Critical Edition ou supérieur.

    Pour plus d’informations, reportez-vous à Réplication de base de données et basculement/restauration.

  • Si vous spécifiez la clause IGNORE EDITION CHECK pour la réplication des bases de données dans une instruction ALTER DATABASE ou dans un groupe de réplication avec une instruction CREATE REPLICATION GROUP ou ALTER REPLICATION GROUP , la réplication des balises peut se produire lorsque le compte cible est une édition inférieure à Business Critical.

    Pour plus de détails, reportez-vous à la description des clauses de ces commandes.

Réplication et tâches

Cette section décrit la réplication des tâches dans Réplication de base de données et basculement/restauration ou la réplication des comptes et le basculement/la récupération.

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 :

Scénario

Répliqué

Remarques

La tâche a été créée et reprise ou exécutée manuellement (en utilisant EXECUTE TASK). La reprise ou l’exécution d’une tâche crée une version initiale de la tâche.

La tâche a été créée mais n’a jamais été reprise ou exécutée.

La tâche a été recréée (en utilisant CREATE OR REPLACE TASK), mais n’a jamais été reprise ou exécutée.

La dernière version avant que la tâche a été recréée est répliquée.

La reprise ou l’exécution manuelle de la tâche valide une nouvelle version. Lorsque la base de données est à nouveau répliquée, la nouvelle, ou dernière version est répliquée dans la base de données secondaire.

La tâche a été créée et reprise ou exécutée, puis modifiée (à l’aide de ALTER TASK), mais pas reprise ou exécutée à nouveau.

La reprise ou l’exécution manuelle d’une tâche valide une nouvelle version qui inclut toutes les modifications apportées aux paramètres de la tâche. Comme les nouvelles modifications n’ont jamais été validées, la dernière version avant la suspension et la modification de la tâche est répliquée.

Notez que si la tâche modifiée n’est pas reprise dans une période de conservation (actuellement 30 jours), la dernière version de la tâche est détruite. Après cette période, la tâche n’est pas répliquée dans une base de données secondaire, sauf si elle est reprise à nouveau.

Une tâche autonome a été créée et reprise ou exécutée, mais elle a ensuite été détruite.

La tâche racine d’un DAG a été créée et reprise ou exécutée, mais a ensuite été suspendue et détruite.

La totalité de DAG n’est pas répliquée dans une base de données secondaire.

Une tâche enfant dans un DAG est créée et reprise ou exécutée, mais est ensuite suspendue et détruite.

La dernière version du DAG (avant que la tâche ne soit suspendue et détruite) est répliquée dans une base de données secondaire.

É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 planification 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.

Activer la réplication des tâches

Pour activer l’aperçu de la réplication des tâches, voir Activer l’aperçu de la réplication des flux et des tâches — Facultatif.

Réplication et Time Travel

Les données Time Travel et Fail-safe sont maintenues indépendamment pour une base de données secondaire et ne sont pas répliquées à partir de la base de données principale. L’interrogation de tables et de vues dans une base de données secondaire à l’aide de Time Travel peut produire des résultats différents de ceux obtenus lors de l’exécution de la même requête dans la base de données principale.

Données historiques

Les données historiques disponibles pour une requête dans une base de données principale à l’aide de Time Travel ne sont pas répliquées vers des bases de données secondaires.

Par exemple, supposons que les données soient chargées en permanence dans une table toutes les 10 minutes à l’aide de Snowpipe, et qu’une base de données secondaire soit actualisée toutes les heures. L’opération d’actualisation ne réplique que la dernière version de la table. Bien que chaque version horaire de la table dans la fenêtre de conservation soit disponible pour une requête utilisant Time Travel, aucune des versions itératives de chaque heure (les charges Snowpipe individuelles) n’est disponible.

Période de conservation des données

La période de conservation des données pour les tables d’une base de données secondaire commence lorsque la base de données secondaire est actualisée avec les opérations DML (c.-à-d. modification ou suppression de données) écrites dans les tables de la base de données principale.

Note

Le paramètre de période de conservation des données, DATA_RETENTION_TIME_IN_DAYS, n’est répliqué que sur les objets de la base de données secondaire, et non sur la base de données elle-même. Pour plus de détails sur la réplication des paramètres, voir Paramètres.

Réplication et tables de grande taille et à roulement élevé

Lorsqu’une ou plusieurs lignes d’une table sont mises à jour ou supprimées, toutes les micro-partitions touchées qui stockent ces données dans une base de données principale sont recréées et doivent être synchronisées avec les bases de données secondaires. Pour les tables de grande taille et à roulement élevé, les coûts de réplication peuvent être importants.

Pour les tables de grande taille et à roulement élevé qui entraînent des coûts de réplication importants, les mesures d’atténuation suivantes sont disponibles :

  • Répliquez moins fréquemment les bases de données principales qui stockent ces tables.

  • Modifiez votre modèle de données pour réduire le roulement.

Pour plus d’informations, voir Gestion des coûts pour les tables de grande taille et à roulement élevé.

Réplication et clonage

Les objets clonés sont répliqués physiquement plutôt que logiquement vers des bases de données secondaires. C’est-à-dire que les tables clonées dans une base de données standard ne contribuent pas au stockage de données global à moins que ou jusqu’à ce que les opérations DML sur le clone ajoutent ou modifient des données existantes. Cependant, lorsqu’une table clonée est répliquée dans une base de données secondaire, les données physiques le sont également, ce qui augmente l’utilisation du stockage de données pour votre compte.

Références pendantes

Références aux objets d’une autre base de données

Analysez soigneusement si les vues ou les contraintes de table dans une base de données principale font référence aux objets d’une autre base de données.

Vues
  • Les vues non matérialisées qui référencent n’importe quel objet d’une autre base de données (par exemple, colonnes de table, autres vues, UDFs ou zones de préparation) peuvent être répliquées, car ce type de référence est basé sur un nom. Les références basées sur des noms n’entraînent pas l’échec de la réplication. Cependant, les requêtes sur la vue dans les bases de données secondaires échoueront si les autres bases de données ne sont pas répliquées dans la même région.

    Par exemple, supposons que la vue v1 dans la base de données d1 fasse référence aux tables t1 et t2 dans les bases de données d1 et d2, respectivement. Pour interroger la vue V1 dans la base de données secondaire d1, la base de données secondaire d2 doit également exister dans le compte (par exemple, en tant qu’autre base de données secondaire). En outre, pour des résultats de requête cohérents avec les bases de données principales, les bases de données d1 et d2 secondaires doivent être actualisées simultanément.

  • Les vues matérialisées qui font référence à tout objet dans une autre base de données entraînent actuellement l’échec de la réplication ou de l’actualisation, 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])
    

    En effet, les vues matérialisées font référence aux objets par ID plutôt que par nom. Un instantané de base de données ne peut pas résoudre les références basées sur ID aux objets extérieurs à la base de données.

    Pour contourner cette limitation, nous vous recommandons de stocker les vues matérialisées et les objets auxquels elles font référence dans la même base de données.

Contraintes

Actuellement, la suspension des clés étrangères entraîne l’échec de 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])

Cette situation se produit lorsqu’une clé étrangère dans la base de données principale fait référence à une clé principale dans une autre base de données, ou vice-versa. En effet, les références aux contraintes sont basées sur ID. Un instantané de base de données ne peut pas résoudre les références basées sur ID aux objets extérieurs à sa propre base de données.

Pour afficher les références de clé étrangère dans votre compte, interrogez la vue TABLE_CONSTRAINTS dans le schéma Information Schema ou le schéma ACCOUNT_USAGE.

Pour contourner cette limitation, nous vous recommandons de stocker les tables liées dans la même base de données.

Séquences

Actuellement, la suspension de séquences entraîne l’échec de 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])

Cette situation se produit lorsqu’une table dans une base de données principale fait référence à une séquence dans une autre base de données. C’est parce que les références de séquence sont basées sur un ID. Un instantané de base de données ne peut pas résoudre les références basées sur ID aux objets extérieurs à sa propre base de données.

Pour contourner cette limitation, nous vous recommandons de faire référence à des séquences dans la même base de données.

Politiques et balises

Une référence pendante pour une politique de masquage, une politique d’accès aux lignes, ou une balise non respectée entraîne l’échec de 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])

Cette situation se produit lorsque la politique/la balise et l’objet auquel la politique/la balise est attribué(e) existent dans des bases de données différentes. Par exemple, une table nommée db1.s1.t1, une politique d’accès aux lignes nommée db2.s1.rap1, et la politique d’accès aux lignes est attribuée à la table.

Ce comportement de référence pendante s’applique à la réplication des bases de données.

Pour contourner ce problème, répliquez les bases de données en utilisant les groupes de réplication.

Une référence pendante peut également se produire lorsqu’une politique réseau est assignée à un utilisateur dans le contexte de Réplication et basculement de compte. Pour plus de détails, voir réplication de la politique réseau.

Références aux objets détruits

Le fait de détruire un objet auquel un autre objet fait référence dans la même base de données ou dans une autre entraîne une référence pendante. Lorsqu’un objet de la base de données principale fait référence à un objet détruit, une opération de réplication échoue 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])

Pour contourner cette limitation, nous vous recommandons de suivre l” une des étapes suivantes :

  • Rétablissez les objets référencés.

  • Modifiez les objets de référence (par exemple, modifiez une vue matérialisée en utilisant ALTER MATERIALIZED VIEW). Soit vous faites référence à un objet différent, soit vous supprimez la référence à l’objet détruit.

  • Dans la base de données principale, détruisez tous les objets qui font référence aux objets détruits.

Réplication des procédures stockées et des fonctions définies par l’utilisateur (UDFs)

Les procédures stockées et les UDFs sont répliquées d’une base de données primaire vers des bases de données secondaires.

Notez que la réplication de zone de préparation n’est pas encore prise en charge. 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 manuellement la zone de préparation et ses fichiers vers la base de données secondaire.

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

Réplication et contrôle d’accès

Les bases de données secondaires sont en lecture seule ; cependant, le propriétaire de la base de données (c’est-à-dire le rôle qui a le privilège OWNERSHIP sur la base de données secondaire) peut accorder des privilèges sur les objets de la base de données (c.-à-d. schémas, tables, vues, etc.) à d’autres rôles à l’aide de GRANT <privilèges>.

Réplication de plusieurs bases de données

Lorsque plusieurs bases de données sont répliquées, la cohérence ponctuelle entre les bases de données n’est pas disponible. Un instantané de chaque base de données principale est créé indépendamment et les modifications apportées à la base de données secondaire sont validées indépendamment. Cela peut être problématique si vous avez des vues qui joignent des tables dans différentes bases de données ou qui dépendent de transactions entre bases de données. Par exemple, une transaction qui met à jour deux bases de données principales de façon atomique peut ne pas être reflétée dans les bases de données secondaires au même moment.

Données d’utilisation historiques

Les données d’utilisation historiques pour l’activité dans la base de données principale ne sont pas répliquées dans des bases de données secondaires. Chaque compte a son propre historique de requêtes, d’historique de connexion, etc.

Les données d’utilisation historiques incluent les données de requêtes renvoyées par les Schéma d’information de Snowflake fonctions de table ou Account Usage les vues suivantes :

  • COPY_HISTORY

  • LOGIN_HISTORY

  • QUERY_HISTORY

  • etc.

Revenir au début