Mysql常用主從複製架構以及MHA高可用的主從複製的實現
實驗一：一主多從或者是一主從從架構的實現
一、實驗環境：
三臺服務器，一臺master,一臺slave，一臺slave的slave（或者是master的slave）。
二、實驗準備：
配置好yum源、 防火牆關閉、 各節點時鐘服務同步、 各節點之間可以通過主機名互相通信。
三、mysql主從複製原理：
1、該過程的第一部分就是master記錄二進制日誌。在每個事務更新數據完成之前，master在二進制日誌記錄這些改變。MySQL將事務串行的寫入二進制日誌，在事件寫入二進制日誌完成後，master通知存儲引擎提交事務。此後可接收slave的請求。
2、下一步就是slave將master的binary log拷貝到它自己的中繼日誌。首先，slave開始一個工作線程——I/O線程。I/O線程在master上打開一個普通的連接，然後開始在主節點上binlog dump process（二進制轉存線程）。Binlog dump process從master的二進制日誌中讀取事件，如果已經跟上master，它會睡眠並等待master產生新的事件。I/O線程將這些事件寫入中繼日誌。
3、 SQL slave thread（SQL從線程）處理該過程的最後一步。SQL線程從中繼日誌讀取事件，並重放其中的事件而更新slave的數據，使其與master中的數據一致。只要該線程與I/O線程保持一致，中繼日誌通常會位於OS的緩存中，所以中繼日誌的開銷很小。
四、架構圖
五、實驗步驟：
第一步：配置maser服務器
vim /etc/my.cnf
server-id=33 指定serverid，唯一辨識主服務器
log-bin=mysql-bin 開啓二進制日誌，記錄數據變化，給從通路。
skip-name-resolve 跳過名稱解析
第二步：配置slave服務器
vim /etc/my.cnf
server-id=34 配置從服務器，讓其擁有唯一辨識
relay-log=mysql-relay-log 打開中繼日誌，和主通訊。
read-only=1 只讀權限，讀寫分離，確保數據的一致性
log-bin=mysql-bin 開啓二進制日誌，記錄數據的變化，從也能再設置從服務器
log-slave-updates=1 把中繼日誌中更新的日誌寫入二進制日誌中
第三步：創建複製帳號
在Master的數據庫中建立一個備份帳戶：每個slave使用標準的MySQL用戶名和密碼連接master。進行復制操作的用戶會授予REPLICATION SLAVE權限。
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON . TO slave@'172.17.%.%' IDENTIFIED BY 'magedu';
這一步完成後可以查看一下當前的二進制日誌的position。設計好從哪裏開始複製，並且複製的二進制數據庫是哪一個。
show master status; 查看主服務器的二進制日誌的狀態
show binlog events in 'mysql-bin.000003'\G 查看這個二進制日誌的信息
第四步：啓動從服務器複製線程
change master to master_host='172.17.254.171',master_user='slave',master_password='magedu',master_log_file='mysql-bin.000003',master_log_pos=245;
start slave；開啓slave的I/O線程和SQL線程
第五步：查看從服務器狀態
可使用SHOW SLAVE STATUS\G查看從服務器狀態，如下所示，也可用show processlist \G查看當前複製狀態：
Slave_IO_Running: Yes #IO線程正常運行
Slave_SQL_Running: Yes #SQL線程正常運行
第六步：配置從的從服務器
由上面就可以知道，當把主的全部的內容複製到從了，包括主的授權，所以當從再配置一個從服務器的時候，不需要再次授權，直接配置就行了。配置文件上面都已經標明，不需要再次解釋了。
vim /etc/my.cnf
server-id=36
relay-log=mysql-relay-log
read-only=1
log-bin =mysql-bin
log-slave-updates=1
第七步：啓動從的從服務器複製線程。
CHANGE MASTER TO MASTER_HOST='172.17.254.181',master_user='slave',master_password='magedu',master_log_file='mysql-bin.000003',master_log_pos=245;
start slave；開啓slave的I/O線程和SQL線程
第八步：也可以把從 的從服務器改成主的從服務器，也就是一主多從的意思，把第七步的master_host換成主的ip就行了。
五：易錯點：
1、切換master的時候要stop slave，當然關閉之後要更換完之後要記得開啓start slave。
2、要注意複製的日誌的銜接。切換主的時候提示數據庫已經存在，就要更改position了。
3、把從的從服務器更改成主的從服務器的時候出現如下錯誤：
Could not initialize master info structure; more error messages can be found in the MySQL error log。
原因：配置過主從後可能數據庫中存放的路徑下會出現master|relay.info兩個文件，這兩個文件說明已經配置過主從，要想切換直接刪除就行了。
實驗總結：實現一主多從或者是一主從從都是爲了減輕數據庫服務器的壓力，但是也只是能夠解決讀的問題，不能解決寫的問題，數據庫主從複製最重要的問題就是數據的一致性。如果非要解決也只能實現雙主，但是不推薦使用。
實驗二：雙主架構
在上一題的基礎上實現就行了，只需要把主配置成從。
第一步：每個節點都配置需要配置中繼日誌和二進制日誌。
把從的配置複製一份過來就可以了。
第二步：設置自增長ID。增長的方式要不一樣，不然還是會重複id,導致數據不一致。
定義一個節點使用奇數id
auto_increment_increment=2 #表示自增長字段每次遞增的量
auto_increment_offset=1 #表示自增長字段從那個數開始
另一個節點使用偶數id
auto_increment_increment=2
auto_increment_offset=2
第三步：啓動從的從服務器複製線程。
MASTER_HOST='172.17.254.171',master_user='slave',master_password='magedu',master_log_file='mysql-bin.000003',master_log_pos=245;
start slave；開啓slave的I/O線程和SQL線程
第四步：測試
節點一：insert into m26 values(1),(2),(3)
節點二：insert into m26 values(1),(2),(3)
效果：select * from m26;
+----+
| id |
+----+
| 1 |
| 2 |
| 3 |
| 1 |
| 2 |
| 3 |
實驗總結：雙主雖然可以插入數據，但是數據的排序並不是按順序排列，只能保證奇數偶數不重複。但是當兩個人同時對一個數據進行修改，就要看下手的速度了。通過分庫來實現雙主，效果會好一點，雙主也只能在小併發的情況下使用。
實驗三：MySQL高可用架構之MHA
MHA是一款開源的 MySQL 的高可用程序， 它爲 MySQL主從複製架構提供 了 automating master failover 功能。 MHA 在監控到master 節點故障時， 會提升其中擁有最新數據的 slave 節點成爲新的master 節點， 在此期間， MHA 會通過於其它從節點獲取額外信息來避免一致性方面的問題。 MHA 還提供了 master 節點的在線切換功能， 即按需切換 master/slave 節點 。
一、實驗環境：
1、準備mysql的主從結構，具體步驟見上面的實驗；
2、準備提供mha工作的基本工具
3、關閉selinux和iptables，同步系統時間
二、實驗拓撲圖：
三、實驗原理
MHA工作原理總結爲以下幾條：
（1） 從宕機崩潰的master保存二進制日誌事件（binlog events） ;
（2） 識別含有最新更新的slave;
（3） 應用差異的中繼日誌(relay log) 到其他slave;
（4） 應用從master保存的二進制日誌事件(binlog events);
（5） 提升一個slave爲新master;
（6） 使用其他的slave連接新的master進行復制。
四、實驗步驟
第一步：每個節點都要開啓中繼日誌和二進制日誌，各個從節點都要啓用read-only,並關閉relay_log_purge功能等.
本實驗環境共有四個節點， 其角色分配如下：
node1:MariaDB master
node2: MariaDB slave
node3: MariaDB slave
node4: MHA Manager
各節點的/etc/hosts文件配置內容中添加：
172.17.254.171 node1.magedu.com
172.17.254.181 node2.magedu.com
172.17.252.196 node3.magedu.com
172.17.254.238 node4.magedu.com
第二步：初始節點的配置，詳情步驟參看上面主從配置：
master：
server-id=20 //指定serverid，唯一辨識主服務器
log-bin = master-log //開啓二進制日誌
relay-log = relay-log //開啓中繼日誌
skip_name_resolve //關閉名稱解析（非必須）
systemctl restart mariadb
Slave1：
server-id = 21 //指定serverid，唯一辨識主服務器
relay-log = relay-log //開啓中繼日誌
log-bin = master-log //開啓二進制日誌
relay_log_purge = 0 //是否自動清空不再需要中繼日誌
skip_name_resolve //關閉名稱解析（非必須）
log_slave_updates = 1 //使得更新的數據寫進二進制日誌中
systemctl restart mariadb
Slave2:
server-id = 21 //指定serverid，唯一辨識主服務器
relay-log = relay-log //開啓中繼日誌
log-bin = master-log //開啓二進制日誌
relay_log_purge = 0 //是否自動清空不再需要中繼日誌
skip_name_resolve //關閉名稱解析（非必須）
log_slave_updates = 1 //使得更新的數據寫進二進制日誌中
systemctl restart mariadb
第三步：配置一主多從複製架構
master節點上：
MariaDB [(none)]>GRANT REPLICATION SLAVE,REPLICATION CLIENT ON
. TO 'slave'@'172.17.%.%' IDENTIFIED BY 'magedu';
MariaDB [(none)]> FLUSH PRIVILEGES;
MariaDB [(none)]> SHOW MASTER STATUS;
各slave節點上：
[root@node3 ~]# mysql
MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='172.17.%.%',MASTER_USER='slave' ,MASTER_PASSWOR
D='magedu' ,MASTER_LOG_FILE='master-log.000003',MASTER_LOG_POS=245;
MariaDB [(none)]> START SLAVE;
MariaDB [(none)]> SHOW SLAVE STATUS\G;
第四步：安裝MHA並配置
1、在所有MYSQL節點授權擁有管理權限的用戶可在本地網絡中有其他節點上遠程訪問。 當然， 此時僅需要且只能在master節點運行類似如下SQL語句即可。
mysql> GRANT ALL ON . TO 'mhaadmin'@'172.17.%.%' IDENTIFIED BY 'mhapass';
2、MHA集羣中的各節點彼此之間均需要基於ssh互信通信， 以實現遠程控制及數據管理功能。簡單起見， 可在Manager節點生成密鑰對兒， 並設置其可遠程連接本地主機後， 將私鑰文件及authorized_keys文件複製給餘下的所有節點即可。
下面操作在node4：
Manager 節點上操作：
[root@node4 ~]# ssh-keygen -t rsa
[root@node4 ~]#ssh-copy-id -i .ssh/id_rsa.pub root@node4
四臺機器都做如上操作，然後manager下就會出現一個包含所有節點的公鑰文件authorized_keys。
然後把這個文件上發送給其他的節點
scp authorized_keys [email protected]:~/.ssh/
scp authorized_keys [email protected]:~/.ssh/
scp authorized_keys [email protected]:~/.ssh/
3、進行MHA安裝包安裝
Manager 節點： #yum install mha4mysql-manager-0.56-0.el6.noarch.rpm
所有節點， 包括Manager: #yum install mha4mysql-node-0.56-0.el6.norch.rpm
4、初始化MHA， 進行配置
Manager 節點需要爲每個監控的master/slave集羣提供一個專用的配置文件，而所有的master/slave集羣也可共享全局配置。全局配置文件默認爲/etc/masterha_default.cnf，其爲可選配置。 如果僅監控一組master/slave集羣， 也可直接通過application的配置來提供各服務器的默認配置信息。而每application的配置文件路徑爲自定義。
5、定義MHA管理配置文件,需要注意的地方是有幾臺mysql服務器就需要幾個server，manager管理所有的機器爲MHA專門創建一個管理用戶， 方便以後使用， 在mysql的主節點上， 三個節點自動同步
mkdir /etc/mha_master
vim /etc/mha_master/app1.cnf
配置文件內容如下：
[server default]
user=mhaadmin
password=mhapass
manager_workdir=/etc/mha_master/app1
manager_log=/etc/mha_master/manager.log
remote_workdir=/mydata/mha_master/app1
ssh_user=root
repl_user=slave
repl_password=magedu
ping_interval=1
[server1]
hostname=172.17.254.181
ssh_port=22
candidate_master=1
[server2]
hostname=172.17.252.196
ssh_port=22
candidate_master=1
[server3]
hostname=172.17.254.171
ssh_port=22
candidate_master=1
6、檢測各節點間ssh互信通信配置是否Ok:
[root@node4 ~]# masterha_check_ssh -conf=/etc/mha_master/app1.cnf
輸出信息最後一行類似如下信息， 表示其通過檢測。
[info]All SSH connection tests passed successfully.
7、檢查管理的MySQL複製集羣的連接配置參數是否OK：
[root@node4 ~]#masterha_check_repl -conf=/etc/mha_master/app1.cnf
如果測試時會報錯， 可能是從節點上沒有賬號，因爲這個架構，任何一個從節點，將有可能
成爲主節點， 所以也需要創建賬號。
因此， 這裏只要在mater節點上再次執行以下操作即可：
MariaDB [(none)]>GRANT REPLICATION SLAVE,REPLICATION CLIENT ON . TO '[email protected].%.%' IDENTIFIED BY 'magedu';
MariaDB [(none)]> FLUSH PRIVILEGES;
Manager節點上再次運行， 就顯示Ok了。
第五步：啓動MHA
[root@node4 ~]#nohup masterha_manager -conf=/etc/mha_master/app1.cnf &> /etc/mha_master/manager.log &
啓動成功後， 可用過如下命令來查看master節點的狀態:
[root@node4 ~]#masterha_check_status -conf=/etc/mha_master/app1.cnf
app1 (pid:4978)is running(0:PING_OK),master:172.16.252.18
上面的信息中“app1 (pid:4978)is running(0:PING_OK)”表示MHA服務運行OK，否則， 則會顯示爲類似“app1 is stopped(1:NOT_RUNNINg).”
如果要停止MHA， 需要使用master_stop命令。
[root@node4 ~]#masterha_stop -conf=/etc/mha_master/app1.cnf
五、測試MHA測試故障轉移
1、在master節點關閉mariadb服務,模擬主節點數據崩潰
killall -9 mysqld mysqld_safe
rm -rf /var/lib/mysql/*
2、在manager查看日誌
tail -200 /etc/mha_master/manager.log
……
Thu Nov 23 09:17:19 2017 - [info] Master failover to 172.17.254.181(192.168.254.181:3306) completed successfully.
3、查看當前的manager狀態，會提示mha停止
masterha_check_status –conf=/etc/mha_master/app1.cnf
app1 is stopped(2:NOT_RINNING)
4、提供新的從節點以修復複製集羣
原有 master 節點故障後， 需要重新準備好一個新的MySQL節點。基於來自於master節點的備份恢復數據後將其配置爲新的 master 的從節點即可。 注意，新加入的節點如果爲新 增節點，其IP地址要配置爲原來master節點的IP，否則還需要修改 app1.cnf 中相應的 ip 地址。隨後再次啓動manager，並再次檢測其狀態。也就是說把故障的master節點變成新的master的從節點，注意備份的問題，避免數據脫節。
現在slave1已經是主了。所以我們對它進行完全備份。
mysqldump --all-database > /backup/date +%F-%T.sql
然後把文件傳送給原來的master
scp 2017-11-23-22:09:25.sql [email protected]:/root/
注意的是：我也不知道爲什麼會提示傳送解析不了，所以我就去原來的主上直接來下載了。
5、在原來的主上進行數據恢復
mysql -uroot <2017-11-21_09:43:22-all.sql；
6、接下來配置主從，照例查看一下現在的主的二進制日誌的位置，然後進行新的從節點配置：
Node1：
change master to master_host='172.17.254.181', master_user='slave', master_password='magedu', master_log_file='master-log.000003', master_log_pos=1044;
這裏需要提示的是，不需要主上再次授權，因爲之前主從複製的時候複製過去的邏輯語句已經執行過了。
7、新節點提供後再次執行檢查操作
masterha_check_repl -conf=/etc/mha_master/app1.cnf
8、檢查無誤， 再次運行， 這次要記錄日誌
masterha_manager -conf=/etc/mha_master/app1.cnf >/etc/mha_master/manager.log 2>&1
9、可用如下命令來查看master節點的狀態：
masterha_check_status -conf=/etc/mha_master/app1.cnf
mha (pid:9561) is running(0:PING_OK), master:171.17.254.181
六、新節點上線， 故障轉換恢復注意事項
(1)、 在生產環境中， 當你的主節點掛了後， 一定要在從節點上做一個備份， 拿着備份文件把主節點手動提升爲從節點， 並指明從哪一個日誌文件的位置開始複製
(2)、 每一次自動完成轉換後， 每一次的(replication health )檢測不ok始終都是啓動不了必須手動修復主節點， 除非你改配置文件
(3)、 手動修復主節點提升爲從節點後， 再次運行檢測命令
[root@node5 ~]# masterha_check_repl --conf=/etc/mha_master/app1.cnf
app1 (pid:3211) is running(0:PING_OK), master:172.17.254.181
(4)、 再次運行起來就恢復成功了
masterha_manager --conf=/etc/mha_master/app1.cnf
七、易錯點
問題1、 Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
原因：二進制名稱寫錯
問題2、 Opening /var/lib/mysql/relay-log.info ...Could not open relay-log-info file /var/lib/mysql/relay-log.info.
原因：master|relay.info兩個文件，主從配置好過後一定有的文件。需要檢查一下從服務器有沒有這個文件
問題3、scp 2017-11-23-22:09:25.sql [email protected]:~
ssh: Could not resolve hostname 2017-11-23-22: Name or service not known
原因：不知道 ，上傳不行，我就下載了。
問題4、ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ''1044'' at line
原因：,MASTER_LOG_POS='1044'; 多了一個雙引號。
問題5、Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
原因：複製的二進制數據庫寫錯了。
問題6、[error][/usr/share/perl5/vendor_perl/MHA/ServerManager.pm, ln301] Got MySQL error when connecting 172.17.254.171(172.17.254.171:3306) :1130:Host '172.17.254.238' is not allowed to connect to this MariaDB server, but this is not a MySQL crash. Check MySQL server settings.
原因：每一個數據庫都可以是主節點，所以需要在主上再一次授權。
實驗總結：都是自己挖的坑，配置文件要檢查好，不要寫錯，寫掉，授權容易出錯，一定要注意。