MySQL ClickPipe prend-il en charge MariaDB ?
Pourquoi mon pipe a-t-il échoué en raison d’un événement de lignes partielles MariaDB non pris en charge ?
binlog_row_event_fragment_threshold sur la source afin que moins de modifications de lignes soient fragmentées ; maintenez-le inférieur à max_allowed_packet, car un seul événement binlog non fragmenté dépassant max_allowed_packet ferait échouer le flux de réplication (voir Pourquoi mon pipe échoue-t-il avec une erreur binlog liée à max_allowed_packet ?).
Pourquoi mon pipe a-t-il échoué en raison d’une colonne MariaDB COMPRESSED non prise en charge ?
COLUMN_FORMAT COMPRESSED). Nous ne pouvons pas décompresser ces valeurs à partir du binlog, donc la table concernée ne peut pas être répliquée via CDC.
Pour corriger le problème :
- Convertissez les colonnes compressées en un type non compressé sur la source (ou retirez une table du pipe) :
- resynchronisez la table ou le pipe
MySQL ClickPipe prend-il en charge PlanetScale, Vitess ou TiDB ?
Comment la réplication est-elle gérée ?
GTID et FilePos. Contrairement à Postgres, il n’y a pas de slot pour gérer l’offset. Vous devez donc configurer votre serveur MySQL avec une période de rétention du binlog suffisante. Si notre offset dans le binlog devient invalide (par exemple, si le mirror reste en pause trop longtemps ou si un basculement de la base de données se produit lors de l’utilisation de la réplication FilePos), vous devrez resynchroniser le pipe. Veillez à optimiser les vues matérialisées qui dépendent des tables de destination, car des requêtes inefficaces peuvent ralentir l’ingestion jusqu’à dépasser la période de rétention.
Il est également possible qu’une base de données inactive effectue une rotation du fichier journal sans permettre à ClickPipes d’avancer vers un offset plus récent. Vous devrez peut-être mettre en place une table heartbeat avec des mises à jour planifiées à intervalles réguliers.
Au début d’un chargement initial, nous enregistrons l’offset du binlog à partir duquel démarrer. Cet offset doit toujours être valide lorsque le chargement initial se termine pour que le CDC puisse progresser. Si vous ingérez un grand volume de données, veillez à configurer une période de rétention du binlog adaptée. Pendant la configuration des tables, vous pouvez accélérer le chargement initial en configurant Use a custom partitioning key for initial load pour les grandes tables dans les paramètres avancés afin que nous puissions charger une seule table en parallèle.
Pourquoi mon pipe échoue-t-il en raison d’une erreur max_allowed_packet du binlog ?
max_allowed_packet de votre serveur MySQL. Comme le serveur ne peut pas envoyer d’événement qui dépasse cette limite, la lecture du flux binlog s’interrompt et CDC ne peut pas continuer.
Cela est le plus souvent dû à des lignes contenant de grandes valeurs BLOB, TEXT ou JSON. Pour résoudre ce problème :
- Augmentez
max_allowed_packetcôté source. Définissez-le au-delà de la taille de votre plus grande modification de ligne — le régler au maximum, soit1G, est généralement sans risque :Définissez-le également dans la configuration de votre serveur (par exemplemy.cnfou le DB Parameter Group) afin qu’il soit conservé après les redémarrages. - Si une seule ligne dépasse 1G : resynchronisez le pipe.
Pourquoi mon pipe échoue-t-il avec une erreur de binlog JSON incomplet ?
binlog_row_value_options défini sur PARTIAL_JSON. Lorsque cette option est activée, MySQL enregistre les mises à jour des colonnes JSON sous forme de différences partielles (uniquement les chemins modifiés), plutôt que sous la forme du document complet. ClickPipes ne peut pas appliquer ces différences partielles, donc le CDC ne peut pas progresser.
Pour résoudre ce problème :
- Désactivez
PARTIAL_JSONsur la source. Rétablissez une valeur vide :Supprimez également ce paramètre de la configuration de votre serveur (par exemple,my.cnfou le DB Parameter Group) afin que ce réglage soit conservé après les redémarrages. - Resynchronisez le pipe afin que la réplication reprenne à partir d’un offset propre.
Pourquoi mon pipe échoue-t-il avec une erreur require_secure_transport ?
require_secure_transport est activé sur le serveur source — il rejette toute connexion non chiffrée — alors que TLS est désactivé sur le ClickPipe. Dans RDS pour MySQL, ce paramètre provient du groupe de paramètres DB de l’instance. Dans Aurora MySQL, il s’agit d’un paramètre du groupe de paramètres de cluster DB, qui n’est pas disponible dans les groupes de paramètres d’instance. Aucun des deux ne nécessite de redémarrage pour prendre effet. Dans Aurora MySQL 8.4, ce paramètre est défini par défaut sur ON, tandis que les versions 2 et 3 utilisent OFF. Un pipe dont la réplication fonctionnait correctement peut donc commencer à échouer après une modification de paramètre ou une mise à niveau de version, sans aucune modification de sa configuration.
Pour résoudre ce problème :
- Réactivez TLS sur le pipe. Dans les Settings du pipe, ouvrez les paramètres de connexion et désactivez le toggle Disable TLS. Si l’enregistrement affiche ensuite une erreur de certificat, consultez Pourquoi est-ce que j’obtiens une erreur de validation de certificat TLS lors de la connexion à MySQL ? pour savoir comment définir un hôte TLS, téléverser un certificat d’autorité de certification (CA) racine ou ignorer la vérification du certificat.
- Ou désactivez
require_secure_transportsur la source — dans le groupe de paramètres DB sur RDS ou dans le groupe de paramètres de cluster DB sur Aurora — si les connexions non chiffrées sont acceptables dans votre environnement.
Pourquoi est-ce que j’obtiens une erreur de validation de certificat TLS lors de la connexion à MySQL ?
x509: certificate is not valid for any names ou x509: certificate signed by unknown authority. Cela se produit parce que ClickPipes active le chiffrement TLS par défaut.
Vous disposez de plusieurs options pour résoudre ces problèmes :
- Définir le champ TLS Host - Lorsque le nom d’hôte de votre connexion diffère de celui du certificat (cas courant avec AWS PrivateLink via Endpoint Service). Définissez “TLS Host (optional)” pour qu’il corresponde au Common Name (CN) ou au Subject Alternative Name (SAN) du certificat.
- Téléverser votre CA racine - Pour les serveurs MySQL utilisant des autorités de certification internes ou Google Cloud SQL avec la configuration de CA par défaut par instance. Pour plus d’informations sur la manière d’accéder aux certificats Google Cloud SQL, consultez cette section.
- Configurer le certificat du serveur - Mettez à jour le certificat SSL de votre serveur afin d’inclure tous les noms d’hôte de connexion et d’utiliser une autorité de certification de confiance.
- Ignorer la vérification du certificat - Pour les déploiements MySQL ou MariaDB auto-hébergés, dont les configurations par défaut génèrent un certificat auto-signé que nous ne pouvons pas valider (MySQL, MariaDB). S’appuyer sur ce certificat chiffre les données en transit, mais présente un risque d’usurpation d’identité du serveur. Nous recommandons des certificats correctement signés pour les environnements de production, mais cette option est utile pour des tests sur une instance ponctuelle ou pour se connecter à une infrastructure legacy.