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 2024_02 BCR bundle. Vous pouvez activer le 2024_02 BCR bundle en exécutant l’instruction suivante :

SELECT SYSTEM$ENABLE_BEHAVIOR_CHANGE_BUNDLE('2024_02');
Copy

Note

La réplicationETL faisait partie du bundle 2024_01, mais elle a été déplacée vers le bundle 2024_02.

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.

Si vous ajoutez INTEGRATIONS à la liste OBJECT_TYPES dans votre instruction ALTER, incluez 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;
Copy

Note

Votre fournisseur de stockage Cloud peut limiter la réplication des objets du pipeline de données entre les régions Cloud commerciales et gouvernementales. Pour éviter les limitations de réplication des données du Cloud gouvernemental, configurez vos ressources de basculement dans n’importe quelle région accessible à votre région de Cloud gouvernemental. Pour plus d’informations sur les limitations du Cloud gouvernemental, consultez la documentation de votre fournisseur de stockage Cloud.

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 STORAGE INTEGRATIONS dans la liste ALLOWED_INTEGRATION_TYPES. Pour plus d’informations, consultez CREATE FAILOVER GROUP.

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.

    1. Désactivez la table de répertoire sur la zone de préparation principale.

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

    3. 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 sont à l’état d’exécution READ_ONLY et 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 principale. Une fois que vous avez promu une base de données secondaire, les canaux passent à un état d’exécution FAILING_OVER. Une fois le basculement terminé, les canaux doivent se trouver à l’état d’exécution RUNNING et 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 Chargement de 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

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.

  • Snowflake ne réplique l’historique des chargements qu’après la dernière troncature de table.

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

  • Utilisez la fonction SYSTEM$PIPE_STATUS pour résoudre tous les canaux qui ne sont pas dans leur état d’exécution prévu après le basculement.

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 la zone de préparation avant et après la réplication.

La première partie de l’exemple effectue les tâches suivantes dans un compte source.

  1. 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ée my_table dans des fichiers sur la zone de préparation.

    Note

    L’exemple actualise la table de répertoire après avoir chargé file1 et file2 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 de file3.

    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;
    
    Copy
  2. 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;
    
    Copy

La deuxième partie de l’exemple complète le processus de réplication et de basculement dans un compte cible :

  1. 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;
    
    Copy
  2. 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ée my_table .

    Note

    L’instruction COPY INTO charge file1 et file2 dans la table, mais pas file3. Cela est dû au fait que la table de répertoire n’a pas été actualisée après l’ajout de file3 dans le compte source.

    ALTER STAGE my_stage REFRESH;
    
    COPY INTO my_table FROM @my_stage;
    
    Copy

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.

  1. 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;
    
    Copy
  2. Créer une zone de préparation externe dans la base de données my_database_2 en utilisant l’intégration de stockage my_storage_int.

    CREATE STAGE my_ext_stage
      URL = 's3://mybucket/path'
      STORAGE_INTEGRATION = my_storage_int
    
    Copy
  3. 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;
    
    Copy

La deuxième partie de l’exemple complète le processus de réplication et de basculement dans un compte cible :

  1. 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;
    
    Copy
  2. 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 :

Commencer par les tâches suivantes dans un compte source.

  1. 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');
    
    Copy
  2. 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;
    
    Copy
  3. 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;
    
    Copy

La deuxième partie de l’exemple complète le processus de réplication et de basculement dans un compte cible :

  1. 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;
    
    Copy
  2. 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;
    
    Copy
  3. 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>');
    
    Copy

    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.

  4. Actualiser les objets de votre nouveau groupe de basculement.

    ALTER FAILOVER GROUP my_pipe_failover_group REFRESH;
    
    Copy
  5. 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;
    
    Copy

    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;
    
    Copy

Migration vers Amazon Simple Notification Service (SNS)

Cette section explique comment passer de l’envoi de notifications d’événements Amazon S3 directement à une file d’attente Amazon Simple Queue Service (SQS) à l’utilisation d’une rubrique Amazon Simple Notification Service (SNS) dans les scénarios suivants :

Lorsque vous répliquez un canal ou une table de répertoire, Snowflake crée une nouvelle file d’attente SQS dans votre compte cible pour gérer l’automatisation. Vous pouvez configurer une seule rubrique SNS pour envoyer des notifications d’événements de votre compartiment S3 à toutes les files d’attente SQS de plusieurs comptes. En diffusant votre ou vos notifications d’événements S3 à chaque file d’attente SQS, vous réduisez le risque de perdre des notifications et des données après un basculement.

Note

Si vous utilisez déjà SNS, la migration n’est pas nécessaire. Au lieu de cela, suivez les étapes habituelles pour configurer l’automatisation avec SNS pour les tables de répertoire secondaires ou les canaux d’intégration automatique avant le basculement.

Conditions préalables

Pour pouvoir effectuer la migration, vous devez remplir les conditions suivantes :

Migration vers une rubrique SNS

  1. Créez une rubrique SNS dans votre compte AWS. Pour obtenir des instructions, voir Création d’une rubrique SNS Amazon dans la documentation AWSSNS.

  2. Abonnez vos destinations cibles (par exemple, d’autres files d’attente SQS ou des charges de travail Lambda AWS) pour votre ou vos notifications d’événements S3 à votre rubrique SNS. SNS publie des notifications d’événement pour votre compartiment à tous les abonnés du sujet. Pour obtenir des instructions, voir la documentation AWSSNS.

  3. Mettez à jour la politique d’accès à votre rubrique en y ajoutant les autorisations suivantes :

    • Autorisez l’utilisateur de Snowflake IAM à abonner la file d’attente SQS qui se trouve dans votre compte cible à votre rubrique.

    • Autorisez Amazon S3 à publier les notifications d’événements de votre compartiment dans la rubrique SNS.

    Pour obtenir des instructions, voir Étape 1 : Abonner la file d’attente SQS Snowflake à la rubrique SNS.

  4. Dans votre compte Snowflake cible, appelez la fonction SYSTEM$CONVERT_PIPES_SQS_TO_SNS. La fonction abonne la file d’attente SQS de votre compte cible à votre rubrique SNS sans interrompre la synchronisation des métadonnées ni le travail d’ingestion.

    Spécifiez le nom de votre compartiment S3 et la rubrique SNS ARN.

    SELECT SYSTEM$CONVERT_PIPES_SQS_TO_SNS('s3_mybucket', 'arn:aws:sns:us-west-2:001234567890:MySNSTopic')
    
    Copy
  5. Mettez à jour vos notifications d’événements S3 de sorte à utiliser votre rubrique SNS comme destination. Pour obtenir des instructions, voir le Guide de l’utilisateur Amazon S3.

Une fois ces étapes terminées, la file d’attente SQS se dissocie automatiquement de votre ou vos notifications d’événements S3. L’ensemble des tables de répertoire et canaux qui utilisent le compartiment S3 spécifié commenceront à utiliser SNS comme source de notifications.