MariaDB | Fabric docs

MariaDB uses the same binary-log approach as MySQL, with a MariaDB-specific connector. The snapshot-then-stream flow and the file-and-position resume are identical; the differences are in server variables, grant names, and how row events are decoded.

Supported deployments

The same connector serves self-hosted MariaDB, Amazon RDS for MariaDB, and Azure Database for MariaDB. As with MySQL, the server variables below are parameter-group or flag changes on a managed service.

Prerequisites

Server settings

[mysqld]
log-bin=mysql-bin
binlog-format=ROW
binlog-row-image=FULL
server_id=2
binlog-expire-logs-seconds=604800   # 7 days; 0 = never purge

log-bin, binlog-format=ROW, and binlog-row-image=FULL are required, exactly as for MySQL.
binlog_row_metadata does not exist on MariaDB and is not required — Fabric overrides that check.
Retention accepts either expire_logs_days or (10.6+) binlog_expire_logs_seconds; 0 means never purge and always passes, otherwise the window must exceed 72 hours.
A non-zero server_id, a distinct Fabric reader ID, and a UTC-pinnable session time zone — same as MySQL.

MariaDB 10.5 renamed the replication grants. Granting both the new and legacy names keeps older releases working:

CREATE USER 'replicator'@'%' IDENTIFIED BY '<password>';
GRANT REPLICATION MASTER ADMIN, SLAVE MONITOR,
      REPLICATION SLAVE, REPLICATION CLIENT, SELECT ON *.*
  TO 'replicator'@'%';
FLUSH PRIVILEGES;

MariaDB uses plain IDENTIFIED BY — it rejects MySQL's WITH mysql_native_password clause.

Connection fields

Field	Required	Default	Notes
Connector name	Yes	—	Unique across sources.
Host	Yes	—	TCP host of the server.
Port	Yes	3306
Username	Yes	—	The replication/SELECT user.
Password	Yes on create	—	Leave blank on edit to keep the stored password.
Database	Yes	—	Test connection lists the visible databases. Read-only after creation.
Server ID	Yes	—	Fabric's reader identity. Must differ from the server's own `server_id` and from every replica's, and be unique across MariaDB sources.

The engine selection is what differs from MySQL — it cannot be changed after creation.

How it replicates

Identical to MySQL: one consistent snapshot transaction, serial scanning, a binlog bookmark captured before the scan, and per-chunk checkpoints. The only behavioral difference is decoding.

MariaDB row decoding

MariaDB's table-map events carry no column names, so Fabric decodes rows positionally against the introspected column order. A column added mid-stream shifts that order and is refused with a mismatch error rather than corrupted data — run schema changes while the runner is up, or re-introspect before resuming.

Gotchas

Watch out

Same prerequisite refusals as MySQL: binlog format, row image, retention, grants, server ID, replica updates, time zone, and keyless tables.
The positional decode caveat cannot be configured away — it is inherent to MariaDB.
A silent binlog disconnect is treated as a failure, never a clean stop, so a dead connection never looks like an idle source.