Réplication des objets du compte¶
Cette rubrique décrit les étapes nécessaires pour répliquer les objets et les données de compte entre les comptes Snowflake de la même organisation, et maintenir la synchronisation des objets et des données. La réplication de comptes peut se produire entre des comptes Snowflake dans différentes régions et entre des plateformes Cloud.
Dans ce chapitre :
Prise en charge de la région pour la réplication et le basculement/la récupération
Transition de la réplication de base de données à la réplication par groupe
Réplication d’objets de compte et de bases de données
Prérequis : activer la réplication des comptes dans l’organisation
Étape 1 : Créer un rôle avec le privilège CREATE FAILOVER GROUP dans le compte source — Facultatif
Étape 2 : Créer un groupe de basculement principal dans un compte source
Étape 3 : Créer un rôle avec le privilège CREATE FAILOVER GROUP dans le compte cible — Facultatif
Étape 4 : Créer un groupe de basculement secondaire dans le compte cible
Actualiser manuellement un groupe de basculement secondaire dans un compte cible
Comparaison des ensembles de données dans les bases de données principales et secondaires
Prise en charge de la région pour la réplication et le basculement/la récupération¶
Les clients peuvent répliquer dans toutes les régions d’un groupe de régions. Pour effectuer une réplication entre des régions de Groupes de régions différentes (par exemple, d’une région commerciale Snowflake à une région gouvernementale Snowflake), veuillez contacter l’assistance de Snowflake afin d’autoriser l’accès.
Transition de la réplication de base de données à la réplication par groupe¶
Les bases de données pour lesquelles la réplication a été activée à l’aide de ALTER DATABASE doivent avoir la réplication désactivée avant qu’elles puissent être ajoutées à un groupe de réplication ou de basculement.
Note
Exécutez les instructions SQL de cette section en utilisant le rôle ACCOUNTADMIN.
Étape 1. Désactiver la réplication pour une base de données pour laquelle la réplication a été autorisée¶
Exécutez la fonction SYSTEM$DISABLE_DATABASE_REPLICATION pour désactiver la réplication d’une base de données principale, ainsi que de toutes les bases de données secondaires qui lui sont liées, afin de l’ajouter à un groupe de réplication ou de basculement.
Exécutez l’instruction SQL suivante depuis le compte source avec la base de données principale :
SELECT SYSTEM$DISABLE_DATABASE_REPLICATION('mydb');
Étape 2. Ajouter la base de données à un groupe de basculement principal et créer un groupe de basculement secondaire¶
Une fois que vous avez réussi à désactiver la réplication pour une base de données, vous pouvez ajouter la base de données principale à un groupe de basculement dans le compte source.
Ensuite, créez un groupe de basculement secondaire dans le compte cible. Lorsque le groupe de basculement secondaire est actualisé dans le compte cible, la base de données précédemment secondaire sera automatiquement ajoutée en tant que membre du groupe de basculement secondaire et actualisée avec les modifications de la base de données principale.
Pour plus de détails sur la création de groupes de basculement principaux et secondaires, voir Workflow.
Note
Lorsque vous ajoutez une base de données précédemment répliquée à un groupe de réplication ou de basculement, Snowflake ne réplique pas à nouveau les données qui ont déjà été répliquées pour cette base de données. Seules les modifications depuis la dernière actualisation sont répliquées lorsque le groupe est actualisé.
Workflow¶
Les instructions SQL suivantes démontrent le flux de travail pour activer la réplication des objets de compte et de base de données et pour actualiser les objets. Chaque étape est examinée en détail ci-dessous.
Note
Les exemples suivants exigent que la réplication soit activée pour les comptes source et cible. Pour plus de détails, voir Prérequis : activer la réplication des comptes dans l’organisation.
Exemples¶
Exécutez les instructions SQL suivantes dans votre client Snowflake préféré pour activer la réplication et le basculement des objets de compte et de base de données, et actualiser les objets.
Exécuter à partir du compte source¶
Créez un rôle et accordez-lui le privilège CREATE FAILOVER GROUP. Cette étape est facultative :
-- Execute the following SQL statements using the ACCOUNTADMIN role: USE ROLE ACCOUNTADMIN; CREATE ROLE myrole; GRANT CREATE FAILOVER GROUP ON ACCOUNT TO ROLE myrole;
Créez un groupe de basculement dans le compte source et activez la réplication vers des comptes cibles spécifiques.
Note
Si vous avez des bases de données à ajouter à un groupe de réplication ou de basculement qui ont été précédemment activées pour la réplication de base de données et le basculement à l’aide de ALTER DATABASE, suivez les instructions Transition de la réplication de base de données à la réplication par groupe (dans cette rubrique) avant de les ajouter à un groupe.
Pour ajouter une base de données à un groupe de basculement, le rôle actif doit avoir le privilège MONITOR sur la base de données. Pour plus de détails sur les privilèges de la base de données, voir Privilèges de base de données (dans une rubrique distincte).
USE ROLE myrole; -- Execute the following SQL statement using a role with the CREATE FAILOVER GROUP privilege: CREATE FAILOVER GROUP myfg OBJECT_TYPES = USERS, ROLES, WAREHOUSES, RESOURCE MONITORS, DATABASES ALLOWED_DATABASES = db1, db2 ALLOWED_ACCOUNTS = myorg.myaccount2, myorg.myaccount3 REPLICATION_SCHEDULE = '10 MINUTE';
Attention
Si des objets de compte (par exemple des utilisateurs ou des rôles) que vous ne souhaitez pas détruire pendant la réplication existent dans le compte cible, n’incluez pas le paramètre
REPLICATION_SCHEDULE
lorsque vous créez un groupe de réplication ou de basculement. Pour plus de détails, voir Étape 5. Appliquer des IDs globaux à des objets créés par des scripts dans des comptes cibles — Facultatif.
Exécuté sur le compte cible¶
Créez un rôle dans le compte cible et accordez-lui le privilège CREATE FAILOVER GROUP. Cette étape est facultative :
-- Execute the following SQL statements using the ACCOUNTADMIN role: USE ROLE ACCOUNTADMIN; CREATE ROLE myrole; GRANT CREATE FAILOVER GROUP ON ACCOUNT TO ROLE myrole;
Créez un groupe de basculement dans le compte cible comme un réplica du groupe de basculement dans le compte source.
USE ROLE myrole; -- Execute the following SQL statement using a role with the CREATE FAILOVER GROUP privilege: CREATE FAILOVER GROUP myfg AS REPLICA OF myorg.myaccount1.myfg;
Appliquez les IDs globaux à des objets. Il s’agit d’une étape facultative pour tout objet de compte non créé par réplication.
-- Execute the following SQL statements using the ACCOUNTADMIN role: SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('myfg');
Attention
Cette étape doit être exécutée si des objets de compte (par exemple des utilisateurs ou des rôles) que vous ne voulez pas détruire pendant la réplication existent dans le compte cible. Si vous ignorez cette étape, vous risquez de perdre les feuilles de calcul des utilisateurs ou les privilèges accordés à des rôles sur des objets (par exemple, des partages). Pour plus de détails, voir Étape 5. Appliquer des IDs globaux à des objets créés par des scripts dans des comptes cibles — Facultatif.
Actualiser manuellement un groupe secondaire¶
Pour actualiser manuellement un groupe de basculement secondaire dans le compte cible, voir Actualiser manuellement un groupe de basculement secondaire dans un compte cible (dans cette rubrique).
Note
En tant que meilleure pratique, Snowflake recommande de programmer des actualisations automatiques en utilisant le paramètre REPLICATION_SCHEDULE. Voir Planification de réplication (dans cette rubrique).
Réplication d’objets de compte et de bases de données¶
Les instructions de cette section expliquent comment préparer vos comptes pour la réplication, activer la réplication d’objets spécifiques du compte source vers le compte cible, et synchroniser les objets dans le compte cible.
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.
Prérequis : 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.
Pour activer la réplication pour les comptes, un utilisateur ayant le rôle ORGADMIN utilise la fonction SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER pour définir le paramètre ENABLE_ACCOUNT_DATABASE_REPLICATION
sur true
. Notez que plusieurs comptes dans une organisation peuvent être activés pour la réplication à partir du même compte ORGADMIN.
Connectez-vous à un compte ORGADMIN pour activer la réplication pour chaque compte source et cible de votre organisation.
-- Assume the ORGADMIN role
use role orgadmin;
-- View the list of the accounts in your organization
-- Note the organization name and account name for each account for which you are enabling replication
show organization accounts;
-- Enable replication by executing this statement for each source and target account in your organization
select system$global_account_set_parameter('<organization_name>.<account_name>', 'ENABLE_ACCOUNT_DATABASE_REPLICATION', 'true');
Bien que la fonction SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER prenne en charge l’ancien identificateur de localisateur de compte , elle donne des résultats inattendus lorsqu’une organisation possède plusieurs comptes qui partagent le même localisateur (dans différentes régions).
Activer l’aperçu de la réplication des flux et des tâches — Facultatif¶
Pour activer l’aperçu de la réplication des flux et des tâches pour un compte, une base de données ou un groupe de réplication ou de basculement, définissez le paramètre ENABLE_STREAM_TASK_REPLICATION sur true
pour le compte source ou l’objet primaire.
Exemples¶
Les exemples suivants doivent être exécutés dans le compte source.
Activez la réplication des flux et des tâches pour une base de données mydb
:
alter database mydb set ENABLE_STREAM_TASK_REPLICATION = true;
Activer la réplication de flux et de tâches pour un groupe de réplication myrg
:
alter replication group myrg set ENABLE_STREAM_TASK_REPLICATION = true;
Activez la réplication des flux et des tâches pour le compte myaccount
dans l’organisation myorg
:
alter account myorg.myaccount set ENABLE_STREAM_TASK_REPLICATION = true;
Note
Le paramètre ne peut pas être défini pour une base de données si celle-ci est incluse dans un groupe de réplication ou de basculement.
Si le paramètre est explicitement défini sur un objet de base de données qui n’est pas inclus dans un groupe de réplication ou de basculement, vous devez annuler le paramètre avant de l’ajouter à un groupe de réplication ou de basculement, sinon l’opération de réplication échouera.
Les paramètres définis sur la base de données, le groupe de réplication ou le groupe de basculement remplacent les paramètres définis sur le compte. Pour plus de détails, reportez-vous à Hiérarchie des paramètres et types et Paramètres d’objet.
Étape 1 : Créer un rôle avec le privilège CREATE FAILOVER GROUP dans le compte source — Facultatif¶
Créez un rôle et accordez-lui le privilège CREATE FAILOVER GROUP. Cette étape est facultative. Si vous avez déjà créé ce rôle, passez à Étape 2 : Créer un groupe de basculement principal dans un compte source.
-- Execute the following SQL statements using the ACCOUNTADMIN role:
USE ROLE ACCOUNTADMIN;
CREATE ROLE myrole;
GRANT CREATE FAILOVER GROUP ON ACCOUNT
TO ROLE myrole;
Étape 2 : Créer un groupe de basculement principal dans un compte source¶
Créez un groupe de basculement principal et activez la réplication et le basculement d’objets spécifiques du compte actuel (source) vers un ou plusieurs comptes cibles dans la même organisation.
Voir tous les comptes pour lesquels la réplication est activée¶
Pour récupérer la liste des comptes de votre organisation pour lesquels la réplication est activée, utilisez SHOW REPLICATION ACCOUNTS.
-- Execute the following SQL statements using the ACCOUNTADMIN role:
SHOW REPLICATION ACCOUNTS;
+------------------------+-------------------------+--------------+-----------------+-----------------+-------------------+
| snowflake_region | created_on | account_name | account_locator | comment | organization_name |
+------------------------+-------------------------+--------------+-----------------+-----------------+-------------------+
| AWS_US_WEST_2 | 2020-07-15 21:59:25.455 | myaccount1 | myacctlocator1 | | myorg |
+------------------------+-------------------------+--------------+-----------------+-----------------+-------------------+
| AWS_US_EAST_1 | 2020-07-23 14:12:23.573 | myaccount2 | myacctlocator2 | | myorg |
+------------------------+-------------------------+--------------+-----------------+-----------------+-------------------+
| AWS_US_EAST_2 | 2020-07-25 19:25:04.412 | myaccount3 | myacctlocator3 | | myorg |
+------------------------+-------------------------+--------------+-----------------+-----------------+-------------------+
Voir la liste complète des IDs de région.
Afficher l’appartenance à un groupe de basculement et de réplication¶
Les objets de compte, de base de données et de partage ont des contraintes sur l’appartenance à un groupe. Avant de créer de nouveaux groupes ou d’ajouter des objets aux groupes existants, vous pouvez consulter la liste des groupes de basculement existants et les objets de chaque groupe.
Note
Seuls un administrateur de compte (utilisateur avec le rôle ACCOUNTADMIN) ou le propriétaire du groupe (rôle avec le privilège OWNERSHIP sur le groupe) peuvent exécuter les instructions SQL de cette section.
Voir tous les groupes de basculement liés au compte actuel et les types d’objets dans chaque groupe :
SHOW FAILOVER GROUPS;
Voir toutes les bases de données du groupe de basculement myfg
:
SHOW DATABASES IN FAILOVER GROUP myfg;
Voir tous les partages du groupe de basculement myfg
:
SHOW SHARES IN FAILOVER GROUP myfg;
Activer la réplication d’objets de compte et de base de données d’un compte source vers un compte cible¶
Créez un groupe de basculement d’objets de compte et de base de données spécifiés dans le compte source et activez la réplication et le basculement vers une liste de comptes cibles. Pour plus d’informations sur la syntaxe, voir CREATE FAILOVER GROUP.
Par exemple, activez la réplication d’utilisateurs, de rôles, d’entrepôts, de moniteurs de ressources et de bases de données db1
et db2
du compte source vers le compte myaccount2
dans la même organisation. Définissez la planification de réplication pour actualiser automatiquement myaccount2
toutes les 10 minutes.
Note
Si vous avez des bases de données à ajouter à un groupe de réplication ou de basculement pour lesquelles la réplication de base de données est activée à l’aide de ALTER DATABASE, suivez les instructions Transition de la réplication de base de données à la réplication par groupe (dans cette rubrique) avant de les ajouter à un groupe.
Exécution sur le compte source :
use role myrole;
-- Execute the following SQL statement using a role with the CREATE FAILOVER GROUP privilege:
create failover group myfg
object_types = users, roles, warehouses, resource monitors, databases, integrations, network policies
allowed_databases = db1, db2
allowed_integration_types = API INTEGRATIONS
allowed_accounts = myorg.myaccount2
replication_schedule = '10 MINUTE';
Attention
Si des objets de compte (par exemple des utilisateurs ou des rôles) que vous ne souhaitez pas détruire pendant la réplication existent dans le compte cible, n’incluez pas le paramètre REPLICATION_SCHEDULE
lorsque vous créez un groupe de réplication ou de basculement. Pour plus de détails, voir Étape 5. Appliquer des IDs globaux à des objets créés par des scripts dans des comptes cibles — Facultatif.
Étape 3 : Créer un rôle avec le privilège CREATE FAILOVER GROUP dans le compte cible — Facultatif¶
Créez un rôle dans le compte cible et accordez-lui le privilège CREATE FAILOVER GROUP. Cette étape est facultative. Si vous avez déjà créé ce rôle, passez à Étape 4 : Créer un groupe de basculement secondaire dans le compte cible.
-- Execute the following SQL statements using the ACCOUNTADMIN role:
USE ROLE ACCOUNTADMIN;
CREATE ROLE myrole;
GRANT CREATE FAILOVER GROUP ON ACCOUNT
TO ROLE myrole;
Étape 4 : Créer un groupe de basculement secondaire dans le compte cible¶
Créez un groupe de basculement secondaire dans le compte cible en tant que réplica du groupe de basculement principal dans le compte source.
Exécutez une instruction CREATE FAILOVER GROUP … AS REPLICA OF dans chaque compte cible pour lequel vous avez activé la réplication dans Étape 2 : Créer un groupe de basculement principal dans un compte source (dans cette rubrique).
Exécution à partir de chaque compte cible :
use role myrole;
-- Execute the following SQL statement using a role with the CREATE FAILOVER GROUP privilege:
CREATE FAILOVER GROUP myfg
AS REPLICA OF myorg.myaccount1.myfg;
Étape 5. Appliquer des IDs globaux à des objets créés par des scripts dans des comptes cibles — Facultatif¶
Attention
Cette étape doit être exécutée si des objets de compte (par exemple des utilisateurs ou des rôles) que vous ne voulez pas détruire pendant la réplication existent dans le compte cible. Si vous ignorez cette étape, vous risquez de perdre les feuilles de calcul des utilisateurs ou les privilèges accordés à des rôles sur des objets (par exemple, des partages).
Si vous avez créé des objets de compte, par exemple des utilisateurs et des rôles, dans votre compte cible par un moyen autre que via la réplication (par exemple en utilisant des scripts), ces utilisateurs et rôles n’ont pas d’identificateur global par défaut. L’opération d’actualisation utilise des identificateurs globaux pour synchroniser ces objets avec les mêmes objets dans le compte source. Lorsqu’un compte cible est actualisé à partir du compte source, l’opération d’actualisation détruit tous les objets de compte des types de la liste object_types
(c’est-à-dire les users
ou les roles
) du compte cible qui n’ont pas d’identificateur global.
Créer des groupes de réplication ou de basculement sans planification de réplication¶
Lorsqu’un groupe de réplication ou de basculement secondaire est créé en tant que réplica d’un groupe de réplication ou de basculement principal avec une planification de la réplication, une actualisation initiale du groupe secondaire est automatiquement exécutée lors de la création du groupe de réplication ou de basculement secondaire. Pour éviter que cela ne se produise avant que vous puissiez exécuter les instructions suivantes, créez le groupe de réplication ou de basculement principal sans définir le paramètre REPLICATION_SCHEDULE
.
Une fois le groupe secondaire créé dans le compte cible, utilisez la fonction SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME pour ajouter des identificateurs globaux aux objets de compte dans le compte cible. Pour les objets de compte qui n’existent que dans le compte cible, répliquez-les manuellement dans le compte source avant d’appeler cette fonction.
Après avoir appliqué des identificateurs globaux aux objets du compte cible, ou les avoir recréés manuellement dans le compte source, utilisez la commande ALTER REPLICATION GROUP ou ALTER FAILOVER GROUP pour définir la planification de la réplication pour le groupe de réplication ou de basculement principal.
Utiliser SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME() pour appliquer des IDs globaux¶
Note
Les identificateurs globaux ne sont ajoutés qu’aux objets de compte qui sont inclus dans un groupe de réplication ou de basculement pour les types d’objets suivants :
RESOURCE_MONITOR
ROLE
USER
WAREHOUSE
Appliquer des identificateurs globaux aux objets du compte cible des types inclus dans la liste object_types
pour le groupe de basculement myfg
:
-- Execute the following SQL statements using the ACCOUNTADMIN role:
SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('myfg');
Mettre à jour le service distant pour les intégrations API¶
Si vous avez activé la réplication de l’intégration API, des étapes supplémentaires sont nécessaires après la réplication de l’intégration API sur le compte cible. L’intégration répliquée possède sa propre entité de gestion des identités et des accès (IAM) qui sont différents de l’identité et de l’entité IAM de l’intégration principale. Par conséquent, vous devez mettre à jour les autorisations sur le service distant pour accorder l’accès à des fonctions répliquées. Le processus est similaire à l’octroi d’accès à des fonctions sur le compte principal. Voir les liens ci-dessous pour plus de détails :
Amazon Web Services Configurer la relation de confiance entre Snowflake et le nouveau rôle IAM.
Google Cloud Platform : créez une politique de sécurité GCP pour le service proxy.
Microsoft Azure :
Actualiser manuellement un groupe de basculement secondaire dans un compte cible¶
Pour actualiser manuellement les objets d’un compte cible, exécutez la commande ALTER FAILOVER GROUP … REFRESH.
Nous vous recommandons de planifier vos actualisations secondaires en définissant le paramètre REPLICATION_SCHEDULE à l’aide de CREATE FAILOVER GROUP ou ALTER FAILOVER GROUP.
Note
Si l’utilisateur qui appelle la fonction dans le compte cible a été détruit dans le compte source, l’opération d’actualisation échoue.
Accordez le privilège REPLICATE sur le groupe de basculement au rôle — Facultatif¶
Le privilège REPLICATE est actuellement non répliqué et doit être accordé à un groupe de basculement (ou de réplication) dans les comptes source et cible.
Exécution depuis le compte source :
-- Execute the following SQL statements using a role with the OWNERSHIP privilege on the group: GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;Exécution depuis le compte cible :
-- Execute the following SQL statements using a role with the OWNERSHIP privilege on the group: GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;
Actualiser manuellement un groupe de basculement secondaire¶
Par exemple, pour actualiser les objets du groupe de basculement myfg
, exécutez l’instruction suivante à partir du compte cible :
USE ROLE my_replication_role; -- Execute the following SQL statements using a role with the REPLICATE privilege: ALTER FAILOVER GROUP myfg REFRESH;
Surveillance de la réplication¶
Cette section fournit des informations sur la façon de surveiller la progression, l’historique et les coûts de réplication des comptes.
Surveiller la progression d’une actualisation de groupe de réplication ou de basculement¶
Pour surveiller la progression d’une actualisation de groupe de réplication ou de basculement, interrogez la fonction de table REPLICATION_GROUP_REFRESH_PROGRESS, REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB (dans le Schéma d’information de Snowflake).
Exemple¶
Visualiser la progression de l’opération d’actualisation la plus récente pour le groupe de basculement myfg
:
SELECT PHASE_NAME, START_TIME, END_TIME, PROGRESS, DETAILS
FROM TABLE(information_schema.replication_group_refresh_progress('myfg'));
Historique de la réplication¶
Pour afficher l’historique de réplication d’un groupe de réplication ou de basculement spécifique dans une période spécifiée, effectuez l’une des requêtes suivantes :
la fonction de table REPLICATION_GROUP_REFRESH_HISTORY (dans Schéma d’information de Snowflake).
Exemples¶
Interrogez la fonction de table Information Schema REPLICATION_GROUP_REFRESH_HISTORY pour afficher l’historique de réplication de compte du groupe de basculement myfg
au cours des 7 derniers jours :
SELECT PHASE_NAME, START_TIME, END_TIME, TOTAL_BYTES, OBJECT_COUNT
FROM TABLE(information_schema.replication_group_refresh_history('myfg'))
WHERE START_TIME >= current_date - interval '7 days';
Interrogez la vue REPLICATION_GROUP_REFRESH_HISTORY de Account Usage pour voir l’historique de réplication de compte pour le mois en cours :
SELECT REPLICATION_GROUP_NAME, PHASE_NAME, START_TIME, END_TIME, TOTAL_BYTES, OBJECT_COUNT
FROM snowflake.account_usage.replication_group_refresh_history
WHERE START_TIME >= date_trunc('month', current_date());
Surveiller les coûts de réplication¶
Pour surveiller l’utilisation du crédit pour la réplication, effectuez l’une des requêtes suivantes :
la fonction de table REPLICATION_GROUP_USAGE_HISTORY (dans Schéma d’information de Snowflake).
Exemples¶
Interroger la fonction de table REPLICATION_GROUP_USAGE_HISTORY pour voir les crédits utilisés pour la réplication de compte au cours des 7 derniers jours :
SELECT start_time, end_time, replication_group_name, credits_used, bytes_transferred
FROM table(information_schema.replication_group_usage_history(date_range_start=>dateadd('day', -7, current_date())));
Interrogez la vue Account Usage REPLICATION_GROUP_USAGE_HISTORY pour voir les crédits utilisés par la réplication ou le groupe de basculement pour l’historique de réplication de compte dans le mois en cours :
SELECT start_time,
end_time,
replication_group_name,
credits_used,
bytes_transferred
FROM snowflake.account_usage.replication_group_usage_history
WHERE start_time >= DATE_TRUNC('month', CURRENT_DATE());
Surveiller les coûts de réplication des bases de données¶
Le coût de la réplication pour une base de données individuelle incluse dans un groupe de réplication ou de basculement peut être calculé en récupérant le nombre d’octets copiés pour la base de données et en l’associant aux crédits utilisés.
Exemples¶
Interrogation des vues de Account Usage¶
Les exemples suivants calculent les coûts de la réplication de la base de données dans un groupe de réplication pour les 30 derniers jours.
Interrogez la vue REPLICATION_GROUP_REFRESH_HISTORY de Account Usage et calculez la somme du nombre d’octets répliqués par base de données.
Par exemple, pour calculer la somme du nombre d’octets répliqués pour les bases de données du groupe de réplication
myrg
au cours des 30 derniers jours :select sum(value:totalBytesToReplicate) as sum_database_bytes from snowflake.account_usage.replication_group_refresh_history rh, lateral flatten(input => rh.total_bytes:databases) where rh.replication_group_name = 'MYRG' and rh.start_time >= current_date - interval '30 days';
Notez la sortie de la somme des octets de la base de données :
+--------------------+ | SUM_DATABASE_BYTES | |--------------------| | 22016 | +--------------------+
Interrogez la vue REPLICATION_GROUP_USAGE_HISTORY de Account Usage et calculez la somme du nombre de crédits utilisés et la somme des octets transférés pour la réplication.
Par exemple, pour calculer la somme du nombre de crédits utilisés et la somme des octets transférés pour la réplication du groupe de réplication
myrg
au cours des 30 derniers jours :select sum(credits_used) as credits_used, SUM(bytes_transferred) as bytes_transferred from snowflake.account_usage.replication_group_usage_history where replication_group_name = 'MYRG' and start_time >= current_date - interval '30 days';
Notez la sortie de la somme des crédits utilisés et de la somme des octets transférés :
+--------------+-------------------+ | CREDITS_USED | BYTES_TRANSFERRED | |--------------+-------------------| | 1.357923604 | 22013 | +--------------+-------------------+
Calculez les coûts de réplication pour les bases de données en utilisant les valeurs des octets transférés pour les bases de données, la somme des crédits utilisés, et la somme de tous les octets transférés pour la réplication des deux étapes précédentes :
(<octets_de_base_de_données_transférés> / <octets_transférés>) * <crédits_utilisés>
Par exemple :
(22016 / 22013) * 1.357923604 = 1.35810866)
Interrogation des fonctions de table d’Information Schema¶
Pour les opérations d’actualisation effectuées au cours des 14 derniers jours, interrogez les fonctions de la table Information Schema associée.
Interroger la fonction de table REPLICATION_GROUP_REFRESH_HISTORY pour voir la somme du nombre d’octets copiés pour la réplication de la base de données pour le groupe de réplication
myrg
:select sum(value:totalBytesToReplicate) from table(information_schema.replication_group_refresh_history('myrg')) as rh, lateral flatten(input => total_bytes:databases) where rh.phase_name = 'COMPLETED' and rh.start_time >= current_date - interval '14 days';
Interroger la fonction de la table REPLICATION_GROUP_USAGE_HISTORY pour voir la somme du nombre de crédits utilisés et la somme des octets transférés pour la réplication pour le groupe de réplication
myrg
:select sum(credits_used), sum(bytes_transferred) from table(information_schema.replication_group_usage_history( date_range_start=>dateadd('day', -14, current_date()), replication_group_name => 'myrg' ));
Comparaison des ensembles de données dans les bases de données principales et secondaires¶
Si les objets de la base de données sont répliqués dans un groupe de réplication ou de basculement, la fonction HASH_AGG peut être utilisée pour comparer les lignes d’un ensemble aléatoire de tables dans une base de données primaire et secondaire afin de 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¶
Dans les exemples ci-dessous, la base de données mydb
est incluse dans le groupe de basculement myfg
. La base de données mydb
contient la table mytable
.
Exécuté sur le compte cible¶
Interrogez la fonction de table REPLICATION_GROUP_REFRESH_PROGRESS (dans Schéma d’information de Snowflake). Notez le
primarySnapshotTimestamp
dans la colonneDETAILS
pour la phasePRIMARY_UPLOADING_METADATA
. Il s’agit de l’horodatage du dernier instantané de la base de données principale.SELECT PARSE_JSON(details)['primarySnapshotTimestamp'] FROM TABLE(information_schema.replication_group_refresh_progress('myfg')) WHERE PHASE_NAME = 'PRIMARY_UPLOADING_METADATA';
Interrogez la fonction HASH_AGG pour une table spécifiée d’une base de données secondaire. La requête suivante renvoie une valeur de hachage pour toutes les lignes de la table
mytable
:SELECT HASH_AGG( * ) FROM mytable;
Exécuter à partir du compte source¶
Interrogez la fonction HASH_AGG pour la même table dans la base de données principale. À 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 => '<primarySnapshotTimestamp>'::TIMESTAMP);
Comparez les résultats des deux requêtes. La sortie doit être identique.