Upgrading MariaDB 10.6 to 10.11 without downtime isn’t about a magical "zero-downtime" feature; it’s about orchestrating a carefully planned switchover using replication.
Let’s watch a fresh cluster come online and start serving traffic. Imagine we have a single 10.6 master and two 10.11 replicas.
# On the 10.6 master (let's call it mariadb-master-10-6)
SHOW MASTER STATUS;
-- Output will show File: binlog.000001, Position: 123456
# On a new 10.11 replica (mariadb-replica-1)
CHANGE MASTER TO
MASTER_HOST='mariadb-master-10-6',
MASTER_USER='repl_user',
MASTER_PASSWORD='secure_password',
MASTER_LOG_FILE='binlog.000001',
MASTER_LOG_POS=123456;
START SLAVE;
SHOW SLAVE STATUS\G
-- Look for Slave_IO_Running: Yes and Slave_SQL_Running: Yes
We repeat this for mariadb-replica-2. Now, all writes happening on mariadb-master-10-6 are being replicated to our 10.11 replicas.
The core problem this solves is the disruptive nature of traditional database upgrades. You stop the old, upgrade, start the new, potentially lose data between the stop and start, or have a significant maintenance window. Replication allows us to have both versions running concurrently, with the new version lagging only by the replication delay.
Internally, MariaDB’s replication mechanism is based on binary logs. The master writes all data-changing events (like INSERT, UPDATE, DELETE, CREATE TABLE) into its binary log. Replicas connect to the master, read these binary log events, and re-execute them on their own data. For an upgrade, we set up our new 10.11 servers as replicas of the 10.6 master, starting them from the master’s current binary log position.
The levers you control are primarily in the CHANGE MASTER TO command (or CHANGE REPLICATION SOURCE TO in newer versions) and the START SLAVE command. You also manage the repl_user’s privileges and ensure network connectivity between servers. Crucially, you need to configure log_bin=ON and server_id on the master, and server_id on the replicas.
The most surprising thing is how forgiving the initial synchronization can be. You don’t have to take a full backup of the master to seed the replicas. If your master has a relatively low write volume and you can tolerate a slightly longer initial sync, you can simply point the replica’s MASTER_LOG_FILE and MASTER_LOG_POS to before the actual current master status, and let it catch up. The key is to find a log file and position that is guaranteed to be present on the master when the replica starts reading. Often, this means picking a log file that’s not the very latest but one that’s still active or recently rotated, and a position within it. The replica will then play through all events from that point forward, effectively performing a point-in-time recovery and then catching up on live changes.
Once the 10.11 replicas are caught up and serving read traffic, the switchover involves redirecting application writes from the old 10.6 master to one of the new 10.11 servers. This is typically done at the application level or via a load balancer. The final step is promoting a 10.11 replica to become the new master, then reconfiguring any remaining replicas to follow it.
The next challenge you’ll face is handling feature differences or deprecated syntax between 10.6 and 10.11 that might cause replication errors or application failures.