À propos de Openflow Connector for SQL Server¶
Note
Ce connecteur est soumis aux conditions d’utilisation de Snowflake Connector.
Cette rubrique décrit les concepts de base, le workflow et les limites de Openflow Connector for SQL Server.
Utilisez Openflow Connector for SQL Server pour connecter plusieurs bases de données SQL Server dans une seule instance SQL Server à une base de données Snowflake et répliquer des données quasiment en temps réel ou selon un calendrier spécifié.
Le connecteur effectue une réplication CDC des données de Microsoft SQL Server avec Snowflake pour des rapports complets et centralisés.
Workflow¶
Le workflow suivant décrit les étapes pour configurer et exécuter Openflow Connector for SQL Server :
L’administrateur de la base de données du serveur SQL effectue les tâches suivantes :
Configure les paramètres de réplication de SQL Server et active le suivi des modifications sur les bases de données et les tables en cours de réplication.
Crée des identifiants de connexion pour le connecteur.
(Facultatif) Fournit le certificat SSL pour se connecter à l’instance SQL Server sur SSL.
Un administrateur de compte Snowflake effectue les tâches suivantes :
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.
Installe le connecteur.
Spécifie les paramètres requis pour la définition du flux du connecteur.
Gère le flux.
Le connecteur effectue les opérations suivantes lorsqu’il est exécuté dans Openflow :
Crée les schémas et les tables de destination correspondant aux tables sources configurées pour la réplication.
Commence la réplication conformément au cycle de vie de la réplication de la table.
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 ?¶
Le connecteur réplique les tables dans les zones de préparation suivantes :
Introspection du schéma : le connecteur découvre les colonnes de la table source, y compris les noms et les types de colonnes, puis les valide par rapport aux limites de Snowflake et du connecteur. Les échecs de validation entraînent l’échec de cette préparation et le cycle s’achève. À l’issue de cette préparation, le connecteur crée une table de destination vide.
Chargement d’un instantané : le connecteur copie toutes les données disponibles dans la table source dans la table de destination. Si cette zone de préparation échoue, plus aucune donnée n’est répliquée. Une fois l’opération réussie, les données de la table source sont disponibles dans la table de destination.
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.
Note
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. Si une défaillance permanente empêche la réplication d’une table, supprimez la table de la liste des tables à répliquer. Après avoir résolu le problème à l’origine de l’échec, vous pouvez ajouter à nouveau la table à la liste des tables à répliquer.
Versions du serveur SQL prises en charge¶
La table suivante annonce les versions testées et officiellement prises en charge du serveur SQL:
Plateforme |
Service/Version |
Édition/Niveau |
Pris en charge |
|---|---|---|---|
Sur site |
Développeur, Enterprise, Standard |
✔ pris en charge |
|
Microsoft SQL Server 2019 |
Développeur, Enterprise, Standard |
✔ pris en charge |
|
Microsoft SQL Server 2017 |
Développeur, Enterprise, Standard |
✔ pris en charge |
|
Microsoft SQL Server 2016 |
Développeur, Enterprise, Standard |
✔ pris en charge |
|
Microsoft SQL Server 2014 |
Tout |
Non testé |
|
Microsoft SQL Server 2012 |
Tout |
Non testé |
|
Azure |
Tous les types d’instances |
Pas encore pris en charge |
|
Tous les types d’instances |
✔ pris en charge |
||
Serveur SQL sur VM Azure |
Tout |
Non testé |
|
AWS |
Tous les types d’instances |
✔ pris en charge |
|
Serveur SQL pour EC2 Amazon |
Tout |
✔ pris en charge |
|
Google Cloud |
SQL Google Cloud pour le Serveur SQL |
Tout |
Non testé |
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.
Le connecteur ne réplique que les tables de la base de données qui contiennent des clés primaires.
Le connecteur ne met pas à jour les enregistrements existants dans la base de données Snowflake lorsqu’une nouvelle colonne NOT NULL avec une valeur par défaut est ajoutée à l’une des bases de données source.
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.
Après avoir supprimé une colonne dans l’une des bases de données sources et l’avoir rajoutée avec le même nom, les suppressions supplémentaires provoquent des erreurs.
Après avoir inclus une colonne dans le filtre de colonne JSON et l’avoir exclue, les tentatives d’inclusion supplémentaires provoquent des erreurs.
Le connecteur prend en charge les modifications du schéma de la table source, à l’exception des modifications des définitions des clés primaires, de la précision ou de l’échelle d’une colonne numérique.
Le connecteur ne prend pas en charge l’opération de troncature de table.
Le connecteur ne prend pas en charge le nouvel ajout d’une colonne après sa suppression.
Note
Vous pouvez contourner les limites affectant certaines colonnes de la table en excluant ces colonnes spécifiques de la réplication.