> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Questions fréquemment posées sur ClickPipes for MySQL. # FAQ ClickPipes for MySQL
### 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](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log/row-binlog-events#partial_rows_log_event) 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 ?](#binlog-event-exceeded-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 : ```text theme={null} table . has MariaDB COMPRESSED column(s) [], which cannot be replicated via CDC; convert them to a non-compressed type or remove the table from the mirror ``` cela signifie que la table contient une ou plusieurs colonnes utilisant la [compression de colonnes](https://mariadb.com/kb/en/storage-engine-independent-column-compression/) 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) : ```sql theme={null} ALTER TABLE
MODIFY ; -- sans COLUMN_FORMAT COMPRESSED ``` * 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 : ```text theme={null} 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`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_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 : ```sql theme={null} 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 mon pipe échoue-t-il avec une erreur de binlog JSON incomplet ?
Si votre pipe échoue avec une erreur semblable à : ```text theme={null} Received a partial JSON update event while processing .
; binlog_row_value_options must be disabled (set to '') ``` cela signifie que le serveur MySQL source a [`binlog_row_value_options`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_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 : ```sql theme={null} SET GLOBAL binlog_row_value_options = ''; ``` 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 à : ```text theme={null} MySQL execute error: handleAuthResult: ERROR 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON. ``` cela signifie que [`require_secure_transport`](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-ssl-connections.require-ssl.html) de l’instance. Dans Aurora MySQL, il s’agit d’un paramètre du [groupe de paramètres de cluster DB](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Security.html#AuroraMySQL.Security.SSL.RequireSSL), 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 ?](#tls-certificate-validation-error) 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 ?](#how-is-replication-managed)), 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](/fr/integrations/clickpipes/mysql/source/gcp#download-root-ca-certificate-gcp-mysql). 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](https://dev.mysql.com/doc/refman/8.4/en/creating-ssl-rsa-files-using-mysql.html#creating-ssl-rsa-files-using-mysql-automatic), [MariaDB](https://mariadb.com/kb/en/securing-connections-for-client-and-server/#enabling-tls-for-mariadb-server)). 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](/fr/integrations/clickpipes/mysql/schema-changes) 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](https://dev.mysql.com/doc/refman/8.0/en/innodb-and-mysql-replication.html), 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](/fr/integrations/clickpipes/mysql/table-resync) dont vous souhaitez inclure les colonnes.