Setting Up MariaDB MaxScale Binlog Proxy for backup/failover

 

Setting Up MariaDB MaxScale Binlog Proxy

MariaDB MaxScale Binlog Server acts as an intermediate master replication proxy. By storing binary logs and serving them to replicas, it enables scalable replication architectures, reduces primary database load, and accelerates disaster recovery.

Step 1: Install MariaDB MaxScale

Install MaxScale using the package manager appropriate for your Linux distribution, then verify the installation.

On Ubuntu/Debian:

sudo apt-get update
sudo apt-get install maxscale

On RHEL/CentOS:

sudo yum install maxscale

Verify the installation:

maxscale --version

Step 2: Configure MaxScale as a Binlog Proxy

Open MaxScale's core configuration file to establish the routing properties and specify your database backend configuration.

sudo nano /etc/maxscale.cnf

Add the following configurations for the monitor block and the binlog router service:

[maxscale]
threads=4

[Replication-Monitor]
type=monitor
module=mariadbmon
servers=primary-db,replica-db1,replica-db2
user=maxscale
password=maxpass
monitor_interval=10000
auto_failover=true

[Binlog-Server]
type=service
router=binlogrouter
servers=primary-db
user=maxscale
password=maxpass
filestem=binlog
binlogdir=/var/lib/maxscale/binlogs
gtid_strict_mode=on

Key parameters defined above:

• router=binlogrouter: Directs MaxScale to act explicitly as a binlog proxy proxying system.
• binlogdir: The dedicated storage directory where MaxScale caches binary logs locally.

Step 3: Set Up Users on the Primary Database

Access the primary database instance to provision administrative credentials and replication authority to MaxScale.

mysql -u root -p

Execute the following queries to create the proxy user account and apply capabilities:

CREATE USER 'maxscale'@'%' IDENTIFIED BY 'maxpass';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'maxscale'@'%';
FLUSH PRIVILEGES;

Step 4: Start and Enable MaxScale

Register MaxScale with the system init daemon to start automatically upon booting, then initiate the runtime service process.

sudo systemctl enable maxscale
sudo systemctl start maxscale
sudo systemctl status maxscale

Step 5: Configure Replica Servers to Use MaxScale

Log into each of your target replica database nodes. Point their data-fetching routes directly to your MaxScale proxy instance instead of targeting the primary database node infrastructure directly.

CHANGE MASTER TO
    MASTER_HOST='maxscale-server-ip',
    MASTER_PORT=3306,
    MASTER_USER='maxscale',
    MASTER_PASSWORD='maxpass',
    MASTER_LOG_FILE='binlog.000001',
    MASTER_LOG_POS=4;

START SLAVE;

Verify that your data stream pipeline status reflects normal active operation:

SHOW SLAVE STATUS\G;

Conclusion: Implementing the MariaDB MaxScale Binlog Proxy architecture successfully insulates your primary production database against high-volume read replica scaling loads, provides a robust localized binlog caching layer for fast disaster recovery, and automates high-availability database cluster failovers.