I. Overview
This article describes the mysql MMM (Master-Master replication manager for MySQL) program. Official documents address: https://mysql-mmm.org/start.html
MMM mysql server architecture consists of three (two master-slave) and a monitoring nodes, only one main library can provide external writing services, another station owners only read from the external service. When writing services provide the primary database server fails, it can automatically write vip drift to the library to write another one, and redirected to another write library from the library, to achieve high availability.
Write library before failure occurs:
After the failure to write libraries:
Second, the introduction node
The experiment uses four virtual machines, operating system version Centos6.10, mysql version 5.7.25
Monitor 10.40.16.60 surveillance monitor cluster
node1 10.40.16.61 main library provides writing services
node2 10.40.16.62 main library provides reading services
node3 10.40.16.63 from the library provides reading services
Must reserve vip 4, without manual configuration, want to mention here, later step of installation to give
written 10.40.16.71 vip
10.40.16.72 read vip
10.40.16.73 read vip
10.40.16.74 read vip
Third, the installation
1. dual master-slave
And wherein node1 node2 mainly from the interaction, node3 as a node1. Copy specific structures is omitted here, and if it will not, then this article you senseless.
Note: Copy Clusters account used to repl, the password is '123456'
node1(10.40.16.61)
(root@localhost)(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.40.16.62
Master_User: repl
node2(10.40.16.62)
(root@localhost)[(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.40.16.61
Master_User: repl
node3(10.40.16.63)
(root@localhost)[(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 10.40.16.61
Master_User: repl
可以看到node1和node2互为主备，node3作为node1的备
2. 下载扩展包(node1&node2&node3&monitor)
wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
rpm -ivh epel-release-latest-6.noarch.rpm
编辑文件/etc/yum.repos.d/epel.repo
将该文件的第三行前注释取消，第四行注释掉，如下所示
3. 安装MMM包
每个数据库节点(node1&node2&node3)
yum install -y mysql-mmm-agent.noarch
监控节点(monitor)
yum install -y mysql-mmm-*
4. 创建相关账号
在node1中创建以下账号
监控账号(监控数据库状态)
(root@localhost)[(none)]> grant replication client on *.* to 'mmm_monitor'@'%' identified by '123456';
代理账号(MMM代理)
(root@localhost)[(none)]> grant super, replication client, process on *.* to 'mmm_agent'@'%' identified by '123456';
5. 修改配置文件
所有中文的注释是要修改的地方，注意不要在配置文件中写任何注释
在monitor中编辑/etc/mysql-mmm/mmm_mon.conf
在monitor中编辑/etc/mysql-mmm/mmm_common.conf，传给其它三个节点，内容都一致
scp /etc/mysql-mmm/mmm_common.conf 10.40.16.61:/etc/mysql-mmm/
scp /etc/mysql-mmm/mmm_common.conf 10.40.16.62:/etc/mysql-mmm/
scp /etc/mysql-mmm/mmm_common.conf 10.40.16.63:/etc/mysql-mmm/
在node1&node2&node3中编辑/etc/mysql-mmm/mmm_agent.conf，更改'this db1'，与mmm_mon保持一致
6. 启动
node1&node2&node3
[root@mysqla ~]# service mysql-mmm-agent start
[root@mysqlb ~]# service mysql-mmm-agent start
[root@mysqlc ~]# service mysql-mmm-agent start
monitor
[root@monitor ~]# service mysql-mmm-monitor start
7. View
In the monitor in
[root @ monitor ~] # mmm_control show # View cluster status [root @ monitor ~] # mmm_control checks all # View more detailed information
Four, MMM advantages and disadvantages
Advantages:
1. Provide reader VIP
2. supplied from the delay monitor server, a large number of master or master-slave delay occurs from when a link is interrupted, can be read from this table on the server VIP, drift from the server to the cluster the other normal nodes
3. after the primary database to provide failover re-synchronization from the server to the new master
Disadvantages:
1. Published earlier, the document was last updated in 2012, some bug, and does not support gtid services
2. No read load balancing function
3. master-slave switching, if the new master behind the old main, likely to cause new master data loss. If there is backward from the library, from the library will be behind the main library.
4. If the server's log from the new primary server logs than new, it is the main submit duplicate inconsistent, there will be a transaction from.
Five experiments
Experiments on mmm's see next blog (...)