Ausführliche Erläuterung der MySQL-Hochverfügbarkeitslösung MMM
- 黄舟Original
- 2017-10-04 09:26:271891Durchsuche
MySQL selbst bietet keine Replikations-Failover-Lösung. Durch die MMM-Lösung kann ein Server-Failover erreicht werden, wodurch eine hohe Verfügbarkeit von MySQL erreicht wird. MMM bietet nicht nur die Funktion von Floating IP, sondern auch, wenn der aktuelle Master-Server auflegt, wird Ihr Back-End-Slave-Server automatisch zur synchronen Replikation auf den neuen Master-Server übertragen, ohne dass die Synchronisierungskonfiguration manuell geändert werden muss
, MMM-Einführung:
MMM ist Multi-Master-Replikationsmanager für MySQL: MySQL-Multi-Master-Replikationsmanager, basierend auf Perl-Implementierung, einer Reihe von Überwachungs-, Failover- und Verwaltungsfunktionen für MySQL Master-Master-Replikationskonfiguration Skalierbare Skriptsuite (es kann immer nur auf einen Knoten geschrieben werden), MMM kann auch den Lastausgleich der Slave-Server lesen, sodass es unter anderem zum Starten virtueller IP auf einer Gruppe von Servern für die Replikation verwendet werden kann Dinge, es verfügt auch über Skripte zur Implementierung von Datensicherungs- und Resynchronisierungsfunktionen zwischen Knoten. MySQL selbst bietet keine Replikations-Failover-Lösung. Durch die MMM-Lösung kann ein Server-Failover erreicht werden, wodurch eine hohe Verfügbarkeit von MySQL erreicht wird. MMM bietet nicht nur die Funktion von Floating IP, sondern auch, wenn der aktuelle Master-Server auflegt, wird Ihr Back-End-Slave-Server automatisch zur synchronen Replikation auf den neuen Master-Server übertragen, ohne dass die Synchronisierungskonfiguration manuell geändert werden muss. Diese Lösung ist derzeit eine relativ ausgereifte Lösung. Einzelheiten finden Sie auf der offiziellen Website: http://mysql-mmm.org
Vorteile: hohe Verfügbarkeit, gute Skalierbarkeit, automatische Einschaltung Im Fehlerfall bietet die Master-Master-Synchronisation nur einen Datenbank-Schreibvorgang gleichzeitig, um die Datenkonsistenz sicherzustellen. Wenn der Master-Server auflegt, übernimmt sofort ein anderer Master und andere Slave-Server können automatisch ohne manuelles Eingreifen umschalten.
Nachteile: Der Monitorknoten ist ein einzelner Punkt, aber Sie können ihn auch mit keepalived oder haertbeat kombinieren, um ihn hochverfügbar zu machen, was die Anzahl der Knoten erfordert Hosts und müssen gelesen und geschrieben werden. Die Trennung erfordert das Schreiben eines Lese-/Schreib-Trennprogramms am Frontend. In Geschäftssystemen, die stark mit Lese- und Schreibvorgängen beschäftigt sind, ist die Leistung nicht sehr stabil, und es können Probleme wie Replikationsverzögerungen und Switching-Fehler auftreten. Für Umgebungen mit hohen Anforderungen an die Datensicherheit und viel Lese- und Schreibzugriff ist die MMM-Lösung wenig geeignet.
Anwendbare Szenarien:
MMM eignet sich für Szenarien, in denen der Datenbankzugriff groß ist und eine Lese-/Schreibtrennung erreicht werden kann.
Die Hauptfunktionen von Mmm werden durch die folgenden drei Skripte bereitgestellt:
mmm_mond ist der Überwachungs-Daemon-Prozess, der für alle Überwachungsarbeiten verantwortlich ist und die Entfernung von Knoten bestimmt (der mmm_mond-Prozess führt eine regelmäßige Heartbeat-Erkennung durch und wenn sie fehlschlägt, die Schreib-IP wird an einen anderen Master weitergeleitet) und so weiter
mmm_agentd ist ein Agent-Daemon, der auf dem MySQL-Server läuft und dem Überwachungsknoten über einen einfachen Remote-Service-Satz bereitgestellt wird
mmm_control verwaltet den mmm_mond-Prozess über den Befehl Zeile
Während des gesamten Überwachungsprozesses müssen Sie es zu MySQL hinzufügen. Zu den relevanten autorisierten Benutzern gehören ein mmm_monitor-Benutzer und ein mmm_agent-Benutzer. Wenn Sie das Backup-Tool von mmm verwenden möchten, müssen Sie auch einen mmm_tools-Benutzer hinzufügen.
2. Bereitstellung und Implementierung
1. Umgebungseinführung
Betriebssystem: Centos7.2 (64-Bit) Datenbanksystem: MySQL5.7.13
Selinux schließen
NTP konfigurieren, Zeit synchronisieren
| IPHostname | Server-ID | Schreiben vip | Vip lesen | ||||||||||||||||||||||||||||||||||||
| Master1 | 192.168.31.83 | master1 | 1 | 192.168.31.2 td> | ||||||||||||||||||||||||||||||||||||
| Master2(Backup) | 192.168.31.141 td> | 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 | Keine |
2. Konfigurieren Sie die Datei /etc/hosts auf allen Hosts und fügen Sie den folgenden Inhalt hinzu:
192.168.31.83 Master1
192.168.31.141 Master2
192.168.31.250 Slave1
192.168. 31.225 SLAVE2
192.168.31.106 Monitor1
perl, perl-develperl-cpan libart_lgpl.x86_64 rrdtool.x86_64 rrdtool-perl.x86_64 Paket auf allen Hosts
#> #yum-#yum-Ist-Perl-1Ut-Pakel-A-#yum-I-Id-Paket-I-Bahn-Paket für die Hosts
Hinweis: Centos7-Online-Yum-Quellinstallation verwenden
Perl-bezogene Bibliotheken installieren#cpan - i Algorithmus::Diff Class::Singleton DBI DBD::mysql Log::Dispatch Log::Log4perl Mail::Send Net::Ping Proc::Daemon Time::HiRes Params::Validate Net::ARP3. Installieren Sie mysql5.7 und konfigurieren Sie die Replikation auf den Hosts Master1, Master2, Slave1, Slave2
Master1 und Master2 sind Master-Slave zueinander, und Slave1 und Slave2 sind die Slaves von 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 = 1Nach Abschluss der Änderung an my.cnf starten Sie den MySQL-Dienst über systemctl restart mysqld neu Wenn Sie die Firewall auf den 4 Datenbankhosts aktivieren möchten, müssen Sie entweder die Firewall ausschalten oder Zugriffsregeln erstellen:
firewall-cmd --permanent --add-port=3306/tcp
firewall -cmd --reload
Master-Slave-Konfiguration (Master1 und Master2 sind als Master konfiguriert, Slave1 und Slave2 sind als Slave von Master1 konfiguriert):
Autorisierung auf Master1:
mysql> grant replication slave on *.* to rep@'192.168.31.%' identified by '123456';
auf Master2 Autorisierung:
mysql> grant replication slave on *.* to rep@'192.168.31.%' identified by '123456';
Master2, Slave1 und Slave2 als Slave-Bibliotheken von Master1 konfigurieren:
Show Master Status auf Master1 ausführen; Binlog-Datei und Position abrufen Punkt
mysql> show master status; +------------------+----------+--------------+------------------+--------------------------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+---------------------------------------------------+ | mysql-bin.000001 | 452 | | | | +------------------+----------+--------------+------------------+-----------------------------------------------------+
Führen Sie
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;
auf Master2, Slave1 und Slave2 aus, um die Master-Slave-Replikation zu überprüfen:
Master2-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
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
Wenn Slave_IO_Running und Slave_SQL_Running beide „Ja“ sind, dann der Master-Slave Konfiguration ist OK
Master1 als Slave-Bibliothek von Master2 konfigurieren:
Ausführen, Master-Status auf Master2 anzeigen; Binlog-Datei und Positionspunkt abrufen
mysql> show master status; +------------------+----------+--------------+------------------+--------------------------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+---------------------------------------------------+ | mysql-bin.000001 | 452 | | | | +------------------+----------+--------------+------------------+----------------------------------------------------+
Auf Master1 ausführen:
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;
Master-Slave-Replikation überprüfen:
Master1-Host:
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
Wenn Slave_IO_Running und Slave_SQL_Running beide „Ja“ sind, ist die Master-Slave-Konfiguration in Ordnung
4. MySQL -mmm-Konfiguration:
Benutzer auf 4 MySQL-Knoten erstellen
Proxy-Konto erstellen:
mysql> grant super,replicationclient,process on *.* to 'mmm_agent'@'192.168.31.%' identified by '123456';
Überwachungskonto erstellen:
mysql> grant replication client on *.* to 'mmm_monitor'@'192.168.31.%' identified by '123456';
Hinweis 1: Da die vorherige Master-Slave-Replikation und Master-Slave bereits in Ordnung waren, habe ich sie auf dem Master1-Server ausgeführt und es war in Ordnung.
Überprüfen Sie, ob Überwachungs- und Proxy-Konten auf Master2, Slave1 und Slave2-Datenbank vorhanden sind
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.% | +-------------+------------------------------+
oder
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.%' |
Hinweis 2:
mmm_monitor Benutzer: mmm-Überwachung wird verwendet, um den Zustand des MySQL-Serverprozesses zu überprüfen
mmm_agent-Benutzer: mmm-Agent wird verwendet, um den schreibgeschützten Modus, den replizierten Hauptserver usw. zu ändern.
Mysql-mmm-Installation
auf dem Monitor-Host ( 192.168.31.106) Installieren Sie das Überwachungsprogramm
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
Installieren Sie den Agenten auf dem Datenbankserver (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. Konfigurieren Sie mmm
Schreiben Sie die Konfigurationsdatei. Die fünf Hosts müssen konsistent sein:
Nach Abschluss der Installation werden alle Konfigurationsdateien unter /etc/mysql abgelegt. mmm/. Sowohl der Verwaltungsserver als auch der Datenbankserver müssen eine gemeinsame Datei mmm_common.conf mit dem folgenden Inhalt enthalten:
active_master_rolewriter#Aktiver Master-Rollenindikator. Alle Datenbankserver müssen den read_only-Parameter aktivieren. Der Writer-Server-Überwachungsagent wird automatisch read_only festlegen Die Unterkunft ist geschlossen.
<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
adb36db4876d5ae8ea335a15e6246fd6
53f263d2cc20f60e093642c0c2da6c77#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代表负载均衡
adb36db4876d5ae8ea335a15e6246fd6
同时将这个文件拷贝到其它的服务器，配置不变
#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 [f7e6dec31ab1a0471d06c55afaca8d77|all [268cfb9ae487ce9877c28672167a818c|all]] - show checks status#执行监控检查操作
set_onlinef7e6dec31ab1a0471d06c55afaca8d77 - set host f7e6dec31ab1a0471d06c55afaca8d77 online #将host设置为online
set_offlinef7e6dec31ab1a0471d06c55afaca8d77 - set host f7e6dec31ab1a0471d06c55afaca8d77 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] 3b3677fa5ae28346828080dc6d333550f7e6dec31ab1a0471d06c55afaca8d77 - move exclusive role 3b3677fa5ae28346828080dc6d333550 to host f7e6dec31ab1a0471d06c55afaca8d77 #移除writer服务器为指定的host服务器(Only use --force if you know what you are doing!)
set_ipfb7c3ed00d0ce5f01877a916db4eae14f7e6dec31ab1a0471d06c55afaca8d77 - set role with ipfb7c3ed00d0ce5f01877a916db4eae14 to host f7e6dec31ab1a0471d06c55afaca8d77
检查所有的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、其它处理问题
Wenn Sie nicht möchten, dass der Writer vom Master zum Backup wechselt (einschließlich der Master-Slave-Verzögerung, die auch dazu führt, dass der Schreib-VIP wechselt), können Sie 3612df8997eca9306e1f789dddf71f78 entfernen, wenn Sie /etc/mysql- konfigurieren. mmm/mmm_common.conf Backup
9eb76ca14b70376eea824ece21d2e495#Writer-Rollenkonfiguration
Hosts Master1 #Nur ein Host ist hier konfiguriert
ips 192.168.31.2#Die virtuelle IP für externe Schreibvorgänge
Modus exklusiv #exclusive steht für Es darf nur ein Master existieren, das heißt, es kann nur eine Schreib-IP bereitgestellt werden
adb36db4876d5ae8ea335a15e6246fd6
Wenn in diesem Fall Master1 ausfällt, wird der Writer-Schreibvorgang nicht auf umgeschaltet Master2-Server und der Slave zeigen nicht auf den neuen Server-Master. Zu diesem Zeitpunkt hat der aktuelle MMM zuvor Schreibdienste für die Außenwelt bereitgestellt.
5. Zusammenfassung
1. Die virtuelle IP, die externes Lesen und Schreiben ermöglicht, wird vom Monitorprogramm gesteuert. Wenn der Monitor nicht gestartet wird, wird dem Datenbankserver keine virtuelle IP zugewiesen. Wenn jedoch die virtuelle IP zugewiesen wurde, wird das externe Programm nicht sofort geschlossen, wenn das Monitorprogramm die ursprünglich zugewiesene virtuelle IP schließt Das Programm kann weiterhin verbunden und aufgerufen werden (solange das Netzwerk nicht neu gestartet wird). Dies hat den Vorteil, dass die Zuverlässigkeitsanforderungen an den Monitor geringer sind. Wenn jedoch einer der DB-Server zu diesem Zeitpunkt ausfällt, ist dies nicht der Fall Das heißt, die ursprüngliche virtuelle IP bleibt unverändert und die ausgefallene Datenbank kann den Switch nicht mehr verarbeiten.
2. Das Agentenprogramm wird vom Monitorprogramm gesteuert, um Vorgänge wie Schreibwechsel und Slave-Bibliotheksumschaltung durchzuführen. Wenn der Monitorprozess geschlossen ist, spielt der Agentprozess keine Rolle und kann Fehler nicht selbst behandeln.
3. Das Überwachungsprogramm ist für die Überwachung des Status des Datenbankservers verantwortlich, einschließlich der MySQL-Datenbank, ob der Server läuft, ob der Replikationsthread normal ist, die Master-Slave-Verzögerung usw.; Wird auch zur Steuerung des Agentenprogramms zur Fehlerbehandlung verwendet.
4. Der Monitor überwacht alle paar Sekunden den Status des Datenbankservers. Wenn der Datenbankserver von „Fehler“ auf „Normal“ wechselt, versetzt er ihn nach 60 Sekunden automatisch in den Online-Status. Auf andere Werte eingestellt), bestimmt durch den Konfigurationsdateiparameter „auto_set_online“ des Überwachungsendes. Es gibt drei Status des Clusterservers: HARD_OFFLINE→AWAITING_RECOVERY→online
5. Standardmäßig steuert der Monitor mmm_agent und ändert den Write-DB-Server read_only wird auf OFF gesetzt, andere DB-Server read_only werden auf ON geändert, sodass der Genauigkeit halber read_only=1 zur my.cnf-Datei aller vom Monitor zu steuernden Server hinzugefügt werden kann, um den Writer und das Lesen zu steuern . Der Root-Benutzer und der Replikationsbenutzer sind vom Parameter read_only nicht betroffen.
Das obige ist der detaillierte Inhalt vonAusführliche Erläuterung der MySQL-Hochverfügbarkeitslösung MMM. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!