MariaDB 10.6 to 10.11 Upgrade Guide, and On to 11.4, 11.8 or 12.3

The short answer

MariaDB 10.6 reached community end of life on 6 July 2026. You can upgrade it to 10.11 in one step, and the MariaDB Foundation states that mariadb-upgrade can upgrade database files from any older release, so 10.6 can also go straight to 11.4, 11.8 or 12.3. The procedure is the same for each: back up, point the package repository at the new series, replace the server packages, clean the option files, start the server and run mariadb-upgrade.

The decision is the target. 10.11 is the smallest change but its community maintenance ends on 16 February 2028. 11.4 runs to 29 May 2029 and 12.3 to 12 June 2029. Going further means picking up more documented changes at once: the optimizer cost model from 11.0, SSL on by default from 11.4, and stricter Repeatable Read behaviour and a new default character set by 11.8. MariaDB does not support downgrading between major versions, so plan the way back before you start.

Upgrade targets

11.8 ends before 11.4 because, from 11.8, the Foundation publishes community binaries for three years instead of five. For one move that lasts, 11.4 and 12.3 are the targets that make sense; 10.11 suits estates that want the smallest change now and will move again before 2028. The dates are on the MariaDB 10.6 end of life and MariaDB 10.11 end of life pages, and every line is on the MariaDB end-of-life chart.

Pre-upgrade checklist

• A full physical backup with mariadb-backup, which MariaDB recommends, plus a logical dump of the mysql schema, restored once on a spare host to prove it works.
• Every option file collected: /etc/mysql/, /etc/my.cnf, /etc/my.cnf.d/ and any systemd drop-ins.
• The InnoDB and Mroonga compression algorithms in use, and whether the libraries are installed for the new packages.
• A list of system-versioned tables and their row counts if the target is 11.8 or later.
• Slow-query samples and EXPLAIN output for the queries that matter, if the target is 11.4 or later.
• Every client, script and replica that connects without TLS, if the target is 11.4 or later.
• For Galera, the wsrep provider version on each node and a gcache.size large enough to avoid a full state transfer during the rolling upgrade.

Breaking changes from 10.6 to 10.11

MariaDB describes most 10.6 upgrades as painless. The documented items:

• Removed options. innodb_log_write_ahead_size (the physical block size is now detected), innodb_version, and wsrep_replicate_myisam and wsrep_strict_ddl, both replaced by wsrep_mode. Remove them from option files; an option the server no longer recognises can stop it from starting.
• Compression. InnoDB or Mroonga tables compressed with anything other than zlib are unreadable on 10.11 until the matching compression library package is installed.
• Changed defaults. innodb_buffer_pool_chunk_size is now sized automatically instead of 128 MiB, and most Spider engine variables changed from -1 to explicit values.
• Deprecated. keep_files_on_create, because MariaDB now deletes orphan files itself.

Find them before the change:

grep -rnE "innodb_log_write_ahead_size|innodb_version|wsrep_replicate_myisam|wsrep_strict_ddl|keep_files_on_create" \
  /etc/mysql /etc/my.cnf /etc/my.cnf.d 2>/dev/null

SHOW GLOBAL VARIABLES LIKE 'innodb_compression_algorithm';
SELECT table_schema, table_name, create_options
FROM information_schema.tables
WHERE create_options LIKE '%page_compressed%';

Further changes on the way to 11.4

• Optimizer cost model. MariaDB 11.0 introduced a new cost model, and the optimizer_switch defaults differ between 10.11 and 11.4. Plan changes only show up when you compare plans. Capture EXPLAIN for your critical queries on 10.6 and compare on the target.
• InnoDB change buffer removed. Gone since 11.0, along with innodb_change_buffering and innodb_change_buffer_max_size. Remove both from option files.
• Removed options. innodb_defragment and its five related settings, debug_no_thread_alarm, and old_alter_table, replaced by alter_algorithm.
• Changed default. innodb_purge_batch_size rises from 300 to 1000.
• Deprecated. tx_isolation and tx_read_only, replaced by transaction_isolation and transaction_read_only.
• SSL by default. In 11.4 the server enables SSL with no configuration and generates a self-signed certificate if none is provided. Clients now require SSL and verify the server certificate by default, and replicas enable MASTER_SSL_VERIFY_SERVER_CERT by default. Scripts and tools that connect with an 11.4 client to a server without a trusted certificate can fail; --disable-ssl or --disable-ssl-verify-server-cert restores the old client behaviour while certificates are sorted out.

grep -rnE "innodb_change_buffer|innodb_defragment|debug_no_thread_alarm|old_alter_table|tx_isolation|tx_read_only" \
  /etc/mysql /etc/my.cnf /etc/my.cnf.d 2>/dev/null

Further changes on the way to 11.8

• Stricter Repeatable Read. innodb_snapshot_isolation now defaults to ON. Under Repeatable Read, an UPDATE or DELETE that touches rows another transaction changed after the snapshot was taken now fails with ERROR 1020 and the transaction is rolled back. Bulk updates and concurrent workloads are the ones MariaDB names. Check the isolation level in use, and make sure the application retries on 1020 or set the variable to OFF until it does.
• New default character set. From 11.6 the default is utf8mb4 instead of latin1, with uca1400_ai_ci as the default Unicode collation. Tables created without an explicit character set change, and MariaDB notes implications for replicas running 10.6 or older. If you rely on the old default, set character_set_server and collation_server explicitly before the upgrade.
• System-versioned tables. The TIMESTAMP range now runs to 2106. Every row and index in system-versioned tables has to be updated, and MariaDB warns this can take a long time on large tables. Plan the window around it.
• Removed for Galera. wsrep_load_data_splitting.

SELECT @@global.tx_isolation;  -- on 10.6; REPEATABLE-READ is the default
SHOW GLOBAL VARIABLES LIKE 'character_set_server';
SELECT table_schema, table_name, table_rows
FROM information_schema.tables
WHERE table_type = 'SYSTEM VERSIONED';

Further changes on the way to 12.3

• Removed options. big_tables, storage_engine (use default_storage_engine) and large_page_size.
• New reserved words. CONVERSION and TO_DATE. Statements that use them as unquoted identifiers fail to parse.
• Replication. Upgrading a replica to 12.3.2 reset its master_use_gtid setting to the default. 12.3.3 fixes this; use 12.3.3 or later and check the setting after the upgrade either way.
• Deprecated. The MYSQLD_OPTS environment variable for the systemd service. Move those options into an option file.

SELECT table_schema, table_name, column_name
FROM information_schema.columns
WHERE LOWER(column_name) IN ('conversion', 'to_date')
   OR LOWER(table_name) IN ('conversion', 'to_date');

grep -rnE "^\s*(big[-_]tables|storage[-_]engine|large[-_]page[-_]size)\b|MYSQLD_OPTS" \
  /etc/mysql /etc/my.cnf /etc/my.cnf.d /etc/systemd/system 2>/dev/null

Also search stored procedures, views and application SQL for the two new reserved words, since the column check above only covers table definitions.

The upgrade procedure

For a standalone server or a replica, following MariaDB's documented steps, on Debian or Ubuntu:

# 1. Back up and prepare the backup
sudo mariadb-backup --backup --target-dir=/backup/pre-upgrade --user=root
sudo mariadb-backup --prepare --target-dir=/backup/pre-upgrade

# 2. Point the MariaDB APT repository at the new series (10.11, 11.4, 11.8 or 12.3)

# 3. Replace the server packages
sudo systemctl stop mariadb
sudo apt-get remove mariadb-server
sudo apt-get install mariadb-server

# 4. Remove unsupported options from the option files, then start and upgrade
sudo systemctl start mariadb
sudo mariadb-upgrade --verbose

On RHEL and similar systems the package commands are sudo yum remove MariaDB-server and sudo yum install MariaDB-server, after updating the MariaDB YUM repository; on SLES use zypper. mariadb-upgrade makes the system tables in the mysql schema compatible with the new version and marks the existing tables as checked.

With replication, upgrade a replica first, let it replicate from the 10.6 primary under real traffic, then move the primary role to it. On a 11.8 or later replica, watch for the character set note above.

Galera clusters

For 10.6 to 10.11, MariaDB documents two methods: stop every node, upgrade them all and start the cluster again, or a rolling upgrade that relies on incremental state transfer (IST). A rolling upgrade that needs a full state snapshot transfer (SST) does not work for this step, which is why gcache.size matters. On each node in turn:

1. Drain it from MaxScale, HAProxy or whichever proxy fronts the cluster.
2. Stop MariaDB, remove the old server and Galera wsrep provider packages, and install the new ones.
3. Clean the option file. On systemd hosts, raise the service start timeout if the default 90 seconds is not enough.
4. Start MariaDB, run mariadb-upgrade --skip-write-binlog, and wait for wsrep_local_state_comment to show Synced before moving to the next node.

Do not use features of the new version until every node runs it, and do not restart a node that has not been upgraded once the others have, since the Galera protocol version can change. MariaDB publishes a separate Galera page for each LTS step; read the one for your step before skipping a release on a cluster.

Rollback limits

MariaDB does not officially support downgrading between major versions. Its documentation gives three routes, in order of preference:

• Replica on the old version. Keep a 10.6 server replicating from the upgraded primary, then stop writes, promote it and redirect traffic. This only works while the new primary uses nothing the old version cannot read, and it has to be set up before you need it.
• Restore the backup. Install the old version on a clean server, restore the pre-upgrade backup, run mariadb-upgrade and reconnect the application. Reliable, with more downtime, and every write since the upgrade is lost unless you replay it.
• In-place downgrade. Untested by MariaDB and not advised. It is generally only possible if mariadb-upgrade has not yet run on the new version.

Version details narrow these further. Coming back from 11.0 or later to 10.6 or 10.11 requires innodb_change_buffering=none on the old server. And 10.8 changed the InnoDB redo log format, so 10.11 data files cannot simply be opened by 10.6.

Where OSSeva fits

If some servers cannot move yet, OSSeva for MariaDB ships patched, signed 10.6 Community Server builds as DEB and RPM packages, tarballs and container images. They stay in the 10.6 series, on the same data directory and configuration, so applying one is a normal minor update. OSSeva Assure adds an upgrade plan from 10.x to a current LTS, rehearsed with mariadb-upgrade, and a Galera and replication topology review. OSSeva Operate runs rolling upgrades node by node and patches Critical CVEs (CVSS ≥ 9.0) within 48 hours and High within 7 days. MariaDB sits under the same contract as MySQL, PostgreSQL and the rest of the stack, priced per cluster; book a discovery call for a quote. For the MySQL side of the same estate, see the MySQL 8.0 to 8.4 upgrade guide.

Frequently asked questions

Can I upgrade MariaDB 10.6 directly to 11.4?

Yes. The Foundation states that mariadb-upgrade can upgrade database files from any older release, so there is no need to stop at 10.11. Read the incompatibility notes for each LTS step in between, since they all apply.

Is MariaDB 10.11 an LTS release?

Yes. Its community maintenance runs to 16 February 2028, the earliest end date of the current LTS lines.

Do I need to run mariadb-upgrade after upgrading MariaDB?

Yes. It updates the system tables in the mysql schema for the new version and checks the existing tables. On Galera nodes, run it with --skip-write-binlog.

Can I downgrade from MariaDB 10.11 to 10.6?

Not in a supported way. Restore a pre-upgrade backup, or switch to a 10.6 replica you set up beforehand. An in-place downgrade is untested by MariaDB and the 10.8 redo log change stands in the way.

Why do I get ERROR 1020 after upgrading to MariaDB 11.8?

innodb_snapshot_isolation now defaults to ON, so a Repeatable Read transaction that changes rows modified after its snapshot is rolled back with error 1020. Retry the transaction in the application, or set the variable to OFF as a temporary measure.

Why does the mariadb client fail with an SSL error after upgrading to 11.4?

From 11.4, clients require SSL and verify the server certificate by default. Give the server a certificate the client trusts, or use --disable-ssl-verify-server-cert while you fix the certificates.

Which MariaDB version should I upgrade 10.6 to?

11.4 or 12.3, which are maintained to May and June 2029. 10.11 is the smallest change but ends in February 2028, and 11.8 ends in June 2028.