Réplication des zones de préparation, des canaux et de l’historique des chargements¶
Cette rubrique fournit des informations sur la prise en charge de la réplication pour les objets de pipeline de données et les métadonnées associées, y compris les zones de préparation, les intégrations de stockage, les canaux et l’historique de chargement. Vous pouvez répliquer ces objets pour configurer le basculement des pipelines d’ingestion et ETL dans les régions et dans les plateformes Cloud.
Avant de commencer, nous vous recommandons de vous familiariser avec le support de Snowflake pour la réplication et le basculement/la restauration. Pour plus d’informations, consultez Présentation de la réplication et du basculement à travers plusieurs comptes.
Exigences¶
Important
Si une base de données dans un compte cible que vous prévoyez d’utiliser contient déjà contient des zones de préparation et des canaux, nous vous recommandons de contacter l’assistance avant d’activer la réplication. Lorsqu’un groupe de réplication ou de basculement de votre compte source inclut cette base de données, l’ensemble des zones de préparation et canaux préexistants sont supprimés de la base de données.
Avant de pouvoir répliquer les objets du pipeline de données, vous devez activer la réplication ETL. La prise en charge de la réplication ETL fait partie du bundle 2024_01 BCR. Vous pouvez activer le bundle 2024_01 BCR en exécutant l’instruction suivante :
SELECT SYSTEM$ENABLE_BEHAVIOR_CHANGE_BUNDLE('2024_01');
Pour répliquer toutes les zones de préparation externes qui utilisent une intégration de stockage, vous devez également configurer votre groupe de réplication ou de basculement pour répliquer STORAGE INTEGRATIONS
. Dans le cas contraire, les zones de préparation externes sont répliquées sans l’intégration de stockage associée.
Vous pouvez utiliser une instruction ALTER REPLICATION GROUP ou ALTER FAILOVER GROUP pour modifier ces propriétés pour un groupe existant.
Note
Si vous ajoutez INTEGRATIONS
à la liste OBJECT_TYPES
dans votre instruction ALTER, vous devez inclure tous les autres objets existants dans la liste afin d’éviter de supprimer ces objets dans le compte cible. Il en va de même si vous ajoutez STORAGE INTEGRATIONS
à la liste ALLOWED_INTEGRATION_TYPES
.
Par exemple :
ALTER FAILOVER GROUP my_failover_group SET
OBJECT_TYPES = ROLES, INTEGRATIONS
ALLOWED_INTEGRATION_TYPES = API INTEGRATIONS, STORAGE INTEGRATIONS;
Réplication et zones de préparation¶
Cette section décrit le niveau actuel de fonctionnalité de réplication que Snowflake prend en charge pour différents types de zones de préparation.
Réplication des zones de préparation internes¶
Le tableau suivant décrit le fonctionnement de la réplication pour chaque type de zone de préparation interne.
Type |
Description de l’aide à la réplication |
---|---|
Zone de préparation de table |
Des zones de préparation de table vides sont créées pour les tables d’une base de données répliquée. Les fichiers sur les zones de préparation de tables ne sont pas répliqués. |
Zone de préparation de l’utilisateur |
La réplication de l’utilisateur et de la zone de préparation de l’utilisateur nécessite Business Critical Edition (ou une version plus récente). Des zones de préparation d’utilisateurs vides sont créées pour les utilisateurs répliqués. Les fichiers sur les zones de préparation d’utilisateurs ne sont pas répliqués. |
Zone de préparation nommée |
Les zones de préparation internes nommées sont répliquées lorsque vous répliquez une base de données. Une table de répertoire doit être activée sur la zone de préparation afin de répliquer les fichiers qui s’y trouvent. |
Réplication des zones de préparation externes¶
Note
Snowflake ne réplique pas les fichiers sur une zone de préparation externe. L’URL de stockage Cloud pointe vers le même emplacement pour les zones de préparation externes dans les bases de données principales et secondaires.
Le tableau suivant décrit le fonctionnement de la réplication pour chaque type de zone de préparation externe.
Type |
Description de l’aide à la réplication |
---|---|
Zone de préparation nommée sans identifiants de connexion (emplacement de stockage public) |
Les zones de préparation externes nommées sont répliquées lorsque vous répliquez une base de données. Les fichiers d’une zone de préparation externe ne sont pas répliqués. |
Zone de préparation nommée avec identifiants de connexion (emplacement de stockage privé) |
Les zones de préparation répliquées comprennent les identifiants de connexion du fournisseur Cloud, telles que les clés secrètes ou les jetons d’accès. |
Zone de préparation nommée avec intégration de stockage (emplacement de stockage privé) |
La réplication d’intégration de stockage nécessite Business Critical Edition (ou une version supérieure). Le groupe de réplication ou de basculement doit inclure Vous devez également prendre des mesures pour configurer les relations de confiance pour votre stockage Cloud dans les comptes cibles. Pour plus d’informations, consultez Configurer l’accès au stockage Cloud pour les intégrations de stockage secondaire. |
Note
Pour associer une zone de préparation ou un canal secondaire à un emplacement de stockage dans le cloud différent de celui associé à l’objet principal, contactez l’équipe d’assistance. Par exemple, vous pouvez choisir un site dans une autre région.
Considérations¶
Les contraintes suivantes s’appliquent aux objets de zone de préparation :
Snowflake prend actuellement en charge la réplication de zone de préparation dans le cadre de la réplication par groupe (groupes de réplication et de basculement). La réplication de zones de préparation n’est pas prise en charge pour la réplication des bases de données.
Vous pouvez reproduire une zone de préparation externe. Cependant, les fichiers d’une zone de préparation externe ne sont pas répliqués.
Vous pouvez répliquer une zone de préparation interne. Pour répliquer les fichiers d’une zone de préparation interne, vous devez activer une table de répertoire sur la zone de préparation. Snowflake ne réplique que les fichiers qui sont mappés par la table de répertoire.
Lorsque vous répliquez une zone de préparation interne avec une table de répertoire, vous ne pouvez pas désactiver la table de répertoire sur la zone de préparation primaire ou secondaire. La table des répertoires contient des informations essentielles sur les fichiers répliqués et les fichiers chargés à l’aide d’une instruction COPY.
Une opération d’actualisation échoue si la table des répertoires d’une zone de préparation interne contient un fichier dont la taille est supérieure à 5GB. Pour contourner cette limitation, déplacez tous les fichiers d’une taille supérieure à 5GB vers une autre zone de préparation.
Vous ne pouvez pas désactiver la table de répertoire sur une zone de préparation principale ou secondaire, ou sur une zone de préparation qui a déjà été répliquée. Suivez ces étapes avant d’ajouter la base de données qui contient la zone de préparation à un groupe de réplication ou de basculement.
Désactivez la table de répertoire sur la zone de préparation principale.
Déplacez les fichiers dont la taille est supérieure à 5GB vers une autre zone de préparation où la table des répertoires n’est pas activée.
Après avoir déplacé les fichiers vers une autre zone de préparation, réactivez la table des répertoires sur la zone de préparation principale.
Les fichiers sur les zones de préparation d’utilisateur et de table ne sont pas répliqués.
Pour les zones de préparation externes nommées qui utilisent une intégration de stockage, vous devez configurer la relation de confiance pour les intégrations de stockage secondaires dans vos comptes cibles avant le basculement. Pour plus d’informations, consultez Configurer l’accès au stockage Cloud pour les intégrations de stockage secondaire.
Si vous répliquez une zone de préparation externe avec une table de répertoire et que vous avez configuré l’actualisation automatique pour la table de répertoire source, vous devez configurer l’actualisation automatique pour la table de répertoire secondaire avant le basculement. Pour plus d’informations, consultez Configuration de l’actualisation automatique des tables de répertoire dans les zones de préparation secondaires.
Une commande de copie peut prendre plus de temps que prévu si la table des répertoires d’une zone de préparation répliquée n’est pas cohérente avec les fichiers répliqués de cette zone de préparation. Pour rendre une table de répertoire cohérente, rafraîchissez-la à l’aide d’une instruction ALTER STAGE… REFRESH. Pour vérifier le statut de cohérence d’une table de répertoire, utilisez la fonction SYSTEM$GET_DIRECTORY_TABLE_STATUS.
Réplication et canaux¶
Cette section décrit le niveau actuel des fonctionnalités de réplication prises en charge pour les différents types de canaux.
Snowflake prend en charge la réplication pour les éléments suivants :
Objets « canaux », y compris les canaux « intégration automatique » et des points de terminaison REST qui chargent des données à partir de zones de préparation externes.
Paramètres au niveau du canal.
Octroi de privilèges sur les objets de type canal.
Note
Pour associer une zone de préparation ou un canal secondaire à un emplacement de stockage dans le cloud différent de celui associé à l’objet principal, contactez l’équipe d’assistance. Par exemple, vous pouvez choisir un site dans une autre région.
Canaux dans des bases de données secondaires¶
Les canaux d’une base de données secondaire reçoivent des notifications mais ne chargent pas de données tant que la base de données secondaire n’est pas promue au rang de base de données primaire. Après la promotion d’une base de données secondaire, les canaux commencent à charger toutes les données disponibles depuis la dernière actualisation (c’est-à-dire la dernière mise à jour de l’ancienne base de données principale).
Réplication des canaux d’intégration automatique¶
En cas de basculement, un canal d’intégration automatique répliqué devient le nouveau canal primaire et peut effectuer les opérations suivantes :
Charger toutes les données qui n’ont pas encore été chargées. Il s’agit de toutes les données nouvelles depuis la dernière actualisation de la base de données principale nouvellement promue.
Continuer à recevoir des notifications lorsque la zone de préparation a de nouveaux fichiers à charger et charge les données de ces fichiers.
Note
Pour recevoir des notifications, vous devez configurer un canal d’intégration automatique secondaire dans un compte cible avant le basculement. Pour plus d’informations, consultez Configurer les notifications pour les canaux secondaires d’intégration automatique.
Réplication des canaux de points de terminaison REST¶
Pour les canaux qui utilisent l”API REST Snowpipe pour charger les données, Snowflake réplique les canaux et leurs métadonnées d’historique de chargement sur chaque compte cible que vous spécifiez. Il n’y a pas d’autres étapes de configuration à effectuer sur les comptes cibles. Pour une liste détaillée des métadonnées de l’historique de chargement, voir Charger les métadonnées.
Pour poursuivre le chargement des données en cas de basculement, appelez l’API REST du compte source nouvellement promu.
Considérations¶
Note
Un problème connu dans la version de prévisualisation de cette fonctionnalité entraîne le chargement en double de fichiers datant de plus de 64 jours. En guise de solution de contournement, attendez 24 heures après avoir répliqué une table avant de procéder au basculement.
Les contraintes suivantes s’appliquent aux objets de canaux :
Snowflake prend actuellement en charge la réplication de canaux dans le cadre de la réplication par groupe (groupes de réplication et de basculement). La réplication de canal n’est pas prise en charge pour la réplication de bases de données.
Snowflake réplique l’historique des copies d’un canal uniquement lorsque le canal appartient au même groupe de réplication que sa table cible.
La réplication des intégrations de notification n’est pas prise en charge.
Pour recevoir des notifications, vous devez configurer un canal d’intégration automatique secondaire dans un compte cible avant le basculement. Pour plus d’informations, consultez Configurer les notifications pour les canaux secondaires d’intégration automatique.
Exemple 1 : Répliquer une zone de préparation interne nommée¶
Cet exemple montre comment fonctionne la réplication pour les zones de préparation internes. En particulier, l’exemple montre comment la table de répertoire est la seule source de vérité pour les métadonnées de table avant et après la réplication.
La première partie de l’exemple effectue les tâches suivantes dans un compte source.
Créer une zone de préparation interne nommée
my_int_stage
avec une table de répertoire activée pour répliquer les fichiers sur la zone de préparation. Copier ensuite les données d’une table nomméemy_table
dans des fichiers sur la zone de préparation.Note
L’exemple actualise la table de répertoire après avoir chargé
file1
etfile2
sur la zone de préparation afin de synchroniser les métadonnées de la table avec le dernier ensemble de fichiers dans la définition de la zone de préparation pour les tables de répertoire. Cependant, aucune opération d’actualisation ne se produit après le chargement defile3
.CREATE OR REPLACE STAGE my_stage DIRECTORY = (ENABLE = TRUE); COPY INTO @my_stage/folder1/file1 from my_table; COPY INTO @my_stage/folder2/file2 from my_table; ALTER STAGE my_stage REFRESH; COPY INTO @my_stage/folder3/file3 from my_table;
Créez un groupe de basculement :
CREATE FAILOVER GROUP my_stage_failover_group OBJECT_TYPES = DATABASES ALLOWED_DATABASES = my_database_1 ALLOWED_ACCOUNTS = myorg.my_account_2;
La deuxième partie de l’exemple complète le processus de réplication et de basculement dans un compte cible :
Créer un groupe de basculement en tant que réplique du groupe de basculement du compte source, actualiser les objets du nouveau groupe de basculement et faire en sorte que le compte cible serve de compte source.
CREATE FAILOVER GROUP my_stage_failover_group AS REPLICA OF myorg.my_account_1.my_stage_failover_group; ALTER FAILOVER GROUP my_stage_failover_group REFRESH; ALTER FAILOVER GROUP my_stage_failover_group PRIMARY;
Ensuite, actualiser la table de répertoire sur la zone de préparation répliquée et copier tous les fichiers suivis par la table de répertoire sur
my_stage
dans une table nomméemy_table
.Note
L’instruction COPY INTO charge
file1
etfile2
dans la table, mais pasfile3
. Cela est dû au fait que la table de répertoire n’a pas été actualisée après l’ajout defile3
dans le compte source.ALTER STAGE my_stage REFRESH; COPY INTO my_table FROM @my_stage;
Exemple 2 : répliquer une zone de préparation externe et une intégration de stockage¶
Cet exemple fournit un exemple de flux de travail pour la réplication d’une zone de préparation externe et d’une intégration de stockage vers un compte cible.
L’exemple suppose que vous avez déjà effectué les opérations suivantes : Configurer l’accès sécurisé à votre compartiment Amazon S3.
La première partie de l’exemple effectue les tâches suivantes dans un compte source.
Créer une intégration de stockage pour un compartiment Amazon S3 dans la base de données
my_database_2
.CREATE STORAGE INTEGRATION my_storage_int TYPE = external_stage STORAGE_PROVIDER = 's3' STORAGE_ALLOWED_LOCATIONS = ('s3://mybucket/path') STORAGE_BLOCKED_LOCATIONS = ('s3://mybucket/blockedpath') ENABLED = true;
Créer une zone de préparation externe dans la base de données
my_database_2
en utilisant l’intégration de stockagemy_storage_int
.CREATE STAGE my_ext_stage URL = 's3://mybucket/path' STORAGE_INTEGRATION = my_storage_int
Créer un groupe de basculement et inclure la base de données
my_database_2
et les objets d’intégration de stockage.CREATE FAILOVER GROUP my_external_stage_fg OBJECT_TYPES = databases, integrations ALLOWED_INTEGRATION_TYPES = storage integrations ALLOWED_DATABASES = my_database_2 ALLOWED_ACCOUNTS = myorg.my_account_2;
La deuxième partie de l’exemple complète le processus de réplication et de basculement dans un compte cible :
Créer un groupe de basculement comme une réplique du groupe de basculement dans le compte source et actualiser.
CREATE FAILOVER GROUP my_external_stage_fg AS REPLICA OF myorg.my_account_1.my_external_stage_fg; ALTER FAILOVER GROUP my_external_stage_fg REFRESH;
Après avoir répliqué l’intégration de stockage sur le compte cible, vous devez prendre des mesures supplémentaires pour mettre à jour les autorisations de votre fournisseur Cloud afin d’accorder à l’intégration de réplication l’accès à votre stockage sur le Cloud. Pour plus d’informations, voir Configurer l’accès au stockage Cloud pour les intégrations de stockage secondaire.
Exemple 3 : répliquer un canal d’intégration automatique¶
Cet exemple fournit un exemple de workflow pour répliquer un canal qui utilise un sujet Amazon Simple Notification Service (SNS) avec Amazon Simple Queue Service (SQS) pour automatiser Snowpipe.
L’exemple suppose que vous avez déjà effectué les tâches suivantes :
Création et configuration d’une intégration de stockage pour Amazon S3. À titre d’exemple, nous utilisons une intégration de stockage nommée
my_s3_storage_int
.Création d’une zone de préparation externe qui fait référence à votre intégration de stockage. À titre d’exemple, nous utilisons une zone de préparation nommée
my_s3_stage
. Pour obtenir des instructions, voir CREATE STAGE.
Commencer par les tâches suivantes dans un compte source.
Utiliser la commande CREATE PIPE pour créer un canal avec l’intégration automatique activée qui charge les données de la zone de préparation externe dans une table nommée
mytable
.CREATE PIPE snowpipe_db.public.mypipe AUTO_INGEST=TRUE AWS_SNS_TOPIC='<topic_arn>' AS COPY INTO snowpipe_db.public.mytable FROM @snowpipe_db.public.my_s3_stage FILE_FORMAT = (TYPE = 'JSON');
Actualiser le canal avec une instruction ALTER PIPE pour charger les données de la zone de préparation des 7 derniers jours.
ALTER PIPE mypipe REFRESH;
Enfin, utiliser CREATE FAILOVER GROUP pour créer un groupe de basculement qui permet la réplication des intégrations de stockage.
CREATE FAILOVER GROUP my_pipe_failover_group OBJECT_TYPES = DATABASES, INTEGRATIONS ALLOWED_INTEGRATION_TYPES = STORAGE INTEGRATIONS ALLOWED_DATABASES = snowpipe_db ALLOWED_ACCOUNTS = myorg.my_account_2;
La deuxième partie de l’exemple complète le processus de réplication et de basculement dans un compte cible :
Créer un groupe de basculement comme une réplique du groupe de basculement dans le compte source.
CREATE FAILOVER GROUP my_pipe_failover_group AS REPLICA OF myorg.my_account_1.my_pipe_failover_group;
Exécuter une instruction DESCRIBE INTEGRATION pour récupérer l’ARN de l’utilisateur AWS IAM pour votre compte Snowflake sur le déploiement secondaire.
Utiliser l’ARN pour accorder à l’utilisateur les autorisations IAMpour accéder à votre compartiment S3. Voir l’étape 5 : Accorder à l’utilisateur les autorisations IAM pour accéder aux objets du compartiment.
DESC INTEGRATION my_s3_storage_int;
Appeler la SYSTEM$GET_AWS_SNS_IAM_POLICY fonction système pour générer une politique IAM qui accorde à la nouvelle file d’attente SQS l’autorisation de s’abonner à votre sujet SNS. Snowflake a créé la nouvelle file d’attente SQS dans votre compte cible lorsque vous avez répliqué le groupe de basculement à partir de votre compte source.
SELECT SYSTEM$GET_AWS_SNS_IAM_POLICY('<topic_arn>');
topic_arn
est le nom de ressource Amazon (ARN) du sujet SNS que vous avez créé pour le canal d’origine dans votre compte source.Ensuite, souscrire la nouvelle file d’attente Amazon SQS à votre sujet SNS.
Actualiser les objets de votre nouveau groupe de basculement.
ALTER FAILOVER GROUP my_pipe_failover_group REFRESH;
Enfin, la commande ALTER FAILOVER GROUP vous permet de promouvoir le compte cible en tant que compte source.
ALTER FAILOVER GROUP my_pipe_failover_group PRIMARY;
Le canal
mypipe
commencera à charger toutes les données qui ont été rendues disponibles depuis la dernière fois que le groupe de basculement a été actualisé dans le compte source.Pour vérifier que le canal répliqué fonctionne, interrogez la table à partir de l’instruction COPY du canal.
SELECT * FROM mytable;