FAQ ClickPipes for MySQL - ClickHouse Documentation

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.

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 :

MySQL execute error: ERROR 1236 (HY000): log event entry exceeded max_allowed_packet;
Increase max_allowed_packet on source

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 :
```
SET GLOBAL max_allowed_packet = 1073741824; -- 1 GiB
```
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 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 :

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.

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.

​MySQL ClickPipe prend-il en charge MariaDB ?

​MySQL ClickPipe prend-il en charge PlanetScale, Vitess ou TiDB ?

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

​Pourquoi mon pipe échoue-t-il en raison d’une erreur max_allowed_packet du binlog ?

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

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

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

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

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