How to Configure MariaDB on Linux Server – (Step-by-Step Guide 2026)

To configure MariaDB on a Linux server in 2026, install the latest LTS build, run mysql_secure_installation, tune my.cnf for performance and security (InnoDB memory, logs, bind-address, TLS), create least-privilege users, enable backups and monitoring, and harden the firewall. The steps below include commands for Ubuntu, Debian, RHEL, AlmaLinux, and Rocky Linux.

Configuring MariaDB on a Linux server is straightforward when you follow a structured plan. This step-by-step guide shows you exactly how to install, secure, optimize, and maintain MariaDB with production-grade settings. You’ll learn how to tune my.cnf, harden access, create users, set up backups, and monitor performance using practical commands and proven configurations.

Who This Guide Is For

This tutorial is beginner-friendly but detailed enough for sysadmins. Whether you host on Ubuntu, Debian, AlmaLinux, Rocky, or RHEL, you’ll find commands for your distro and configurations that match real-world workloads.

Prerequisites and System Requirements

• Linux server with sudo/root access (Ubuntu 20.04/22.04/24.04, Debian 12, AlmaLinux/Rocky 8/9, RHEL 8/9)
• At least 2 GB RAM for light workloads; 4–8 GB+ for production databases
• Open ports: 22 (SSH), 3306 (MariaDB) — restrict with firewall or private network
• Accurate time sync (chrony or systemd-timesyncd)

Step 1 — Install MariaDB on Linux

Use your distribution’s package manager or the official MariaDB repository to install the latest stable LTS (as of 2026, MariaDB 10.6/10.11 LTS are commonly used). Prefer the vendor repo for timely security updates.

Ubuntu/Debian

sudo apt update
sudo apt install -y software-properties-common gnupg
# Optional: add official MariaDB repo for newer builds (adjust version if needed)
sudo apt-key adv --fetch-keys 'https://mariadb.org/mariadb_release_signing_key.asc'
sudo add-apt-repository 'deb [arch=amd64,arm64] http://mirror.mariadb.org/repo/10.11/ubuntu jammy main'  # Example for Ubuntu 22.04
sudo apt update
sudo apt install -y mariadb-server mariadb-client

# Enable and start
sudo systemctl enable mariadb
sudo systemctl start mariadb

# Verify
mariadb --version
sudo systemctl status mariadb --no-pager

RHEL/AlmaLinux/Rocky

sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --set-enabled crb || true

# Optional: official MariaDB repo (adjust version and release)
sudo tee /etc/yum.repos.d/MariaDB.repo >/dev/null <<'EOF'
# MariaDB 10.11 (example)
[mariadb]
name = MariaDB
baseurl = https://mirror.mariadb.org/yum/10.11/rhel/$releasever/$basearch
gpgkey=https://mariadb.org/mariadb_release_signing_key.asc
gpgcheck=1
enabled=1
EOF

sudo dnf -y install MariaDB-server MariaDB-client

# Enable and start
sudo systemctl enable mariadb
sudo systemctl start mariadb

# Verify
mariadb --version
sudo systemctl status mariadb --no-pager

Step 2 — Secure the Installation

Run the built-in hardening script, set a strong root password, remove test databases, and disable remote root access.

sudo mysql_secure_installation

# Recommended choices:
# - Set root password: Yes (use a long, random passphrase)
# - Remove anonymous users: Yes
# - Disallow root login remotely: Yes
# - Remove test database and access: Yes
# - Reload privilege tables: Yes

On modern MariaDB builds, the root user may authenticate via unix_socket on localhost, which is safe. If you change to password-based auth, ensure you use strong credentials and SSH tunneling or private networking for administration.

Step 3 — Know Your MariaDB Configuration Files

MariaDB reads multiple configuration files. The primary file is my.cnf, but includes let you split configs by purpose (server, client, performance, replication).

• Global: /etc/mysql/my.cnf (Ubuntu/Debian) or /etc/my.cnf (RHEL family)
• Included directories: /etc/mysql/mariadb.conf.d/, /etc/mysql/conf.d/ (Debian family) or /etc/my.cnf.d/ (RHEL family)
• Data directory: /var/lib/mysql/
• Logs: /var/log/mysql/ or /var/log/mariadb/

Use a dedicated file like /etc/mysql/mariadb.conf.d/50-server.cnf (Debian) or /etc/my.cnf.d/server.cnf (RHEL) to keep server tuning clean.

Step 4 — Tune Core Settings (Performance + Safety)

The most impactful tuning focuses on InnoDB memory, I/O, and connection limits. The examples below fit typical web apps; always benchmark and adjust for your workload.

Memory (InnoDB)

• innodb_buffer_pool_size: 60–70% of RAM on a dedicated DB server
• innodb_buffer_pool_instances: 1–8 depending on buffer size (start with 1 for ≤8GB)
• innodb_log_file_size: 512M–2G for write-heavy workloads

# /etc/mysql/conf.d/99-tuning.cnf or /etc/my.cnf.d/99-tuning.cnf
[mysqld]
# Memory
innodb_buffer_pool_size = 4G
innodb_buffer_pool_instances = 1
innodb_log_file_size = 1G
innodb_log_buffer_size = 256M

# General
max_connections = 300
table_open_cache = 8000
thread_cache_size = 100

# Character set
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci

# Slow query log
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

# Binary logging (required for PITR/replication)
server_id = 1
log_bin = /var/log/mysql/mariadb-bin
binlog_format = ROW
expire_logs_days = 7

# Networking
bind-address = 127.0.0.1
# If you must expose externally, bind to private IP and firewall it:
# bind-address = 10.0.0.10

After editing, restart MariaDB:

sudo systemctl restart mariadb
sudo mariadb -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

Logs and I/O

• Place logs on fast storage and monitor disk space
• Enable slow query log to surface missing indexes
• Use ROW binlog format for consistency; adjust expire_logs_days based on backup retention

Connections and Timeouts

• max_connections: Size this realistically; high values magnify RAM usage
• wait_timeout: Reduce for web apps (e.g., 60–120) to clean idle connections
• thread_cache_size: Helps reuse threads under bursty traffic

[mysqld]
wait_timeout = 120
interactive_timeout = 120
thread_cache_size = 100

Avoid relying on the legacy Query Cache; many builds keep it disabled due to contention. Focus on indexing and buffer pool sizing.

Step 5 — Create Databases, Users, and Least-Privilege Access

Create separate users per application with only the permissions they need. Do not use root for applications.

# Login as root (socket auth)
sudo mariadb

# Create database and user with strong password
CREATE DATABASE appdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'REPLACE_WITH_LONG_RANDOM_PASSWORD';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX ON appdb.* TO 'appuser'@'localhost';
FLUSH PRIVILEGES;

# Test login
mariadb -u appuser -p -e "SHOW GRANTS FOR 'appuser'@'localhost';"

Step 6 — Harden Network and Access Security

• Bind to localhost or private IP only (bind-address)
• Use a firewall (UFW, firewalld) to restrict 3306 to trusted hosts
• Prefer SSH tunnels or VPN for remote administration
• Enable TLS for client connections if exposed to untrusted networks

# UFW (Ubuntu/Debian)
sudo ufw allow OpenSSH
sudo ufw allow from 10.0.0.0/24 to any port 3306 proto tcp
sudo ufw enable
sudo ufw status

# firewalld (RHEL/AlmaLinux/Rocky)
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.0/24" port protocol="tcp" port="3306" accept'
sudo firewall-cmd --reload

For TLS, generate server certificates and point to them in my.cnf (ssl_cert, ssl_key). Then require SSL per user or globally.

[mysqld]
ssl_cert = /etc/mysql/ssl/server-cert.pem
ssl_key  = /etc/mysql/ssl/server-key.pem
ssl_ca   = /etc/mysql/ssl/ca.pem

# Example: require SSL for a user
GRANT SELECT ON appdb.* TO 'appuser'@'10.%' REQUIRE SSL;

Step 7 — Backups and Point-in-Time Recovery (PITR)

Use mariabackup for hot physical backups and mysqldump for logical, schema-level backups. Retain binary logs to roll forward changes.

# Install backup tool (if not included)
sudo apt install -y mariadb-backup || sudo dnf install -y MariaDB-backup

# Full hot backup
sudo mariabackup --backup --target-dir=/backups/full-$(date +%F) --user=root

# Prepare (apply redo logs) and restore test
sudo mariabackup --prepare --target-dir=/backups/full-2026-01-01

# Logical backup (for migrations)
mysqldump --single-transaction --routines --triggers --events appdb | gzip > /backups/appdb-$(date +%F).sql.gz

Automate backups with cron/systemd timers and verify restores regularly. Store copies offsite to protect against server loss or ransomware.

Step 8 — Monitoring and Troubleshooting

• Enable slow query log and fix high-latency queries with indexes
• Use mysqltuner or mdb_stat_tools for quick heuristics (review suggestions carefully)
• Check performance schema, SHOW ENGINE INNODB STATUS\G for locks and I/O
• Export metrics to Prometheus/Grafana via exporters for long-term trending

# Quick health
sudo mariadb -e "SHOW GLOBAL STATUS LIKE 'Threads_connected';"
sudo mariadb -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

# Install MySQLTuner (heuristic tool)
sudo apt install -y mysqltuner || sudo dnf install -y mysqltuner
sudo mysqltuner

Step 9 — Optional: Basic Replication Setup

Replication improves read scalability and availability. Use Row-Based Logging and GTID (if supported in your chosen MariaDB LTS) to simplify failover.

# On primary (ensure binary logging enabled)
[mysqld]
server_id = 1
log_bin = /var/log/mysql/mariadb-bin
binlog_format = ROW

# Create a replication user
CREATE USER 'repl'@'10.%' IDENTIFIED BY 'REPLACE_STRONG_PASSWORD';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.%';
FLUSH PRIVILEGES;

# Get a consistent snapshot
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
# Take a backup now; then UNLOCK TABLES;

# On replica
[mysqld]
server_id = 2
relay_log = /var/log/mysql/relay-bin

# Initialize from primary backup, then:
CHANGE MASTER TO
  MASTER_HOST='10.0.0.10',
  MASTER_USER='repl',
  MASTER_PASSWORD='REPLACE_STRONG_PASSWORD',
  MASTER_LOG_FILE='mariadb-bin.000123',
  MASTER_LOG_POS=456789;

START SLAVE;
SHOW SLAVE STATUS\G

Common Pitfalls and Best Practices

• Do not expose 3306 to the internet; use private networking and firewalls
• Size innodb_buffer_pool_size based on RAM and monitor free memory
• Avoid overcommitting max_connections; use pooling at the application level
• Keep packages updated; schedule maintenance windows for major version upgrades
• Test backups and restores quarterly; practice PITR with binlogs
• Document changes in version-controlled config files and use staging to validate

FAQs: How to Configure MariaDB on Linux Server

Conclusion

Now you know how to configure MariaDB on a Linux server from zero to production: install, secure, tune my.cnf, manage users, lock down access, back up, and monitor. Start conservatively, measure, then iterate. With a solid baseline and disciplined maintenance, your MariaDB will stay fast, stable, and secure in 2026 and beyond.