From 24515cbd6160dddb015b1381fc435c46eb84188d Mon Sep 17 00:00:00 2001 From: Dmitrii Tunikov Date: Fri, 3 Jul 2026 14:32:18 +0200 Subject: [PATCH 1/3] Add MySQL FAQ entry for unsupported MariaDB partial row events Documents why a pipe fails on a MariaDB 12.3+ PARTIAL_ROW_DATA_EVENT and how to recover (resync, optionally raise binlog_row_event_fragment_threshold below max_allowed_packet). This anchor is referenced by the NOTIFY_BINLOG_PARTIAL_ROW_EVENT_UNSUPPORTED alert in clickpipes-platform. Co-Authored-By: Claude Opus 4.8 (1M context) --- docs/integrations/data-ingestion/clickpipes/mysql/faq.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/integrations/data-ingestion/clickpipes/mysql/faq.md b/docs/integrations/data-ingestion/clickpipes/mysql/faq.md index eee0f05b9b3..dfe49537529 100644 --- a/docs/integrations/data-ingestion/clickpipes/mysql/faq.md +++ b/docs/integrations/data-ingestion/clickpipes/mysql/faq.md @@ -15,6 +15,11 @@ integration: ### Does the MySQL ClickPipe support MariaDB? {#does-the-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. +### Why did my pipe fail with an unsupported MariaDB partial row event? {#mariadb-partial-row-event-unsupported} +MariaDB 12.3 and above can emit a `PARTIAL_ROW_DATA_EVENT` in the binlog. When a row change exceeds the fragment threshold, MariaDB splits it across several binlog events that a consumer must buffer and reassemble before decoding. ClickPipes does not yet support reassembling these fragments, so rather than silently dropping the row change the pipe fails loudly and requires a resync. + +To recover, [resync the pipe](./table_resync.md). To reduce the chance of hitting this again, you can also raise `binlog_row_event_fragment_threshold` on the source so fewer row changes get fragmented — keep it below your `max_allowed_packet`, since a single unfragmented binlog event larger than `max_allowed_packet` will fail the replication stream instead. + ### Does the MySQL ClickPipe support PlanetScale, Vitess, or TiDB? {#does-the-clickpipe-support-planetscale-vitess} No, these don't support MySQL's binlog API. From 42385b1c55f0a06459ef22f4a522547414734e1d Mon Sep 17 00:00:00 2001 From: Dmitrii Tunikov Date: Fri, 3 Jul 2026 14:38:25 +0200 Subject: [PATCH 2/3] Link MariaDB partial rows event docs instead of quoting event name Co-Authored-By: Claude Opus 4.8 (1M context) --- docs/integrations/data-ingestion/clickpipes/mysql/faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/integrations/data-ingestion/clickpipes/mysql/faq.md b/docs/integrations/data-ingestion/clickpipes/mysql/faq.md index dfe49537529..7650f10247c 100644 --- a/docs/integrations/data-ingestion/clickpipes/mysql/faq.md +++ b/docs/integrations/data-ingestion/clickpipes/mysql/faq.md @@ -16,7 +16,7 @@ integration: Yes, the MySQL ClickPipe supports MariaDB 10.0 and above. The configuration for it is very similar to MySQL, using GTID replication by default. ### Why did my pipe fail with an unsupported MariaDB partial row event? {#mariadb-partial-row-event-unsupported} -MariaDB 12.3 and above can emit a `PARTIAL_ROW_DATA_EVENT` in the binlog. When a row change exceeds the fragment threshold, MariaDB splits it across several binlog events that a consumer must buffer and reassemble before decoding. ClickPipes does not yet support reassembling these fragments, so rather than silently dropping the row change the pipe fails loudly and requires a resync. +MariaDB 12.3 and above can emit a [partial rows event](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log/row-binlog-events#partial_rows_log_event) in the binlog. When a row change exceeds the fragment threshold, MariaDB splits it across several binlog events that a consumer must buffer and reassemble before decoding. ClickPipes does not yet support reassembling these fragments, so rather than silently dropping the row change the pipe fails loudly and requires a resync. To recover, [resync the pipe](./table_resync.md). To reduce the chance of hitting this again, you can also raise `binlog_row_event_fragment_threshold` on the source so fewer row changes get fragmented — keep it below your `max_allowed_packet`, since a single unfragmented binlog event larger than `max_allowed_packet` will fail the replication stream instead. From c121b33d04a5ce2fe565b31dbfbc897363fae232 Mon Sep 17 00:00:00 2001 From: Dmitrii Tunikov Date: Fri, 3 Jul 2026 14:46:08 +0200 Subject: [PATCH 3/3] cleanup --- docs/integrations/data-ingestion/clickpipes/mysql/faq.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/integrations/data-ingestion/clickpipes/mysql/faq.md b/docs/integrations/data-ingestion/clickpipes/mysql/faq.md index 7650f10247c..1bd2b41a25d 100644 --- a/docs/integrations/data-ingestion/clickpipes/mysql/faq.md +++ b/docs/integrations/data-ingestion/clickpipes/mysql/faq.md @@ -16,9 +16,9 @@ integration: Yes, the MySQL ClickPipe supports MariaDB 10.0 and above. The configuration for it is very similar to MySQL, using GTID replication by default. ### Why did my pipe fail with an unsupported MariaDB partial row event? {#mariadb-partial-row-event-unsupported} -MariaDB 12.3 and above can emit a [partial rows event](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log/row-binlog-events#partial_rows_log_event) in the binlog. When a row change exceeds the fragment threshold, MariaDB splits it across several binlog events that a consumer must buffer and reassemble before decoding. ClickPipes does not yet support reassembling these fragments, so rather than silently dropping the row change the pipe fails loudly and requires a resync. +MariaDB 12.3 and above can emit a [partial rows event](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log/row-binlog-events#partial_rows_log_event) in the binlog, which we don't support yet. -To recover, [resync the pipe](./table_resync.md). To reduce the chance of hitting this again, you can also raise `binlog_row_event_fragment_threshold` on the source so fewer row changes get fragmented — keep it below your `max_allowed_packet`, since a single unfragmented binlog event larger than `max_allowed_packet` will fail the replication stream instead. +To recover, resync the pipe. To reduce the chance of hitting this again, you can also raise `binlog_row_event_fragment_threshold` setting on the source so fewer row changes get fragmented — keep it below your `max_allowed_packet`, since a single unfragmented binlog event larger than `max_allowed_packet` will fail the replication stream instead (see [Why is my pipe failing with a max_allowed_packet binlog error?](#binlog-event-exceeded-max-allowed-packet)). ### Does the MySQL ClickPipe support PlanetScale, Vitess, or TiDB? {#does-the-clickpipe-support-planetscale-vitess} No, these don't support MySQL's binlog API.