link<\/a>.)<\/p>\n\n\n\nNew binlog files use the .ibb<\/code> extension and are pre-allocated. Here is what the binlog directory looks like side by side:<\/p>\n\n\n\nClassic FILE binlog:<\/strong><\/p>\n\n\n\n$ ls -lah \/var\/lib\/mysql\/binlog\/\ndrwx------ 2 mysql mysql 4.0K #binlog_cache_files\n-rw-rw---- 1 mysql mysql 1.9K mysqld-bin.000001\n-rw-rw---- 1 mysql mysql 4.0K mysqld-bin.000001.idx\n-rw-rw---- 1 mysql mysql 1.4K mysqld-bin.000002\n-rw-rw---- 1 mysql mysql 0 mysqld-bin.000002.idx\n-rw-rw---- 1 mysql mysql 80 mysqld-bin.index\n<\/code><\/pre>\n\n\n\nInnoDB binlog:<\/strong><\/p>\n\n\n\n$ ls -lah \/var\/lib\/mysql\/binlog\/\n-rw-rw---- 1 mysql mysql 1.0G binlog-000000.ibb\n-rw-rw---- 1 mysql mysql 1.0G binlog-000001.ibb\n<\/code><\/pre>\n\n\n\nThe difference is immediately striking: the .ibb<\/code> files are pre-allocated at max_binlog_size<\/code><\/strong> (default 1 GB). There is no .index<\/code> file, no .idx<\/code> GTID index files, no .state<\/code> file. GTID state is periodically written as state records<\/em> inside the binlog itself, controlled by --innodb-binlog-state-interval<\/code> (bytes between state records). GTID position recovery scans from the last state record forward.<\/p>\n\n\n\nAnother subtle difference visible in the mariadb-binlog<\/code> output: all InnoDB binlog events show end_log_pos 0<\/code> (position tracking is handled by InnoDB internally), whereas FILE binlog events show actual byte offsets (end_log_pos 257<\/code>, end_log_pos 330<\/code>, etc.).<\/p>\n\n\n\nEvents can span multiple .ibb<\/code> files, and parts of the same event can be interleaved across files. mariadb-binlog<\/code> coalesces them transparently. For correct output across files, pass all files at once in order.<\/p>\n\n\n\nThis is a significant improvement over the old model: mariadb-backup<\/code> now includes the binlog in the backup by default<\/strong>, transactionally consistent with the data. The backed-up server is not blocked during binlog copy. A restored backup can be turned into a replica using CHANGE MASTER ... MASTER_DEMOTE_TO_SLAVE=1<\/code> directly \u2014 no separate binlog position reconciliation needed.<\/p>\n\n\n\n<\/p>\n\n\n\n
Operational Impact: GTID, Replica Resync, and Split-Brain Recovery<\/h2>\n\n\n\n
This is arguably the most impactful day-to-day change for DBAs apart from the TPS throughput. You can’t use anything else than GTID mode for replication if you use innodb as the binlog storage engine. I still run into a lot of MariaDB 10.11 so some DBAs might not use this on a daily basis yet. To help them understand the next part is a quick reminder of the GTID capabilities that has been around for 12 years already…<\/p>\n\n\n\n
What MASTER_USE_GTID = slave_pos<\/code> Actually Means<\/h3>\n\n\n\nA common point of confusion when reading MariaDB documentation for the first time: in the CHANGE MASTER TO<\/code> statement, slave_pos<\/code> looks like a placeholder you are supposed to fill in. It is not. It is a literal enum keyword<\/strong> \u2014 one of exactly three accepted values:<\/p>\n\n\n\nMASTER_USE_GTID = no -- classic file\/offset mode, GTID disabled\nMASTER_USE_GTID = slave_pos -- use @@gtid_slave_pos (what this replica last received)\nMASTER_USE_GTID = current_pos -- use @@gtid_current_pos (slave_pos + any local writes)\n<\/code><\/pre>\n\n\n\nslave_pos<\/code> is not a value you provide \u2014 it is an instruction telling MariaDB to read the starting replication position from the server’s own @@gtid_slave_pos<\/code> system variable, which was populated automatically during the backup restore. You are providing an instruction<\/strong>, not data. The actual position is determined by the engine, not by you.<\/p>\n\n\n\nFor completeness: MariaDB accepts the keyword unquoted (unlike MySQL’s tendency to quote string enums), which is why it looks like a variable name in documentation examples.<\/p>\n\n\n\n
Replica Resync Before and After: The Concrete Difference<\/h3>\n\n\n\n
This is best understood by comparing the full procedure side by side.<\/p>\n\n\n\n
With FILE binlog (classic):<\/strong><\/p>\n\n\n\nProblem: two independent sources of truth to reconcile.<\/p>\n\n\n\n
\n- Take fresh backup with mariadb-backup<\/li>\n\n\n\n
- Read xtrabackup_binlog_info from the backup:
\u2192 binlog.000042 position 198472910
BUT: this position may not match what InnoDB actually committed
(MDEV-21611 \u2014 mariabackup does not always update the InnoDB
binlog position during prepare, causing mismatch)<\/li>\n\n\n\n - Restore the backup on the replica<\/li>\n\n\n\n
- Manually declare:
CHANGE MASTER TO
MASTER_LOG_FILE = ‘binlog.000042’, \u2190 you looked this up
MASTER_LOG_POS = 198472910; \u2190 you looked this up<\/li>\n\n\n\n - START SLAVE;<\/li>\n\n\n\n
- Watch for errors, validate row counts, hope the position was right<\/li>\n<\/ol>\n\n\n\n
The fragility: step 2\/4 requires you to provide specific data<\/strong> (a filename string and a byte offset integer). If that data is wrong by even one transaction \u2014 which MDEV-21611 demonstrates can happen \u2014 the replica either re-applies events it already has, or misses events entirely. This produces silent data drift, not an immediate error.<\/p>\n\n\n\nWith InnoDB binlog + GTID:<\/strong><\/p>\n\n\n\nProblem: eliminated. One source of truth.<\/p>\n\n\n\n
\n- Take fresh backup with mariadb-backup
\u2192 .ibb binlog files included automatically, consistent with data<\/li>\n\n\n\n - Restore the backup on the replica
\u2192 @@gtid_slave_pos populated from InnoDB state automatically<\/li>\n\n\n\n - Declare the replica:
CHANGE MASTER TO
MASTER_HOST = ‘primary’,
MASTER_USER = ‘replicator’,
MASTER_PASSWORD = ‘replpass’,
MASTER_USE_GTID = slave_pos, \u2190 instruction, not a value
MASTER_DEMOTE_TO_SLAVE = 1; \u2190 folds local writes into GTID pos<\/li>\n\n\n\n - START SLAVE;
\u2192 replica announces its GTID set to the primary
\u2192 primary streams from that point forward
\u2192 done<\/li>\n<\/ol>\n\n\n\nYou never touch a file name or a byte offset. The position is embedded in the InnoDB state from the moment the backup was consistent.<\/p>\n\n\n\n
Split-Brain Recovery <\/h3>\n\n\n\n
Split-brain is where this matters most. Consider a scenario where the primary and replica became isolated:<\/p>\n\n\n\n
Primary: committed GTIDs 0-1-1 through 0-1-10042\nReplica: applied GTIDs 0-1-1 through 0-1-10039 (was lagging at split)\n then received 3 rogue writes (briefly promoted to primary)\n now has: 0-1-10040, 0-1-10041, 0-1-10042 (divergent, different transactions)\n<\/code><\/pre>\n\n\n\nWith FILE binlog<\/strong>, reconciling this required manually scanning both binlog files to find the exact divergence point \u2014 line by line, event by event. Many teams simply wiped the replica and re-provisioned from scratch to be safe. Even experienced DBAs would spend hours on this.<\/p>\n\n\n\nWith GTID<\/strong>, the divergence is immediately visible and unambiguous:<\/p>\n\n\n\n-- On the drifted replica:\nSELECT @@gtid_slave_pos;\n-- Returns: 0-1-10042 (but these last 3 GTIDs are rogue, divergent from primary)\n\n-- On the primary:\nSELECT @@gtid_binlog_pos;\n-- Returns: 0-1-10042 (completely different transactions at 10040-10042)\n<\/code><\/pre>\n\n\n\nTo resync, declare the last known good position explicitly and restart:<\/p>\n\n\n\n
STOP SLAVE;\nRESET SLAVE;\nSET GLOBAL gtid_slave_pos = '0-1-10039'; -- last confirmed good GTID from primary\nSTART SLAVE;\n-- MariaDB streams 10040-10042 from the primary, no manual intervention\n<\/code><\/pre>\n\n\n\nWith gtid_strict_mode = ON<\/code> (recommended), MariaDB will refuse to apply a GTID it has already seen with different content \u2014 you get an explicit error rather than silent data corruption. The divergence surface is precisely identified, not guessed at.<\/p>\n\n\n\n