搭建MySQL MMM高可用

搭建MMM:
1,安裝
agent 節點執行
yum install -y mysql-mmm-agent
2， monitor 節點執行
yum install -y mysql-mmm-monitor
配置文件

1， /etc/init.d/mysql-mmm-agent start
perl: warning: Setting locale failed."的解決
vi /root/.bashrc
再最底部加上
export LC_ALL=C
或者直接運行
echo "export LC_ALL=C" >> /root/.bashrc
而後執行一下：
source /root/.bashrc php

2，<host db1>
ip 192.168.60.166
mode master
peer centos_TP166
</host>
啓動報錯,Starting MMM Monitor Daemon: Config entry 'host->db2->peer'
修改錯誤這個<host db1>的db1 改爲centos_TP166
3,exec of /usr/libexec/mysql-mmm/monitor/checker reaped child 17439 with exit 65280
須要修改mmm_mon.conf的bin_path
4，配置/usr/sbin/mmm_control show 總是提示
ERROR: Can't connect to monitor daemon!
取消配置文件的 # 中文註釋
5，配置好主主複製，和主從複製
6，/etc/init.d/mysql-mmm-monitor restart報錯
Starting MMM Monitor Daemon: Can't run second copy of mmm_mond
原來是/etc/rc.d/init.d/mysql-mmm-monitor 的 MMMD_MON_PIDFILE="/var/run/mysql-mmm/mmm_mond_test_mmm.pid"
配置錯誤
7，MMM 一臺mysqldown掉，會將虛IP漂移到其餘的機器，當重啓mmm的monitor的監控時，會給其分配虛IP
INFO Moving role 'reader(192.168.60.60)' from host 'centos_TP168'to host 'centos_TP167'
8，mmm_control show 出現：
Warning: agent on host centos_TP167 is not reachable
在167機器上ps -ef|grep mm 出現多個 mmm_agentd, kill掉這些，在啓動mmm_agentd就解決
9，執行命令後 mmm_control set_offline centos_TP166 166機器下線
但執行mmm_control show 就ERROR: Can't connect to monitor daemon!
執行mmm_control checks all也出現centos_TP166 rep_threads [last change: 2019/05/15 15:06:48] ERROR: Replication is broken
只有從新執行mmm_control set_online centos_TP166 再 checks才正常

2019年5月9日13:45:59
生產庫上通常不建議設置過濾規則, 若是非要設置, 強烈建議從庫使用通配符方式過濾某個庫mysql

2019年5月14日14:22:10
查mysql未提交事務
查詢正在執行的事務：
SELECT * FROM information_schema.INNODB_TRXsql

查看正在鎖的事務
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS; 數據庫

查看等待鎖的事務centos

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

原文：https://blog.csdn.net/emoers/article/details/77971468 安全

2019年5月16日15:12:23
手工 kill -9 mmm進程，查看/etc/init.d/mysql-mmm-monitor status
mmm_mond 已死，但 pid 文件仍存
若是
重啓restart，提示 DEBUG Sending command 'GET_AGENT_STATUS()' to 167 (192.168.60.167)
一直不動，
查看167服務器的mysql-mmm-agent，手工kill -9 掉 mmm的進程，重啓agentbash

關閉mysql-mmm-monitor ,要先關閉mysql-mmm-agent,再啓動mysql-mmm-monitor服務器

在CentOS 6.3 x86_64下安裝php-mcrypt的時候出現了問題：Error: Cannot retrieve metalink for repository: epel. Please verify its path and try again，須要安裝epel源。網絡

解決方法：一句話：把/etc/yum.repos.d/epel.repo，文件第3行註釋去掉，把第四行註釋掉。具體以下：多線程

打開/etc/yum.repos.d/epel.repo，將

[epel]
name=Extra Packages for Enterprise Linux 6 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch

修改成

[epel]
name=Extra Packages for Enterprise Linux 6 - $basearch
baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch
#mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch

再清理源，從新安裝

yum clean all
yum install -y 須要的包

若是仍是不行，修改DNS,到/etc/resolv.conf下添加一下：

nameserver 8.8.8.8
search localdomain

而後重啓network服務：service network restart

配置文件：

Monitor機器： mmm_common.conf

active_master_role writer <host default> cluster_interface eth0 pid_path /var/run/mysql-mmm/mmm_agentd.pid bin_path /usr/libexec/mysql-mmm replication_user sa replication_password cc.123 agent_user sa agent_password cc.123 mysql_port 18602 </host> <host centos_TP166> ip 192.168.60.166 mode master peer centos_TP166 </host> <host centos_TP167> ip 192.168.60.167 mode master peer centos_TP167 </host> <host centos_TP168> ip 192.168.60.168 mode slave </host> <role writer> hosts centos_TP167,centos_TP166 ips 192.168.60.40 mode exclusive </role> <role reader> hosts centos_TP167,centos_TP168 ips 192.168.60.60, 192.168.60.61 mode balanced </role> debug 0

View Code

Monitor機器： mmm_mon.conf

include mmm_common.conf <monitor> ip 127.0.0.1 port 9992 pid_path /var/run/mysql-mmm/mmm_mond_mmm.pid bin_path /usr/libexec/mysql-mmm status_path /var/lib/mysql-mmm/mmm_mond_test_mmm.status ping_ips 192.168.60.166, 192.168.60.167, 192.168.60.168 auto_set_online 30                                           
</monitor>

<host default> monitor_user sa monitor_password cc.123  
</host>

<check mysql> check_period 2 trap_period 4 max_backlog 900      
</check>

View Code

agent 機器： mmm_common.conf

active_master_role writer <host default> cluster_interface eth0 pid_path /var/run/mysql-mmm/mmm_agentd.pid bin_path /usr/libexec/mysql-mmm/ replication_user sa replication_password cc.123 agent_user sa agent_password cc.123 mysql_port 18602 </host> <host centos_TP166> ip 192.168.60.166 mode master peer centos_TP166 </host> <host centos_TP167> ip 192.168.60.167 mode master peer centos_TP167 </host> <host centos_TP168> ip 192.168.60.168 mode slave </host> <role writer> hosts centos_TP167,centos_TP166 ips 192.168.60.40 mode exclusive </role> <role reader> hosts centos_TP167,centos_TP168 ips 192.168.60.60, 192.168.60.61 mode balanced </role>

View Code

所有機器： /etc/hosts 新加：

192.168.60.165 centos_TP165 192.168.60.166 centos_TP166 192.168.60.167 centos_TP167 192.168.60.168 centos_TP168

View Code

Monitor機器： /etc/rc.d/init.d/mysql-mmm-monitor 啓動MMM腳本

檢查 MMMD_MON_PIDFILE的pid文件和 monitor的mmm_mon.conf配置的pid文件路徑要一致

mysql-mmm故障處理機制中總結：

1.對外提供讀寫的虛擬IP是由monitor程序控制。若是monitor沒有啓動那麼db服務器不會被分配虛擬ip,可是若是已經分配好了虛擬ip，當monitor程序關閉了原先分配的虛擬ip不會當即關閉外部程序還能夠鏈接訪問（只要不重啓網絡），這樣的好處就是對於monitor的可靠性要求就會低一些，可是若是這個時候其中的某一個db服務器故障了就沒法處理切換，也就是原先的虛擬ip仍是維持不變，掛掉的那臺DB的虛擬ip會變的不可訪問。
 2.agent程序受monitor程序的控制處理write切換，從庫切換等操做。若是monitor進程關閉了那麼agent進程就起不到什麼做用，它自己不能處理故障。
 3.monitor程序負責監控db服務器的狀態，包括Mysql數據庫、服務器是否運行、複製線程是否正常、主從延時等；它還用於控制agent程序處理故障。
 4.monitor會每隔幾秒鐘監控db服務器的狀態，若是db服務器已經從故障變成了正常，那麼monitor會自動在60s以後將其設置爲online狀態(默認是60s能夠設爲其它的值)，有監控端的配置文件參數「auto_set_online」決定，羣集服務器的狀態有三種分別是：HARD_OFFLINE→AWAITING_RECOVERY→online
 5.默認monitor會控制mmm_agent會將writer db服務器read_only修改成OFF，其它的db服務器read_only修改成ON,因此爲了嚴謹能夠在全部的服務器的my.cnf文件中加入read_only=1由monitor控制來控制writer和read,root用戶和複製用戶不受read_only參數的影響。

mysql-mmm架構總結:

(1)master-db2備選主節點宕機不影響集羣的狀態，就是移除了master-db2備選節點的讀狀態。
(2)master-db1主節點宕機，由master-db2備選主節點接管寫角色，slave-db1,slave-db2指向新master2主庫進行復制，slave-db1,slave-db2會自動change master到master2.
(3)若是master-db1主庫宕機，master-db2複製應用又落後於master-db1時就變成了主可寫狀態，這時的數據主沒法保證一致性。
   若是master-db2,slave-db1,slave-db2延遲於master-db1主，這個時master-db1宕機，slave-db1,slave-db2將會等待數據追上master-db1後，再從新指向新的主master-db2進行復制操做，這時的數據也沒法保證同步的一致性。
(4)若是採用MMM高可用架構，主，主備選節點機器配置同樣，並且開啓半同步進一步提升安全性或採用MariaDB/mysql5.7進行多線程從複製，提升複製的性能。