Upgrade MariaDB Minor Versions Without Panic

Minor upgrades are the ones that should be boring: 11.4.3 to 11.4.7, security fixes, InnoDB patches, no new default charset. They become incidents when the hold is forgotten, unattended-upgrades sneaks a package in, or someone jumps a major because the Ubuntu repo alias moved. Panic is optional. A dump, a read of the release notes, a window, and a rollback path you have already typed are not.

Stay on a long-term series. Upgrade inside that series on purpose. Jump majors on a restored copy first. That is the whole policy.

Know which upgrade you are about to run

apt policy tells you what is installed and what the repo would install. If you apt-mark held mariadb-server at install time, the hold is doing its job. Remove the hold only for the window.

apt-cache policy mariadb-server mariadb-client
mariadbd --version
sudo mariadb -e "SELECT VERSION(); SHOW VARIABLES LIKE 'innodb_version';"
sudo apt-mark showhold

Read the series release notes for the target minor. Look for InnoDB redo format changes, deprecated options you set in a drop-in, and any required mariadb-upgrade step. Most 11.4.x minis do not rewrite the datadir. Some do require a start that runs mysql_upgrade/mariadb-upgrade to fix system tables. Assume you will run it; it is cheap when nothing is wrong.

Take a dump and record binlog coordinates even for a minor. If you have a replica, upgrade the replica first, watch lag, then upgrade the primary. If you have one VPS, the dump is the rollback, plus the previous .deb if you need to pin backwards.

STAMP=$(date +%F-%H%M)
sudo mariadb-dump --single-transaction --routines --triggers --events   --all-databases --default-character-set=utf8mb4   | gzip -9 > /var/backups/mariadb/pre-upgrade.$STAMP.sql.gz
sudo systemctl stop mariadb
sudo apt-mark unhold mariadb-server mariadb-client
sudo apt-get update
sudo apt-get install -y mariadb-server mariadb-client
sudo apt-mark hold mariadb-server mariadb-client
sudo systemctl start mariadb
sudo mariadb-upgrade --verbose
sudo mariadbd --version

mariadb-upgrade is idempotent enough to run after every minor. It will tell you if the system tables were already current. Do not skip it because VERSION() looks right; application tables can be fine while mysql.user is not.

Rollback is a datadir you kept, or a dump you restore

If the new server will not start, do not keep restarting it. Read the error log. The usual minor-upgrade failures are a removed option in your drop-in (query_cache_size, old innodb_log_file_size semantics, an ignore-db-dir that no longer exists) and AppArmor after a package that shipped a new binary path.

Rollback options, in order of cleanliness:

• If the unit never started and you still have the previous packages in /var/cache/apt/archives, pin them back, start, confirm VERSION().
• If the new server started and wrote the datadir, do not reinstall the old server on top and hope. Restore the dump onto the old series, or restore a filesystem copy of the datadir you took while the service was stopped.
• A replica still on the old minor can be promoted if you upgraded the primary first. That is a reason to upgrade the replica first, so this option exists.

A filesystem copy of /var/lib/mysql taken after stop and before apt-get install is the fastest rollback for a single host. rsync it to /var/backups/mysql-datadir.bak. Disk is cheaper than a 40 minute logical restore during the window.

sudo systemctl stop mariadb
sudo rsync -aHAX --numeric-ids /var/lib/mysql/ /var/backups/mysql-datadir.bak/
# ... apt upgrade ...
# rollback if needed:
# sudo systemctl stop mariadb
# sudo rsync -aHAX --delete /var/backups/mysql-datadir.bak/ /var/lib/mysql/
# sudo apt-get install mariadb-server=11.4.3+maria~ubuntu2404
# sudo systemctl start mariadb

After start, prove the application, not just VERSION()

Run a short checklist before you close the window:

• VERSION() matches the target minor.
• innodb_buffer_pool_size and bind_address still match your drop-ins.
• The application login works from the app host, not only from unix_socket root.
• A canary UPDATE and SELECT on a non-critical row succeeds.
• Error log has no InnoDB first-start recovery loop.
• The replica, if any, is still IO/SQL Yes.

Then leave the hold on. Unattended-upgrades should not be the change-management process for a database. Schedule the next minor the same way: notes, dump, replica or datadir copy, install, mariadb-upgrade, canary, hold.

Major upgrades (10.11 to 11.4, 11.4 to 11.8) get a restored copy on a second VPS first, a full application test, and a planned cutover. Do not discover replication-incompatible SQL_MODE defaults on the production primary.

A minor upgrade is a dump, a datadir copy, an apt install inside a held series, mariadb-upgrade, and a canary query. Put the hold back. When you want a clone to rehearse 11.4.x to 11.4.y, spin up Ubuntu on Netbay in Lucknow in under 60 seconds and run the window twice at netbayhosts.in.