MariaDB is an open-source relational database management system forked from MySQL. It delivers full SQL compatibility, strong performance, and active community development – making it a solid choice for production database workloads on any Linux distribution. MariaDB 11.8 LTS is the current long-term support release, bringing native vector search support, utf8mb4 as the default character set, extended timestamp range beyond 2038, and improved JSON path expressions.
This guide walks through installing MariaDB on openSUSE Leap 16.0 and openSUSE Tumbleweed using the default zypper repositories. We cover securing the installation, configuring remote access, creating databases and users, firewall rules, binary logging for replication, backups with mariadb-dump, and performance tuning for production use.
Prerequisites
- A server or VM running openSUSE Leap 16.0 or openSUSE Tumbleweed
- Root access or a user with sudo privileges
- At least 1 GB RAM (2 GB+ recommended for production)
- Port 3306/TCP open if remote clients need to connect
Step 1: Install MariaDB on openSUSE
openSUSE Leap 16.0 and Tumbleweed ship MariaDB in the default repositories, so no extra repo configuration is needed. Refresh the package index and install MariaDB server along with the client tools.
sudo zypper refreshInstall the MariaDB server and client packages.
sudo zypper install mariadb mariadb-client mariadb-toolsConfirm the installation by checking the installed version.
mariadb --versionYou should see the MariaDB version string confirming a successful install:
mariadb Ver 15.1 Distrib 11.8.6-MariaDB, for Linux (x86_64) using readline 5.1Step 2: Start and Enable the MariaDB Service
After installation, start the MariaDB service and enable it to launch automatically at boot.
sudo systemctl enable --now mariadbVerify the service is running.
sudo systemctl status mariadbThe output should show active (running) with the MariaDB process listening on port 3306:
● mariadb.service - MariaDB 11.8.6 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; preset: disabled)
Active: active (running) since Sun 2026-03-22 10:15:30 UTC; 5s ago
Main PID: 1234 (mariadbd)
Status: "Taking your SQL requests now..."
Tasks: 8 (limit: 4915)
Memory: 78.5M
CGroup: /system.slice/mariadb.service
└─1234 /usr/sbin/mariadbdStep 3: Secure the MariaDB Installation
MariaDB ships with a security script that sets the root password, removes anonymous users, disables remote root login, and drops the test database. Run it immediately after starting the service.
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]: YAfter completing the script, test the root login. With unix_socket authentication enabled, the root system user can connect without a password prompt.
sudo mariadb -u rootYou should land in the MariaDB monitor prompt:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 10
Server version: 11.8.6-MariaDB openSUSE package
MariaDB [(none)]>Type EXIT; to return to the shell.
Step 4: Configure MariaDB for Remote Access
By default, MariaDB binds to localhost only. To allow connections from remote application servers or database clients, update the bind address in the MariaDB configuration directory at /etc/my.cnf.d/.
Create a custom configuration file to override the default bind address.
sudo vi /etc/my.cnf.d/remote-access.cnfAdd the following configuration to bind MariaDB to all network interfaces:
[mysqld]
bind-address = 0.0.0.0If you want MariaDB to listen on a specific IP address instead, replace 0.0.0.0 with that address. Restart MariaDB to apply the change.
sudo systemctl restart mariadbConfirm MariaDB is now listening on all interfaces by checking port 3306.
ss -tlnp | grep 3306The output should show MariaDB bound to 0.0.0.0:3306:
LISTEN 0 80 0.0.0.0:3306 0.0.0.0:* users:(("mariadbd",pid=1234,fd=21))Step 5: Create Databases and Users in MariaDB
With the server running and secured, create a database and a dedicated application user. Never use the root account for application connections – always create a specific user with limited privileges.
Connect to MariaDB as root.
sudo mariadb -u rootCreate a new database for your application.
CREATE DATABASE appdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;Create a user that can connect from a specific application server IP. Replace 10.0.1.50 with your application server address and set a strong password.
CREATE USER 'appuser'@'10.0.1.50' IDENTIFIED BY 'StrongPassword123!';Grant the user full privileges on the application database only.
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'10.0.1.50';
FLUSH PRIVILEGES;Verify the grants are applied correctly.
SHOW GRANTS FOR 'appuser'@'10.0.1.50';The output confirms the user has full access to the appdb database:
+------------------------------------------------------+
| Grants for [email protected] |
+------------------------------------------------------+
| GRANT USAGE ON *.* TO `appuser`@`10.0.1.50` |
| GRANT ALL PRIVILEGES ON `appdb`.* TO `appuser`@`10.0.1.50` |
+------------------------------------------------------+If you need a user that can connect from any host (less secure, but useful for development), use the % wildcard.
CREATE USER 'devuser'@'%' IDENTIFIED BY 'DevPassword456!';
GRANT ALL PRIVILEGES ON appdb.* TO 'devuser'@'%';
FLUSH PRIVILEGES;Type EXIT; to leave the MariaDB prompt.
Step 6: Configure Firewall for MariaDB (Port 3306)
openSUSE uses firewalld by default. If you configured remote access in the previous step, open TCP port 3306 in the firewall so external clients can reach MariaDB.
sudo firewall-cmd --permanent --add-port=3306/tcp
sudo firewall-cmd --reloadVerify the port is open.
sudo firewall-cmd --list-portsYou should see 3306/tcp in the list of allowed ports:
3306/tcpFor a more restrictive setup, allow connections only from a specific subnet instead of opening the port to everyone.
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.1.0/24" port protocol="tcp" port="3306" accept'
sudo firewall-cmd --reloadTest connectivity from the remote client machine to confirm the firewall and bind address are both configured correctly.
mariadb -h 10.0.1.10 -u appuser -p appdbStep 7: Enable Binary Logging for Replication
Binary logging records all data-modifying SQL statements. This is required for MariaDB replication and also provides point-in-time recovery capability. Even if you are not running replicas today, enabling binary logs is a good practice for any production database.
Create a configuration file for binary logging.
sudo vi /etc/my.cnf.d/binlog.cnfAdd the following settings:
[mysqld]
# Binary logging for replication and point-in-time recovery
log_bin = /var/log/mysql/mariadb-bin
server_id = 1
binlog_format = ROW
expire_logs_days = 7
max_binlog_size = 100MThe server_id must be unique across all servers in a replication topology. The ROW format records actual row changes, which is the most reliable format for replication. Binary logs older than 7 days are purged automatically to prevent disk space issues.
Create the binary log directory and set ownership.
sudo mkdir -p /var/log/mysql
sudo chown mysql:mysql /var/log/mysqlRestart MariaDB to activate binary logging.
sudo systemctl restart mariadbVerify binary logging is active.
sudo mariadb -u root -e "SHOW VARIABLES LIKE 'log_bin';"The value should show ON:
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin | ON |
+---------------+-------+For a full primary-replica replication setup, see our guide on configuring MariaDB replication.
Step 8: Backup MariaDB Databases with mariadb-dump
Regular backups are non-negotiable for any production database. The mariadb-dump utility creates logical SQL backups that are portable and easy to restore. For large databases, consider mariadb-backup (Mariabackup) for hot physical backups.
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 ensures a consistent snapshot for InnoDB tables without locking. The --routines and --triggers flags include stored procedures and triggers in the dump.
Dump all databases at once.
sudo mariadb-dump -u root --all-databases --single-transaction --routines --triggers | gzip > /backup/all_databases_$(date +%F).sql.gzTo restore a backup, decompress and pipe it into the MariaDB client.
gunzip < /backup/appdb_2026-03-22.sql.gz | sudo mariadb -u root appdbCreate the backup directory if it does not exist.
sudo mkdir -p /backupFor automated daily backups, add a cron job.
sudo crontab -eAdd this line to run a full backup every day at 2:00 AM and keep backups for 14 days:
0 2 * * * /usr/bin/mariadb-dump -u root --all-databases --single-transaction --routines --triggers | gzip > /backup/all_databases_$(date +\%F).sql.gz && find /backup -name "*.sql.gz" -mtime +14 -deleteStep 9: MariaDB Performance Tuning on openSUSE
The default MariaDB configuration works for development, but production workloads need tuning. The two most impactful settings are the InnoDB buffer pool size and max connections. Create a dedicated tuning configuration file.
sudo vi /etc/my.cnf.d/tuning.cnfAdd the following performance settings - adjust values based on your server's available RAM and expected workload:
[mysqld]
# InnoDB buffer pool - set to 50-70% of total RAM for a dedicated DB server
# For a server with 4 GB RAM:
innodb_buffer_pool_size = 2G
# Number of buffer pool instances (1 per GB of buffer pool, max 64)
innodb_buffer_pool_instances = 2
# InnoDB log file size - larger values improve write performance
innodb_log_file_size = 512M
# Flush method - O_DIRECT avoids double buffering with OS page cache
innodb_flush_method = O_DIRECT
# Max connections - default is 151, adjust based on your application needs
max_connections = 300
# Thread cache - reduces overhead of creating new threads per connection
thread_cache_size = 50
# Query cache is disabled by default in 11.8 - do not enable it
# query_cache_type = OFF
# Temp table size and max heap table size should match
tmp_table_size = 64M
max_heap_table_size = 64M
# Sort and join buffers - per-connection memory, keep conservative
sort_buffer_size = 4M
join_buffer_size = 4M
# Table open cache - increase if you have many tables
table_open_cache = 4000
# Log slow queries for optimization
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow-query.log
long_query_time = 2The InnoDB buffer pool is the single most important tuning parameter. It caches table data and indexes in memory. On a dedicated database server, allocate 50-70% of total RAM to this setting. On a shared server where MariaDB runs alongside web services, keep it at 25-40% of RAM.
The following table summarizes recommended buffer pool sizes based on available RAM:
| Server RAM | Dedicated DB Server | Shared Server |
|---|---|---|
| 2 GB | 1 GB | 512 MB |
| 4 GB | 2-3 GB | 1 GB |
| 8 GB | 5-6 GB | 2-3 GB |
| 16 GB | 10-12 GB | 4-6 GB |
| 32 GB | 20-24 GB | 8-12 GB |
Restart MariaDB to apply all tuning changes.
sudo systemctl restart mariadbVerify the buffer pool size and other settings took effect.
sudo mariadb -u root -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"The value should reflect the configured size (2 GB = 2147483648 bytes):
+-------------------------+------------+
| Variable_name | Value |
+-------------------------+------------+
| innodb_buffer_pool_size | 2147483648 |
+-------------------------+------------+To monitor current connection usage and identify if you need to adjust max_connections, run this query periodically.
sudo mariadb -u root -e "SHOW STATUS LIKE 'Max_used_connections';"If Max_used_connections is close to max_connections, increase the limit. If it stays well below, you can reduce it to free memory for the buffer pool. For ongoing database monitoring with Prometheus, set up the MySQL exporter to track these metrics over time.
Conclusion
You now have MariaDB 11.8 LTS running on openSUSE with a secured installation, remote access configured, databases and users created, firewall rules in place, binary logging enabled, automated backups, and performance tuning applied. This setup covers most production requirements for web applications and internal services.
For production hardening, consider setting up MariaDB Galera Cluster with HAProxy for high availability, enabling SSL/TLS encryption for client connections, and shipping binary logs to offsite storage for disaster recovery.
