Caractéristiques de Snowflake Connector for MySQL¶

Note

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

Prise en charge des versions¶

Notre politique générale consiste à faire en sorte que Snowflake Connector for MySQL prenne en charge toute version LTS (Long-Term Support-Prise en charge à long terme) de MySQL officiellement prise en charge. Nous cesserons progressivement de prendre en charge les versions plus anciennes à mesure que nos utilisateurs passeront à des versions plus récentes, et nous annoncerons la prise en charge des nouvelles versions à mesure de leur publication.

Bien que le connecteur prenne en charge un certain nombre de versions Cloud MySQL, certaines d’entre elles nécessitent des paramètres supplémentaires. Voir Conditions préalables requises pour les sources de données Snowflake Connector for MySQL.

Le tableau suivant répertorie les versions testées et officiellement prises en charge.

Liste des versions officiellement prises en charge de PostgreSQL¶
	8,0	8,4
Standard	Oui	Oui
AWS RDS	Oui
Amazon Aurora	Oui, en tant que version 3
GCP Cloud SQL	Oui	Oui
Base de données Azure	Non

Paramètres de serveur¶

Pour que le connecteur fonctionne correctement, vérifiez et ajustez les paramètres suivants sur votre serveur MySQL.

`log_bin`	Définissez sur : `on`. Cela permet d’activer le journal binaire qui enregistre les modifications structurelles et les modifications apportées aux données.
`binlog_format`	Définissez sur : `row`. Le connecteur ne prend en charge que la réplication basée sur les lignes. Il se peut que les versions 8.x de MySQL soient les dernières à prendre en charge ce paramètre, et les versions futures ne prendront en charge que la réplication basée sur les lignes. Ne s’applique pas dans GCP Cloud SQL, où il est défini sur la bonne valeur.
`binlog_row_metadata`	Définissez sur : `full`. Le connecteur a besoin de toutes les métadonnées des lignes pour fonctionner, en particulier des noms des colonnes et des informations sur les clés primaires.
`binlog_row_image`	Définissez sur : `full`. Le connecteur nécessite que toutes les colonnes soient écrites dans le journal binaire. Ne s’applique pas dans Amazon Aurora, où cela est défini sur la bonne valeur.
`binlog_row_value_options`	Laissez vide. Cette option n’affecte que les colonnes JSON, où elle peut être définie de sorte à n’inclure que les parties modifiées des documents JSON pour les instructions `UPDATE`. Le connecteur nécessite que les documents complets soient écrits dans le journal binaire.
`binlog_expire_logs_seconds`	Définissez cette option au minimum sur quelques heures ou sur une durée supérieure pour garantir que l’agent de base de données puisse poursuivre la réplication incrémentielle après des pauses prolongées ou des temps d’arrêt. Si vous utilisez la réplication planifiée, la valeur doit être supérieure à la planification configurée.

Le journal binaire¶

Le journal binaire de MySQL, une fois activé, collecte les modifications de toutes les tables d’une instance donnée. Il n’est pas possible d’exclure des tables ou des colonnes. Le connecteur recevra donc les modifications de toutes les tables de la base de données, et l’agent de base de données traitera les modifications des tables que vous avez configurées pour la réplication, mais rejettera les modifications de toutes les autres tables.

Chaque modification doit commencer par être chargée par l’agent de base de données, et, pour certaines modifications particulièrement volumineuses, comme les mises à jour des colonnes BLOB, même si elles sont effectuées sur des tables qui ne sont pas configurées pour la réplication, elles peuvent épuiser la mémoire de l’agent de base de données et provoquer un plantage. Si vous stockez des valeurs particulièrement volumineuses où que ce soit dans votre base de données, veillez à configurer suffisamment de mémoire pour l’agent de base de données et son conteneur.

La taille de transaction est limitée par les limites de réplication de MySQL à moins de 4 GB. Les transactions qui dépassent la limite entraîneront l’échec définitif de la réplication de la table concernée.

Authentification de l’Agent¶

La seule méthode d’authentification actuellement prise en charge est le nom d’utilisateur et le mot de passe. Chaque entrée de source de données de la configuration de l’agent de base de données comprend son propre ensemble d’identifiants de connexion, qui peuvent être différents pour chaque source de données.

Les utilisateurs de l’agent de base de données doivent disposer des autorisations suivantes :

REPLICATION SLAVE sur tous les schémas et toutes les tables
REPLICATION CLIENT sur tous les schémas et toutes les tables
SELECT sur tous les schémas et toutes les tables

Pour obtenir des instructions sur la création d’un utilisateur pour l’agent de base de données, voir Créer l’utilisateur requis.