À propos de Snowflake Connector for MySQL¶

Note

Le Snowflake Connector for MySQL est soumis aux Conditions du connecteur.

Le Snowflake Connector for MySQL vous permet :

Chargez des données dans Snowflake à partir d’une base de données MySQL.
Configurez la réplication afin que les modifications dans votre base de données MySQL soient répliquées sur Snowflake.

Pour gérer les connexions entre Snowflake et MySQL, le connecteur utilise un agent. L’agent est distribué sous forme d’image Docker. L’agent est exécuté au sein de votre réseau et utilisé pour pousser des données dans votre compte Snowflake.

Note

Snowflake Connector for MySQL nécessite une seule instance de l’application d’agent exécutée à tout moment.

Les mises à jour incrémentielles en cours utilisent la technique de capture des données modifiées (Change Data Capture ou CDC), qui capture les modifications effectuées sur la base de données source. Les modifications incluent les opérations INSERT, UPDATE et DELETE, qui sont automatiquement répliquées sur la base de données de destination dans Snowflake.

Plusieurs instances d’application¶

Vous pouvez installer plusieurs instances de Snowflake Connector for MySQL sur votre compte Snowflake. Pour plus d’informations, voir Facultatif : Installation de plusieurs instances de Snowflake Connector for MySQL.

Liens privés¶

Snowflake Connector pour MySQL prend en charge les liens privés. Pour plus d’informations, voir :

Compatibilités des applications Agent et Connecteur¶

Snowflake Connector for MySQL est publié en fonction d’une version spécifique, décrite comme version x.y.z, où x est la version majeure, y la version mineure et z le correctif. Les Agents sur dockerhub sont également publiés avec la version X.Y.Z. Chaque version x.y.z de Snowflake Connector for MySQL prend en charge tous les agents présentant la même version majeure X=x et non une version mineure supérieure de l’agent. De plus, chaque version x.0.0 de Snowflake Connector for MySQL prend en charge toutes les versions (x-1).Y.Z de l’agent pour toutes les versions Y et Z.

Limitations connues¶

Les sections suivantes décrivent les limitations connues du connecteur.

Nombre maximal de tables¶

Le connecteur fonctionne bien avec un maximum de 200 tables sources ajoutées à la réplication. L’ajout de tables supplémentaires peut rendre le connecteur instable.

Taille de transaction¶

Le connecteur est soumis aux mêmes limitations que celles de la réplication de groupe de MySQL. Cela signifie qu’une seule transaction doit tenir dans un message de journal binaire ne dépassant pas 4GB. Les transactions dépassant cette taille entraîneront le marquage de la table source comme en échec définitif et nécessiteront un rechargement instantané complet de la table associée.

Disponibilité du connecteur¶

Lors de l’installation du connecteur, notez les limitations suivantes :

Les comptes dans les régions gouvernementales ne sont pas pris en charge.
Pour installer et configurer le connecteur, vous devez être connecté en tant qu’utilisateur ayant le rôle ACCOUNTADMIN. Les autres rôles ne sont pas pris en charge pour le moment.

Compatibilité des types¶

En raison des différences entre la base de données source et les types de colonne Snowflake, certaines valeurs ne peuvent pas être converties ni écrites dans Snowflake à cause de la capacité de colonne ou des plages autorisées maximales. Par exemple :

La longueur maximale du type BINARY Snowflake est de 8 MB (8 388 608 octets)
L’année maximale des types date Snowflake tels que DATE, DATETIME et TIMESTAMP est 9999
La longueur maximale du type VARCHAR Snowflake est de 16 MB (16 777 216 octets)

S’il se produit une telle incompatibilité, la réplication d’une table est arrêtée avec un échec.

Modifications du schéma de la table source¶

Le tableau suivant présente les différents types de modifications apportées au schéma de la table source et indique s’ils sont pris en charge et si oui, de quelle manière.

Les nouveaux noms de colonne sont soumis aux mêmes limitations que celles décrites à la section Limitations des identificateurs.

Type de modification de schéma	Pris en charge ?	Remarques
Ajout d’une nouvelle colonne	Oui	La nouvelle colonne sera visible dans la table de destination comme n’importe quelle autre colonne qui existait au début de la réplication. Il n’est pas possible d’ajouter une nouvelle colonne portant le même nom qu’une colonne précédemment supprimée ou renommée. Par exemple, si les colonnes `A` et `B` existaient à l’origine, mais que la colonne `A` a été supprimée et que la colonne `B` a été renommée `B2`, il n’est pas possible d’ajouter une colonne nommée `A` ou `B`.
Suppression d’une colonne existante	Oui	Si une colonne est supprimée dans la table source, elle ne sera pas supprimée dans la table de destination. Au lieu de cela, on adopte une approche de type suppression logicielle et le nom de la colonne sera remplacé par le `<nom précédent>__SNOWFLAKE_DELETED` afin que les valeurs historiques puissent encore être interrogées. Toutes les lignes répliquées après la suppression de la colonne auront une valeur NULL dans cette colonne. Par exemple, si une colonne `A` est supprimée, son nom sera remplacé par `A__SNOWFLAKE_DELETED` dans la table de destination et le contenu de la colonne restera inchangé.
Renommage d’une colonne	Oui	Le renommage d’une colonne équivaut à supprimer la colonne et à en créer une nouvelle portant le nouveau nom. La suppression suit l’approche de type suppression logicielle expliquée dans la ligne précédente. Par exemple, si la colonne `A` a été renommée `B`, dans la table de destination, la colonne `A` est renommée `A__SNOWFLAKE_DELETED` et une nouvelle colonne `B` est ajoutée. Toutes les lignes existantes avant la modification conservent les valeurs de la colonne dans la colonne `A__SNOWFLAKE_DELETED`, tandis que les valeurs des nouvelles lignes ajoutées après la modification sont placées dans la colonne `B`. Il n’est pas possible de renommer une colonne en lui donnant le même nom que celui d’une colonne précédemment supprimée ou renommée. Par exemple, si les colonnes `A`, `B` et `C` existaient à l’origine, mais que la colonne `A` a été supprimée et que la colonne `B` a été renommée `B2`, il n’est pas possible de remplacer le nom de la colonne `C` par `A` ou `B`.
Modification du type de colonne	Partiellement	La modification du type de colonne de la table source n’est possible que si le type précédent et le nouveau type sont mappés vers le même type dans Snowflake. Dans tous les autres cas, la réplication échouera définitivement.
Modification de la précision d’une colonne numérique	Non	La modification de la précision d’une colonne de la table source entraînera l’échec définitif de la réplication.
Modification de l’échelle d’une colonne numérique	Non	La modification de l’échelle d’une colonne de la table source entraînera l’échec définitif de la réplication.
Modification de la définition de la clé primaire	Non	La modification de la définition de la clé primaire d’une colonne de la table source entraînera l’échec définitif de la réplication.

Colonnes haute capacité¶

Un agent actif lit en permanence tous les événements du journal binaire, même si certains événements font référence à des tables sources qui n’ont pas été ajoutées pour la réplication. Si le journal binaire contient des événements très volumineux comme des mises à jour de colonnes de type BLOB, l’agent risque de planter en raison du manque de mémoire disponible.

Clés primaires¶

Les tables sans clés primaires ne sont pas prises en charge.

Limitations des identificateurs¶

Actuellement, le connecteur ne prend pas en charge le caractère " dans les noms de schéma, de table ou de colonne répliqués. De plus, les mots clés suivants ne sont pas pris en charge :

Pour les noms de schéma :

INFORMATION_SCHEMA

Pour les noms de colonne :

_SNOWFLAKE_INSERTED_AT
_SNOWFLAKE_UPDATED_AT
_SNOWFLAKE_DELETED
Noms avec le suffixe __SNOWFLAKE_DELETED
Noms de colonne marqués comme Cannot be used as column name dans Mots clés réservés et limités Snowflake

MySQL version >= 8.0.0¶

Actuellement, le connecteur dépend de la propriété de configuration binlog_row_metadata = full qui a été lancée dans MySQL, version 8.

Autorisation de la base de données source¶

L’autorisation de clé privée sur la base de données source n’est pas prise en charge. Seule l’autorisation via l’utilisateur et le mot de passe est prise en charge.