MariaDB Primary-Replica Replication on Rocky Linux 10 [Guide]

MariaDB replication copies data from a primary server to one or more replica servers in real time. It provides high availability, read scaling, and a reliable disaster recovery path for production databases. MariaDB 11.4 LTS is the current long-term support release with maintenance until 2029.

This guide covers setting up MariaDB 11.4 LTS primary-replica replication on Rocky Linux 10 and AlmaLinux 10 using two servers. All commands work on both distributions.

Prerequisites

Two servers running Rocky Linux 10 or AlmaLinux 10 with root or sudo access
Primary server: 10.0.1.10
Replica server: 10.0.1.11
Network connectivity between both servers on port 3306/tcp
Firewalld running on both servers

Step 1: Install MariaDB 11.4 on Both Servers

Run these steps on both the primary (10.0.1.10) and replica (10.0.1.11) servers. The official MariaDB repository provides the latest 11.4 LTS packages for RHEL-based distributions.

Create the MariaDB 11.4 repository file:

sudo vi /etc/yum.repos.d/MariaDB.repo

Add the following content:

[mariadb]
name = MariaDB 11.4 LTS
baseurl = https://rpm.mariadb.org/11.4/rhel/$releasever/$basearch
gpgkey = https://rpm.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck = 1

Install MariaDB server and client packages:

sudo dnf install MariaDB-server MariaDB-client -y

Enable and start the MariaDB service:

sudo systemctl enable --now mariadb

Verify that MariaDB is running:

$ sudo systemctl status mariadb
● mariadb.service - MariaDB 11.4 database server
     Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; preset: disabled)
     Active: active (running)

Harden the installation by running the security script:

sudo mariadb-secure-installation

Answer Y to all prompts – set a root password, remove anonymous users, disallow remote root login, remove the test database, and reload privilege tables.

Confirm the installed version:

$ mariadb -u root -p -e "SELECT VERSION();"
+-------------------+
| VERSION()         |
+-------------------+
| 11.4.10-MariaDB   |
+-------------------+

Step 2: Configure the Primary Server

On the primary server (10.0.1.10), configure MariaDB for binary logging and assign a unique server ID. Open the MariaDB server configuration file:

sudo vi /etc/my.cnf.d/server.cnf

Add the following under the [mysqld] section:

[mysqld]
bind-address = 10.0.1.10
server-id = 1
log_bin = mysql-bin
binlog_format = ROW

Configuration breakdown:

bind-address – listen on the primary server’s IP so the replica can connect
server-id – unique integer identifying this server in the replication topology
log_bin – enables binary logging, which records all changes for the replica to replay
binlog_format – ROW format logs actual row changes, which is the safest for replication

Restart MariaDB to apply the changes:

sudo systemctl restart mariadb

Create a Replication User on the Primary

mariadb -u root -p

Run these SQL statements to create the replication user and grant the required privilege:

CREATE USER 'replicator'@'10.0.1.11' IDENTIFIED BY 'StrongReplicaP@ss1';
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'10.0.1.11';
FLUSH PRIVILEGES;

Replace StrongReplicaP@ss1 with a strong password of your choice. The user is restricted to connections from the replica IP (10.0.1.11) only.

Step 3: Open Firewall Port for MariaDB Replication

On the primary server, allow incoming connections on port 3306/tcp through firewalld:

sudo firewall-cmd --add-port=3306/tcp --zone=public --permanent
sudo firewall-cmd --reload

Verify the port is open:

$ sudo firewall-cmd --list-ports
3306/tcp

Step 4: Record Primary Binary Log Position

On the primary server, get the current binary log file name and position. The replica needs these values to know where to start reading changes.

mariadb -u root -p

Run the following SQL commands:

FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

Expected output:

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      663 |              |                  |
+------------------+----------+--------------+------------------+

Write down the File and Position values – you need them when configuring the replica. Keep this session open with the lock held until you finish the next step.

If you have existing databases that need to be replicated, dump them now while the tables are locked:

mariadb-dump -u root -p --all-databases --master-data > /tmp/primary_dump.sql

Copy the dump to the replica server:

scp /tmp/primary_dump.sql [email protected]:/tmp/

Then unlock the tables on the primary:

UNLOCK TABLES;

If you sent a database dump to the replica, import it before starting replication:

mariadb -u root -p < /tmp/primary_dump.sql

Step 5: Configure the Replica Server

On the replica server (10.0.1.11), open the server configuration file:

sudo vi /etc/my.cnf.d/server.cnf

Add the following under the [mysqld] section:

[mysqld]
bind-address = 10.0.1.11
server-id = 2
relay-log = relay-bin
read_only = 1

Configuration breakdown:

server-id - must be a different number from the primary (2 in this case)
relay-log - defines the relay log filename prefix where replicated events are stored before being applied
read_only - prevents accidental writes to the replica, keeping data consistent

Restart MariaDB on the replica:

sudo systemctl restart mariadb

Step 6: Start MariaDB Replication on Rocky Linux 10

On the replica server, log in to MariaDB and configure it to connect to the primary. Use the binary log file and position values from Step 4.

mariadb -u root -p

Stop any existing replica threads, then set the primary connection details:

STOP SLAVE;

CHANGE MASTER TO
  MASTER_HOST='10.0.1.10',
  MASTER_USER='replicator',
  MASTER_PASSWORD='StrongReplicaP@ss1',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=663;

START SLAVE;

Replace MASTER_LOG_FILE and MASTER_LOG_POS with the actual values from your SHOW MASTER STATUS output.

Step 7: Verify Replication Status

On the replica server, check the replication status:

SHOW SLAVE STATUS\G

The two key fields to check are:

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.0.1.10
                  Master_User: replicator
                  Master_Port: 3306
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
        Seconds_Behind_Master: 0

Both Slave_IO_Running and Slave_SQL_Running must show Yes. If either shows No, check the Last_IO_Error or Last_SQL_Error fields for details. Common issues include wrong credentials, firewall blocking port 3306, or incorrect log file/position values.

Step 8: Test Replication

Create a test database and table on the primary server to confirm data replicates to the replica.

On the primary server (10.0.1.10), log in and create test data:

mariadb -u root -p

Run these SQL statements:

CREATE DATABASE testdb;
USE testdb;
CREATE TABLE employees (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50), department VARCHAR(50));
INSERT INTO employees (name, department) VALUES ('Alice', 'Engineering'), ('Bob', 'Operations');

On the replica server (10.0.1.11), verify the database and data appeared:

mariadb -u root -p

Query the replicated data:

MariaDB [(none)]> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| testdb             |
+--------------------+

MariaDB [(none)]> SELECT * FROM testdb.employees;
+----+-------+-------------+
| id | name  | department  |
+----+-------+-------------+
|  1 | Alice | Engineering |
|  2 | Bob   | Operations  |
+----+-------+-------------+
2 rows in set (0.001 sec)

The test database and its data are visible on the replica, confirming that replication is working correctly. Clean up the test data on the primary when done:

DROP DATABASE testdb;

Troubleshooting MariaDB Replication

If replication breaks or falls behind, here are common fixes.

Replica not connecting - verify firewall on the primary allows port 3306, and test connectivity from the replica:

mariadb -h 10.0.1.10 -u replicator -p

SQL thread stopped with error - check the error, fix the underlying issue, then skip the problematic event if needed:

STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;

Replica too far behind - if Seconds_Behind_Master keeps growing, the replica may not have enough resources to keep up. Check disk I/O and consider enabling parallel replication by adding slave_parallel_threads = 4 to the replica's server.cnf.

SELinux blocking connections - if SELinux is enforcing and MariaDB cannot bind to a non-default address, allow it:

sudo setsebool -P mysql_connect_any 1

Conclusion

MariaDB 11.4 LTS primary-replica replication is now running between two Rocky Linux 10 servers. The replica receives all write operations from the primary in real time and can serve as a read-only node or a failover target.

For production environments, add SSL/TLS encryption to the replication channel with MASTER_SSL=1, set up automated MariaDB monitoring, and schedule regular backups of both servers using mariadb-backup.