Setting Up MariaDB Replication Across 3 Nodes with MaxScale

Introduction

In modern production environments, demand for more than basic database reliability. They require high availability, scalability, and the ability to upgrade safely with minimal downtime. This blog explains, step by step, how to:

• Configure MariaDB 10.5.27 replication
• Add High Availability (HA) using MariaDB MaxScale
• Perform a safe upgrade from MariaDB 10.5.27 to 11.4.4 with minimal downtime

1. Architecture Overview

Components

• Primary (Master): MariaDB 10.5.27–handles all write operations
• Replica (Slave): MariaDB 10.5.27 –mirrors data, serves reads
• MaxScale: Acts as a proxy, router, and HA controller

High-Level Architecture

 Key Benefit: MaxScale continuously monitors both MariaDB nodes and automatically redirects application traffic during failures, eliminating manual intervention.

2. Prerequisites :

• 3 Linux servers (RHEL/CentOS/Rocky/Ubuntu) with MariaDB
• MariaDB 10.5.27 is installed on all DB nodes
• MaxScale is installed on a separate server (recommended)
• Root or sudo access on all servers
• Time synchronization enabled (NTP)
• Firewall ports open:
  • 3306 (MariaDB)
  • 8989 (MaxScale REST API)

3.MariaDB Replication Setup (10.5.27)

Step 1: Configure Primary Server

Edit your MariaDB configuration file:

• Edit /etc/my.cnf or /etc/my.cnf.d/server.cnf:

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

Restart MariaDB to apply changes:

systemctl restart mariadb

Step 2: Create Replication User

Connect to the primary and create a dedicated replication user:

Create replication user:
CREATE USER 'repl'@'%' IDENTIFIED BY 'repl_pass';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

Step 3: Capture Binlog Position

Record the current binlog file and position:

SHOW MASTER STATUS;

Note: With GTID enabled, you don’t strictly need to track the binlog position, but it’s good practice to record it.

Step 4: Configure Replica Server

Edit the replica’s configuration file:

[mysqld]
server-id=2
read_only=ON

Restart MariaDB:

systemctl restart mariadb

Step 5: Configure Replication on Replica

Connect to the replica and configure the replication source:

CHANGE MASTER TO
MASTER_HOST='PRIMARY_IP',
MASTER_USER='repl',
MASTER_PASSWORD='repl_pass',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=XXXX;
START SLAVE;

Verify replication status:

SHOW SLAVE STATUS

Success indicators:

• Slave_IO_Running: Yes
• Slave_SQL_Running: Yes

Similarly , add the third node as a replica to the cluster.

Conclusion

MariaDB 10.5.27 replication setup using binary logs provides a reliable asynchronous data synchronization mechanism for production environments. Proper configuration of log_bin, server-id, and consistent backup initialization ensures accurate replication between primary and replica. Continuous monitoring of SHOW SLAVE STATUS\G is essential to track replication health and identify lag or errors.

From a DBA standpoint, optimizing queries, avoiding long transactions, and maintaining proper indexing help reduce replication delay. Implementing security best practices like SSL and least-privileged replication users strengthens the setup. Regular backup validation and failover testing are critical for high availability.

Overall, a stable replication environment depends not just on setup, but on proactive monitoring, performance tuning, and operational discipline.