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 ; cependant, les données de la vue matérialisée ne sont pas répliquées, ce qui signifie que certaines ou toutes les données des vues matérialisées peuvent devenir obsolètes.

Pour effectuer la maintenance en arrière-plan automatique des vues matérialisées dans une base de données secondaire, configurez explicitement AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = TRUE sur la base de données secondaire lorsque vous créez la base de données secondaire (avec CREATE DATABASE … AS REPLICA OF) ou ultérieure (à l’aide de ALTER DATABASE). Si le clustering automatique est activé pour une vue matérialisée dans la base de données principale, le paramétrage de AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = TRUE sur une base de données secondaire permet également d’effectuer une surveillance et un reclustering automatiques de la vue matérialisée dans la base de données secondaire.

Voir également Références aux objets dans une autre base de données (dans cette rubrique).

Note

Les frais de maintenance de la vue matérialisée sont facturés au compte où le paramètre AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY est activé pour une base de données secondaire.

Politiques de réplication et de masquage

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 de masquage, mais un ou plusieurs des comptes approuvés pour la réplication se trouvent sur des éditions inférieures.

  • Une politique de masquage contenue dans la base de données principale est appliquée aux colonnes d’une table ou d’une vue dans une autre base de données, ou vice-versa.

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 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 à 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 référencent tout objet dans une autre base de données entraînent actuellement l’échec de la réplication ou de l’actualisation. En effet, les vues matérialisées référencent les 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.

Contraintes

Actuellement, la suspension des clés étrangères entraînera l’échec de la réplication. Cette situation se produit lorsqu’une clé étrangère dans la base de données principale fait référence à une clé primaire 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.

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.

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.