Wide tables, unsigned integers, and multibyte strings replicate correctly on MySQL and MariaDB

A handful of MySQL and MariaDB edge cases could fail a backfill or land the wrong value. Backfilling a table with more than 65 columns into MySQL could hit the 65,535-placeholder limit on a prepared statement. An INT UNSIGNED value above the signed maximum streamed as a negative number (2451001005 arrived as -1843966291), which on a destination with a non-strict sql_mode could clamp several rows onto the same primary key. MariaDB stores JSON as LONGTEXT with a validity check, so after a restart Artie treated those columns as plain text. VARCHAR(n) limits were measured in bytes rather than characters, so a six-character Japanese string in a VARCHAR(10) was replaced with the exceeded-value marker. And on MariaDB, which opens a transaction with a GTID event instead of BEGIN, an offset could be committed mid-transaction and a restart would skip the rest of it.

All of these are fixed. MySQL destination batches are now sized by column count so rows times columns stays under the placeholder cap. Reader masks unsigned binlog integers back to their unsigned value (BIGINT UNSIGNED is carried as a string so nothing is lost). MariaDB JSON columns are recognised as JSON. String limits count characters the way the column does, including NVARCHAR(n) on SQL Server destinations. And MariaDB GTID events now mark a transaction start, so offsets are only committed at a real boundary.

Two more MySQL destination fixes landed in the same week. In hard-delete mode, an update from PostgreSQL that left a large TOASTed column untouched overwrote the real value in MySQL with Debezium's unavailable-value placeholder; the existing value is now kept, as it already was in soft-delete mode. And tinyint(1) columns were described as boolean, so a value like 2 failed a MySQL-to-MySQL backfill; they are now described as integers.

One thing to check if you have unsigned integer columns: rows that were already written with a negative or clamped key are not corrected retroactively, so an affected table needs a resync.

This is for MySQL and MariaDB pipelines with wide tables, unsigned keys, JSON columns, or non-ASCII data.

Why this matters

• Wide-table backfills into MySQL complete instead of failing on the placeholder limit
• Unsigned integers and multibyte strings arrive as the source holds them, with no silent collisions
• A MariaDB restart resumes at a transaction boundary, never inside one
• Unchanged large values stay intact on update instead of being replaced with a placeholder