MariaDB is a community-driven, open-source relational database that evolved from MySQL. It delivers full SQL compliance, rich storage engine support, and strong performance for both transactional and analytical workloads. This guide walks through installing MariaDB on Rocky Linux 10, AlmaLinux 10, and RHEL 10 – covering both the distribution-provided AppStream package (MariaDB 10.11) and the latest LTS release from MariaDB.org (currently 11.8 LTS). We also cover securing the installation, setting up remote access, creating databases and users, configuring the firewall, enabling binary logging, backups, and basic performance tuning.
Prerequisites
- A server or VM running Rocky Linux 10, AlmaLinux 10, or RHEL 10
- Root or sudo access
- At least 1 GB RAM (2 GB+ recommended for production)
- Firewall access to TCP port 3306 if remote clients need to connect
Step 1: Install MariaDB from AppStream Repository
Rocky Linux 10, AlmaLinux 10, and RHEL 10 ship MariaDB 10.11 in the default AppStream repository. This is the simplest path – no extra repos needed and you get security patches through your OS vendor.
Install the MariaDB server and client packages.
sudo dnf install mariadb-server mariadb -yAfter installation completes, verify the installed version.
mariadb --versionThe output confirms MariaDB 10.11 from the AppStream repository:
mariadb Ver 15.1 Distrib 10.11.16-MariaDB, for Linux (x86_64) using EditLine wrapperIf you need a newer version with features like enhanced replication, improved JSON functions, and SSL enabled by default, proceed to Step 2 instead. Otherwise, skip to Step 3.
Step 2: Install MariaDB from the Official MariaDB.org Repository
The official MariaDB repository provides the latest LTS releases – currently MariaDB 11.8 (LTS, supported with bug and security fixes until June 2028) and 11.4 (LTS, supported until May 2029). Choose 11.8 for the newest features or 11.4 for maximum long-term stability. This section installs 11.8.
First, remove any existing AppStream MariaDB packages to avoid conflicts.
sudo dnf remove mariadb-server mariadb -yCreate the MariaDB repository file.
sudo vi /etc/yum.repos.d/MariaDB.repoAdd the following repository configuration for MariaDB 11.8 on RHEL 10:
[mariadb]
name = MariaDB
baseurl = https://rpm.mariadb.org/11.8/rhel/$releasever/$basearch
gpgkey = https://rpm.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck = 1
module_hotfixes = 1To install MariaDB 11.4 LTS instead, replace 11.8 with 11.4 in the baseurl line.
Install MariaDB server and client from the official repository.
sudo dnf install MariaDB-server MariaDB-client MariaDB-backup -yNote the capitalized package names – the official MariaDB repository uses MariaDB-server (capital M) while the AppStream packages use mariadb-server (lowercase).
Confirm the installed version.
mariadb --versionYou should see the 11.8 series version confirmed:
mariadb Ver 15.1 Distrib 11.8.6-MariaDB, for Linux (x86_64) using EditLine wrapperStep 3: Start and Enable MariaDB Service
Start the MariaDB service and enable it to launch automatically on boot.
sudo systemctl enable --now mariadbVerify the service is running.
sudo systemctl status mariadbThe output should show the service as active (running):
● mariadb.service - MariaDB 11.8.6 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; preset: disabled)
Active: active (running) since Sat 2026-03-22 10:15:00 UTC; 5s ago
Main PID: 12345 (mariadbd)
Status: "Taking your SQL requests now..."
Tasks: 12 (limit: 23456)
Memory: 80.0M
CPU: 250ms
CGroup: /system.slice/mariadb.service
└─12345 /usr/sbin/mariadbdStep 4: Secure MariaDB Installation
MariaDB ships with insecure defaults – no root password, test databases, and anonymous users. The mariadb-secure-installation script fixes all of this in one pass.
sudo mariadb-secure-installationThe script walks through several prompts. Here are the recommended answers for a production setup:
Enter current password for root (enter for none): [Press Enter]
Switch to unix_socket authentication [Y/n]: Y
Change the root password? [Y/n]: Y
New password: [Enter a strong password]
Re-enter new password: [Confirm password]
Remove anonymous users? [Y/n]: Y
Disallow root login remotely? [Y/n]: Y
Remove test database and access to it? [Y/n]: Y
Reload privilege tables now? [Y/n]: YWith unix_socket authentication enabled, the root user authenticates through the OS socket – no password needed when running as root or with sudo. This is more secure than password-based root login because it ties database access to OS-level permissions.
Verify you can connect to the database.
sudo mariadb -u root -e "SELECT VERSION();"This should return the MariaDB version without prompting for a password:
+-------------------+
| VERSION() |
+-------------------+
| 11.8.6-MariaDB |
+-------------------+Step 5: Configure Remote Access
By default, MariaDB listens only on localhost (127.0.0.1). To allow remote client connections, you need to change the bind address.
Open the MariaDB server configuration file.
sudo vi /etc/my.cnf.d/server.cnfUnder the [mysqld] section, set the bind address. Use 0.0.0.0 to listen on all interfaces, or specify a particular IP address:
[mysqld]
bind-address = 0.0.0.0Restart MariaDB to apply the change.
sudo systemctl restart mariadbVerify MariaDB is now listening on all interfaces by checking port 3306.
ss -tlnp | grep 3306The output should show MariaDB listening on 0.0.0.0:3306:
LISTEN 0 80 0.0.0.0:3306 0.0.0.0:* users:(("mariadbd",pid=12345,fd=22))Step 6: Create Databases and Users
With MariaDB running and secured, create application databases and dedicated users. Never let applications connect as root – always create purpose-specific accounts with the minimum privileges needed.
Connect to the MariaDB shell.
sudo mariadb -u rootCreate a database, a user with a strong password, and grant full privileges on that database. Replace the values with your actual database name, username, and password:
CREATE DATABASE appdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'appuser'@'%' IDENTIFIED BY 'StrongPassword123!';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'%';
FLUSH PRIVILEGES;The '%' wildcard allows connections from any host. For tighter security, replace it with a specific IP address or subnet – for example 'appuser'@'10.0.1.%' to allow connections only from the 10.0.1.0/24 network.
Verify the user and grants were created correctly.
SHOW GRANTS FOR 'appuser'@'%';
EXIT;The output confirms the privileges assigned to the user:
+--------------------------------------------------------------------------------------------------------------+
| Grants for appuser@% |
+--------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `appuser`@`%` IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19' |
| GRANT ALL PRIVILEGES ON `appdb`.* TO `appuser`@`%` |
+--------------------------------------------------------------------------------------------------------------+Test the connection from a remote machine or from the same server using the new credentials. If you have the MariaDB client installed on your workstation, connect with the -h flag pointing to the server IP:
mariadb -u appuser -p -h 10.0.1.50 appdbStep 7: Configure Firewall for MariaDB
If you enabled remote access in Step 5, the firewall must allow incoming connections on TCP port 3306. Rocky Linux 10, AlmaLinux 10, and RHEL 10 use firewalld by default. If you manage your MariaDB databases through phpMyAdmin, you will also need web server ports open.
Add the MariaDB service to the firewall and reload the rules.
sudo firewall-cmd --permanent --add-service=mysql
sudo firewall-cmd --reloadVerify the rule was applied.
sudo firewall-cmd --list-servicesYou should see mysql in the list of allowed services:
cockpit dhcpv6-client mysql sshTo restrict database access to a specific subnet instead of allowing all sources, use a rich rule:
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.1.0/24" port port="3306" protocol="tcp" accept'
sudo firewall-cmd --reloadStep 8: Enable Binary Logging
Binary logging records all data-changing statements executed on the server. You need it for point-in-time recovery, replication to replica servers, and auditing. It is disabled by default on standalone installations.
Open the server configuration file.
sudo vi /etc/my.cnf.d/server.cnfAdd the following binary logging settings under the [mysqld] section:
[mysqld]
log-bin = /var/log/mariadb/mariadb-bin
binlog_format = ROW
expire_logs_days = 14
max_binlog_size = 512M
server-id = 1Create the binary log directory and set ownership.
sudo mkdir -p /var/log/mariadb
sudo chown mysql:mysql /var/log/mariadbRestart MariaDB to activate binary logging.
sudo systemctl restart mariadbVerify binary logging is enabled by checking the server variable.
sudo mariadb -u root -e "SHOW VARIABLES LIKE 'log_bin';"The value should show ON:
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin | ON |
+---------------+-------+You can view the current binary log files with the following query:
sudo mariadb -u root -e "SHOW BINARY LOGS;"The ROW format records actual row changes rather than SQL statements, which is safer for replication and produces deterministic results. The expire_logs_days = 14 setting automatically purges binary logs older than 14 days to prevent disk fill. Adjust the retention period based on your backup schedule – ensure binary logs cover at least the gap between your last two full backups.
Step 9: Back Up Databases with mariadb-dump
Regular backups are non-negotiable for any production database. The mariadb-dump utility creates logical SQL dumps that you can restore on any MariaDB version. For backing up MySQL or MariaDB databases to external storage, you can also ship backups to Amazon S3.
Dump a single database to a compressed SQL file.
sudo mariadb-dump -u root --single-transaction --routines --triggers appdb | gzip > /backup/appdb_$(date +%F).sql.gzThe --single-transaction flag takes a consistent snapshot without locking tables (InnoDB only). The --routines and --triggers flags include stored procedures, functions, and triggers in the dump.
To dump all databases at once:
sudo mariadb-dump -u root --all-databases --single-transaction --routines --triggers | gzip > /backup/all_databases_$(date +%F).sql.gzRestore a database from a dump file.
gunzip < /backup/appdb_2026-03-22.sql.gz | sudo mariadb -u root appdbFor production environments, create a backup directory and set up a daily cron job.
sudo mkdir -p /backup
sudo chown mysql:mysql /backupAdd a cron entry to run nightly backups at 2:00 AM:
sudo crontab -eAdd the following line to the crontab:
0 2 * * * /usr/bin/mariadb-dump -u root --all-databases --single-transaction --routines --triggers | /usr/bin/gzip > /backup/all_databases_$(date +\%F).sql.gz && find /backup -name "*.sql.gz" -mtime +7 -deleteThis backs up all databases nightly and automatically removes backup files older than 7 days.
Step 10: Performance Tuning - InnoDB Buffer Pool
The InnoDB buffer pool is the single most impactful performance setting in MariaDB. It caches table data and indexes in memory, reducing disk I/O dramatically. By default it is set to 128 MB, which is far too small for any production workload.
The general rule: set innodb_buffer_pool_size to 50-70% of total system RAM on a dedicated database server. On a shared server, allocate what you can spare while leaving enough for the OS and other services. For database performance monitoring, consider setting up Prometheus monitoring for MariaDB to track buffer pool hit rates and query performance.
Open the server configuration file.
sudo vi /etc/my.cnf.d/server.cnfAdd or update the following InnoDB settings under the [mysqld] section. This example assumes a server with 4 GB RAM:
[mysqld]
# InnoDB buffer pool - set to 50-70% of total RAM
innodb_buffer_pool_size = 2G
innodb_buffer_pool_instances = 2
# InnoDB log settings
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 1
innodb_flush_method = O_DIRECT
# Connection and thread settings
max_connections = 200
thread_cache_size = 16
# Temp table settings
tmp_table_size = 64M
max_heap_table_size = 64M
# Query cache (disable for MariaDB 11.x - optimizer handles this)
query_cache_type = 0Here is what each setting does:
innodb_buffer_pool_size = 2G- caches data and indexes in memory. Larger values mean fewer disk readsinnodb_buffer_pool_instances = 2- splits the buffer pool into multiple instances to reduce lock contention. Use 1 instance per GB of buffer poolinnodb_log_file_size = 512M- larger redo logs improve write performance by reducing checkpoint frequencyinnodb_flush_log_at_trx_commit = 1- full ACID compliance, flushing the log to disk on every commit. Set to 2 for better performance with a small durability trade-offinnodb_flush_method = O_DIRECT- bypasses the OS file cache to avoid double buffering with the InnoDB buffer poolmax_connections = 200- adjust based on your application needs. Each connection consumes memory
Restart MariaDB to apply the tuning changes.
sudo systemctl restart mariadbVerify the buffer pool size was applied.
sudo mariadb -u root -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"The value should reflect the configured size (2147483648 bytes = 2 GB):
+--------------------------+------------+
| Variable_name | Value |
+--------------------------+------------+
| innodb_buffer_pool_size | 2147483648 |
+--------------------------+------------+After the server has been running under load for a while, check the buffer pool hit rate to see if the size is adequate.
sudo mariadb -u root -e "SHOW STATUS LIKE 'Innodb_buffer_pool_read%';"A healthy buffer pool has a hit rate above 99%. If Innodb_buffer_pool_reads (disk reads) is high relative to Innodb_buffer_pool_read_requests (total requests), increase the buffer pool size.
Conclusion
You now have MariaDB installed and configured on Rocky Linux 10, AlmaLinux 10, or RHEL 10 - whether from the AppStream repository (10.11) or the official MariaDB.org repository (11.8 LTS). The installation is secured, binary logging is active for point-in-time recovery, backups are automated, and the InnoDB buffer pool is tuned for your available memory. For a deeper look at backup strategies and restoring to a specific point in time using binary logs, see our MariaDB and PostgreSQL backup and PITR guide.
For production deployments, add SSL/TLS encryption for client connections, set up Galera Cluster for high availability, configure replication to a standby server, and integrate with a monitoring stack to track query latency, connection counts, and replication lag. Store backups offsite - a backup that lives on the same disk as the database is not a backup.
Hello friend
Your post is so helpful,it give me much help,thanks!
Thank you.