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 tout en conservant la synchronisation des objets de base de données et des données stockées. La réplication de la base de données peut se produire entre des comptes Snowflake situés dans la même région ou dans des régions différentes.
Note
Snowflake recommande d’utiliser la fonction de réplication de compte pour répliquer les bases de données. Les groupes de réplication et de basculement permettent la réplication de plusieurs bases de données et d’autres objets de compte avec une cohérence ponctuelle pour les objets du groupe. Pour une liste complète de la disponibilité des fonctionnalités et des objets pris en charge, reportez-vous à Présentation de la réplication et du basculement à travers plusieurs comptes.
Dans ce chapitre :
Prise en charge de la région pour la réplication de la base de données et le basculement/la 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/la récupération.
Remarque : les comptes peuvent répliquer des bases de données entre Groupes de régions (par exemple, entre Virtual Private Snowflake (VPS) et des régions mutualisées) 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. Vous pouvez 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¶
Attention
La gestion et la surveillance de la réplication et du basculement / de la restauration dans Snowsight et Classic Console ne sont disponibles que pour les comptes utilisant une connectivité privée.
Pour tous les autres comptes, consultez Surveiller la réplication à l’aide de Snowsight et Réplication d’objets de compte et de bases de données.
Les administrateurs de comptes (utilisateurs ayant le rôle ACCOUNTADMIN) peuvent gérer les actions de réplication et de basculement/restauration dans Snowsight ou dans l”Classic Console.
Snowsight¶
- Navigation :
Data » Databases
Gérer les bases de données principales¶
Attention
Uniquement disponible pour les comptes utilisant une connectivité privée. Pour tous les autres comptes, consultez Surveiller la réplication à l’aide de Snowsight et Réplication d’objets de compte et de bases de données.
Connectez-vous à Snowsight avec un compte Snowflake qui contient une base de données principale.
Sélectionnez le menu déroulant dans le coin supérieur gauche (à côté de votre nom de connexion) » Switch Role »
ACCOUNTADMIN
.Dans le volet de navigation de gauche, sélectionnez Data » Databases. Sélectionnez une base de données principale dans l’explorateur d’objets de base de données. La page des détails de la base de données s’ouvre.
Sinon, pour afficher uniquement les bases de données qui ont été activées pour la réplication, utilisez le filtre Replication Status » Primary pour répertorier les bases de données principales du compte. Sélectionnez une base de données dans la liste pour ouvrir la page de détails.
Note
Le filtre Replication Status n’est disponible que si un compte est un compte source ou cible pour la réplication de base de données.
Sélectionnez » Enable Replication. La boîte de dialogue Enable replication s’ouvre.
Sélectionnez l’action à effectuer :
Activer le basculement. Cette fonctionnalité nécessite Business Critical Edition (ou une version supérieure).
Créer une base de données secondaire dans un ou plusieurs comptes cibles.
Si une base de données principale d’un autre compte est activée pour la réplication vers le compte actif, vous pouvez créer une base de données secondaire dans le compte actif. Pour ajouter des comptes cibles supplémentaires, utilisez la commande ALTER DATABASE dans le compte source pour mettre à jour la base de données principale.
Actualiser chaque base de données secondaire une fois, après sa création.
Pour chaque compte cible de cette base de données, cochez les options permettant de créer une base de données secondaire et d’actualiser la base de données.
Connectez-vous au compte cible en tant qu’utilisateur à qui on a précédemment accordé le rôle ACCOUNTADMIN dans ce compte.
Snowflake effectue les actions demandées et affiche un message de réussite.
Gérez la réplication pour cette base de données à partir de l’onglet Replication dans les détails de la base de données.
Gérer les bases de données secondaires¶
Attention
Uniquement disponible pour les comptes utilisant une connectivité privée. Pour tous les autres comptes, consultez Surveiller la réplication à l’aide de Snowsight et Réplication d’objets de compte et de bases de données.
Connectez-vous à Snowsight avec un compte Snowflake qui contient une base de données secondaire.
Sélectionnez le menu déroulant dans le coin supérieur gauche (à côté de votre nom de connexion) » Switch Role »
ACCOUNTADMIN
.Dans le volet de navigation de gauche, sélectionnez Data » Databases.
Les actions suivantes sont disponibles à partir du bouton actions (…) situé dans le coin supérieur droit de la page :
Créez une base de données secondaire.
Note
Cette option n’est disponible que si un compte est un compte source ou cible pour la réplication de base de données.
Si une base de données principale d’un autre compte est activée pour la réplication vers le compte actif, vous pouvez créer une base de données secondaire dans le compte actif. Pour ajouter des comptes cibles supplémentaires, utilisez la commande ALTER DATABASE dans le compte source pour mettre à jour la base de données principale.
Sélectionnez une base de données secondaire dans l’explorateur d’objets de base de données. La page des détails de la base de données s’ouvre.
Sélectionnez l’onglet Replication.
Les actions suivantes sont disponibles à partir du bouton actions (…) situé dans le coin supérieur droit de la page :
Promouvoir la base de données secondaire comme base de données principale. Cette fonctionnalité nécessite Business Critical Edition (ou une version supérieure).
Note
Pour qu’une base de données secondaire soit promue au rang de base principale, le basculement de la base de données principale vers le compte cible où se trouve la base de données secondaire doit être activé.
Si cette option n’est pas disponible, vous pouvez utiliser la commande ALTER DATABASE dans le compte source pour activer le basculement de la base de données principale vers le compte cible. Pour plus d’informations, consultez Étape 3 : Activation du basculement pour une base de données principale.
Actualiser la base de données secondaire.
Copier un modèle pour créer une tâche qui actualise la base de données secondaire selon une planification. Coller le modèle dans une feuille de calcul Snowsight et le modifiez pour spécifier le calendrier souhaité.
Console classique¶
Attention
Uniquement disponible pour les comptes utilisant une connectivité privée. Pour tous les autres comptes, consultez Surveiller la réplication à l’aide de Snowsight et Réplication d’objets de compte et de bases de données.
Utilisez la zone Replication de l’onglet Databases dans l”Classic Console 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 :
Activez la réplication pour une base de données locale. Permettre à la base de données 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).
Note
Pour qu’une base de données secondaire puisse être promue au rang de base principale, le basculement de la base de données principale vers le compte cible où se trouve la base de données secondaire doit être activé.
Si cette option n’est pas disponible :
Connectez-vous au compte source de la base de données principale.
Dans la zone Databases , sélectionnez Replication.
Sélectionnez l’onglet Primary pour dresser la liste des bases de données principales. Sélectionnez la ligne contenant la base de données principale.
Recherchez le compte cible pour lequel vous souhaitez activer le basculement et sélectionnez Failover.
Désactiver la réplication et/ou le basculement pour une base de données principale.
Réplication d’une base de données dans 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, effectuer la réplication initiale de cette base de données principale vers un autre compte, et planifier l’actualisation de bases de données secondaires.
Important
Les comptes cibles n’ont pas Tri-Secret Secure ou une connectivité privée au service Snowflake (par exemple AWS PrivateLink) activé par défaut. Si vous avez besoin de Tri-Secret Secure ou d’une connectivité privée au service Snowflake à des fins de conformité, de sécurité ou à d’autres fins, il est de votre responsabilité de configurer et d’activer ces fonctionnalités dans le compte cible.
Condition préalable : activer la réplication des comptes dans l’organisation¶
L’administrateur de l’organisation (rôle ORGADMIN) doit activer la réplication pour les comptes source et cible avant de répliquer une base de données. Pour des instructions détaillées, voir Condition préalable : activer la réplication des comptes dans l’organisation.
Activer la réplication et le basculement de base de données et actualiser des bases de données secondaires¶
Note
Sauf exception, seuls les administrateurs de compte (utilisateurs dotés du rôle ACCOUNTADMIN) peuvent exécuter l’instruction SQL dans cette section.
Étape 1 : Affichage de tous les comptes de votre organisation¶
Récupérez la liste des comptes de votre organisation pour lesquels la réplication a été activée. Toute base de données permanente ou transitoire existante dans ces comptes peut être modifiée pour servir de base de données primaire. Les réplicas d’une base de données principale (c.-à-d. les bases de données secondaires) ne peuvent être créés que dans ces comptes.
Pour afficher la liste des comptes de votre entreprise, interrogez SHOW REPLICATION ACCOUNTS.
SHOW REPLICATION ACCOUNTS;
+------------------+---------------------------------+---------------+------------------+---------+-------------------+
| snowflake_region | created_on | account_name | account_locator | comment | organization_name |
|------------------+---------------------------------+---------------+------------------+---------+-------------------|
| AWS_US_WEST_2 | 2018-11-19 16:11:12.720 -0700 | ACCOUNT1 | MYACCOUNT1 | | MYORG |
| AWS_US_EAST_1 | 2019-06-02 14:12:23.192 -0700 | ACCOUNT2 | MYACCOUNT2 | | MYORG |
+------------------+---------------------------------+---------------+------------------+---------+-------------------+
Voir la liste complète des IDs de région.
Étape 2 : 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.
Exemple¶
Promouvez la base de données locale mydb1
(dans le compte account1
) pour qu’elle serve de base de données principale et indiquez que les comptes account2
et account3
peuvent chacun stocker un réplica de cette base de données :
ALTER DATABASE mydb1 ENABLE REPLICATION TO ACCOUNTS myorg.account2, myorg.account3;
Étape 3 : Activation du basculement pour une base de données principale¶
Note
Le basculement/la restauration automatique nécessite Business Critical (ou une version supérieure). Pour en savoir plus sur la mise à niveau, veuillez contacter le support Snowflake.
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 de la base de données principale mydb1
vers les comptes account2
et account3
.
-- Executed from primary account
ALTER DATABASE mydb1 ENABLE FAILOVER TO ACCOUNTS myorg.account2, myorg.account3;
Étape 4 : 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 2 : Promotion d’une base de données locale pour qu’elle serve de base de données principale.
Note
Les commandes de réplication (par exemple, la promotion d’une base de données vers une base de données principale dans un compte source) déclenchent généralement des opérations à travers les régions et peuvent prendre quelques secondes pour prendre effet. Par exemple, si vous promouvez par programmation une base de données pour servir de base de données principale dans un compte source et créez une base de données secondaire dans un compte cible, il peut s’écouler quelques secondes avant que vous puissiez créer la base de données secondaire.
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. 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 myorg.account1.mydb1
dans le compte myorg.account2
:
-- Log into the ACCOUNT2 account.
-- Query the set of primary and secondary databases in your organization.
-- In this example, the MYORG.ACCOUNT1 primary database is available to replicate.
SHOW REPLICATION DATABASES;
+------------------+-------------------------------+-----------------+----------+---------+------------+----------------------------+---------------------------------+------------------------------+-------------------+-----------------+
| snowflake_region | created_on | account_name | name | comment | is_primary | primary | replication_allowed_to_accounts | failover_allowed_to_accounts | organization_name | account_locator |
|------------------+-------------------------------+-----------------+----------+---------+------------+----------------------------+---------------------------------+------------------------------+-------------------+-----------------|
| AWS_US_WEST_2 | 2019-11-15 00:51:45.473 -0700 | ACCOUNT1 | MYDB1 | NULL | true | MYORG.ACCOUNT1.MYDB1 | MYORG.ACCOUNT2, MYORG,ACCOUNT1 | MYORG.ACCOUNT1 | MYORG | MYACCOUNT1 |
+------------------+-------------------------------+-----------------+----------+---------+------------+----------------------------+---------------------------------+------------------------------+-------------------+-----------------+
-- Create a replica of the 'mydb1' primary database
-- If the primary database has the DATA_RETENTION_TIME_IN_DAYS parameter set to a value other than the default value,
-- set the same value for the parameter on the secondary database.
CREATE DATABASE mydb1
AS REPLICA OF myorg.account1.mydb1
DATA_RETENTION_TIME_IN_DAYS = 10;
-- Verify the secondary database
SHOW REPLICATION DATABASES;
+------------------+-------------------------------+---------------+----------+---------+------------+-------------------------+---------------------------------+------------------------------+-------------------+-----------------+
| snowflake_region | created_on | account_name | name | comment | is_primary | primary | replication_allowed_to_accounts | failover_allowed_to_accounts | organization_name | account_locator |
|------------------+-------------------------------+---------------+----------+---------+------------+------------------------------------------+----------------+------------------------------+-------------------------------------|
| AWS_US_WEST_2 | 2019-11-15 00:51:45.473 -0700 | ACCOUNT1 | MYDB1 | NULL | true | MYORG.ACCOUNT1.MYDB1 | MYORG.ACCOUNT2, MYORG.ACCOUNT1 | MYORG.ACCOUNT1 | MYORG | MYACCOUNT1 |
| AWS_US_EAST_1 | 2019-08-15 15:51:49.094 -0700 | ACCOUNT2 | MYDB1 | NULL | false | MYORG.ACCOUNT1.MYDB1 | | | MYORG | MYACCOUNT2 |
+------------------+-------------------------------+---------------+----------+---------+------------+-------------------------+---------------------------------+------------------------------+-------------------+-----------------+
Étape 5 : 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. Pour la réplication initiale d’une très grande base de données principale, nous recommandons d’augmenter le délai d’attente de l’instruction.
Note
Pour actualiser une base de données secondaire, le rôle utilisé pour effectuer l’opération doit avoir le privilège OWNERSHIP sur la base de données ou le rôle doit se voir accorder un rôle qui a le privilège OWNERSHIP sur la base de données.
Le rôle qui exécute l’opération d’actualisation est propriétaire de tous les nouveaux objets ajoutés à la suite de l’actualisation de 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;
Vous pouvez également rafraîchir une base de données secondaire dans l’interface utilisateur Web.
Étape 6. 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 . Envisagez 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. Tout entrepôt peut être fourni ici pour répondre à l’exigence syntaxique, mais n’est pas utilisé 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
privileges
… TO ROLE.Entrepôt
Entrepôt utilisé pour configurer la tâche
USAGE
La spécification d’un entrepôt est nécessaire pour configurer la tâche, mais l’entrepôt n’est pas utilisé pour exécuter la tâche ou pour l’opération d’actualisation.
- Étapes:
Effectuez les étapes suivantes pour chaque base de données secondaire que vous souhaitez actualiser selon une planification :
Créez une tâche qui lance l’actualisation de la base de données selon une planification (à l’aide de CREATE TASK). Bien que la syntaxe CREATETASK pour spécifier un calendrier de réplication nécessite un entrepôt, l’entrepôt n’est pas utilisé pour la réplication.
Par exemple, créez une tâche nommée
refresh_mydb1_task
qui actualise une base de données secondaire nomméemydb1
toutes les 10 minutes avec un délai d’expiration de 4 heures. La tâche est configurée en utilisant l’entrepôt existantmywh
:CREATE TASK refresh_mydb1_task WAREHOUSE = mywh SCHEDULE = '10 minute' USER_TASK_TIMEOUT_MS = 14400000 AS ALTER DATABASE mydb1 REFRESH;
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;
Exemple¶
Exécutez les instructions SQL suivantes dans votre client Snowflake préféré pour activer la réplication et le basculement, effectuez une actualisation initiale de la base de données et mettez en place des actualisations programmées.
Exécuter à partir du compte source¶
-- The commands below are executed from the source account
-- View replication enabled accounts
SHOW REPLICATION ACCOUNTS;
ALTER DATABASE mydb ENABLE REPLICATION TO ACCOUNTS myorg.account2, myorg.account3;
ALTER DATABASE mydb ENABLE FAILOVER TO ACCOUNTS myorg.account2, myorg.account3;
Exécuter à partir de chaque compte cible¶
-- The commands below are executed from each target account
-- View replication enabled databases
-- Note the primary column of the source database for the CREATE DATABASE statement below
SHOW REPLICATION DATABASES;
-- If the primary database has the DATA_RETENTION_TIME_IN_DAYS parameter set to a value other than the default value,
-- set the same value for the parameter on the secondary database.
CREATE DATABASE mydb
AS REPLICA OF myorg.account1.mydb
DATA_RETENTION_TIME_IN_DAYS = 10;
-- Increase statement timeout for initial refresh
-- Optional but recommended for initial refresh of a large database
ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;
-- If you have an active warehouse in current session, update warehouse statement timeout
SELECT CURRENT_WAREHOUSE();
ALTER WAREHOUSE my_wh SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;
-- Reset warehouse statement timeout after initial refresh
ALTER WAREHOUSE my_wh UNSET STATEMENT_TIMEOUT_IN_SECONDS;
-- Refresh a secondary database
ALTER DATABASE mydb REFRESH;
-- Create task
-- Set up refresh schedule for each secondary database using a separate database
USE DATABASE my_db2;
-- Create a task and RESUME the task for each secondary database
-- Edit the task schedule and timeout for your specific use case
CREATE TASK my_refresh_task
WAREHOUSE = my_wh
SCHEDULE = '10 minute'
USER_TASK_TIMEOUT_MS = 14400000
AS
ALTER DATABASE mydb REFRESH;
-- Start task
ALTER TASK my_refresh_task RESUME;
Utilisation de l’ancien localisateur de comptes¶
Bien que l’ancien format snowflake_region.account_locator
soit actuellement pris en charge pour l’identification d’un compte dans les commandes de réplication et de basculement, son utilisation est déconseillée, car il pourrait cesser de fonctionner à l’avenir.
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 secondary_db_name 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;
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 de Snowflake).
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 :
la fonction de table DATABASE_REPLICATION_USAGE_HISTORY (dans Schéma d’information de Snowflake). Cette fonction renvoie l’activité d’utilisation de la réplication au cours des 14 derniers jours.
Vue DATABASE_REPLICATION_USAGE_HISTORY (dans Account Usage). Cette vue renvoie l’activité d’utilisation de la réplication au cours des 365 derniers jours (1 an).
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 la console classique¶
Démarrez manuellement une actualisation de la base de données secondaire dans Classic Console 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 :
Dans l”Classic Console, sélectionnez l’onglet Databases » Replication.
Sélectionnez la base de données secondaire à actualiser.
Sélectionnez le bouton Refresh now. La boîte de dialogue Refresh Database s’ouvre.
Sélectionnez 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.
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 de Snowflake). Cette fonction renvoie l’activité d’actualisation de la base de données au cours des 14 derniers jours.
ou
Interrogez le schéma Vue DATABASE_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 de base de données 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));
Surveillance du coût de réplication d’une base de données¶
Pour les bases de données individuelles répliquées à l’aide de la réplication de base de données, des utilisateurs avec le rôle ACCOUNTADMIN peuvent utiliser Snowsight, l”Classic Console, ou SQL pour voir la quantité de données de réplication transférées (en octets) pour votre compte Snowflake sur une période donnée.
Pour afficher les quantités de données transférées pour votre compte :
- Snowsight:
Select Admin » Cost Management
- Classic Console:
Cliquez sur Account » Billing & Usage.
L’utilisation de la réplication est illustrée sous forme d’un entrepôt spécial fourni par Snowflake nommé REPLICATION. Cliquez sur le bouton Data Transfer pour afficher les coûts de transfert de données. Notez que l’interface Web ne décompose pas les coûts de transfert de données pour la réplication.
- SQL:
Interrogez l’un des éléments suivants :
la fonction de table DATABASE_REPLICATION_USAGE_HISTORY (dans Schéma d’information de Snowflake). Cette fonction renvoie l’activité d’utilisation de la réplication de base de données au cours des 14 derniers jours.
la vue Vue DATABASE_REPLICATION_USAGE_HISTORY (dans Account Usage). Cette vue renvoie l’activité d’utilisation de la réplication de base de données au cours des 365 derniers jours (1 an).
Les requêtes suivantes peuvent être exécutées sur la vue DATABASE_REPLICATION_USAGE_HISTORY :
Requête : historique des coûts de réplication (par jour, par objet)
Cette requête fournit une liste complète des bases de données répliquées et le volume de crédits consommés via le service de réplication au cours des 30 derniers jours, ventilés par jour. Toute irrégularité dans la consommation de crédit ou une consommation constamment élevée sont des signaux d’alerte qui entraînent la nécessité d’une investigation plus profonde.
SELECT TO_DATE(start_time) AS date, database_name, SUM(credits_used) AS credits_used FROM snowflake.account_usage.database_replication_usage_history WHERE start_time >= DATEADD(month,-1,CURRENT_TIMESTAMP()) GROUP BY 1,2 ORDER BY 3 DESC;Requête : historique de réplication et moyenne sur X jours
Cette requête montre les crédits quotidiens moyens consommés par la réplication, groupés par semaine, au cours de la dernière année. Cela permet d’identifier toute anomalie dans la moyenne quotidienne. Ainsi, vous pouvez enquêter sur des pics ou des changements dans la consommation.
WITH credits_by_day AS ( SELECT TO_DATE(start_time) AS date, SUM(credits_used) AS credits_used FROM snowflake.account_usage.database_replication_usage_history WHERE start_time >= DATEADD(year,-1,CURRENT_TIMESTAMP()) GROUP BY 1 ORDER BY 2 DESC ) SELECT DATE_TRUNC('week',date), AVG(credits_used) AS avg_daily_credits FROM credits_by_day GROUP BY 1 ORDER BY 1;
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 principale (à partir de l’horodatage de l’instantané de la base de données principale) et comparez la sortie.
Exemple¶
Exécution sur la base de données secondaire¶
Sur la base de données secondaire, interrogez la fonction de table DATABASE_REFRESH_PROGRESS (dans Schéma d’information de Snowflake). Notez-le
snapshot_transaction_timestamp
dans la colonneDETAILS
pour la phasePRIMARY_UPLOADING_DATA
. Il s’agit de l’horodatage du dernier instantané de la base de données principale.select parse_json(details)['snapshot_transaction_timestamp'] from table(information_schema.database_refresh_progress(mydb)) where phase_name = 'PRIMARY_UPLOADING_DATA';
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;
Exécution sur la base de données principale¶
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 => '<snapshot_transaction_timestamp>'::TIMESTAMP);
Comparez les résultats des deux requêtes. La sortie doit être identique.
Suppression d’une base de données secondaire¶
Vous pouvez détruire une base de données secondaire à tout moment à l’aide de la commande DROP DATABASE. Seul le propriétaire de la base de données (c’est-à-dire le rôle doté du privilège OWNERSHIP sur la base de données) peut détruire la base de données.
Suppression d’une base de données principale¶
Une base de données principale ne peut pas être supprimée s’il existe au moins un réplica de la base de données (c.-à-d. des bases de données secondaires). Pour détruire la base de données principale, commencez par promouvoir une base de données secondaire, afin qu’elle serve de base de données principale, puis détruisez l’ancienne base de données principale. Vous pouvez également détruire toutes les bases de données secondaires de la base de données principale, puis détruire la base de données principale.
Notez que seul le propriétaire de la base de données peut détruire la base de données.