Openflow Connector for SQL Server : Maintenance¶

Note

Ce connecteur est soumis aux conditions d’utilisation de Snowflake Connector.

Cette rubrique décrit les considérations de maintenance et les bonnes pratiques pour le Openflow Connector for SQL Server, comme la réinstallation du connecteur ou la définition de la position de départ du suivi des modifications.

Ces opérations sont souvent utilisées conjointement avec la réplication incrémentielle avec instantanés.

Réinstaller le connecteur¶

Cette rubrique fournit des instructions sur la manière de réinstaller le connecteur et de continuer à répliquer les données pour les mêmes tables sans avoir à créer de nouveaux instantanés de celles-ci. Elle couvre les situations où le nouveau connecteur est installé dans le même environnement d’exécution, ainsi que déplacé vers un nouvel environnement d’exécution.

Conditions préalables¶

Examinez et notez les valeurs contextuelles des paramètres du connecteur. Si vous réinstallez le connecteur dans le même environnement d’exécution, vous pouvez réutiliser le contexte existant. Si la nouvelle instance se trouve dans un environnement d’exécution différent, vous devez saisir à nouveau tous les paramètres.

Terminez le traitement de tous les FlowFiles en cours dans le connecteur existant, puis arrêtez le connecteur.
1. Connectez-vous à Snowsight.
2. Dans le menu de navigation, sélectionnez Ingestion » Openflow.
3. Dans le volet Openflow, sélectionnez l’onglet Runtimes.
4. Sélectionnez l’environnement d’exécution contenant le connecteur.
5. Sélectionnez le connecteur.
6. Arrêtez le processeur le plus élevé Set Tables for Replication dans le groupe Snapshot Load.
7. Arrêtez le processeur le plus élevé Read SQLServer Change Tracking tables dans le groupe Incremental Load.
8. Si vous avez modifié la valeur du paramètre Merge Task Schedule CRON, rétablissez-le sur * * * * * ?. Sinon, les files d’attente ne seront pas vidées avant la prochaine exécution planifiée.
  
  Attendez que tous les FlowFiles du connecteur aient été traités et que toutes les files d’attente soient vides. Lorsque tous les FlowFiles ont été traités, la valeur Queued sur le groupe de processeurs du connecteur devient nulle. S’il reste des éléments dans les files d’attente du connecteur d’origine, il se peut qu’il y ait des écarts de données au démarrage du nouveau connecteur.
9. Arrêtez tous les processeurs et tous les services de contrôleur dans le connecteur.
Prudence

Le connecteur existant peut rester dans l’environnement d’exécution et n’interfère pas avec la nouvelle instance, tant qu’il reste à l’arrêt.
Créez une nouvelle instance du connecteur. Si vous utilisez le même environnement d’exécution que le connecteur d’origine, vous pouvez choisir de conserver les contextes de paramètres existants et de réutiliser les paramètres.
Si vous procédez à une installation dans un environnement d’exécution différent, ou si vous avez supprimé les contextes de paramètres précédents, entrez les paramètres de configuration dans les nouveaux contextes de paramètres, y compris les noms et les modèles de tables, comme décrit dans Paramétrez Openflow Connector for SQL Server.
Accédez au contexte SQLServer Ingestion Parameters et définissez les paramètres suivants :
- Définissez le paramètre Ingestion Type sur incremental. Pour plus d’informations, voir Activer la réplication incrémentielle sans instantanés.
- Définissez le paramètre Starting Change Tracking Position sur Earliest. Pour plus d’informations, voir Spécifier la charge à partir de la position de la table de suivi des modifications.
Démarrez le nouveau connecteur.

Notes sur l’utilisation¶

Le nouveau connecteur utilise les tables de destination existantes créées par le connecteur d’origine, mais crée de nouvelles tables de journal.

Spécifier la charge à partir de la position de la table de suivi des modifications¶

Le connecteur Openflow Connector for SQL Server vous permet de sélectionner la position de départ dans laquelle les tables de suivi des modifications sont lues. Par défaut, le connecteur lit à partir de la position la plus récente disponible. Vous pouvez également choisir la position la plus ancienne disponible sur l’instance source. Lors de la réinstallation du connecteur, il est courant de choisir de commencer par la position la plus ancienne. Cela permet à la nouvelle instance de rattraper son retard et de continuer à répliquer les tables existantes sans avoir à créer un nouvel instantané de chacune d’entre elles.

Le fait de faire passer un connecteur en cours d’exécution de la position la plus récente à la position la plus ancienne entraîne la relecture, le nouveau traitement et la ré-application du contenu des tables de suivi des modifications dans la table de destination.

Avertissement

Pendant la relecture des tables de suivi des modifications, les données dans les tables de destination concernées peuvent être désynchronisées avec leurs sources, jusqu’à ce que tous les événements aient été retraités et fusionnés.

Les paramètres suivants sont disponibles dans le contexte Ingestion Parameters :

Paramètre	Description
Position de départ du suivi des modifications	`Latest` (par défaut) : la lecture de la table de suivi des modifications commence à la position la plus récente disponible et continue à partir de là. `Earliest` : Active le chargement incrémentiel pour démarrer ou redémarrer la lecture à partir de la position la plus ancienne disponible dans la table de suivi des modifications.
Relire les tables dans l’état	`New` (par défaut) : Seules les nouvelles tables, ajoutées après le changement de la position de départ en `Earliest`, verront leurs tables de suivi des modifications lues à partir des positions les plus anciennes disponibles. Les tables qui ont commencé la réplication avant le changement de configuration continueront à lire à partir de leurs dernières positions. `Any active` : Relisez et retraitez les modifications de n’importe quelle table actuellement en réplication.

Paramètre

Description

Position de départ du suivi des modifications

Latest (par défaut) : la lecture de la table de suivi des modifications commence à la position la plus récente disponible et continue à partir de là.
Earliest : Active le chargement incrémentiel pour démarrer ou redémarrer la lecture à partir de la position la plus ancienne disponible dans la table de suivi des modifications.

Relire les tables dans l’état

New (par défaut) : Seules les nouvelles tables, ajoutées après le changement de la position de départ en Earliest, verront leurs tables de suivi des modifications lues à partir des positions les plus anciennes disponibles. Les tables qui ont commencé la réplication avant le changement de configuration continueront à lire à partir de leurs dernières positions.
Any active : Relisez et retraitez les modifications de n’importe quelle table actuellement en réplication.

Pour déterminer si le connecteur a terminé la relecture des tables de suivi des modifications, procédez comme suit :

Accédez au canevas Openflow.
Ouvrez le groupe de processus Incremental Load.
Cliquez avec le bouton droit de la souris sur le processeur le plus élevé nommé Read SQLServer Change Tracking tables, puis sélectionnez View state.
Vérifiez les entrées d’état pour chaque table dont les clés commencent par position.. Si une valeur correspond à 0/0, alors le connecteur n’a pas encore terminé de lire les modifications de cette table.

Notes sur l’utilisation¶

Une fois que vous avez basculé un connecteur en cours d’exécution pour lire à partir des positions les plus anciennes et que vous l’avez démarré, vous ne pouvez plus reconfigurer ni annuler le processus, qui se poursuivra jusqu’à ce que les positions actuellement lues atteignent les valeurs les plus récentes.
Le passage à la position la plus ancienne sur un connecteur en cours d’exécution entraîne, pour toutes les tables en cours de retraitement, la fin des journaux existants et la création de nouvelles tables de journal.