Remarques relatives à la réplication¶
Cette rubrique décrit le comportement de certaines fonctionnalités Snowflake dans des bases de données secondaires et les objets lorsqu’ils sont répliqués avec les groupes de réplication ou de basculement ou la réplication de base de données, et fournit des conseils généraux pour utiliser des objets et des données répliqués.
Si vous avez précédemment activé la réplication de base de données pour des bases de données individuelles à l’aide de la commande ALTER DATABASE … ENABLE REPLICATION TO ACCOUNTS, référez-vous à Remarques relatives à la réplication de base de données pour des considérations supplémentaires spécifiques à la réplication de base de données.
Dans ce chapitre :
Contraintes du groupe de réplication et du groupe de basculement¶
Les sections suivantes expliquent les contraintes liées à l’ajout d’objets de compte, de bases de données et de partages à des groupes de réplication et de basculement.
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.
Privilèges de réplication¶
Cette section décrit les privilèges de réplication qui peuvent être accordés à des rôles pour spécifier les opérations que les utilisateurs peuvent effectuer sur des objets de groupes de réplication et de basculement dans le système. Pour la syntaxe de la commande GRANT, reportez-vous à GRANT <privilèges>.
Note
Pour la réplication de base de données, seul un utilisateur ayant le rôle ACCOUNTADMIN peut activer et gérer la réplication et le basculement de la base de données. Pour plus d’informations sur les privilèges requis pour la réplication de base de données, voir le tableau privilèges requis dans Étape 6. Actualisation d’une base de données secondaire sur une planification.
Privilège |
Objet |
Utilisation |
Remarques |
---|---|---|---|
OWNERSHIP |
Groupe de réplication Groupe de basculement |
Donne la possibilité de supprimer, de modifier, d’accorder ou de révoquer l’accès à un objet. |
Peut être accordé par :
|
CREATE REPLICATION GROUP |
Compte |
Donne la possibilité de créer un groupe de réplication. |
Doit être accordé par le rôle ACCOUNTADMIN. |
CREATE FAILOVER GROUP |
Compte |
Donne la possibilité de créer un groupe de basculement. |
Doit être accordé par le rôle ACCOUNTADMIN. |
FAILOVER |
Groupe de basculement |
Donne la possibilité de promouvoir un groupe de basculement secondaire pour servir de groupe de basculement principal. |
Peut être accordé ou révoqué par un rôle ayant le privilège OWNERSHIP sur le groupe. |
REPLICATE |
Groupe de réplication Groupe de basculement |
Donne la possibilité d’actualiser un groupe secondaire. |
Peut être accordé ou révoqué par un rôle ayant le privilège OWNERSHIP sur le groupe. |
MODIFY |
Groupe de réplication Groupe de basculement |
Permet de modifier les paramètres ou les propriétés d’un objet. |
Peut être accordé ou révoqué par un rôle ayant le privilège OWNERSHIP sur le groupe. |
MONITOR |
Groupe de réplication Groupe de basculement |
Donne la possibilité de voir les détails d’un objet. |
Peut être accordé ou révoqué par un rôle ayant le privilège OWNERSHIP sur le groupe. |
Pour obtenir des instructions sur la création d’un rôle personnalisé avec un ensemble spécifique de privilèges, voir Création de rôles personnalisés.
Pour des informations générales sur les rôles et les privilèges accordés pour effectuer des actions SQL sur des objets sécurisables, voir Aperçu du contrôle d’accès.
Réplication et références à travers les groupes de réplication¶
Les objets d’un groupe de réplication (ou de basculement) qui ont des références pendantes (c’est-à-dire des références à des objets d’un autre groupe de réplication ou de basculement) peuvent être répliqués avec succès vers un compte cible dans certaines circonstances. Si l’opération de réplication entraîne un comportement dans le compte cible cohérent avec le comportement qui peut se produire dans le compte source, la réplication réussit.
Par exemple, si une colonne d’une table du groupe de basculement fg_a
fait référence à une séquence du groupe de basculement fg_b
, la réplication des deux groupes réussit. Si fg_a
est répliqué avant fg_b
, les opérations d’insertion (après basculement) sur la table qui fait référence à la séquence échouent si fg_b
n’a pas été répliqué. Ce comportement peut se produire dans un compte source. Si une séquence est détruite dans un compte source, les opérations d’insertion sur une table dont une colonne fait référence à la séquence détruite échouent.
Lorsque la référence pendante est une politique de sécurité qui protège des données, le groupe de réplication (ou de basculement) avec la politique de sécurité doit être répliqué avant que tout groupe de réplication contenant des objets qui font référence à la politique soit répliqué.
Attention
La mise à jour des politiques de sécurité qui protègent les données dans des groupes de réplication ou de basculement distincts peut entraîner des incohérences et doit être effectuée avec précaution.
Pour les objets de base de données, vous pouvez visualiser les dépendances d’objets dans la Vue OBJECT_DEPENDENCIES Account Usage.
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
etACCOUNT PARAMETERS
dans la listeOBJECT_TYPES
.Si une politique réseau est associée à un utilisateur, incluez
USERS
dans la listeOBJECT_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.
Réplication et objets secondaires en lecture seule¶
Tous les objets secondaires d’un compte cible, y compris les bases de données et les partages, sont en lecture seule. Les modifications apportées à des objets ou à des types d’objets répliqués ne peuvent pas être effectuées localement dans un compte cible. Par exemple, si le type d’objet USERS
est répliqué d’un compte source vers un compte cible, de nouveaux utilisateurs ne peuvent pas être créés ou modifiés dans le compte cible.
De nouvelles bases de données locales et des partages peuvent être créés et modifiés dans un compte cible. Si des ROLES
sont également répliqués dans le compte cible, de nouveaux rôles ne peuvent pas être créés ou modifiés dans ce compte cible. C’est pourquoi des privilèges ne peuvent pas être accordés à un rôle (ni révoqués d’un rôle) sur un objet secondaire dans le compte cible. Toutefois, des privilèges peuvent être accordés à un rôle secondaire (ou révoqués) sur des objets locaux (par exemple, des bases de données, des partages ou des groupes de réplication ou de basculement) créés dans le compte cible.
Réplication et objets dans les comptes cibles¶
Si vous créez des objets de compte, par exemple des utilisateurs et des rôles, dans votre compte cible par un moyen autre que via la réplication (par exemple, en utilisant des scripts), ces utilisateurs et rôles n’ont pas d’identificateur global par défaut. Lorsqu’un compte cible est actualisé à partir du compte source, l’opération d’actualisation détruit tous les objets de compte des types de la liste OBJECT_TYPES
(c’est-à-dire les USERS
ou les ROLES
) du compte cible qui n’ont pas d’identificateur global.
Pour éviter la destruction de ces objets, reportez-vous à Appliquer des IDs globaux à des objets créés par des scripts dans des comptes cibles.
Politiques de réplication et de sécurité¶
La base de données contenant une politique de sécurité et les références (c’est-à-dire les affectations) peut être répliquée à l’aide de groupes de réplication et de basculement. Les politiques de sécurité incluent les éléments suivants :
Si vous utilisez la réplication de base de données, reportez-vous à Politiques de réplication de base de données et de sécurité.
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.
Note
La politique doit être dans le même compte que l’affectation de politique au niveau du compte et l’affectation de politique au niveau de l’utilisateur.
Si vous avez défini une politique de session ou de mot de passe sur le compte ou un utilisateur du compte et que vous ne mettez pas à jour le groupe de réplication ou de basculement pour inclure les policy_db
contenant la politique et les USERS
, une référence pendante se produit dans le compte cible. Dans ce cas, une référence pendante signifie que Snowflake ne peut pas localiser la politique dans le compte cible, parce que le nom entièrement qualifié de la politique pointe vers la base de données dans le compte source. Par conséquent, le compte cible ou les utilisateurs du compte cible ne sont pas tenus de respecter la politique de session ou la politique de mot de passe.
Pour répliquer avec succès une politique de sécurité, vérifiez que le groupe de réplication ou de basculement comprend les types d’objets et les bases de données nécessaires pour éviter une référence pendante.
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éplication et clustering automatique¶
Dans une 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é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, reportez-vous à Gestion des coûts pour les tables de grande taille et à roulement élevé.
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 d’une 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, reportez-vous à Paramètres.
Réplications et vues matérialisées¶
Dans une 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 une 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 une 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.
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 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.
Réplication et Streaming Snowpipe¶
Une table alimentée par Snowpipe Streaming dans une base de données primaire est répliquée dans la base de données secondaire d’un compte cible.
Dans la base de données primaire, les tables sont créées et les lignes sont insérées par l’intermédiaire de canaux. Des jetons de décalage permettent de suivre la progression de l’ingestion. Une opération d’actualisation réplique l’objet de table, les données de table et les décalages de canaux associés à la table de la base de données primaire vers la base de données secondaire.
Les opérations en lecture seule de Snowflake Streaming pour récupérer les décalages sont disponibles dans les comptes source et cible :
Le canal getLatestCommittedOffsetToken API
Commande SHOW CHANNELS
Les opérations d’écriture de Snowflake Streaming ne sont disponibles que dans le compte source :
Le client openChannel API
Le canal insertRow API
Le canal insertRows API
É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 :
La table
t1
dans la base de données primairerepl_db
est alimentée en données par Snowpipe Streaming et le connecteur Kafka.Le
offsetToken
est 100 pour le canal 1 et 100 pour le canal 2 pourt1
dans la base de données primaire.Une opération d’actualisation se termine avec succès dans le compte cible.
Le
offsetToken
est 100 pour le canal 1 et 100 pour le canal 2 pour let1
dans la base de données secondaire.D’autres lignes sont insérées dans
t1
dans la base de données primaire.Le
offsetToken
est maintenant 200 pour le canal 1 et 200 pour le canal 2 pour let1
dans la base de données primaire.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.
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 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 bases de données sur plusieurs comptes 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.
À l’horodatage
t1
, une ligne est insérée dans la table source pour le fluxs
, créant ainsi une nouvelle version de la table. Le flux stocke le décalage pour cette version de la table.À 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.À l’horodatage
t3
, les données de modification du fluxs
sont insérées dans la tabledt
.À l’horodatage
t4
, la base de données secondaire qui stocke le fluxs
est basculée.À l’horodatage
t5
, les données de modification du fluxs
sont à nouveau insérées dans la tabledt
.
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 :
La table
t1
est créée dans la base de données principale avec le suivi des modifications activé (version de la tabletv0
). Les transactions DML suivantes créent des versions de tabletv1
ettv2
.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 esttv2
; cependant, l’historique de la table n’est pas répliqué.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.La base de données secondaire est basculée et devient la base de données principale.
L’interrogation du flux
s1
renvoie une erreur, car la version de la tabletv1
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.
Réplication et tâches¶
Cette section décrit la réplication des tâches dans Réplication de bases de données sur plusieurs comptes 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.
Note
Toutes les tâches secondaires sont suspendues indépendamment de leur state
. Pour plus de détails, consultez le document Exécution des tâches après un basculement.
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.
Réplication et balises¶
Les balises et leurs affectations peuvent être répliquées d’un compte source à un compte cible.
Les attributions de balises ne peuvent pas être modifiées dans le compte cible après la réplication initiale à partir du compte source. Par exemple, la mise en place d’une balise sur une base de données secondaire (c’est-à-dire répliquée) n’est pas autorisée. Pour modifier les attributions de balises dans le compte cible, il faut les modifier dans le compte source et les répliquer dans le compte cible.
Pour réussir à répliquer les balises, il faut s’assurer que le groupe de réplication ou de basculement comprend les éléments suivants :
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 exempleROLES
,WAREHOUSES
).Pour plus de détails, reportez-vous à CREATE REPLICATION GROUP et CREATE FAILOVER GROUP.
Données d’utilisation historiques¶
Les données d’utilisation historiques pour l’activité dans une 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.