Replication Notes

Status:

Exploratory note

Last updated:

2026-05

Context

Drizzle has several replication-related plugins, but they do not all form complete replication systems on their own. This note records the current reading of the old implementation so future revival work has a starting point.

What exists

The implemented Drizzle-to-Drizzle replication path is a protobuf-based analogue of MySQL async binlog replication, but it does not use MySQL’s binlog format or replication protocol.

The native path is:

  1. The primary encodes changes as Drizzle protobuf Transaction messages.

  2. A replicator such as default_replicator or filtered_replicator passes those messages to an applier.

  3. The InnoDB replication-log applier stores the messages in the InnoDB SYS_REPLICATION_LOG table.

  4. The slave plugin runs as a daemon on another Drizzle server.

  5. Its queue producer polls the upstream DATA_DICTIONARY.SYS_REPLICATION_LOG table and copies messages into local sys_replication.queue.

  6. Its queue consumer drains the local queue, converts protobuf statements back to SQL, applies them locally, and advances sys_replication.applier_state.

The old tree also contains real end-to-end test support for this path. The small plugin/slave test starts two servers, writes data on the upstream server, waits until the downstream applied commit ID reaches the upstream max commit ID, and then checks the replicated table contents. The randgen randgen_slavePlugin suite exercises the same two-server shape and compares master and replica dumps after the workload.

Current caveat

That coverage looks legacy rather than part of the current default container test path. make test-drizzle runs the normal DTR suites, while the randgen slave coverage has a separate test-randgen-slave target. The small plugin/slave end-to-end test also uses a master.cnf two-server configuration, which the old DTR collection path marks as skipped.

External queues

The RabbitMQ and ZeroMQ plugins are best understood as change-data-capture sinks in the current tree. They publish Drizzle replication protobuf messages to an external queue or socket, but the tree does not appear to contain matching consumer plugins that read those external messages and apply them back into Drizzle.

A future external-queue replication system would need a consumer shaped like the current slave plugin, but with the queue producer replaced by a RabbitMQ consumer, ZeroMQ subscriber, or equivalent. Such a consumer could feed sys_replication.queue and reuse the existing protobuf-to-SQL apply path, or it could factor that apply path into a shared component.

Open design questions for that work include:

  • ordering and commit sequence preservation

  • acknowledgements and retry behavior

  • deduplication and idempotence

  • crash recovery

  • retention and garbage collection

  • origin UUID handling and loop prevention

  • provisioning a new replica from a specific commit ID

Terminology

The code and docs still use master/slave names. Since the revival has no current user compatibility burden, the public terminology should be renamed before broader announcement.

Preferred terminology:

  • primary / replica for user-facing docs, options, tests, and product language

  • source where a replica may consume from one of several upstreams

  • producer / consumer only for internal queue mechanics where those words describe the implementation directly

Storage-engine note

If a MyRocks storage engine is added later, its LSM structure may be a more natural fit for replication log storage than an InnoDB table. The workload is append-heavy and read mostly by ordered commit ranges. Any design should still make retention, range scans, exact commit-order indexing, crash recovery, and start from commit ID semantics explicit.