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 :

Cette section 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.

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

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.

Réplication et politiques (masquage et accès aux lignes)

Pour les politiques de masquage et d’accès aux lignes , si l’une des conditions suivantes est remplie, l’opération de réplication initiale ou une opération d’actualisation ultérieure échoue :

  • 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.

  • Une politique contenue dans la base de données principale fait référence à une politique dans une autre base de données.

Réplication et flux de table

Comme indiqué dans Objets de base de données répliqués, actuellement, les flux de tables d’une base de données principale ne sont pas répliqués dans des bases de données secondaires. Les flux delta peuvent être créés sur des tables secondaires, mais la tentative de créer des flux d’ajout uniquement produit une erreur utilisateur. La clause CHANGES fonctionne de la même manière. Pour suivre les données de modification delta sur les tables d’une base de données secondaire, utilisez la clause CHANGES dans les requêtes sur les tables d’une base de données secondaire.

En outre, si le suivi des modifications est activé pour une table, seule la version actuelle de la table au moment de l’actualisation de la base de données secondaire est répliquée. Les versions des tables entre les actualisations ne sont pas répliquées. Pour suivre les données de modification d’ajout uniquement dans les tables d’une base de données secondaire, il est actuellement nécessaire de promouvoir la base de données secondaire pour qu’elle serve de base de données principale. Ensuite, les utilisateurs peuvent créer des flux de tables dans la même base de données ou dans une autre base de données du même compte. Ces flux de tables ne suivent que les changements dans les tables qui ont été initiées et complétées après la promotion de la base de données secondaire.

Pour créer un flux au moment où la base de données qui stocke une table a été promue, utilisez la syntaxe CREATE STREAM … AT | BEFORE. La clause AT | BEFORE détermine le point du passé à partir duquel des données historiques sont demandées pour la table.

Time Travel

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.

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.

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 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 <privileges> … TO ROLE.

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 fonctions de table ou Account Usage les vues suivantes :

  • COPY_HISTORY

  • LOGIN_HISTORY

  • QUERY_HISTORY

  • etc.