Skip to main content

​
MySQL ClickPipe prend-il en charge MariaDB ?

Oui, MySQL ClickPipe prend en charge MariaDB 10.0 et les versions ultérieures. Sa configuration est très proche de celle de MySQL, avec la réplication GTID utilisée par défaut.

​
Pourquoi mon pipe a-t-il échoué en raison d’un événement de lignes partielles MariaDB non pris en charge ?

MariaDB 12.3 et les versions ultérieures peuvent émettre un événement de lignes partielles dans le binlog, que nous ne prenons pas encore en charge. Pour récupérer, resynchronisez le pipe. Pour réduire le risque que cela se reproduise, vous pouvez également augmenter le paramètre 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 ?

Si votre pipe échoue avec une erreur du type :
cela signifie que la table contient une ou plusieurs colonnes utilisant la compression de colonnes de MariaDB (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 ?

Non, ces solutions ne prennent pas en charge l’API de binlog de MySQL.

​
Comment la réplication est-elle gérée ?

Nous prenons en charge la réplication 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 ?

Si votre pipe échoue avec une erreur du type :
cela signifie qu’un seul événement binlog (correspondant à une modification de ligne) est plus volumineux que le paramètre 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_packet côté source. Définissez-le au-delà de la taille de votre plus grande modification de ligne — le régler au maximum, soit 1G, est généralement sans risque :
    Définissez-le également dans la configuration de votre serveur (par exemple my.cnf ou 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 ?

Si votre pipe échoue avec une erreur semblable à :
cela signifie que le serveur MySQL source a 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_JSON sur la source. Rétablissez une valeur vide :
    Supprimez également ce paramètre de la configuration de votre serveur (par exemple, my.cnf ou 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 ?

Si votre pipe échoue avec une erreur semblable à :
cela signifie que 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_transport sur 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.
La réplication reprend là où elle s’est arrêtée une fois la connexion établie. Si le pipe est resté en échec plus longtemps que votre période de rétention des binlogs (consultez Comment la réplication est-elle gérée ?), vous devrez le resynchroniser.

​
Pourquoi est-ce que j’obtiens une erreur de validation de certificat TLS lors de la connexion à MySQL ?

Lors de la connexion à MySQL, vous pouvez rencontrer des erreurs de certificat comme 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 :
  1. 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.
  2. 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.
  3. 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.
  4. 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.

​
Prenez-vous en charge les modifications de schéma ?

Veuillez consulter la page ClickPipes for MySQL: prise en charge de la propagation des modifications de schéma pour plus d’informations.

​
Prenez-vous en charge la réplication des suppressions en cascade de clés étrangères MySQL ON DELETE CASCADE ?

En raison de la manière dont MySQL gère les suppressions en cascade, celles-ci ne sont pas inscrites dans le binlog. Il n’est donc pas possible pour ClickPipes (ni pour aucun outil de CDC) de les répliquer. Cela peut entraîner des incohérences dans les données. Il est recommandé d’utiliser plutôt des triggers pour prendre en charge les suppressions en cascade.

​
Pourquoi ne puis-je pas répliquer ma table contenant un point ?

PeerDB présente actuellement une limitation : les points dans les identifiants de table source — c’est-à-dire dans le nom du schéma ou de la table — ne sont pas pris en charge pour la réplication, car PeerDB ne peut alors pas distinguer ce qui relève du schéma et ce qui relève de la table puisqu’il découpe sur le point. Des travaux sont en cours pour permettre la saisie séparée du schéma et de la table afin de contourner cette limitation.

​
Puis-je inclure des colonnes que j’ai initialement exclues de la réplication ?

Ce n’est pas encore pris en charge ; vous pouvez sinon resynchroniser la table dont vous souhaitez inclure les colonnes.
Dernière modification le 14 août 2026