Caractéristiques d’un Snowflake Connector for MySQL¶

Important

Merci de votre intérêt pour le Snowflake Connector pour MySQL. Nous nous concentrons maintenant sur une solution de nouvelle génération qui offrira une expérience considérablement améliorée. Par conséquent, le déplacement de ce connecteur vers l’état de disponibilité générale ne figure actuellement pas dans la feuille de route de notre produit. Vous pouvez continuer à utiliser ce connecteur en tant que fonction de prévisualisation, mais notez que la prise en charge des corrections de bogues et des améliorations futures n’est pas garantie. La nouvelle solution est disponible en tant que Connecteur Openflow pour MySQL et comprend de meilleures performances, une meilleure personnalisation et des options de déploiement améliorées.

Prise en charge des versions¶

Notre politique générale est que le Snowflake Connector for MySQL prend en charge toute version de Long-Term Support (LTS) MySQL officiellement prise en charge. Nous supprimerons progressivement la prise en charge des anciennes versions au fur et à mesure que nos utilisateurs passeront aux nouvelles versions, et nous annoncerons la prise en charge des nouvelles versions au fur et à mesure qu’elles seront publiées.

Bien que le connecteur prenne en charge plusieurs versions du cloudMySQL, certaines 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 PostgreSQL officiellement prises en charge¶
	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 du 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 sur au moins quelques heures ou plus pour garantir que l’agent de base de données puisse poursuivre la réplication incrémentielle après des pauses ou des temps d’arrêt étendus. 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’existe aucun moyen 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 configurez pour la réplication, mais ignorera les modifications apportées à toutes les autres tables.

Chaque modification doit d’abord être chargée par l’agent de base de données, et pour certaines modifications particulièrement importantes, comme les mises à jour des colonnes BLOB, même si elles sont créées sur des tables non configurées pour la réplication, celles-ci peuvent épuiser la mémoire de l’agent de base de données et provoquer son plantage. Si vous stockez des valeurs particulièrement volumineuses dans votre base de données, assurez-vous de configurer une mémoire suffisante pour l’agent de base de données et son conteneur.

La taille de la transaction est limitée par les limites de réplication de MySQL à moins de 4 GB. Les transactions dépassant la limite entraîneront l’échec définitif de la réplication de la table affecté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 dans la configuration de l’agent de base de données comprend son propre ensemble d’identifiants de connexion, et ceux-ci peuvent être différents pour chaque source de données.

Les utilisateurs de l’agent de base de données doivent disposer des droits suivants :

REPLICATION SLAVE sur l’ensemble des schémas et tables
REPLICATION CLIENT sur l’ensemble des schémas et tables
SELECT sur l’ensemble des schémas et 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.