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 n’utilisent pas la réplication des espaces de travail. Les fichiers des espaces de travail restent dans le déploiement actuel et ne sont pas copiés ou synchronisés avec d’autres déploiements. Les espaces de travail LOCAL sont stockés dans un schéma appelé LOCAL et sont toujours en lecture-écriture, que le compte soit un compte principal ou un compte secondaire.

Lorsque la réplication des espaces de travail est activée pour la première fois, tous les espaces de travail qui existent déjà dans le déploiement secondaire sont automatiquement migrés depuis le schéma PUBLIC vers le schéma LOCAL lors de la première actualisation. Cette migration en une fois garantit que les utilisateurs conservent l’accès aux données de leurs espaces de travail existants dans le déploiement secondaire au lieu de les perdre lorsque la réplication est activée.

Après la migration en une fois, le comportement de réplication standard de Snowflake s’applique :

Les espaces de travail du compte secondaire (à l’exception de ceux du schéma LOCAL) sont mis à jour pour refléter le compte principal lors de chaque actualisation et sont en lecture seule.
Les espaces de travail dans le schéma LOCAL ne sont pas affectés par les actualisations de la réplication et restent en lecture-écriture.

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');

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' ]

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;

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' ]

Compte secondaire¶

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

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.