Explication détaillée de la solution MySQL haute disponibilité MMM

MySQL lui-même ne fournit pas de solution de basculement de réplication. Le basculement du serveur peut être réalisé via la solution MMM, permettant ainsi d'obtenir une haute disponibilité de MySQL. MMM fournit non seulement la fonction d'IP flottante, mais aussi si le serveur maître actuel raccroche, votre serveur esclave back-end sera automatiquement transféré vers le nouveau serveur maître pour une réplication synchrone sans avoir à modifier manuellement la configuration de synchronisation

, Introduction à MMM :

MMM est Multi-Master Replication Manager pour MySQL : gestionnaire de réplication multi-maître mysql, basé sur l'implémentation perl, un ensemble de surveillance, de basculement et de gestion de mysql configuration de réplication maître-maître Suite de scripts évolutive (un seul nœud peut être écrit à tout moment), MMM peut également lire l'équilibrage de charge des serveurs esclaves, il peut donc être utilisé pour démarrer une IP virtuelle sur un groupe de serveurs pour la réplication, entre autres choses, il dispose également de scripts pour implémenter des fonctions de sauvegarde et de resynchronisation des données entre les nœuds. MySQL lui-même ne fournit pas de solution de basculement de réplication. Le basculement du serveur peut être réalisé via la solution MMM, permettant ainsi d'obtenir une haute disponibilité de MySQL. MMM fournit non seulement la fonction d'IP flottante, mais aussi si le serveur maître actuel raccroche, votre serveur esclave back-end sera automatiquement transféré vers le nouveau serveur maître pour une réplication synchrone sans avoir à modifier manuellement la configuration de synchronisation. Cette solution est actuellement une solution relativement mature. Pour plus de détails, veuillez consulter le site officiel : http://mysql-mmm.org

Avantages : haute disponibilité, bonne évolutivité, commutation automatique En cas d'échec, la synchronisation maître-maître ne fournit qu'une seule opération d'écriture dans la base de données en même temps pour garantir la cohérence des données. Lorsque le serveur maître raccroche, un autre maître prend immédiatement le relais et les autres serveurs esclaves peuvent automatiquement basculer sans intervention manuelle.

Inconvénients : Le nœud de surveillance est un point unique, mais vous pouvez également le combiner avec keepalived ou haertbeat pour le rendre hautement disponible, il y a au moins trois nœuds, ce qui nécessite le nombre de ; héberge et doit être lu et écrit. La séparation nécessite l'écriture d'un programme de séparation en lecture-écriture sur le front-end. Les performances ne sont pas très stables dans les systèmes d'entreprise très sollicités en lecture et en écriture, et des problèmes tels que des retards de réplication et des échecs de commutation peuvent survenir. La solution MMM n'est pas très adaptée aux environnements avec des exigences élevées en matière de sécurité des données et une lecture et une écriture chargées.

Scénarios applicables :

MMM convient aux scénarios dans lesquels l'accès à la base de données est important et où une séparation en lecture-écriture peut être obtenue.
Les principales fonctions de Mmm sont assurées par les trois scripts suivants :
mmm_mond est le processus démon de surveillance responsable de tous les travaux de surveillance et détermine la suppression des nœuds (le processus mmm_mond effectue une détection régulière des battements de cœur, et s'il échoue, l'adresse IP d'écriture sera transmise à un autre maître) et ainsi de suite
mmm_agentd est un démon d'agent exécuté sur le serveur MySQL et est fourni au nœud de surveillance via un simple ensemble de services à distance
mmm_control gère le processus mmm_mond via la commande line
Pendant tout le processus de surveillance, vous devez l'ajouter à mysql. Les utilisateurs autorisés pertinents incluent un utilisateur mmm_monitor et un utilisateur mmm_agent. Si vous souhaitez utiliser l'outil de sauvegarde de mmm, vous devez également ajouter un utilisateur mmm_tools.

2. Déploiement et mise en œuvre

1. Introduction à l'environnement

OS : centos7.2 (64 bits) Système de base de données : mysql5.7.13

Fermer Selinux

Configurer ntp, synchroniser l'heure

IP

角色	IP	hostname	Server-id	Write vip	Read vip
Master1	192.168.31.83	master1	1	192.168.31.2
Master2(backup)	192.168.31.141	master2	2		192.168.31.3
Slave1	192.168.31.250	slave1	3		192.168.31.4
Slave2	192.168.31.225	slave2	4		192.168.31.5
monitor	192.168.31.106	monitor1	无

Rôle

nom d'hôte

ID du serveur

Écrire vip

Lire vip

Master1

192.168.31.83

maître1

1

192.168.31.2 td>

Master2 (sauvegarde)

192.168.31.141

maître2

2

192.168. 31.3

Esclave1

192.168.31.250

esclave1

3

192.168.31.4

Esclave2

192.168.31.225

esclave2

4

192.168.31.5

moniteur

192.168.31.106

moniteur1

Aucun

2. Configurez le fichier /etc/hosts sur tous les hôtes et ajoutez le contenu suivant :

192.168.31.83 master1
192.168.31.141 master2
192.168.31.250 slave1
192.168. 31.225 slave2
192.168.31.106 moniteur1

Installer perl, perl-develperl-CPAN libart_lgpl.x86_64 rrdtool.x86_64 rrdtool-perl.x86_64 package sur tous les hôtes
#yum -y install perl-* libart_lgpl .x86_64 rrdtool.x86_64 rrdtool-perl.x86_64

Remarque : utilisez l'installation des sources Yum en ligne de Centos7

Installer les bibliothèques liées à Perl

#cpan - i Algorithme :: Classe Diff :: Singleton DBI DBD :: mysql Log :: Dispatch Log :: Log4perl Mail :: Send Net :: Ping Proc :: Daemon Time :: HiRes Params :: Validate Net :: ARP

3. Installez mysql5.7 et configurez la réplication sur les hôtes master1, master2, slave1, slave2

master1 et master2 sont maître-esclave l'un de l'autre, et slave1 et slave2 sont les esclaves de master1
In each mysql Ajoutez le contenu suivant au fichier de configuration /etc/my.cnf Notez que server_id ne peut pas être répété.

hôte master1 :

log-bin = mysql-bin
binlog_format = mixed
server-id = 1
relay-log = relay-bin
relay-log-index = slave-relay-bin.index
log-slave-updates = 1
auto-increment-increment = 2
auto-increment-offset = 1
master2主机：
log-bin = mysql-bin
binlog_format = mixed
server-id = 2
relay-log = relay-bin
relay-log-index = slave-relay-bin.index
log-slave-updates = 1
auto-increment-increment = 2
auto-increment-offset = 2
slave1主机：
server-id = 3
relay-log = relay-bin
relay-log-index = slave-relay-bin.index
read_only  = 1
slave2主机：
server-id = 4
relay-log = relay-bin
relay-log-index = slave-relay-bin.index
read_only  = 1

Après avoir terminé la modification de my.cnf, redémarrez le service mysql via systemctl restart mysqld

Si vous souhaitez activer le pare-feu sur les 4 hôtes de la base de données, vous devez soit désactiver le pare-feu, soit créer des règles d'accès :

firewall-cmd --permanent --add-port=3306/tcp
firewall -cmd --reload
Configuration maître-esclave (master1 et master2 sont configurés en maître, slave1 et slave2 sont configurés en esclaves de master1) :
Autorisation sur master1 :

mysql> grant replication slave on *.* to rep@'192.168.31.%' identified by '123456';

sur master2 Autorisation :

mysql> grant replication slave on *.* to rep@'192.168.31.%' identified by '123456';

Configurer master2, slave1 et slave2 en tant que bibliothèques esclaves de master1 :
Exécuter show master status sur master1 et obtenir le fichier binlog ; Point de positionnement

mysql> show master status;
+------------------+----------+--------------+------------------+--------------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+---------------------------------------------------+
| mysql-bin.000001 | 452 | | | |
+------------------+----------+--------------+------------------+-----------------------------------------------------+

Exécuter

mysql> change master to master_host='192.168.31.83',master_port=3306,master_user='rep',master_password='123456',master_log_file='mysql-bin.000001',master_log_pos=452;
mysql>slave start;

sur master2, slave1 et slave2 pour vérifier la réplication maître-esclave :
hôte master2 :

mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.31.83
Master_User: rep
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 452
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 320
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

slave1 host :

mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.31.83
Master_User: rep
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 452
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 320
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

slave2 host :

mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.31.83
Master_User: rep
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 452
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 320
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Si Slave_IO_Running et Slave_SQL_Running sont tous les deux oui, alors le maître- la configuration de l'esclave est OK
Configurez master1 comme bibliothèque esclave de master2 :
Exécutez show master status sur master2 ; obtenez le fichier binlog et le point de position

mysql> show master status;
+------------------+----------+--------------+------------------+--------------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+---------------------------------------------------+
| mysql-bin.000001 | 452 | | | |
+------------------+----------+--------------+------------------+----------------------------------------------------+

Exécutez sur master1 :

mysql> change master to master_host='192.168.31.141',master_port=3306,master_user='rep',master_password='123456',master_log_file='mysql-bin.000001',master_log_pos=452;
mysql> start slave;

Vérifiez la réplication maître-esclave :
hôte master1 :

mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.31.141
Master_User: rep
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 452
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 320
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Si Slave_IO_Running et Slave_SQL_Running sont tous deux oui, alors la configuration maître-esclave est OK
4. Configuration mysql -mmm :
Créer des utilisateurs sur 4 nœuds mysql
Créer un compte proxy :

mysql> grant super,replicationclient,process on *.* to 'mmm_agent'@'192.168.31.%' identified by '123456';

Créer un compte de surveillance :

mysql> grant replication client on *.* to 'mmm_monitor'@'192.168.31.%' identified by '123456';

Remarque 1 : Parce que la réplication maître-esclave et maître-esclave précédentes étaient déjà ok, je l'ai donc exécuté sur le serveur master1 et c'était ok.
Vérifiez si des comptes de surveillance et proxy existent sur les bases de données master2, slave1 et slave2

mysql> select user,host from mysql.user where user in ('mmm_monitor','mmm_agent');
+-------------+----------------------------+
| user | host |
+-------------+----------------------------+
| mmm_agent | 192.168.31.% |
| mmm_monitor | 192.168.31.% |
+-------------+------------------------------+

ou

mysql> show grants for 'mmm_agent'@'192.168.31.%';
+-----------------------------------------------------------------------------------------------------------------------------+
| Grants for mmm_agent@192.168.31.% |
+-----------------------------------------------------------------------------------------------------------------------------+
| GRANT PROCESS, SUPER, REPLICATION CLIENT ON *.* TO 'mmm_agent'@'192.168.31.%' |
+-----------------------------------------------------------------------------------------------------------------------------+
mysql> show grants for 'mmm_monitor'@'192.168.31.%';
+-----------------------------------------------------------------------------------------------------------------------------+
| Grants for mmm_monitor@192.168.31.% |
+-----------------------------------------------------------------------------------------------------------------------------+
| GRANT REPLICATION CLIENT ON *.* TO 'mmm_monitor'@'192.168.31.%' |

Remarque 2 :
mmm_monitor utilisateur : la surveillance mmm est utilisée pour vérifier la santé du processus du serveur mysql
utilisateur mmm_agent : l'agent mmm est utilisé pour changer le mode lecture seule, le serveur principal répliqué, etc.
Installation Mysql-mmm
sur l'hôte du moniteur ( 192.168.31.106) Installez le programme de surveillance

cd /tmp
wget http://pkgs.fedoraproject.org/repo/pkgs/mysql-mmm/mysql-mmm-2.2.1.tar.gz/f5f8b48bdf89251d3183328f0249461e/mysql-mmm-2.2.1.tar.gz
tar -zxf mysql-mmm-2.2.1.tar.gz
cd mysql-mmm-2.2.1
make install

Installez l'agent sur le serveur de base de données (master1, master2, slave1, slave2)

cd /tmp
wget http://pkgs.fedoraproject.org/repo/pkgs/mysql-mmm/mysql-mmm-2.2.1.tar.gz/f5f8b48bdf89251d3183328f0249461e/mysql-mmm-2.2.1.tar.gz
tar -zxf mysql-mmm-2.2.1.tar.gz
cd mysql-mmm-2.2.1
make install

6. Configurez mmm

Écrivez le fichier de configuration Les cinq hôtes doivent être cohérents :
Une fois l'installation terminée, tous les fichiers de configuration sont placés sous /etc/mysql-. mmm/. Le serveur de gestion et le serveur de base de données doivent contenir un fichier commun mmm_common.conf avec le contenu suivant :
active_master_rolewriter#Active master role Indicator. Tous les serveurs de base de données doivent activer le paramètre read_only. L'agent de surveillance du serveur d'écriture définira automatiquement read_only. La propriété est fermée.

<host default>
cluster_interfaceeno16777736#群集的网络接口
pid_path /var/run/mmm_agentd.pid#pid路径
bin_path /usr/lib/mysql-mmm/#可执行文件路径
replication_user rep#复制用户
replication_password 123456#复制用户密码
agent_usermmm_agent#代理用户
agent_password 123456#代理用户密码
</host>
<host master1>#master1的host名
ip 192.168.31.83#master1的ip
mode master#角色属性，master代表是主
peer master2#与master1对等的服务器的host名，也就是master2的服务器host名
</host>
<host master2>#和master的概念一样
ip 192.168.31.141
mode master
peer master1
</host>
<host slave1>#从库的host名,如果存在多个从库可以重复一样的配置
ip 192.168.31.250#从的ip
mode slave#slave的角色属性代表当前host是从
</host>
<host slave2>#和slave的概念一样
ip 192.168.31.225
mode slave
</host>
<role writer>#writer角色配置

hosts master1,master2#能进行写操作的服务器的host名，如果不想切换写操作这里可以只配置master,这样也可以避免因为网络延时而进行write的切换，但是一旦master出现故障那么当前的MMM就没有writer了只有对外的read操作。
ips 192.168.31.2#对外提供的写操作的虚拟IP
mode exclusive#exclusive代表只允许存在一个主，也就是只能提供一个写的IP

#read角色配置
hosts master2,slave1,slave2#对外提供读操作的服务器的host名,当然这里也可以把master加进来
ips 192.168.31.3, 192.168.31.4, 192.168.31.5#对外提供读操作的虚拟ip，这三个ip和host不是一一对应的,并且ips也hosts的数目也可以不相同，如果这样配置的话其中一个hosts会分配两个ip
mode balanced#balanced代表负载均衡

同时将这个文件拷贝到其它的服务器，配置不变
#for host in master1 master2 slave1 slave2 ; do scp /etc/mysql-mmm/mmm_common.conf $host:/etc/mysql-mmm/ ; done
代理文件配置
编辑 4台mysql节点机上的/etc/mysql-mmm/mmm_agent.conf
在数据库服务器上，还有一个mmm_agent.conf需要修改，其内容是：
includemmm_common.conf
this master1
注意：这个配置只配置db服务器，监控服务器不需要配置，this后面的host名改成当前服务器的主机名。
启动代理进程
在 /etc/init.d/mysql-mmm-agent的脚本文件的#!/bin/sh下面，加入如下内容
source /root/.bash_profile
添加成系统服务并设置为自启动

#chkconfig --add mysql-mmm-agent
#chkconfigmysql-mmm-agent on
#/etc/init.d/mysql-mmm-agent start

注：添加source /root/.bash_profile目的是为了mysql-mmm-agent服务能启机自启。
自动启动和手动启动的唯一区别，就是激活一个console 。那么说明在作为服务启动的时候，可能是由于缺少环境变量
服务启动失败，报错信息如下：

Daemon bin: '/usr/sbin/mmm_agentd'
Daemon pid: '/var/run/mmm_agentd.pid'
Starting MMM Agent daemon... Can't locate Proc/Daemon.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/sbin/mmm_agentd line 7.
BEGIN failed--compilation aborted at /usr/sbin/mmm_agentd line 7.
failed

解决方法：

# cpanProc::Daemon
# cpan Log::Log4perl
# /etc/init.d/mysql-mmm-agent start
Daemon bin: '/usr/sbin/mmm_agentd'
Daemon pid: '/var/run/mmm_agentd.pid'
Starting MMM Agent daemon... Ok
# netstat -antp | grep mmm_agentd
tcp 0 0 192.168.31.83:9989 0.0.0.0:* LISTEN 9693/mmm_agentd
配置防火墙
firewall-cmd --permanent --add-port=9989/tcp
firewall-cmd --reload
编辑 monitor主机上的/etc/mysql-mmm/mmm_mon.conf 
includemmm_common.conf

<monitor>
ip 127.0.0.1##为了安全性，设置只在本机监听，mmm_mond默认监听9988
pid_path /var/run/mmm_mond.pid
bin_path /usr/lib/mysql-mmm/
status_path/var/lib/misc/mmm_mond.status
ping_ips192.168.31.83,192.168.31.141,192.168.31.250,192.168.31.225#用于测试网络可用性 IP 地址列表，只要其中有一个地址 ping 通，就代表网络正常，这里不要写入本机地址
auto_set_online 0#设置自动online的时间，默认是超过60s就将它设置为online，默认是60s，这里将其设为0就是立即online
</monitor>

<check default>
check_period 5
trap_period 10
timeout 2
#restart_after 10000
max_backlog 86400
</check>
check_period

描述：检查周期默认为5s
默认值：5s
trap_period
描述：一个节点被检测不成功的时间持续trap_period秒，就慎重的认为这个节点失败了。
默认值：10s
timeout
描述：检查超时的时间
默认值：2s
restart_after
描述：在完成restart_after次检查后，重启checker进程
默认值：10000
max_backlog
描述：记录检查rep_backlog日志的最大次数
默认值：60

<host default>
monitor_usermmm_monitor#监控db服务器的用户
monitor_password 123456#监控db服务器的密码
</host>
debug 0#debug 0正常模式，1为debug模式
启动监控进程：
在 /etc/init.d/mysql-mmm-agent的脚本文件的#!/bin/sh下面，加入如下内容 
source /root/.bash_profile 
添加成系统服务并设置为自启动
#chkconfig --add mysql-mmm-monitor
#chkconfigmysql-mmm-monitor on
#/etc/init.d/mysql-mmm-monitor start

启动报错:

Starting MMM Monitor daemon: Can not locate Proc/Daemon.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/sbin/mmm_mond line 11.
BEGIN failed--compilation aborted at /usr/sbin/mmm_mond line 11.
failed

解决方法：安装下列perl的库

#cpanProc::Daemon
#cpan Log::Log4perl
[root@monitor1 ~]# /etc/init.d/mysql-mmm-monitor start
Daemon bin: '/usr/sbin/mmm_mond'
Daemon pid: '/var/run/mmm_mond.pid'
Starting MMM Monitor daemon: Ok
[root@monitor1 ~]# netstat -anpt | grep 9988
tcp 0 0 127.0.0.1:9988 0.0.0.0:* LISTEN 8546/mmm_mond

注1：无论是在db端还是在监控端如果有对配置文件进行修改操作都需要重启代理进程和监控进程。
注2：MMM启动顺序：先启动monitor，再启动 agent

检查集群状态：

[root@monitor1 ~]# mmm_control show
master1(192.168.31.83) master/ONLINE. Roles: writer(192.168.31.2)
master2(192.168.31.141) master/ONLINE. Roles: reader(192.168.31.5)
slave1(192.168.31.250) slave/ONLINE. Roles: reader(192.168.31.4)
slave2(192.168.31.225) slave/ONLINE. Roles: reader(192.168.31.3)

如果服务器状态不是ONLINE，可以用如下命令将服务器上线，例如：

#mmm_controlset_online主机名

例如：[root@monitor1 ~]#mmm_controlset_onlinemaster1
从上面的显示可以看到，写请求的VIP在master1上，所有从节点也都把master1当做主节点。
查看是否启用vip

[root@master1 ~]# ipaddr show dev eno16777736
eno16777736: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscpfifo_fast state UP qlen 1000
link/ether 00:0c:29:6d:2f:82 brdff:ff:ff:ff:ff:ff
inet 192.168.31.83/24 brd 192.168.31.255 scope global eno16777736
valid_lft forever preferred_lft forever
inet 192.168.31.2/32 scope global eno16777736
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fe6d:2f82/64 scope link
valid_lft forever preferred_lft forever
[root@master2 ~]# ipaddr show dev eno16777736
eno16777736: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscpfifo_fast state UP qlen 1000
link/ether 00:0c:29:75:1a:9c brdff:ff:ff:ff:ff:ff
inet 192.168.31.141/24 brd 192.168.31.255 scope global dynamic eno16777736
valid_lft 35850sec preferred_lft 35850sec
inet 192.168.31.5/32 scope global eno16777736
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fe75:1a9c/64 scope link
valid_lft forever preferred_lft forever
[root@slave1 ~]# ipaddr show dev eno16777736
eno16777736: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscpfifo_fast state UP qlen 1000
link/ether 00:0c:29:02:21:19 brdff:ff:ff:ff:ff:ff
inet 192.168.31.250/24 brd 192.168.31.255 scope global dynamic eno16777736
valid_lft 35719sec preferred_lft 35719sec
inet 192.168.31.4/32 scope global eno16777736
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fe02:2119/64 scope link
valid_lft forever preferred_lft forever
[root@slave2 ~]# ipaddr show dev eno16777736
eno16777736: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscpfifo_fast state UP qlen 1000
link/ether 00:0c:29:e2:c7:fa brdff:ff:ff:ff:ff:ff
inet 192.168.31.225/24 brd 192.168.31.255 scope global dynamic eno16777736
valid_lft 35930sec preferred_lft 35930sec
inet 192.168.31.3/32 scope global eno16777736
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fee2:c7fa/64 scope link
valid_lft forever preferred_lft forever
在master2，slave1，slave2主机上查看主mysql的指向
mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.31.83
Master_User: rep
Master_Port: 3306
Connect_Retry: 60

MMM高可用性测试：

服务器读写采有VIP地址进行读写，出现故障时VIP会漂移到其它节点，由其它节点提供服务。
首先查看整个集群的状态，可以看到整个集群状态正常

[root@monitor1 ~]# mmm_control show
master1(192.168.31.83) master/ONLINE. Roles: writer(192.168.31.2)
master2(192.168.31.141) master/ONLINE. Roles: reader(192.168.31.5)
slave1(192.168.31.250) slave/ONLINE. Roles: reader(192.168.31.4)
slave2(192.168.31.225) slave/ONLINE. Roles: reader(192.168.31.3)

模拟master1宕机，手动停止mysql服务，观察monitor日志,master1的日志如下：

[root@monitor1 ~]# tail -f /var/log/mysql-mmm/mmm_mond.log
2017/01/09 22:02:55 WARN Check 'rep_threads' on 'master1' is in unknown state! Message: UNKNOWN: Connect error (host = 192.168.31.83:3306, user = mmm_monitor)! Can't connect to MySQL server on '192.168.31.83' (111)
2017/01/09 22:02:55 WARN Check 'rep_backlog' on 'master1' is in unknown state! Message: UNKNOWN: Connect error (host = 192.168.31.83:3306, user = mmm_monitor)! Can't connect to MySQL server on '192.168.31.83' (111)
2017/01/09 22:03:05 ERROR Check 'mysql' on 'master1' has failed for 10 seconds! Message: ERROR: Connect error (host = 192.168.31.83:3306, user = mmm_monitor)! Can't connect to MySQL server on '192.168.31.83' (111)
2017/01/09 22:03:07 FATAL State of host 'master1' changed from ONLINE to HARD_OFFLINE (ping: OK, mysql: not OK)
2017/01/09 22:03:07 INFO Removing all roles from host 'master1':
2017/01/09 22:03:07 INFO Removed role 'writer(192.168.31.2)' from host 'master1'
2017/01/09 22:03:07 INFO Orphaned role 'writer(192.168.31.2)' has been assigned to 'master2'

查看群集的最新状态

[root@monitor1 ~]# mmm_control show
master1(192.168.31.83) master/HARD_OFFLINE. Roles:
master2(192.168.31.141) master/ONLINE. Roles: reader(192.168.31.5), writer(192.168.31.2)
slave1(192.168.31.250) slave/ONLINE. Roles: reader(192.168.31.4)
slave2(192.168.31.225) slave/ONLINE. Roles: reader(192.168.31.3)

从显示结果可以看出master1的状态有ONLINE转换为HARD_OFFLINE，写VIP转移到了master2主机上。
检查所有的db服务器群集状态

[root@monitor1 ~]# mmm_control checks all
master1 ping [last change: 2017/01/09 21:31:47] OK
master1 mysql [last change: 2017/01/09 22:03:07] ERROR: Connect error (host = 192.168.31.83:3306, user = mmm_monitor)! Can't connect to MySQL server on '192.168.31.83' (111)
master1 rep_threads [last change: 2017/01/09 21:31:47] OK
master1 rep_backlog [last change: 2017/01/09 21:31:47] OK: Backlog is null
slave1 ping [last change: 2017/01/09 21:31:47] OK
slave1mysql [last change: 2017/01/09 21:31:47] OK
slave1 rep_threads [last change: 2017/01/09 21:31:47] OK
slave1 rep_backlog [last change: 2017/01/09 21:31:47] OK: Backlog is null
master2 ping [last change: 2017/01/09 21:31:47] OK
master2 mysql [last change: 2017/01/09 21:57:32] OK
master2 rep_threads [last change: 2017/01/09 21:31:47] OK
master2 rep_backlog [last change: 2017/01/09 21:31:47] OK: Backlog is null
slave2 ping [last change: 2017/01/09 21:31:47] OK
slave2mysql [last change: 2017/01/09 21:31:47] OK
slave2 rep_threads [last change: 2017/01/09 21:31:47] OK
slave2 rep_backlog [last change: 2017/01/09 21:31:47] OK: Backlog is null

从上面可以看到master1能ping通，说明只是服务死掉了。

查看master2主机的ip地址：

[root@master2 ~]# ipaddr show dev eno16777736
eno16777736: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscpfifo_fast state UP qlen 1000
link/ether 00:0c:29:75:1a:9c brdff:ff:ff:ff:ff:ff
inet 192.168.31.141/24 brd 192.168.31.255 scope global dynamic eno16777736
valid_lft 35519sec preferred_lft 35519sec
inet 192.168.31.5/32 scope global eno16777736
valid_lft forever preferred_lft forever
inet 192.168.31.2/32 scope global eno16777736
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fe75:1a9c/64 scope link
valid_lft forever preferred_lft forever

slave1主机：

mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.31.141
Master_User: rep
Master_Port: 3306

slave2主机：

mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.31.141
Master_User: rep
Master_Port: 3306

启动master1主机的mysql服务，观察monitor日志,master1的日志如下：

[root@monitor1 ~]# tail -f /var/log/mysql-mmm/mmm_mond.log
2017/01/09 22:16:56 INFO Check 'mysql' on 'master1' is ok!
2017/01/09 22:16:56 INFO Check 'rep_backlog' on 'master1' is ok!
2017/01/09 22:16:56 INFO Check 'rep_threads' on 'master1' is ok!
2017/01/09 22:16:59 FATAL State of host 'master1' changed from HARD_OFFLINE to AWAITING_RECOVERY

从上面可以看到master1的状态由hard_offline改变为awaiting_recovery状态
用如下命令将服务器上线：

[root@monitor1 ~]#mmm_controlset_onlinemaster1

查看群集最新状态

[root@monitor1 ~]# mmm_control show
master1(192.168.31.83) master/ONLINE. Roles:
master2(192.168.31.141) master/ONLINE. Roles: reader(192.168.31.5), writer(192.168.31.2)
slave1(192.168.31.250) slave/ONLINE. Roles: reader(192.168.31.4)
slave2(192.168.31.225) slave/ONLINE. Roles: reader(192.168.31.3)

可以看到主库启动不会接管主，只到现有的主再次宕机。
总结
(1)master2备选主节点宕机不影响集群的状态，就是移除了master2备选节点的读状态。
(2)master1主节点宕机，由master2备选主节点接管写角色，slave1,slave2指向新master2主库进行复制，slave1,slave2会自动change master到master2.
(3)如果master1主库宕机，master2复制应用又落后于master1时就变成了主可写状态，这时的数据主无法保证一致性。
如果master2,slave1,slave2延迟于master1主，这个时master1宕机，slave1,slave2将会等待数据追上db1后，再重新指向新的主node2进行复制操作，这时的数据也无法保证同步的一致性。
(4)如果采用MMM高可用架构，主，主备选节点机器配置一样，而且开启半同步进一步提高安全性或采用MariaDB/mysql5.7进行多线程从复制，提高复制的性能。

附：

1、日志文件：
日志文件往往是分析错误的关键，所以要善于利用日志文件进行问题分析。
db端：/var/log/mysql-mmm/mmm_agentd.log
监控端：/var/log/mysql-mmm/mmm_mond.log
2、命令文件：
mmm_agentd：db代理进程的启动文件
mmm_mond：监控进程的启动文件
mmm_backup：备份文件
mmm_restore：还原文件
mmm_control：监控操作命令文件
db服务器端只有mmm_agentd程序，其它的都是在monitor服务器端。
3、mmm_control用法
mmm_control程序可以用于监控群集状态、切换writer、设置online\offline操作等。
Valid commands are:
help - show this message #帮助信息
ping - ping monitor #ping当前的群集是否正常
show - show status #群集在线状态检查
checks [|all [|all]] - show checks status#执行监控检查操作
set_online - set host online #将host设置为online
set_offline - set host offline #将host设置为offline
mode - print current mode. #打印输出当前的mode
set_active - switch into active mode.

set_manual - switch into manual mode.
set_passive - switch into passive mode.
move_role [--force] - move exclusive role to host #移除writer服务器为指定的host服务器(Only use --force if you know what you are doing!)
set_ip - set role with ip to host
检查所有的db服务器群集状态：
[root@monitor1 ~]# mmm_control checks all
检查项包括：ping、mysql是否正常运行、复制线程是否正常等
检查群集环境在线状况：
[root@monitor1 ~]# mmm_control show
对指定的host执行offline操作：
[root@monitor1 ~]# mmm_controlset_offline slave2
对指定的host执行onine操作：
[root@monitor1 ~]# mmm_controlset_online slave2
执行write切换(手动切换):
查看当前的slave对应的master
[root@slave2 ~]# mysql -uroot -p123456 -e 'show slave status\G;'
mysql: [Warning] Using a password on the command line interface can be insecure.
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.31.141
writer切换，要确保mmm_common.conf文件中的writer属性有配置对应的host,否则无法切换
[root@monitor1 ~]# mmm_controlmove_role writer master1
OK: Role 'writer' has been moved from 'master2' to 'master1'. Now you can wait some time and check new roles info!
[root@monitor1 ~]# mmm_control show
master1(192.168.31.83) master/ONLINE. Roles: writer(192.168.31.2)
master2(192.168.31.141) master/ONLINE. Roles: reader(192.168.31.5)
slave1(192.168.31.250) slave/ONLINE. Roles: reader(192.168.31.4)
slave2(192.168.31.225) slave/ONLINE. Roles: reader(192.168.31.3)
save从库自动切换到了新的master
[root@slave2 ~]# mysql -uroot -p123456 -e 'show slave status\G;'
mysql: [Warning] Using a password on the command line interface can be insecure.
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.31.83

4、其它处理问题

Si vous ne souhaitez pas que le rédacteur passe du maître à la sauvegarde (y compris le délai maître-esclave qui entraînera également le changement du VIP d'écriture), vous pouvez supprimer mmm/mmm_common.conf backup
#writer role configuration
hosts master1 #Un seul hôte est configuré ici
ips 192.168.31.2#L'adresse IP virtuelle pour les opérations d'écriture externes
mode exclusif #exclusive représente Un seul maître est autorisé à exister, c'est-à-dire qu'une seule adresse IP d'écriture peut être fournie

Dans ce cas, lorsque master1 échoue, l'opération d'écriture de l'écrivain ne sera pas basculée vers le master2, et l'esclave ne pointera pas vers le nouveau serveur maître, à ce stade, le MMM actuel fournissait auparavant des services d'écriture externes.

5. Résumé

1. L'adresse IP virtuelle qui fournit la lecture et l'écriture externes est contrôlée par le programme du moniteur. Si le moniteur n'est pas démarré, le serveur de base de données ne se verra pas attribuer une adresse IP virtuelle. Cependant, si l'adresse IP virtuelle a été attribuée, lorsque le programme du moniteur ferme l'adresse IP virtuelle initialement attribuée, le programme externe ne sera pas fermé immédiatement et l'externe. Le programme peut toujours être connecté et accessible (tant que le réseau n'est pas redémarré). L'avantage est que les exigences de fiabilité du moniteur seront inférieures. Toutefois, si l'un des serveurs de base de données tombe en panne à ce moment-là, il ne le sera pas. être capable de gérer le commutateur. Autrement dit, l'adresse IP virtuelle d'origine restera inchangée et la base de données qui a échoué ne pourra pas gérer le commutateur.

2. Le programme agent est contrôlé par le programme moniteur pour gérer des opérations telles que la commutation d'écriture et la commutation de bibliothèque esclave. Si le processus de surveillance est fermé, le processus agent ne jouera aucun rôle et ne pourra pas gérer les erreurs par lui-même.

3. Le programme de surveillance est chargé de surveiller l'état du serveur de base de données, y compris la base de données Mysql, si le serveur est en cours d'exécution, si le thread de réplication est normal, le délai maître-esclave, etc. également utilisé pour contrôler le programme agent afin de gérer les échecs.

4. Le moniteur surveillera l'état du serveur de base de données toutes les quelques secondes. Si le serveur de base de données est passé d'un échec à un état normal, le moniteur le mettra automatiquement à l'état en ligne après 60 s (la valeur par défaut est de 60 s). Réglé sur d'autres valeurs), déterminé par le paramètre du fichier de configuration "auto_set_online" de l'extrémité de surveillance. Il existe trois états du serveur de cluster : HARD_OFFLINE→AWAITING_RECOVERY→online
5. Par défaut, le moniteur contrôlera mmm_agent et modifiera le. le serveur de base de données de l'écrivain read_only sur OFF, les autres serveurs de base de données read_only sont modifiés sur ON, donc par souci de rigueur, read_only=1 peut être ajouté au fichier my.cnf de tous les serveurs à contrôler par le moniteur pour contrôler l'écrivain et lire . L'utilisateur root et l'utilisateur de réplication ne sont pas affectés par le paramètre read_only.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!