Skip to main content
Skip to main content
Edit this page

ClickPipes for MySQL FAQ

Does the MySQL ClickPipe support MariaDB?​

Yes, the MySQL ClickPipe supports MariaDB 10.0 and above. The configuration for it is very similar to MySQL, using GTID replication by default.

Does the MySQL ClickPipe support PlanetScale, Vitess, or TiDB?​

No, these don't support MySQL's binlog API.

How is replication managed?​

We support both GTID & FilePos replication. Unlike Postgres there is no slot to manage offset. Instead, you must configure your MySQL server to have a sufficient binlog retention period. If our offset into the binlog becomes invalidated (eg, mirror paused too long, or database failover occurs while using FilePos replication) then you will need to resync the pipe. Make sure to optimize materialized views depending on destination tables, as inefficient queries can slow down ingestion to fall behind the retention period.

It's also possible for an inactive database to rotate the log file without allowing ClickPipes to progress to a more recent offset. You may need to setup a heartbeat table with regularly scheduled updates.

At the start of an initial load we record the binlog offset to start at. This offset must still be valid when the initial load finishes in order for CDC to progress. If you're ingesting a large amount of data be sure to configure an appropriate binlog retention period. While setting up tables you can speed up initial load by configuring Use a custom partitioning key for initial load for large tables under advanced settings so that we can load a single table in parallel.

Why is my pipe failing with a max_allowed_packet binlog error?​

If your pipe fails with an error similar to:

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

it means a single binlog event (corresponding to one row change) is larger than your MySQL server's max_allowed_packet setting. Because the server can't send an event that exceeds this limit, the binlog stream read aborts and CDC can't progress.

This is most often caused by rows containing large BLOB, TEXT, or JSON values. To resolve it:

  • Increase max_allowed_packet on the source. Raise it above the size of your largest row change — setting it to the maximum of 1G is usually safe: 
    SET GLOBAL max_allowed_packet = 1073741824; -- 1 GiB
    Set it in your server configuration (e.g. my.cnf) as well so it persists across restarts. Existing connections must be re-established for the new value to take effect.
  • If a single large row is the cause, resync the affected table once max_allowed_packet has been increased so the pipe can move past it.
  • If you expect values larger than 1G, exclude the large columns from replication, as max_allowed_packet can't be raised beyond 1G. See Can I include columns I initially excluded from replication?.

Why am I getting a TLS certificate validation error when connecting to MySQL?​

When connecting to MySQL, you may encounter certificate errors like x509: certificate is not valid for any names or x509: certificate signed by unknown authority. These occur because ClickPipes enables TLS encryption by default.

You have several options to resolve these issues:

  1. Set the TLS Host field - When the hostname in your connection differs from the certificate (common with AWS PrivateLink via Endpoint Service). Set "TLS Host (optional)" to match the certificate's Common Name (CN) or Subject Alternative Name (SAN).

  2. Upload your Root CA - For MySQL servers using internal Certificate Authorities or Google Cloud SQL in the default per-instance CA configuration. For more information on how to access Google Cloud SQL certificates, see this section.

  3. Configure server certificate - Update your server's SSL certificate to include all connection hostnames and use a trusted Certificate Authority.

  4. Skip certificate verification - For self-hosted MySQL or MariaDB, whose default configurations provision a self-signed certificate we can't validate (MySQL, MariaDB). Relying on this certificate encrypts the data in transit but runs the risk of server impersonation. We recommend properly signed certificates for production environments, but this option is useful for testing on a one-off instance or connecting to legacy infrastructure.

Do you support schema changes?​

Please refer to the ClickPipes for MySQL: Schema Changes Propagation Support page for more information.

Do you support replicating MySQL foreign key cascading deletes ON DELETE CASCADE?​

Due to how MySQL handles cascading deletes, they're not written to the binlog. Therefore it's not possible for ClickPipes (or any CDC tool) to replicate them. This can lead to inconsistent data. It's advised to use triggers instead for supporting cascading deletes.

Why can I not replicate my table which has a dot in it?​

PeerDB has a limitation currently where dots in source table identifiers - aka either schema name or table name - isn't supported for replication as PeerDB can't discern, in that case, what is the schema and what is the table as it splits on dot. Effort is being made to support input of schema and table separately to get around this limitation.

Can I include columns I initially excluded from replication?​

This isn't yet supported, an alternative would be to resync the table whose columns you want to include.