Configurer la reprise après sinistre

Le Snowflake Connector for ServiceNow® est soumis aux conditions de Snowflake Connector.

Le Snowflake Connector for ServiceNow® peut être configuré de sorte à utiliser une deuxième instance afin de prendre en charge la reprise après sinistre.

À propos de la prise en charge de la reprise après sinistre Snowflake Connector for ServiceNow®

Le Snowflake Connector for ServiceNow® stocke les métadonnées relatives aux tables configurées et à sa propre configuration au sein de l’instance d’application. Lorsque l’application est abandonnée ou corrompue, cet état interne est perdu. Pour éviter cela, le connecteur exporte les métadonnées vers la base de données de destination en même temps que les données ingérées lors d’événements spécifiques, par exemple :

  • Planification d’une nouvelle ingestion

  • Finalisation du rechargement

  • Annulation du rechargement

Le processus d’exportation crée plusieurs tables dans le schéma de destination pour stocker l’état interne du connecteur. Ces tables ne contiennent pas les données ingérées mais sont essentielles pour récupérer l’état du connecteur après l’abandon ou la corruption de l’application. Lorsqu’elles sont répliquées, ces tables peuvent également être utilisées pour récupérer l’état du connecteur sur un autre compte Snowflake. Les tables suivantes sont créées par le processus d’exportation :

  • APP_CONFIG_SFSDKEXPORT_V1

  • APP_STATE_SFSDKEXPORT_V1

  • CONNECTOR_ERRORS_LOG_SFSDKEXPORT_V1

  • INGESTION_PROCESS_SFSDKEXPORT_V1

  • INGESTION_RUN_SFSDKEXPORT_V1

  • NOTIFICATIONS_STATE_SFSDKEXPORT_V1

  • RESOURCE_INGESTION_DEFINITION_SFSDKEXPORT_V1

  • __CONNECTOR_STATE_EXPORT

Importation de données et de rapports existants dans une nouvelle instance du connecteur

Si le Snowflake Connector for ServiceNow® a été désinstallé ou corrompu, il est possible de reprendre l’ingestion des tables précédemment configurées, à condition que la base de données de destination n’ait pas été abandonnée. Les métadonnées des tables configurées dans le connecteur sont enregistrées dans la base de données de destination en même temps que les données ingérées.

Pour continuer à ingérer des données après l’installation d’une nouvelle instance de connecteur, procédez comme suit :

  1. Configuration du connecteur

    Configurez le connecteur en suivant les instructions indiquées à la section Installation et configuration du connecteur avec Snowsight ou Installation et configuration du connecteur via des commandes SQL. Lorsque vous choisissez la base de données et le schéma de destination, sélectionnez le schéma existant qui contient les données ingérées par l’instance précédente du connecteur.

  2. Accordez les privilèges requis au connecteur.

    Note

    Cette étape n’est requise que si vous avez installé et configuré le connecteur à l’aide de commandes SQL. Si vous avez installé le connecteur à l’aide de Snowsight, vous pouvez ignorer cette étape.

    Exécutez la commande suivante pour vous assurer que le connecteur récemment installé devienne le propriétaire de tous les objets dans le schéma existant :

    system$grant_ownership_to_application('your_application_instance', true, '<database>', '<schema>');
    Copy

    Où <base de données> et <schéma> sont les noms de la base de données et du schéma existants, respectivement.

  3. Mettez le connecteur en pause.

    call pause_connector();
    Copy

  4. Importer les données existantes et la configuration de la table

    Importez les données existantes et la configuration de la table en exécutant la commande suivante à partir du contexte de l’application installée :

    call import_state(force => true);
    Copy

    Le paramètre forcer est défini sur vrai afin de garantir que toute modification susceptible d’avoir été apportée au connecteur récemment installé est écrasée par la configuration de la table et les données internes de l’ancienne installation.

  5. Reprendre le connecteur

    call resume_connector();
    Copy

À ce stade, la nouvelle instance du connecteur Snowflake Connector for ServiceNow® doit reprendre l’ingestion des tables existantes.

Réplication de la base de données de destination et de l’état du connecteur vers un autre déploiement Snowflake

Cette section décrit les étapes à suivre pour répliquer le contenu de la base de données de destination. La base de données de destination contient les données ingérées et les métadonnées des tables configurées dans le connecteur. Si le connecteur ou les données téléchargées par le connecteur sont essentiels pour votre entreprise, pensez à paramétrer un compte Snowflake secondaire dans une autre région et à répliquer la base de données de destination sur le compte secondaire.

Termes et définitions

Les termes et définitions suivants sont utilisés au cours du processus de configuration de la reprise après sinistre.

Base de données de destination

Base de données configurée comme cible des données ingérées par le connecteur. C’est également vers cette base de données que l’état interne du connecteur est exporté.

Schéma de destination

Schéma configuré comme cible des données ingérées par le connecteur.

État interne

Données internes et configuration du connecteur, par exemple, configurations des tables, état d’ingestion et journaux d’erreurs.

Instance de connecteur

Instance de connecteur Snowflake Connector for ServiceNow® installée sur le compte Snowflake.

ACCOUNT_PRIM

Exemple de nom de compte principal

ACCOUNT_SEC

Exemple de nom de compte secondaire (réplique)

APP_PRIM

Exemple de nom d’instance de connecteur Snowflake Connector for ServiceNow® installée sur le compte principal

APP_SEC

Exemple de nom d’instance de connecteur Snowflake Connector for ServiceNow® installée sur le compte secondaire

DST_DB.DST_SCHEMA

Exemple de nom de schéma de destination de l’instance de connecteur (où les données sont ingérées et l’état interne du connecteur est enregistré)

DST_DB

Exemple de nom de base de données de destination configurée pour le connecteur

MYORG

Exemple de nom de votre organisation (les deux comptes doivent appartenir à la même organisation)

Introduction

Lorsqu’il est installé sur votre compte, le connecteur Snowflake Connector for ServiceNow® (instance de connecteur) apparaît comme une base de données normale qui contient des données, des procédures, etc. Cependant, il ne peut pas être répliqué sur un compte secondaire de la même manière qu’une base de données normale. Actuellement, il n’existe pas de mécanisme natif permettant de répliquer l’instance de connecteur avec son état interne sur une réplique de compte. Plus précisément, l’application installée ne peut pas être ajoutée à un groupe de réplication.

Au lieu de répliquer directement l’instance de connecteur, le connecteur exporte les métadonnées des tables configurées vers le schéma de destination configuré lors du processus de configuration du connecteur. L’état y est sauvegardé et peut être répliqué en même temps que les données ingérées.

Par exemple, si vous avez configuré le connecteur pour ingérer des données dans le schéma de destination DST_DB.DST_SCHEMA, le connecteur enregistre automatiquement son état interne dans ce schéma. Vous pouvez ensuite répliquer les données ingérées et l’état interne à l’aide de la commande suivante :

create replication group connector_dest_database_group
  object_types = databases
  allowed_databases = dst_db
  allowed_accounts = ...;
Copy

Paramétrage de la réplication des données ingérées et des rapports configurés

Prudence

Testez toujours vos procédures de reprise après sinistre pour vérifier que la réplication des données et des états fonctionne comme prévu.

Avant de poursuivre, familiarisez-vous avec Réplication Snowflake.

Les sections suivantes contiennent des instructions applicables à toutes les versions de Snowflake.

  1. Installation du connecteur sur le compte principal

    Installez et configurez Snowflake Connector for ServiceNow® sur le compte principal. Pour des instructions détaillées, consultez Installation et configuration du connecteur avec Snowsight ou Installation et configuration du connecteur via des commandes SQL.

    Sur le compte principal, créez un groupe de réplication et ajoutez DST_DB comme base de données autorisée :

    -- on primary account
create replication group connector_rep_group_prim
  object_types = databases
  allowed_databases = dst_db
  allowed_accounts = myorg.account_sec
  replication_schedule = '10 minute';
    Copy

  2. Paramétrage de la réplication sur le compte secondaire

    Pour répliquer DST_DB du compte principal vers le compte secondaire, créez un nouveau groupe de réplication sur le compte secondaire :

    -- on secondary account
create replication group connector_rep_group_sec
  as replica of myorg.account_prim.connector_rep_group_prim;

alter replication group connector_rep_group_sec refresh;
    Copy

    À ce stade, une base de données DST_DB en lecture seule doit être créée sur le compte secondaire, et les données du compte principal seront répliquées selon la planification configurée.

  3. Installer le connecteur sur le compte secondaire

    Installez et configurez Snowflake Connector for ServiceNow® sur le compte secondaire de la même manière que sur le compte principal. Pointez l’instance pour qu’elle ingère des données dans la base de données et le schéma répliqués. Tant que la réplication est en cours (jusqu’à ce que le groupe de réplication du compte secondaire soit supprimé), la base de données est en mode lecture seule. Le connecteur peut être configuré de sorte à utiliser une base de données en lecture seule comme cible d’ingestion ; cependant, il ne peut pas ingérer de données tant que la base de données ne passe pas en mode lecture-écriture.

    Après avoir configuré le connecteur sur le compte secondaire, mettez le connecteur en pause en exécutant :

    -- on secondary account
call pause_connector();
    Copy

    À ce stade, le connecteur est installé et prêt à prendre le relais en cas de défaillance du compte principal.

Procédure de récupération

Lorsque le déploiement principal devient indisponible, configurez l’instance de connecteur sur le compte secondaire pour poursuivre l’ingestion.

Important

Toutes les étapes doivent être exécutées sur le compte secondaire.

  1. Supprimer le groupe de réplication

    Supprimez le groupe de réplication sur le compte secondaire pour faire passer la base de données répliquée en mode lecture-écriture :

    drop replication group connector_rep_group_sec;
    Copy

  2. Accorder la propriété d’objets existants de la base de données au connecteur

    Accordez la propriété de tous les objets du schéma répliqué au connecteur en exécutant :

    call system$grant_ownership_to_application('app_sec', true, 'dst_db', 'dst_schema');
    Copy

  3. Importer l’état

    Initialisez le connecteur avec l’état répliqué à partir du compte principal :

    call import_state(true);
    Copy

  4. Reprendre le connecteur

    Reprenez le connecteur en exécutant :

    call resume_connector();
    Copy

    À ce stade, le connecteur du compte secondaire doit reprendre l’ingestion de données là où le connecteur du compte principal l’a laissée.

    Note

    Assurez-vous que le compte principal et le compte secondaire fassent partie de la même organisation. La planification de la réplication peut être adaptée en fonction de vos exigences.

Langage: Français