Master servers under heavy replication load can become bottlenecks. This blog explores how Maxscale's binlog server functionality can alleviate this issue. By establishing Maxscale as a dedicated binlog server, you can significantly reduce the load on your master server and streamline replication processes.
This is the our next blog in Maxscale series, Below is a list of our previous blogs, which provides deep insight for Maxscale and its use cases for different architectures.
In this blog, we are going to discuss about Maxscale binlog server and the configuration.
In general, MySQL replication setup can be a single master server and with a set of slaves servers are configured to pull the binlog files from the master. It will create a lot of load on the master while all the slaves are trying to access the binlog files.
Generic Master Slave Replication:
Introducing a replication layer between the master server and the slave servers can reduce the load on the master by only serving Maxscale’s Binlog Server instead of all the slaves.
Master Slave replication with binlog server:
The slaves will only need to be aware of the Binlog Server and not the real master server. Removing the requirement for the slaves to have knowledge of the master also simplifies the process of replacing a failed master within a replication environment.
Binlog server has a number of advantages:
Reduces load on master caused by Binlog reads..
Ease the master failover and re-align replicas to another master.Because the Binlog server abstracts the dependency between master and replica.
Avoids differential lag on slaves when master goes down.
Creating Maxscale user for getting the binary logs from the master server.
(master) MySQL [(none)]> CREATE USER 'maxscale'@'%' IDENTIFIED BY 'yPE#w73Bb8';
(master) MySQL [(none)]> GRANT SELECT ON mysql.user TO 'maxscale'@'%';
(master) MySQL [(none)]> GRANT SELECT ON mysql.db TO 'maxscale'@'%';
(master) MySQL [(none)]> GRANT SELECT ON mysql.tables_priv TO 'maxscale'@'%';
(master) MySQL [(none)]> GRANT SHOW DATABASES ON *.* TO 'maxscale'@'%';
(master) MySQL [(none)]> GRANT REPLICATION SLAVE ON *.* TO 'maxscale'@'%';
After creating user in the master DB we need to add these details in maxscale configuration file.
[root@binlogserver ~]# ls -lrth /var/lib/maxscale/binlogs/
-rw------- 1 maxscale maxscale 147 Oct 8 18:16 master.ini
drwx------ 2 maxscale maxscale 224 Oct 8 18:16 cache
-rw-r--r-- 1 maxscale maxscale 1.1G Oct 8 18:18 mysql-172321110-binary.002207
-rw-r--r-- 1 maxscale maxscale 1.1G Oct 8 18:39 mysql-172321110-binary.002208
-rw-r--r-- 1 maxscale maxscale 1.1G Oct 8 19:02 mysql-172321110-binary.002209
-rw-r--r-- 1 maxscale maxscale 1.1G Oct 8 19:27 mysql-172321110-binary.002210
-rw-r--r-- 1 maxscale maxscale 1.1G Oct 8 19:50 mysql-172321110-binary.002211
-rw-r--r-- 1 maxscale maxscale 212M Oct 8 19:55 mysql-172321110-binary.002212
We can get some good information from show services command from maxadmin terminal.
MaxScale> show services
Service: Binlog_Service
Router: binlogrouter
State: Started
Master connection DCB: 0x55dd3b832560
Master connection state: Binlog Dump
Binlog directory: /var/lib/maxscale/binlogs
Heartbeat period (seconds): 300
Number of master connects: 1
Number of delayed reconnects: 0
Current binlog file: mysql-172311110-binary.002209
Current binlog position: 716927578
Number of slave servers: 1
No. of binlog events received this session: 74032736
Total no. of binlog events received: 74032736
No. of bad CRC received from master: 0
Number of binlog events per minute
Current 5 10 15 30 Min Avg
630664 514283.8 492402.4 473213.8 459310.4
Number of fake binlog events: 1
Number of artificial binlog events: 8
Number of binlog events in error: 0
Number of binlog rotate events: 7
Number of heartbeat events: 0
Number of packets received: 2115352
Number of residual data packets: 0
Adding replicas under the binlog server:
The steps to add the replicas under the binlog server is same as getting the server under the master server. Only the master IP needs to be changed as binlog server.
We can take mysqldump / percona xtrabackup from the master server for creating replicas. Replace the binlog server IP instead of master server IP while configuring the replication.
Limitations:
Binlogs won’t get auto purged by maxscale server. We need to have a cron job to purge it from the binlog dir.
It won’t support MySQL GTID based replication.
Binlog Router is compatible with MySQL 5.6+, 5.7+ and MariaDB 5.5, the current default.
It’s also works with a MariaDB 10.0 setup (master and slaves) but slave connection must not include any GTID feature.
There is no support for MySQL 5.5 due to missing binlog_checksum variable.
Ready to optimize your MySQL replication setup with Maxscale? Explore Mydbops' Maxscale services or contact us for expert guidance! Contact Mydbops Today !