Réplication de bases de données sur plusieurs comptes

Cette rubrique décrit les étapes nécessaires à la réplication de bases de données sur plusieurs comptes Snowflake dans différentes régions tout en conservant la synchronisation des objets de base de données et des données stockées.

Dans ce chapitre :

Prise en charge de la région pour la réplication de la base de données et le basculement/récupération

Toutes les régions Snowflake sur Amazon Web Services, Google Cloud Platform et Microsoft Azure prennent désormais en charge la fonctionnalité de réplication de base de données et le basculement/récupération, à l’exception de US Gov Virginia sur Microsoft Azure.

Remarque : les comptes peuvent répliquer des bases de données entre Virtual Private Snowflake (VPS) et les régions multi-locataires pour faciliter le partage de données et les migrations de compte entre ces régions. Cette capacité est désactivée par défaut. Les comptes VPS doivent contacter le support Snowflake pour activer l’accès.

Interface Web pour la réplication de la base de données et basculement /récupération

Les administrateurs de compte (utilisateurs avec le rôle ACCOUNTADMIN) peuvent utiliser la zone Replication de l’onglet Databases Databases tab dans l’interface Web Snowflake pour effectuer la plupart des actions liées à la configuration et à la gestion de la réplication de la base de données, y compris les actions suivantes :

  • Permettre à une base de données locale de servir de base de données principale.

  • Activer le basculement pour une base de données principale (comptes Business Critical Edition ou versions ultérieures).

  • Actualiser une base de données secondaire, une fois (manuellement) ou de manière répétée (selon un calendrier, à l’aide d’une tâche).

  • Promouvoir une base de données secondaire pour servir de base de données principale (comptes Business Critical Edition ou versions supérieures).

  • Désactiver la réplication et/ou le basculement pour une base de données principale.

Réplication d’une base de données vers un autre compte

Les instructions de cette section expliquent comment préparer vos comptes pour la réplication, promouvoir une base de données locale pour qu’elle serve de base de données principale et effectuer la réplication initiale de cette base de données principale vers un autre compte.

Important

Les comptes cibles n’ont pas Tri-Secret Secure ou AWS PrivateLink configurés par défaut. Si Tri-Secret Secure ou PrivateLink est requis à des fins de conformité, de sécurité ou à d’autres fins, il est de votre responsabilité de vous assurer que ces fonctionnalités sont configurées dans le compte cible.

Étape 2 : Affichage de tous les comptes de votre entreprise

Récupérez la liste des comptes dans votre entreprise. Toute base de données permanente ou transitoire existante dans ces comptes peut être modifiée pour servir de base de données principale. Les réplicas d’une base de données principale (c.-à-d. les bases de données secondaires) ne peuvent être créées que dans ces comptes.

Note

Seuls les administrateurs de compte (utilisateurs dotés du rôle ACCOUNTADMIN) peuvent exécuter l’instruction SQL dans cette section.

Pour afficher la liste des comptes de votre entreprise, interrogez SHOW REPLICATION ACCOUNTS.

SHOW REPLICATION ACCOUNTS;

+------------------+---------------------------------+---------------+------------+
| snowflake_region | created_on                      | name          | comment    |
|------------------+---------------------------------+---------------+------------|
| AWS_US_WEST_2    | 2018-11-19 16:11:12.720 -0700   | MYACCOUNT1    |            |
| AWS_US_EAST_1    | 2019-06-02 14:12:23.192 -0700   | MYACCOUNT2    |            |
+------------------+---------------------------------+---------------+------------+

Le tableau suivant affiche la liste complète des IDs de régions Snowflake :

IDs de régions Snowflake

Région

ID de région

ID de région Snowflake

Remarques

Amazon Web Services (AWS)

US Ouest (Oregon)

us-west-2

aws_us_west_2

US Est (Ohio)

us-east-2.aws

aws_us_east_2

US Est (Virginie du Nord)

us-east-1

aws_us_east_1

US Est (Gouvernement commercial - Virginie du Nord)

us-east-1-gov.aws

aws_us_east_1_gov

Disponible uniquement pour les comptes sur Business Critical (ou supérieur) ; ne se trouve pas dans AWS GovCloud (US), qui est un Cloud dédié distinct pas encore pris en charge par Snowflake.

Canada (Centre)

ca-central-1.aws

aws_ca_central_1

EU (Irlande)

eu-west-1

aws_eu_west_1

EU (Francfort)

eu-central-1

aws_eu_central_1

Asie-Pacifique (Tokyo)

ap-northeast-1.aws

aws_ap_northeast_1

Asie Pacifique (Mumbai)

ap-south-1.aws

aws_ap_south_1

Asie-Pacifique (Singapour)

ap-southeast-1

aws_ap_southeast_1

Asie-Pacifique (Sydney)

ap-southeast-2

aws_ap_southeast_2

Google Cloud Platform (GCP)

US Central1 (Iowa)

us-central1.gcp

gcp_us_central1

Europe Ouest2 (Londres)

europe-west2.gcp

gcp_europe_west2

Europe Ouest4 (Pays-Bas)

europe-west4.gcp

gcp_europe_west4

Microsoft Azure

Ouest US 2 (Washington)

west-us-2.azure

azure_westus2

Est US 2 (Virginie)

east-us-2.azure

azure_eastus2

US Gov Virginia

us-gov-virginia.azure

azure_usgovvirginia

Disponible uniquement pour les comptes sur Business Critical (ou version supérieure).

Canada Central (Toronto)

canada-central.azure

azure_canadacentral

Europe de l’Ouest (Pays-Bas)

west-europe.azure

azure_westeurope

Asie du Sud-Est (Singapour)

southeast-asia.azure

azure_southeastasia

Suisse Nord (Zurich)

switzerland-north.azure

azure_switzerlandnorth

Australie Est (Nouvelle-Galles-du-Sud)

australia-east.azure

azure_australiaeast

Étape 3 : Promotion d’une base de données locale pour qu’elle serve de base de données principale

Modifiez une base de données permanente ou transitoire existante pour qu’elle serve de base de données principale à l’aide d’une instruction ALTER DATABASE … ENABLE REPLICATION TO ACCOUNTS. Fournissez une liste de comptes de votre entreprise séparés par des virgules pouvant stocker un réplica de cette base de données (c’est-à-dire une base de données secondaire), permettant ainsi aux utilisateurs de ces comptes d’interroger des objets dans la base de données secondaire.

Note

Seuls les administrateurs de compte (utilisateurs dotés du rôle ACCOUNTADMIN) peuvent exécuter l’instruction SQL dans cette section.

Exemple

Promouvez la base de données locale mydb1 (dans la région aws_us_west_2) pour qu’elle serve de base de données principale et indiquez que les comptes myaccount2 et myaccount3 (dans les régions aws_us_east_1 (AWS) et azure_westeurope (Azure), respectivement) peuvent chacun stocker un réplica de cette base de données :

ALTER DATABASE mydb1 ENABLE REPLICATION TO ACCOUNTS aws_us_east_1.myaccount2, azure_westeurope.myaccount3;

Étape 4 : Activation du basculement pour une base de données principale

Note

Effectuez cette étape uniquement si vous prévoyez de configurer cette base de données principale pour basculer vers un autre compte. Pour plus d’informations, voir Introduction à la continuité d’activité et à la récupération après sinistre.

Activez le basculement pour une base de données principale sur un ou plusieurs comptes de votre entreprise à l’aide d’une instruction ALTER DATABASE … ENABLE FAILOVER TO ACCOUNTS. Le réplica de cette base de données principale dans l’un de ces comptes (c’est-à-dire une base de données secondaire) peut être promu pour servir de base de données principale.

Notez que l’activation du basculement pour une base de données principale peut être effectuée avant ou après la création d’un réplica de la base de données principale dans un compte spécifié.

Exemple

Activez le basculement pour la base de données principale mydb1 (dans la région aws_us_west_2) sur les comptes myaccount2 et myaccount3 (dans les régions aws_us_east_1 (AWS) et azure_westeurope (Azure), respectivement). Dans cet exemple, supposons que la base de données principale soit stockée dans le compte myaccount1. La commande ALTER DATABASE doit être exécutée sur ce compte :

ALTER DATABASE mydb1 ENABLE FAILOVER TO ACCOUNTS aws_us_east_1.myaccount2, azure_westeurope.myaccount3;

Étape 5 : Création d’une base de données secondaire

Créez un réplica d’une base de données principale existante dans le même compte que celui qui stocke la base de données principale, ou un compte différent (dans la même région ou dans une autre). Notez que vous ne pouvez créer une base de données secondaire que dans un compte spécifié dans l’instruction ALTER DATABASE … ENABLE REPLICATION TO ACCOUNTS de Étape 3 : Promotion d’une base de données locale pour qu’elle serve de base de données principale.

Exécutez une instruction CREATE DATABASE … AS REPLICA OF dans chaque compte cible pour créer un réplica de la base de données principale spécifiée.

Important

Il est recommandé de donner à chaque base de données secondaire le même nom que sa base de données principale. Cette recommandation prend en charge le référencement d’objets pleinement qualifiés (c’est-à-dire '<bd>.<schéma>.<objet>') par d’autres objets dans la même base de données, comme la requête d’un nom de table complet dans une vue.

Si une base de données secondaire a un autre nom que celui de la base de données principale, ces références d’objet ne fonctionneraient plus dans la base de données secondaire.

Pour afficher la liste des bases de données principales et secondaires de votre entreprise, interrogez SHOW REPLICATION DATABASES.

Note

Seuls les administrateurs de compte (utilisateurs dotés du rôle ACCOUNTADMIN) peuvent exécuter l’instruction SQL dans cette section.

Après la création d’une base de données secondaire, un administrateur de compte peut transférer la propriété de la base de données à un autre rôle (à l’aide de GRANT OWNERSHIP.)

Exemple

L’exemple suivant crée un réplica de la base de données principale aws_us_west_2.myaccount1.mydb1 dans le compte aws_us_east_1.myaccount2, avec l’actualisation automatique des vues matérialisées dans le réplica activé. L’instruction SQL est exécutée dans le même groupe de régions AWS (public), mais dans une région différente du compte qui stocke la base de données principale :

-- Log into the AWS_US_EAST_1.MYACCOUNT2 account.

-- Query the set of primary and secondary databases in your organization.
-- In this example, the AWS_US_WEST_2.MYACCOUNT1 primary database is available to replicate.
SHOW REPLICATION DATABASES;

+------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------+
| snowflake_region | created_on                    | account_name    | name     | comment | is_primary | primary                                  | snowflake_region | replication_allowed_to_accounts                                  | failover_allowed_to_accounts    |
|------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------|
| AWS_US_WEST_2    | 2019-11-15 00:51:45.473 -0700 | MYACCOUNT1      | MYDB1    | NULL    | true       | PUBLIC.AWS_US_WEST_2.MYACCOUNT1.MYDB1    | AWS_US_WEST_2    | PUBLIC.AWS_US_EAST_1.MYACCOUNT2, PUBLIC.AWS_US_WEST_2.MYACCOUNT1 | PUBLIC.AWS_US_WEST_2.MYACCOUNT1 |
+------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------+

-- Create a replica of the 'mydb1' primary database
CREATE DATABASE mydb1
  AS REPLICA OF aws_us_west_2.myaccount1.mydb1
  AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = TRUE;

-- Verify the secondary database
SHOW REPLICATION DATABASES;

+------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------+
| snowflake_region | created_on                    | account_name    | name     | comment | is_primary | primary                                  | snowflake_region | replication_allowed_to_accounts                                  | failover_allowed_to_accounts    |
|------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------|
| AWS_US_WEST_2    | 2019-11-15 00:51:45.473 -0700 | MYACCOUNT1      | MYDB1    | NULL    | true       | PUBLIC.AWS_US_WEST_2.MYACCOUNT1.MYDB1    | AWS_US_WEST_2    | PUBLIC.AWS_US_EAST_1.MYACCOUNT2, PUBLIC.AWS_US_WEST_2.MYACCOUNT1 | PUBLIC.AWS_US_WEST_2.MYACCOUNT1 |
| AWS_US_EAST_1    | 2019-08-15 15:51:49.094 -0700 | MYACCOUNT2      | MYDB1    | NULL    | false      | PUBLIC.AWS_US_WEST_2.MYACCOUNT1.MYDB1    | AWS_US_EAST_1    |                                                                  |                                 |
+------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------+

Actualisation de chaque base de données secondaire

Les instructions de cette section expliquent comment actualiser une base de données secondaire à partir d’un instantané de sa base de données principale (à l’aide de ALTER DATABASE … REFRESH). Un instantané inclut les modifications apportées aux objets et aux données.

Notez que le propriétaire de la base de données secondaire (rôle doté du privilège OWNERSHIP sur la base de données) est propriétaire des nouveaux objets ajoutés à la suite d’une actualisation de la base de données.

Note

Pour actualiser une base de données secondaire, le rôle utilisé pour effectuer l’opération doit disposer du privilège OWNERSHIP sur la base de données.

Pour vérifier la région actuelle après vous être connecté à un compte, interrogez la fonction CURRENT_REGION.

ALTER DATABASE mydb1 REFRESH​;

Actualisation d’une base de données secondaire dans l’interface Web

L’interface Web Snowflake fournit une représentation visuelle de le statut actuel d’une actualisation de base de données secondaire. Pour obtenir des instructions, consultez Surveillance de la progression d’une actualisation de la base de données dans l’interface Web (dans ce chapitre).

Augmentation du délai d’expiration de l’instruction pour la réplication initiale

La réplication de base de données utilise des ressources de calcul fournies par Snowflake au lieu de votre propre entrepôt virtuel pour copier des objets et des données. Cependant, le paramètre de session/objet STATEMENT_TIMEOUT_IN_SECONDS contrôle toujours le temps d’exécution d’une instruction avant son annulation. La valeur par défaut est de 172800 (2 jours). Étant donné que la réplication initiale d’une très grande base de données principale peut durer plus de deux jours (en fonction de la quantité de métadonnées dans la base de données ainsi que de la quantité de données dans les objets de base de données), nous vous recommandons d’augmenter la valeur STATEMENT_TIMEOUT_IN_SECONDS et de la définir sur 604800 (sept jours, la valeur maximale) pour la session dans laquelle vous exécutez l’opération de réplication.

Exécutez l’instruction ALTER SESSION suivante avant l’exécution de l’instruction ALTER DATABASE nom_bdd_secondaire REFRESH dans la même session :

ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;

Notez que le paramètre STATEMENT_TIMEOUT_IN_SECONDS s’applique également à l’entrepôt actif dans une session. Le paramètre respecte la valeur inférieure définie au niveau de la session ou de l’entrepôt. Si vous avez un entrepôt actif dans la session en cours, définissez également STATEMENT_TIMEOUT_IN_SECONDS sur 604800 pour cet entrepôt (avec ALTER WAREHOUSE) également.

Par exemple :

-- determine the active warehouse in the current session (if any)
SELECT CURRENT_WAREHOUSE();

+---------------------+
| CURRENT_WAREHOUSE() |
|---------------------|
| MY_WH               |
+---------------------+

-- change the STATEMENT_TIMEOUT_IN_SECONDS value for the active warehouse

ALTER WAREHOUSE my_wh SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;

vous pouvez réinitialiser la valeur du paramètre à la valeur par défaut une fois l’opération de réplication terminée :

ALTER WAREHOUSE my_wh UNSET STATEMENT_TIMEOUT_IN_SECONDS;

Actualisation d’une base de données secondaire sur une planification

Nous vous recommandons de planifier les actualisations de votre base de données secondaire. Cette section fournit des instructions pour démarrer automatiquement une actualisation de la base de données selon un calendrier spécifié.

La fréquence à laquelle vous actualisez une base de données secondaire dépend de l’objectif du point de récupération (RPO) pour les données de la base de données secondaire. Par exemple, si les applications qui s’appuient sur les données peuvent tolérer jusqu’à 1 heure de perte de données, vous devez actualiser les données au moins toutes les heures. Si la tolérance de perte de données est de 5 minutes, actualisez la base de données secondaire au moins toutes les 5 minutes.

Note

  • Nous vous recommandons d’exécuter manuellement la réplication initiale d’une base de données principale (à l’aide de ALTER DATABASE … REFRESH) et de ne planifier que les actualisations suivantes.

  • Il existe une limite de 60 minutes par défaut pour une seule exécution d’une tâche. Cette limitation a été mise en œuvre à titre de protection contre les tâches ne se terminant pas. Dans de rares circonstances, une actualisation d’une très grande base de données peut dépasser la limite d’exécution de tâches par défaut. Pour déterminer si cela s’est produit, interrogez la fonction de table TASK_HISTORY . Si la tâche a dépassé la période prévue pour la tâche, la cause en est souvent un entrepôt trop petit. Vérifiez la taille de l’entrepôt et envisagez de l’augmenter pour l’adapter à la période de planification ou à la limite d’une heure.

    Vous pouvez également envisager d’augmenter le délai d’expiration de la tâche en exécutant ALTER TASK … SET USER_TASK_TIMEOUT_MS = <num>.

Suivez les étapes décrites dans cette section pour démarrer automatiquement une actualisation de la base de données selon une planification spécifiée.

Conditions préalables

Les objets Snowflake suivants sont requis dans le compte qui stocke la base de données secondaire :

  • La base de données secondaire.

  • Une base de données distincte pour stocker les nouveaux objets créés dans cette section. Comme les bases de données secondaires sont en lecture seule, cette base de données doit être distincte de la base de données secondaire. Cette base de données doit également inclure les objets suivants :

    • Schéma : Utilisez le schéma PUBLIC ou créez un nouveau schéma à l’aide de CREATE SCHEMA.

    • Entrepôt pour fournir des ressources de calcul pour l’actualisation de la base de données. Créez un nouvel entrepôt en utilisant CREATE WAREHOUSE.

    • Tâche qui actualise la base de données secondaire selon une planification.

Privilèges requis

Les étapes décrites dans cette section nécessitent un rôle avec les privilèges suivants dans le compte dans lequel la base de données secondaire est actualisée :

Type d’objet

Objet

Privilège

Remarques

Compte

Compte qui stocke la base de données secondaire

EXECUTE TASK

Requis pour exécuter la nouvelle tâche.

Base de données

Base de données secondaire

OWNERSHIP

Requis pour actualiser la base de données secondaire.

Base de données

Base de données qui stocke la nouvelle tâche.

USAGE

Schéma

Schéma qui stocke la nouvelle tâche

USAGE, CREATE TASK

Tâche

OWNERSHIP

Le rôle qui crée la tâche possède l’objet par défaut. La propriété peut être transférée vers un rôle différent à l’aide de GRANT privilèges … TO ROLE.

Entrepôt virtuel

Entrepôt utilisé pour exécuter la tâche

USAGE

Étapes

Effectuez les étapes suivantes pour chaque base de données secondaire que vous souhaitez actualiser selon une planification :

  1. Créez une tâche qui lance l’actualisation de la base de données selon une planification (à l’aide de CREATE TASK).

    Syntaxe
    CREATE [ OR REPLACE ] TASK [ IF NOT EXISTS ] <name>
      WAREHOUSE = <string>
      SCHEDULE = { <number> MINUTE | USING CRON <expr> <time_zone> } | AFTER <string>
    AS
      ALTER DATABASE <secondary_db_name> REFRESH;
    

    Par exemple, créez une tâche nommée refresh_mydb1_task qui actualise une base de données secondaire nommée mydb1 toutes les 10 minutes. La tâche s’exécute en utilisant l’entrepôt existant mywh :

    CREATE TASK refresh_mydb1_task
      WAREHOUSE = mywh
      SCHEDULE = '10 minute'
    AS
      ALTER DATABASE mydb1 REFRESH;
    
  2. Une tâche est suspendue par défaut lors de sa création. Reprenez la tâche pour qu’elle puisse s’exécuter en fonction des paramètres spécifiés dans la définition de la tâche :

ALTER TASK refresh_mydb1_task RESUME;

Surveillance de la progression d’une actualisation de la base de données

Pour déterminer le statut actuel de la réplication de base de données initiale ou d’une actualisation ultérieure de la base de données secondaire, interrogez la fonction de table DATABASE_REFRESH_PROGRESS , DATABASE_REFRESH_PROGRESS_BY_JOB (dans Schéma d’information).

Une opération d’actualisation de la base de données peut nécessiter plusieurs heures ou plus, en fonction de la quantité de données à répliquer.

Pour afficher l’historique de réplication d’une base de données en particulier dans une plage de dates spécifiée, interrogez au choix :

Exemple

Surveillez la progression de l’actualisation de la base de données secondaire mydb1 :

select *
  from table(information_schema.database_refresh_progress(mydb1));

Surveillance de la progression d’une actualisation de la base de données dans l’interface Web

Démarrez manuellement une actualisation de la base de données secondaire dans l’interface Web Snowflake pour afficher une barre de progression dynamique indiquant le statut actuel de l’opération d’actualisation avec des statistiques.

Pour démarrer une opération d’actualisation de base de données secondaire :

  1. Dans l’interface Web de Snowflake, cliquez sur l’onglet Databases Databases tab » Replication.

  2. Sélectionnez la base de données secondaire à actualiser.

  3. Cliquez sur le bouton Refresh now. La boîte de dialogue Refresh Database s’ouvre.

  4. Cliquez sur le bouton Refresh.

La colonne Last Refresh Status affiche le statut de l’opération d’actualisation en cours. La barre de progression est mise à jour dynamiquement.

Les statistiques Refresh History dans la fenêtre latérale affichent également le statut d’actualisation actuel, ainsi que l’heure de début d’actualisation, le nombre d’octets transférés et d’autres statistiques.

Secondary refresh operation in the Snowflake web interface

Affichage de l’historique d’actualisation de la base de données

Pour afficher l’historique des opérations d’actualisation de la base de données secondaire, interrogez la fonction de table DATABASE_REFRESH_HISTORY (dans Schéma d’information). Cette fonction renvoie l’activité d’actualisation de la base de données au cours des 14 derniers jours.

ou

Interrogez la vue Vue REPLICATION_USAGE_HISTORY (dans le schéma Account Usage de la base de données Snowflake partagée). Cette vue renvoie l’activité d’utilisation de la réplication au cours des 365 derniers jours (1 an).

Exemple

Afficher l’historique de l’opération d’actualisation de la base de données secondaire mydb1 :

select *
  from table(information_schema.database_refresh_history(mydb1));

Comparaison des ensembles de données dans les bases de données principales et secondaires

Utilisez éventuellement la fonction HASH_AGG pour comparer les lignes d’un ensemble aléatoire de tables dans une base de données primaire et secondaire pour vérifier la cohérence des données. La fonction HASH_AGG renvoie une valeur de hachage globale signée de 64 bits sur l’ensemble (non ordonné) des lignes d’entrée. Interrogez cette fonction sur tout ou un sous-ensemble aléatoire de tables dans une base de données secondaire et sur la base de données primaire (à partir de l’horodatage de l’instantané de la base de données primaire) et comparez la sortie.

Exemple

  1. Sur la seconde base de données, interrogez la fonction de table DATABASE_REFRESH_HISTORY (dans Schéma d’information). Notez la colonne END_TIME de la ligne indiquant quand la dernière opération d’actualisation s’est terminée. Il s’agit de l’horodatage du dernier instantané de la base de données principale.

  2. Interrogez la fonction HASH_AGG pour une table spécifiée. La requête suivante renvoie une valeur de hachage pour toutes les lignes de la table mytable :

    SELECT HASH_AGG( * ) FROM mytable;
    
  3. Sur la base de données principale, interrogez la fonction HASH_AGG pour la même table. À l’aide de Time Travel, spécifiez l’horodatage auquel le dernier instantané a été pris pour la base de données secondaire :

    SELECT HASH_AGG( * ) FROM mytable AT(TIMESTAMP => <primary_snapshot_timestamp>);
    
  4. Comparez les résultats des deux requêtes. La sortie doit être identique.