À propos de Openflow Connector for SQL Server¶

Workflow¶

Le workflow suivant décrit les étapes pour configurer et exécuter Openflow Connector for SQL Server :

1. L’administrateur de la base de données du serveur SQL effectue les tâches suivantes :

   1. Configures SQL Server replication settings and enables change tracking on the databases and tables being replicated.

   2. Crée des identifiants de connexion pour le connecteur.

   3. (Optional) Provides the SSL certificate to connect to the SQL Server instance over SSL.

2. Un administrateur de compte Snowflake effectue les tâches suivantes :

   1. Crée un utilisateur de service pour le connecteur, une base de données de destination pour stocker les données répliquées, et un entrepôt pour le connecteur.

   2. Installe le connecteur.

   3. Spécifie les paramètres requis pour la définition du flux du connecteur.

   4. Gère le flux.

The connector does the following when run in Openflow:

1. Crée les schémas et les tables de destination correspondant aux tables sources configurées pour la réplication.

2. Begins replication according to the table replication lifecycle.

   Pour plus d’informations, voir Comment les tables sont-elles répliquées ?.

Réplication des données de tables dans plusieurs bases de données SQL Server¶

Le connecteur prend en charge la réplication de tables à partir de plusieurs bases de données SQL Server dans une seule instance SQL Server. Le connecteur crée des tables répliquées à partir de différentes bases de données dans des schémas distincts dans la base de données de destination Snowflake.

Référencez les tables répliquées en combinant le nom de la base de données source, le nom du schéma source, et le nom de la table au format suivant :

<database_name>.<schema_name>.<table_name>

Pour chaque schéma de chaque base de données source en cours de réplication, le connecteur crée un schéma distinct dans la base de données Snowflake de destination. Le nom du schéma de destination est une combinaison du nom de la base de données source et du nom du schéma source, séparés par un caractère tiret bas (_), comme montré dans l’exemple suivant :

<source_database_name>_<source_schema_name>

Le connecteur crée des tables dans le schéma de destination avec le même nom que le nom de la table source, comme montré dans l’exemple suivant :

<destination_database>_<destination_schema_name>.<source_table_name>

Comment les tables sont-elles répliquées ?¶

The connector replicates tables in the following stages:

1. Schema introspection: The connector discovers the columns in the source table, including the column names and types, then validates them against Snowflake’s and the connector’s limitations. Validation failures cause this stage to fail, and the cycle completes. After successful completion of this stage, the connector creates an empty destination table.

2. Snapshot load: The connector copies all data available in the source table into the destination table. If this stage fails, the connector stops replicating data. After successful completion, the data from the source table is available in the destination table.

3. Chargement incrémentiel : le connecteur suit les modifications apportées à la table source et applique ces modifications à la table de destination. Ce processus se poursuit jusqu’à ce que la table soit retirée de la réplication. Un échec à ce stade arrête définitivement la réplication de la table source, jusqu’à ce que le problème soit résolu.

Pour plus d’informations sur le contournement du chargement des instantanés et l’utilisation du processus de chargement incrémentiel, consultez Réplication incrémentielle.

Vérifier le statut de réplication de la table¶

Les défaillances intermédiaires, telles que les erreurs de connexion, n’empêchent pas la réplication de la table. Toutefois, les défaillances permanentes, telles que les types de données non pris en charge, empêchent la réplication de la table.

Pour résoudre les problèmes de réplication ou vérifier qu’une table a été correctement supprimée du flux de réplication, consultez le magasin d’états des tables (Table State Store) :

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. Une table répertoriant les services du contrôleur s’affiche.

2. Localisez la ligne intitulée Table State Store, cliquez sur le bouton More sur le côté droit de la ligne, puis choisissez View State.

Une liste des tables et de leurs états actuels s’affiche. Renseignez le champ de recherche pour filtrer la liste par nom de table. Les états possibles sont :

• NEW : La table est planifiée pour la réplication, mais la réplication n’a pas commencé.

• SNAPSHOT_REPLICATION : Le connecteur copie des données existantes. Cet état s’affiche jusqu’à ce que tous les enregistrements soient stockés dans la table de destination.

• INCREMENTAL_REPLICATION : Le connecteur réplique activement les modifications. Cet état s’affiche après la fin de la réplication des instantanés et continue de s’afficher indéfiniment jusqu’à ce qu’une table soit supprimée de la réplication ou que la réplication échoue.

• FAILED : La réplication s’est définitivement arrêtée en raison d’une erreur.

Replication state for table <database_name>.<schema_name>.<table_name> changed from <old_state> to <new_state>

Si une défaillance permanente empêche la réplication d’une table, supprimez la table de la réplication. Après avoir résolu le problème à l’origine de l’échec, vous pouvez ajouter à nouveau la table à la réplication. Pour plus d’informations, voir Redémarrer la réplication des tables.

Versions du serveur SQL prises en charge¶

La table suivante annonce les versions testées et officiellement prises en charge du serveur SQL:

Exigences Openflow¶

• La taille de l’environnement d’exécution doit être au moins moyenne. Utilisez un environnement d’exécution plus grand lorsque vous répliquez de grands volumes de données, en particulier lorsque la taille des lignes est importante.

• Le connecteur ne prend pas en charge les environnements d’exécution Openflow à plusieurs nœuds. Configurez l’environnement d’exécution de ce connecteur avec Min nodes et Max nodes définis sur 1.

Limitations¶

• Vous ne pouvez pas exécuter plusieurs connecteurs du même type dans une seule instance d’exécution.

• Le connecteur ne prend en charge que l’authentification par nom d’utilisateur et mot de passe avec le serveur SQL.

• Le connecteur ne réplique que les tables dont les types de données sont supportés par Snowflake. Pour obtenir la liste de ces types de données, voir Résumé des types de données.

• The connector only replicates database tables that contain primary keys.

• The connector does not update existing records in the Snowflake database when a new NOT NULL column with a default value is added to one of the source databases.

• Le connecteur ne met pas à jour les enregistrements existants dans la base de données Snowflake lorsqu’une nouvelle colonne est ajoutée à la liste incluse dans le filtre de colonne JSON.

• After you delete a column in one of the source databases and add it back with the same name, additional deletes cause errors.

• After you include a column in Column Filter JSON and exclude it, additional include attempts cause errors.

• The connector supports source table schema changes, except for changing primary key definitions, changing the precision, or the scale of a numeric column.

• Le connecteur ne prend pas en charge l’opération de troncature de table.

• The connector does not support re-adding a column after it is dropped.

Prochaines étapes¶

Paramétrez Openflow Connector for SQL Server