Sunday, July 26, 2026

MariaDB 11.4.4 to 11.4.12 on RHEL/OEL 8 or 9

```html MariaDB Upgrade from 11.4.4 to 11.4.12 – Complete DBA Guide

MariaDB Upgrade from 11.4.4 to 11.4.12 – Complete DBA Guide

Author: Punit Kumar
Category: MariaDB | Database Administration | Upgrade and Patching
Environment: MariaDB 11.4, RHEL 8/9 or Oracle Linux 8/9
Upgrade Type: Minor Version Upgrade

Introduction

Upgrading MariaDB in a production environment is not simply a package-update activity. A professional DBA upgrade includes database-health verification, configuration backup, physical backup, application coordination, controlled package installation, post-upgrade validation and a tested rollback plan.

This article explains how to upgrade MariaDB from 11.4.4 to 11.4.12 on a Linux server using a safe and production-focused approach.

Important: Always test the upgrade in a non-production environment before performing it on production. Confirm application compatibility, backup recovery and rollback procedures before beginning the maintenance window.

Upgrade Flow

Application Downtime
        |
        v
Pre-Upgrade Health Checks
        |
        v
Configuration and Database Backup
        |
        v
Stop Application Services
        |
        v
Stop MariaDB
        |
        v
Upgrade MariaDB Packages
        |
        v
Start MariaDB
        |
        v
Run mariadb-upgrade
        |
        v
Database and Application Validation
        |
        v
Release the Environment

Environment Details

Component Details
Current MariaDB Version 11.4.4
Target MariaDB Version 11.4.12
Operating System RHEL 8/9 or Oracle Linux 8/9
Storage Engine InnoDB
Service Name mariadb
Default Data Directory /var/lib/mysql

Phase 1: Pre-Upgrade Checks

1. Check the Current MariaDB Version

mariadb --version
mariadbd --version

From the database:

SELECT VERSION();

Expected current version:

11.4.4-MariaDB

2. Check the Operating System

cat /etc/os-release
uname -r

3. Check Installed MariaDB Packages

rpm -qa | grep -i MariaDB | sort

Save the package list:

rpm -qa | grep -i MariaDB | sort \
> /tmp/mariadb_packages_before_upgrade.txt

Typical packages may include:

MariaDB-server
MariaDB-client
MariaDB-common
MariaDB-shared
MariaDB-backup

4. Confirm the MariaDB Repository

dnf repolist | grep -i mariadb

Check whether the target version is available:

dnf --showduplicates list MariaDB-server
Confirm that the repository is pointing to the MariaDB 11.4 release series. Do not accidentally upgrade to another major release.

5. Check MariaDB Service Status

systemctl status mariadb --no-pager

6. Check Database Availability

SHOW DATABASES;

SHOW GLOBAL STATUS LIKE 'Uptime';

SHOW FULL PROCESSLIST;

SHOW ENGINE INNODB STATUS\G

7. Check Database Tables

mariadb-check --all-databases
For very large databases, perform table checks carefully because they may consume additional CPU, memory and I/O resources.

8. Check Disk Space

df -hT
df -i
du -sh /var/lib/mysql
du -sh /var/log/mariadb

Confirm sufficient free space for:

  • MariaDB package installation
  • Database backup
  • Temporary upgrade files
  • Database and operating-system logs
  • Rollback files

9. Capture Current Database Variables

mariadb -e "SHOW VARIABLES" \
> /tmp/mariadb_variables_before_upgrade.txt

mariadb -e "SHOW GLOBAL STATUS" \
> /tmp/mariadb_status_before_upgrade.txt

10. Capture Database Size

SELECT
    table_schema,
    COUNT(*) AS table_count,
    ROUND(
        SUM(data_length + index_length) / 1024 / 1024,
        2
    ) AS size_mb
FROM information_schema.tables
GROUP BY table_schema
ORDER BY size_mb DESC;

11. Review the MariaDB Error Log

journalctl -u mariadb -n 200 --no-pager

If file-based logging is configured:

grep -iE "error|warning|corrupt|crash" \
/var/log/mariadb/*.log
Resolve existing corruption, startup, recovery or storage errors before starting the upgrade. Do not use an upgrade as a workaround for an unidentified production issue.

Phase 2: Backup Before Upgrade

12. Back Up MariaDB Configuration

mkdir -p /backup/mariadb_upgrade_11.4.12/config

cp -p /etc/my.cnf \
/backup/mariadb_upgrade_11.4.12/config/

cp -pr /etc/my.cnf.d \
/backup/mariadb_upgrade_11.4.12/config/

If the following directory exists:

cp -pr /etc/mysql \
/backup/mariadb_upgrade_11.4.12/config/

13. Take a Physical Backup

mkdir -p \
/backup/mariadb_upgrade_11.4.12/full_backup

Run the backup:

mariadb-backup \
--backup \
--target-dir=/backup/mariadb_upgrade_11.4.12/full_backup \
--user=backup_user \
--password='REPLACE_WITH_SECURE_METHOD'
Avoid placing passwords directly in shell scripts or command history. Use a protected option file or enterprise secrets-management solution.

14. Prepare the Backup

mariadb-backup \
--prepare \
--target-dir=/backup/mariadb_upgrade_11.4.12/full_backup

Verify the backup metadata:

cat \
/backup/mariadb_upgrade_11.4.12/full_backup/xtrabackup_checkpoints

Confirm that the backup log contains:

completed OK!

15. Optional Logical Backup

mariadb-dump \
--all-databases \
--single-transaction \
--routines \
--events \
--triggers \
--hex-blob \
> /backup/mariadb_upgrade_11.4.12/all_databases.sql
A physical backup normally provides faster full-server recovery. A logical backup can serve as an additional recovery option for smaller environments.

Phase 3: Stop Application Activity

16. Stop Application Services

Before stopping MariaDB:

  • Stop application servers.
  • Stop batch jobs and scheduled interfaces.
  • Pause backup and maintenance jobs.
  • Disable automatic service-restart automation.
  • Notify the application and business teams.

17. Check Active Sessions

SHOW FULL PROCESSLIST;

18. Check Active Transactions

SELECT
    trx_id,
    trx_state,
    trx_started,
    trx_mysql_thread_id,
    trx_query
FROM information_schema.innodb_trx;

19. Stop MariaDB

sudo systemctl stop mariadb

Verify that the service is stopped:

sudo systemctl status mariadb --no-pager

ps -ef | grep -i mariadbd

Phase 4: Upgrade MariaDB Packages

20. Save the Existing Package List

rpm -qa | grep -i MariaDB | sort \
> /backup/mariadb_upgrade_11.4.12/packages_before.txt

21. Refresh Repository Metadata

sudo dnf clean all
sudo dnf makecache

22. Confirm the Target Version

dnf --showduplicates list MariaDB-server

23. Upgrade MariaDB Packages

sudo dnf upgrade \
MariaDB-server \
MariaDB-client \
MariaDB-common \
MariaDB-shared \
MariaDB-backup

Alternatively, after reviewing the transaction:

sudo dnf upgrade 'MariaDB-*'
Review the proposed DNF transaction carefully before accepting it. Confirm that every package is moving to the approved 11.4.12 release.

24. Confirm Installed Packages

rpm -qa | grep -i MariaDB | sort

Phase 5: Start MariaDB

25. Start the MariaDB Service

sudo systemctl start mariadb

26. Check Service Status

sudo systemctl status mariadb --no-pager

27. Review Startup Logs

sudo journalctl -u mariadb -n 200 --no-pager

Check for critical messages:

sudo grep -iE "error|warning|crash|corrupt" \
/var/log/mariadb/*.log

28. Confirm the New Version

mariadb --version

From the database:

SELECT VERSION();

Expected result:

11.4.12-MariaDB

Phase 6: Run mariadb-upgrade

sudo mariadb-upgrade

If authentication is required:

mariadb-upgrade \
--user=root \
--password

Restart MariaDB after completion:

sudo systemctl restart mariadb

Confirm status:

sudo systemctl status mariadb --no-pager

Phase 7: Post-Upgrade Validation

29. Validate Database Access

SELECT VERSION();

SELECT NOW();

SHOW DATABASES;

30. Validate All Databases

mariadb-check --all-databases

Run upgrade-related checks:

mariadb-check \
--all-databases \
--check-upgrade

31. Compare Database Size

SELECT
    table_schema,
    COUNT(*) AS table_count,
    ROUND(
        SUM(data_length + index_length) / 1024 / 1024,
        2
    ) AS size_mb
FROM information_schema.tables
GROUP BY table_schema
ORDER BY size_mb DESC;

32. Validate Users and Authentication

SELECT
    User,
    Host,
    plugin
FROM mysql.user
ORDER BY User, Host;

33. Validate Procedures and Functions

SELECT
    routine_schema,
    routine_name,
    routine_type
FROM information_schema.routines
ORDER BY routine_schema, routine_name;

34. Validate Events

SELECT
    event_schema,
    event_name,
    status
FROM information_schema.events;

35. Validate Triggers

SELECT
    trigger_schema,
    trigger_name,
    event_object_table
FROM information_schema.triggers;

36. Validate InnoDB Health

SHOW ENGINE INNODB STATUS\G

Check for:

  • InnoDB corruption
  • Crash-recovery errors
  • Deadlocks
  • Long-running transactions
  • Pending I/O
  • Lock waits

37. Test Application Connectivity

mariadb \
-h database-host \
-u application_user \
-p \
application_database

Run a basic query:

SELECT COUNT(*)
FROM critical_application_table;

Perform application smoke tests for:

  • Application login
  • Read transactions
  • Insert and update transactions
  • Batch processing
  • Reports
  • API connectivity
  • Scheduled jobs

38. Compare Configuration Before and After

mariadb -e "SHOW VARIABLES" \
> /tmp/mariadb_variables_after_upgrade.txt
diff -u \
/tmp/mariadb_variables_before_upgrade.txt \
/tmp/mariadb_variables_after_upgrade.txt
Some variable differences may be expected after a patch-level upgrade. Investigate any unexpected default-value or configuration changes.

39. Monitor Operating-System Resources

top
free -m
vmstat 1 10
iostat -xz 1 10
df -hT

40. Monitor MariaDB

SHOW GLOBAL STATUS LIKE 'Threads_connected';

SHOW GLOBAL STATUS LIKE 'Threads_running';

SHOW GLOBAL STATUS LIKE 'Aborted_connects';

SHOW GLOBAL STATUS LIKE 'Slow_queries';

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';

SHOW GLOBAL STATUS LIKE 'Innodb_deadlocks';

Rollback Plan

A rollback should be based on restoring the approved previous version and the prepared pre-upgrade backup. Do not rely only on package downgrade.

Rollback Steps

  1. Stop MariaDB.
  2. Preserve the failed upgraded data directory.
  3. Reinstall the approved previous MariaDB packages.
  4. Restore the previous configuration files.
  5. Restore the prepared physical backup.
  6. Start MariaDB.
  7. Validate the database and application.

Example Restore

sudo systemctl stop mariadb

mv /var/lib/mysql \
/var/lib/mysql_failed_11.4.12

mkdir -p /var/lib/mysql

mariadb-backup \
--copy-back \
--target-dir=/backup/mariadb_upgrade_11.4.12/full_backup

chown -R mysql:mysql /var/lib/mysql

restorecon -Rv /var/lib/mysql

sudo systemctl start mariadb
The restore destination must be empty before using mariadb-backup --copy-back. Preserve the failed environment until the rollback is validated.

DBA Upgrade Checklist

Before Upgrade

  • Current MariaDB version confirmed
  • Target version available in the repository
  • Release notes reviewed
  • Database health checked
  • Disk space verified
  • Configuration files backed up
  • Physical backup completed
  • Backup prepared successfully
  • Restore test completed in non-production
  • Rollback procedure documented
  • Application outage approved

During Upgrade

  • Application services stopped
  • Active transactions reviewed
  • MariaDB stopped cleanly
  • Correct packages selected
  • Target version confirmed before installation
  • MariaDB started successfully
  • Error logs reviewed
  • mariadb-upgrade completed

After Upgrade

  • Version confirmed as 11.4.12
  • Database tables validated
  • Users and privileges validated
  • Application connectivity tested
  • Critical transactions tested
  • Database size compared
  • Performance compared with baseline
  • Monitoring reviewed
  • Application released to users

Common Upgrade Mistakes

  • Upgrading without a tested backup
  • Pointing the repository to the wrong major release
  • Skipping the application shutdown
  • Ignoring active transactions
  • Failing to save configuration files
  • Not checking the MariaDB error log
  • Skipping application smoke tests
  • Changing database parameters during the same maintenance window
  • Considering a successful package installation as complete validation

Interview Questions

  1. What is the difference between a minor and major MariaDB upgrade?
  2. Why should mariadb-backup be prepared before restore?
  3. What checks should be performed before upgrading MariaDB?
  4. Why should the MariaDB repository be verified before package installation?
  5. What does mariadb-upgrade do?
  6. How do you validate InnoDB after an upgrade?
  7. Why should application services be stopped before upgrading?
  8. What is the safest rollback strategy?
  9. Which logs should be reviewed after MariaDB startup?
  10. How do you compare database configuration before and after an upgrade?

Conclusion

A successful MariaDB upgrade is built around preparation, backup, controlled execution, validation and rollback readiness. The actual package installation is only one small part of the complete DBA activity.

The safest upgrade formula is: 

Prechecks
+ Tested Backup
+ Controlled Change
+ Post-Upgrade Validation
+ Monitoring
+ Rollback Plan

Never release the production environment only because the MariaDB service started. Confirm database integrity, application functionality, performance and recovery readiness.

Official References

```
Posted by at
Labels:

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)