Replication and Binary Log Compatibility Boundaries Across MariaDB and MySQL

Learning outcomes

ServiceHub wants near-zero-downtime migration from MySQL to MariaDB. The proposal is to “turn on GTID replication, wait for zero lag, and promote MariaDB.” That sentence hides several incompatible models. MariaDB and MySQL define GTIDs differently, binary-log event compatibility depends on exact versions and direction, DDL and JSON can still fail even when row events flow, and replication lag does not prove that every business row or schema object is correct.

This lesson treats mixed MariaDB/MySQL replication as a migration mechanism that must be qualified by source version, target version, direction, binlog format, authentication, collation, DDL and feature usage. It is not presented as a universal high-availability topology.

1. Binary log and relay log are event streams—not copies of tables

A source server records changes in its binary log. A replica connects, receives events, stores relay-log state, and applies the changes. Depending on binlog_format, events can represent SQL statements, row images, or a mixed strategy. Replication correctness therefore depends not only on table data but on whether the replica can decode the event format and reproduce the semantics of DDL, DML, data types, functions, character sets, and server-specific features.

SELECT @@log_bin AS binary_log_enabled,       @@binlog_format AS binlog_format,       @@server_id AS server_id;SHOW MASTER STATUS;SHOW VARIABLES LIKE 'gtid%';

If binary logging is off, the server cannot act as a conventional asynchronous replication source. SHOW MASTER STATUS and terminology can evolve toward primary/replica synonyms, so use current target-version documentation when automating. This chapter records the concept and evidence, not a frozen vocabulary parser.

2. MariaDB GTID and MySQL GTID are different coordinate systems

MariaDB GTIDs consist of a domain ID, server ID, and sequence number, conventionally shown as domain-server-sequence, for example 0-1-10. MySQL GTIDs are based on a source/server UUID and transaction sequence, traditionally UUID:NUMBER and in current MySQL versions can also include tagged forms. The formats are not cosmetic differences: the servers maintain different GTID state variables, event semantics, and auto-positioning workflows.

MariaDB documentation explicitly states that MariaDB and MySQL GTID implementations are not compatible. This is why “enable GTID on both” is not a migration plan. When a cross-vendor topology is supported, the bridge may need binary-log file and position while each side maintains its own native GTID semantics.

3. Direction matters: MySQL to MariaDB is not the inverse of MariaDB to MySQL

Current MariaDB replication-compatibility documentation is deliberately directional. It states that sufficiently recent MariaDB maintenance releases gained support for consuming MySQL 8.0 binary logs under documented conditions. Earlier maintenance levels could not consume newer MySQL 8.0 events. That means even “MariaDB 11.4” is too vague; the patch level can be the compatibility boundary.

For MariaDB→MySQL, MariaDB documentation lists additional constraints: do not rely on MySQL GTID auto-positioning for MariaDB GTIDs, avoid MariaDB binary-log encryption/compression features that the MySQL side cannot decode, and ensure character sets/collations used by new MariaDB objects are supported by MySQL. The target SQL surface still matters, especially DDL and MariaDB-only features.

4. Row-based replication reduces some SQL differences, not all of them

MariaDB recommends row-based binary logging for several cross-vendor scenarios because row events reduce dependence on re-executing source SQL functions on the replica. But row-based replication does not erase schema or event-format differences. The replica still needs compatible table metadata and must understand the event types emitted by the source. DDL is still replicated as SQL, and special data types such as JSON can introduce representation boundaries.

-- Run only on a disposable source and restore the original observed value afterward.SELECT @@global.binlog_format AS before_format;SET GLOBAL binlog_format='ROW';SELECT @@global.binlog_format AS test_format;-- Existing sessions may retain session-level settings; reconnect before the test.

Do not blindly change binlog format on production. It affects binary-log volume, downstream consumers, point-in-time recovery workflows, and replication behavior. The correct production decision is based on the migration design and validated in staging.

5. DDL, collations, authentication, and feature events are replication dependencies

A data-only comparison misses the operations around the data. Cross-vendor replication can fail when the source creates a collation the target does not support, executes MariaDB-only sequence or system-versioning DDL, uses an authentication path unavailable to the replica connection, or emits a binary-log event introduced by a newer source. This is why the compatibility matrix in Lesson 1 included DDL and operational features.

SELECT TABLE_NAME, ENGINE, TABLE_COLLATIONFROM information_schema.TABLESWHERE TABLE_SCHEMA='servicehub'ORDER BY TABLE_NAME;SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE, COLUMN_TYPE, COLLATION_NAME, EXTRAFROM information_schema.COLUMNSWHERE TABLE_SCHEMA='servicehub'ORDER BY TABLE_NAME, ORDINAL_POSITION;SELECT ROUTINE_TYPE, ROUTINE_NAME, SQL_MODE, DEFINERFROM information_schema.ROUTINESWHERE ROUTINE_SCHEMA='servicehub'ORDER BY ROUTINE_TYPE, ROUTINE_NAME;SHOW TRIGGERS FROM servicehub;

Add events, views, users/authentication plugins, generated columns, partitions, and MariaDB/MySQL-specific objects to the inventory as the real workload requires. Replication is not a substitute for compatibility assessment; it is one test harness inside it.

6. Deliberately wrong: use mixed-vendor replication as permanent HA because it “caught up”

Suppose a MariaDB replica of a MySQL source shows no visible lag after a test workload. The team decides to keep the pair indefinitely and promote either side during failures. This ignores directional support, GTID incompatibility, failback complexity, DDL drift, feature restrictions, client routing, fencing, and the fact that “caught up” is not a proof of application equivalence.

The repair is to give mixed-vendor replication a narrow purpose and exit condition. For example: maintain it only during a migration window, validate the target continuously, stop writes at a controlled cutover, establish a known final source position, verify application invariants, switch clients, and keep the old source read-only for a defined rollback window. If rollback requires reverse replication, test that separate direction explicitly; do not assume symmetry.

7. Disposable lab topology for mixed-vendor testing

The full cross-vendor topology is optional if your workstation cannot run two database servers, but it uses only free local Community software. Use separate ports such as MariaDB 3307 and MySQL 3308, unique server_id values, disposable volumes, and a dedicated replication account. Pin exact images/packages—MariaDB 12.3.2 and MySQL 8.4.11 for this chapter—rather than floating tags when you are producing evidence.

Application test client        |        +--> MySQL 8.4.11 source   :3308        |       | binary log        |       v        +--> MariaDB 12.3.2 replica:3307Migration test only. No automatic failover.Unique server_id values and disposable data volumes.

Configure replication using the exact current vendor instructions for the chosen direction. Do not copy a single generic CHANGE MASTER/CHANGE REPLICATION SOURCE block into both products. The lab’s acceptance criteria are what matter: the replica applies inserts/updates/deletes, compatible DDL succeeds, unsupported DDL is detected in staging, replication status reports no error, and application-level row/invariant checks match.

8. Verify data, not just replication-thread state

Replication status is necessary operational evidence but is not a data-quality oracle. A stopped SQL thread clearly signals failure, yet a running thread does not prove that every source object was included, every filter is correct, or every application invariant survived. Pair replication status with deterministic application checks.

SELECT COUNT(*) AS customers FROM servicehub.customers;SELECT COUNT(*) AS technicians FROM servicehub.technicians;SELECT COUNT(*) AS work_orders FROM servicehub.work_orders;SELECT COUNT(*) AS events FROM servicehub.work_order_events;SELECT status, COUNT(*) AS work_ordersFROM servicehub.work_ordersGROUP BY statusORDER BY status;SELECT COUNT(*) AS orphan_eventsFROM servicehub.work_order_events eLEFT JOIN servicehub.work_orders w  ON w.work_order_id=e.work_order_idWHERE w.work_order_id IS NULL;

For a real migration, add domain-specific sums, min/max timestamps, uniqueness checks, and sampled row comparisons. If the dataset is large, use migration tooling designed for scalable checksums rather than ad-hoc GROUP_CONCAT hashes.

9. Production judgment and knowledge check

Mixed MariaDB/MySQL replication can be valuable during controlled migration, especially when a documented version pair and direction are supported. It is a poor default for permanent HA because the products’ GTID systems, release cadence, feature sets, and replication event compatibility are independent. Native homogeneous replication or clustering is easier to reason about and test for long-lived failover.

10. Summary and bridge

Cross-vendor replication is versioned, directional, and feature-sensitive. MariaDB and MySQL GTIDs are incompatible, binary-log event support changes across maintenance releases, and SQL/DDL/collation behavior still matters even with row logging. The final lesson turns all of Chapter 02 into a formal pre-migration assessment with inventories, dual-version tests, dry-run restore, acceptance gates, rollback boundaries, performance baselines, and documented unknowns.