Paramétrez Openflow Connector for SQL Server¶

Paramètres de débit¶

Commencez par définir les paramètres du contexte des paramètres source SQLServer, puis définissez le contexte des paramètres de destination SQLServer. Une fois cette opération terminée, activez le connecteur. Le connecteur se connecte à la fois à SQLServer et à Snowflake et démarre l’exécution. Toutefois, le connecteur ne réplique aucune donnée tant que les tables à répliquer n’ont pas été explicitement ajoutées à sa configuration.

Pour configurer des tables spécifiques pour la réplication, modifiez le contexte des paramètres d’ingestion SQLServer. Une fois que vous avez appliqué les modifications au contexte des paramètres d’ingestion SQLServer, la configuration est reprise par le connecteur et le cycle de vie de la réplication démarre pour chaque table.

Répliquer des tables à partir d’un serveur de réplique SQL Server¶

Le connecteur peut ingérer des données d’un serveur principal, d’un serveur d’abonnés à l’aide de la réplication transactionnelle , ou d’une réplique secondaire dans un groupe de disponibilité Toujours activé. Avant de configurer le connecteur pour qu’il se connecte à une réplique SQL Server, assurez-vous que la réplication entre les nœuds principaux et les nœuds de réplique fonctionne correctement. Lorsque vous enquêtez sur des problèmes liés à des données manquantes dans le connecteur, assurez-vous d’abord que les lignes manquantes et les événements de suivi des modifications sont présents dans le serveur de réplique utilisé par le connecteur.

Pour assurer la continuité, assurez-vous que le même utilisateur de connexion est disponible sur le serveur principal et le serveur de réplique, et qu’il a accès aux données et aux tables de suivi des modifications.

Groupes de disponibilité Toujours activé¶

Les groupes de disponibilité Toujours activé sont une solution de haute disponibilité et de reprise après incident qui conserve des copies synchronisées des bases de données à des fins de basculement. Le connecteur peut lire à partir d’une réplique secondaire dans le groupe de disponibilité. Pour une expérience optimale, configurez une écoute du groupe de disponibilité et utilisez le nom DNS de l’écoute dans le paramètre SQLServer Connection URL.

Redémarrer la réplication de table¶

Une table à l’état FAILED, par exemple, en raison d’une clé primaire manquante ou d’un changement de schéma non pris en charge, ne redémarre pas automatiquement. Si une table passe à l’état FAILED ou si vous devez redémarrer la réplication à partir de zéro, utilisez la procédure suivante pour supprimer et ajouter à nouveau la table à la réplication.

1. Supprimez la table des paramètres de flux. Dans le contexte Paramètres d’ingestion, supprimez la table dans les Included Table Names ou modifiez le Included Table Regex de sorte que la table n’a plus aucune correspondance.

2. Vérifiez que la table a été supprimée :

   1. Dans le canevas de l’environnement d’exécution Openflow, cliquez avec le bouton droit de la souris sur un groupe de processeurs et choisissez Controller Services.

   2. Dans la table répertoriant les services du contrôleur, recherchez la ligne Table State Store, cliquez sur les trois points verticaux sur le côté droit de la ligne, puis choisissez View State.

   Important

   Vous devez attendre que l’état de la table soit entièrement supprimé de cette liste avant de poursuivre. Ne continuez pas tant que cette modification de la configuration n’est pas terminée.

3. Nettoyez la destination. Une fois que l’état de la table indique qu’elle est entièrement supprimés, DROP manuellement la table de destination dans Snowflake. Notez que le connecteur ne remplacera pas une table de destination existante pendant la phase de l’instantané. Si la table existe toujours, la réplication échouera à nouveau. En option, la table et le flux de journal peuvent également être supprimés s’ils ne sont plus nécessaires.

4. Rajouter la table : Mettez à jour les paramètres Included Table Names ou Included Table Regex pour inclure à nouveau la table.

5. Vérifiez le redémarrage. Vérifiez le Table State Store en utilisant les instructions données précédemment. L’état de la table doit apparaître avec le statut NEW, puis SNAPSHOT_REPLICATION et pour finir INCREMENTAL_REPLICATION.

Répliquer un sous-ensemble de colonnes dans une table¶

Le connecteur filtre les données répliquées par table sur un sous-ensemble de colonnes configurées.

Pour appliquer des filtres aux colonnes, modifiez la propriété Filtre de colonne dans le contexte Paramètres de réplication, en ajoutant un tableau de configurations, une entrée pour chaque table à laquelle vous souhaitez appliquer un filtre.

Incluez ou excluez des colonnes par nom ou modèle. Vous pouvez appliquer une seule condition par table ou combiner plusieurs conditions, les exclusions ayant toujours la priorité sur les inclusions.

L’exemple suivant montre les champs disponibles. Les champs schema et table sont obligatoires. Une ou plusieurs des adresses suivantes : included, excluded, includedPattern, excludedPattern sont exigées.

[
    {
        "schema": "<source table schema>",
        "table" : "<source table name>",
        "included": ["<column name>", "<column name>"],
        "excluded": ["<column name>", "<column name>"],
        "includedPattern": "<regular expression>",
        "excludedPattern": "<regular expression>",
    }
]

Suivre les changements de données dans les tables¶

Le connecteur réplique l’état actuel des données provenant des tables sources, mais aussi chaque état de chaque ligne de chaque jeu de modifications. Ces données sont stockées dans des tables de journal créées dans le même schéma que la table de destination.

Les noms des tables de journal sont formatés comme suit : <source_table_name>_JOURNAL_<timestamp>_<schema_generation> où <timestamp> correspond au nombre de secondes écoulées depuis l’époque de référence au moment où la table source a été ajoutée à la réplication, et <schema_generation> est un nombre entier qui augmente à chaque modification du schéma de la table source. Par conséquent, les tables sources qui subissent des modifications de schéma auront plusieurs tables de journal.

Lorsque vous supprimez une table de la réplication, puis que vous l’ajoutez à nouveau, la valeur <timestamp> change, et <schema_generation> recommence à partir de 1.

Le connecteur ne supprime jamais les tables de journal, mais il utilise le journal le plus récent pour chaque table source répliquée, en se contentant de lire les flux d’ajout uniquement au-dessus des journaux. Pour récupérer le stockage, vous pouvez :

• Tronquer toutes les tables de journal à tout moment.

• Supprimer les tables de journal liées aux tables sources qui ont été retirées de la réplication.

• Supprimer toutes les tables de journal de la dernière génération, sauf les tables activement répliquées.

Par exemple, si votre connecteur est paramétré pour répliquer activement la table source orders, et que vous avez précédemment supprimé la table customers de la réplication, vous pouvez avoir les tables de journal suivantes. Dans ce cas, vous pouvez toutes les supprimer, à l’exception de orders_5678_2.

customers_1234_1
customers_1234_2
orders_5678_1
orders_5678_2

Configuration de la planification des tâches de fusion¶

Le connecteur utilise un entrepôt pour fusionner les données de capture des données de changement (CDC) dans les tables de destination. Cette opération est déclenchée par le processeur MergeSnowflakeJournalTable. S’il n’y a pas de nouvelles modifications ou si aucun nouveau fichier de flux n’est en attente dans la file d’attente MergeSnowflakeJournalTable, aucune fusion n’est déclenchée et l’entrepôt se suspend automatiquement.

Utilisez l’expression CRON dans le paramètre de planification CRON de la tâche de fusion pour limiter le coût de l’entrepôt et restreindre les fusions aux seules heures planifiées. Elle limite les fichiers de flux arrivant au processeur MergeSnowflakeJournalTable et les fusions ne sont déclenchées qu’au cours d’une période donnée. Pour plus d’informations sur la planification, voir Stratégie de planification.