Réplication d’espaces de travail¶

Important

Les espaces de travail appartenant aux utilisateurs requièrent un niveau Business Critical (BC) ou supérieur pour prendre en charge la réplication.
Le basculement et la restauration nécessitent la version Business Critical Edition ou une version ultérieure. Pour en savoir plus sur la mise à niveau, contactez le Support Snowflake.

La réplication permet d’assurer la continuité des activités en rendant les espaces de travail et d’autres objets importants disponibles dans tous les comptes, même lors de catastrophes, de pannes ou de périodes d’indisponibilité. Des administrateurs configurent des groupes de réplication pour copier les objets et les bases de données d’un compte principal vers un ou plusieurs comptes secondaires selon une planification définie.

Fonctionnement de la réplication d’espaces de travail¶

Les espaces de travail partagés sont répliqués lorsqu’ils sont inclus dans une base de données qui fait partie d’un groupe de réplication ou de basculement. Les espaces de travail privés sont répliqués lorsque leurs utilisateurs propriétaires sont répliqués. Dans les comptes secondaires (cibles), le contenu répliqué est en lecture seule ; les fichiers d’espace de travail sont exécutables mais ne peuvent pas être modifiés. Pour créer et exécuter de nouvelles requêtes, utilisez l’interface de feuille de calcul d’origine dans le compte secondaire.

La réplication de base de données peut également être configurée en tant que groupe de basculement pour prendre en charge la haute disponibilité. Lorsqu’un groupe de basculement secondaire est promu en principal, tous les objets contenus, y compris les espaces de travail, deviennent accessibles en écriture dans le nouveau compte principal.

Pour plus d’informations, voir Présentation de la réplication et du basculement à travers plusieurs comptes.

Espaces de travail LOCAL¶

Les espaces de travail LOCAL ne participent pas à la réplication des espaces de travail. Les fichiers de l’espace de travail restent dans le déploiement actuel et ne sont pas copiés ou synchronisés avec d’autres déploiements.

Lorsque la réplication des espaces de travail est activée, tous les espaces de travail et fichiers qui existent déjà dans un déploiement secondaire sont automatiquement désignés comme LOCAL. Cela garantit que les utilisateurs conservent l’accès aux données de leur espace de travail existant dans le déploiement secondaire au lieu de les perdre lorsque la réplication est activée.

Configurer la réplication d’espace de travail¶

Pour répliquer des espaces de travail, vous devez effectuer les tâches de configuration suivantes dans l’ordre :

Étape 1 : Activer la réplication pour le compte.¶

Un utilisateur disposant du rôle ORGADMIN doit activer la réplication pour chaque compte source et cible dans l’organisation :

USE ROLE ORGADMIN;
SELECT SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER(
    '<organization_name>.<account_name>',
    'ENABLE_ACCOUNT_DATABASE_REPLICATION',
    'true');

Copy

Pour plus d’informations, voir. Conditions préalables : Activer la réplication pour les comptes de votre organisation.

Étape 2 : Créer un groupe de réplication.¶

Un groupe de réplication copie les objets d’un compte principal vers un compte secondaire selon une planification définie de façon facultative.

Pour créer un groupe de réplication, spécifiez le compte qui contient l’espace de travail dans le groupe de réplication :

Compte principal¶

USE ROLE ACCOUNTADMIN;

CREATE REPLICATION GROUP my_replication_group
    OBJECT_TYPES = USERS
    ALLOWED_ACCOUNTS = org_name.secondary_account_name
    [ REPLICATION_SCHEDULE = '10 MINUTE' ]

Copy

Dans cet exemple :

ALLOWED_ACCOUNTS - Le compte secondaire vers lequel la réplication doit être effectuée.
REPLICATION_SCHEDULE - La fréquence de la réplication (par exemple, ’10 MINUTE’ ou ’1 HOUR’).

Compte secondaire¶

USE ROLE ACCOUNTADMIN;
CREATE REPLICATION GROUP my_replication_group
  AS REPLICA OF org_name.primary_account_name.my_replication_group;

Copy

Configurer le basculement pour la haute disponibilité¶

Pour activer le basculement (progression d’un compte secondaire en principal) pendant une panne, vous devez utiliser un groupe de basculement au lieu d’un groupe de réplication :

Compte principal¶

USE ROLE ACCOUNTADMIN;
CREATE FAILOVER GROUP my_failover_group
  OBJECT_TYPES = USERS
  ALLOWED_ACCOUNTS = org_name.secondary_account_name
  [ REPLICATION_SCHEDULE = '10 MINUTE' ]

Copy

Compte secondaire¶

USE ROLE ACCOUNTADMIN;
CREATE FAILOVER GROUP my_failover_group
  AS REPLICA OF org_name.primary_account_name.my_failover_group;

Copy

Le compte secondaire prend le relais en cas d’échec du compte principal¶

Si vous promouvez le groupe de basculement en tant que groupe principal, l’espace de travail devient accessible en lecture et en écriture.

Comportement du compte secondaire¶

Si vous ne disposez pas d’espace de travail en lecture-écriture disponible, vous pouvez également revenir à l’utilisation des feuilles de calcul dans Snowsight qui prennent en charge la lecture-écriture.

Considérations¶

Les résultats de la requête ne sont pas répliqués. Les résultats de la requête ne sont stockés que dans le compte où la requête a été exécutée à l’origine.
Le rôle, l’entrepôt, la base de données et le contexte de schéma sélectionnés pour les fichiers ne sont pas répliqués. Vous pouvez répliquer ces objets au niveau du compte séparément, mais ces contextes ne resteront pas sélectionnés sur les fichiers du compte cible.

Limitations¶

L’intégration Git n’est pas prise en charge actuellement après le basculement. Si un compte secondaire avec des espaces de travail est promu en principal, vous devez reconfigurer manuellement l’intégration Git.
Les espaces de travail du compte secondaire sont en lecture seule.

Pour plus d’informations détaillées sur le comportement de réplication, voir Considérations relatives à la réplication.