mysql两主多从
1.實現(xiàn)目標(biāo)
?目標(biāo)清單：
??? 1）Master（192.168.31.230）為正常運行環(huán)境下的主庫，為兩個Slave（192.168.31.231和192.168.31.232）提供“主-從”復(fù)制功能；
??? 2）Master_Backup(192.168.31.233)是Master的備份庫，只要Master是正常的，它不對外提供服務(wù)。它與Master之間屬于"主-主"復(fù)制關(guān)系，即自己既是主機，又是對方的從機；
??? 3）同理，192.168.31.234和192.168.31.235為Slave_Backup，分別為192.168.31.231和 192.168.31.232的備份庫，只要Slave是正常的，對應(yīng)的備份機不對外提供服務(wù)；
??? 4）Slave在此架構(gòu)中的目的是為了實現(xiàn)讀寫分離，對應(yīng)用程序來說，Master只負責(zé)寫，兩個Slave只負責(zé)讀。Slave的數(shù)據(jù)來源于Master的復(fù)制操作；
??? 5）如果Master由于某種原因（例如：宕機和斷電等）導(dǎo)致不能正常運行，則此時需要讓Master_Backup自動切換為新主機，而Slave和Slave_Backup也能自動切換數(shù)據(jù)源到Master_Backup；
??? 6）同理，如果Slave由于某種原因（例如：宕機和斷電等）導(dǎo)致不能正常運行，則此時需要讓對應(yīng)的Slave_Backup自動切換為新從機；
??? 7）無論是Master還是切換后的Master_Backup，它們向客戶端提供的連接地址應(yīng)保持一致，如上圖提供的VIP+Port，即192.168.31.201:3306，Slave和Slave_Backup也應(yīng)如此，對外提供的連接地址始終是192.168.31.202:3306和192.168.31.203:3306。
?2.實現(xiàn)過程
???? MySQL安裝步驟不在此講述。
2.1實現(xiàn)Master-Master結(jié)構(gòu)
2.1.1修改Master和Master_Backup配置文件，vi /etc/my.cnf
??? 主要在[mysqld]內(nèi)添加如下配置項：
Sql配置代碼 ???? 由于是Master-Master結(jié)構(gòu)，因此需在雙方終端中執(zhí)行如下SQL命令：
Sql代碼 ?2.1.3在從機上指定Master數(shù)據(jù)源
?? 1）在Master上執(zhí)行
Sql代碼 ???? 重點關(guān)注File和Position兩個字段值
??? 2）在Master_Backup也執(zhí)行上述步驟，由于是初始狀態(tài)，得到的結(jié)果和上圖一樣；
??? 3）在Master上執(zhí)行如下SQL命令，填入Master_Backup的host、鏈接賬號和密碼、File和Position值
Sql代碼 ?2.1.4測試
??? 1）當(dāng)Master和Master_Backup都正常運行時，在任意一端更新數(shù)據(jù)后都會同步到另一段；
??? 2）當(dāng)Master處于不可運行時，在Master_Backup更新數(shù)據(jù)后重啟Master，這時在Master上可得到最新的數(shù)據(jù)；
??? 3）當(dāng)Master_Backup處于不可運行時，在Maste更新數(shù)據(jù)后重啟Master_Backup，這時在Master_Backup上可得到最新的數(shù)據(jù)。
2.2實現(xiàn)Master-Slave結(jié)構(gòu)
2.2.1實施過程
???? 將2.1.1和2.1.3的過程在所有Slave上操作一遍即可，需要注意配置文件中server-id一定要唯一，還有在執(zhí)行CHANGE MASTER TO命令時，MASTER_HOST為192.168.31.230
??? 1）當(dāng)Master和Master_Backup都正常運行時，在任意一端更新數(shù)據(jù)后都會同步到兩個Slave上；
??? 2）當(dāng)Master處于正常運行時，在此端更新數(shù)據(jù)后都會同步到兩個Slave上，而無論Master_Backup是否正常；
??? 3）當(dāng)Master處于不可運行時，Master_Backup通過Monitor（Keepalived）成為接管者，在Master_Backup更新數(shù)據(jù)后都會同步到所有Slave上，并且重啟Master后，最新數(shù)據(jù)也會同步到此端。
??? 可事與愿違，在第3）種場景下，Master_Backup不會將數(shù)據(jù)同步給Slave，即使后來在Slave上將MASTER_HOST指定為Keepalived提供的VIP（192.168.31.201）也無濟于事：
Sql代碼 ???? 在Slave上執(zhí)行SHOW SLAVE STATUS;
??? 得出如下結(jié)果：
???? 究其原因，如上圖所示，Master_Server_Id為230，仍然指向的是已經(jīng)處于不可運行的Master，而預(yù)期結(jié)果是希望它能自動的更新定位到Master_Backup(233)上，達到自動切換的目的。
???? 沒辦法，只有自己執(zhí)行CHANGE MASTER TO...手動定位了。我草...，一不注意就會定位錯誤，造成數(shù)據(jù)丟失的問題，而且也不滿足快速響應(yīng)容災(zāi)切換的目的。
3.最終方案
??? 最終方案將選擇mysql-mmm結(jié)合半同步機制來實現(xiàn)容災(zāi)自動切換。
3.1在master(230和233)上安裝semisync master并設(shè)置
Sql代碼 ??vi /ect/my.cnf后加入如下配置：
配置代碼 ?3.2在slave(231、232、234和235)上安裝slave插件并設(shè)置
Sql代碼 ??vi /ect/my.cnf后加入如下配置：
配置代碼 ?3.3所有mysql實例停止slave并開啟slave，使半同步機制生效
Sql代碼 ?3.4查看semisync狀態(tài)
Sql代碼 ??重點關(guān)注:
1）Rpl_semi_sync_master_clients：與當(dāng)前master建立半同步連接的客戶端數(shù)；
2）Rpl_semi_sync_master_status：作為半同步master端的就緒狀態(tài)（ON：就緒，OFF：未就緒）
3）Rpl_semi_sync_slave_status：作為半同步slave端的就緒狀態(tài)（ON：就緒，OFF：未就緒）
3.5安裝mysql-mmm
3.5.1新增一臺專門用于監(jiān)控mysql的服務(wù)器（mysql_monitor），IP為192.168.31.250
3.5.2在mysql_monitor、master、master_backup、slave和slave_backup上安裝epel網(wǎng)絡(luò)源
Linux命令行代碼 ?3.5.3在mysql_monitor上安裝mysql-mmm-monitor
Linux命令行代碼 ?3.5.4在master、master_backup、slave和slave_backup上安裝和配置
1）安裝mysql-mmm-agent
Linux命令行代碼 ??2）授權(quán)monitor訪問
Sql代碼 ?3）編輯mmm_agent.conf配置文件
vi /etc/mysql-mmm/mmm_agent.conf
Mmm_agent.conf配置文件代碼 ?4）編輯mmm_common.conf配置文件
vi /etc/mysql-mmm/mmm_common.conf
Mmm_common.conf代碼 ??注意，需要將此配置文件復(fù)制到mysql_monitor的同名目錄下
3.5.5在master、master_backup、slave和slave_backup上啟動mmm agent服務(wù)，并設(shè)置為開機服務(wù)
執(zhí)行如下啟動命令：
Linux命令行代碼 ??如果出現(xiàn)如下示例信息：
則說明配置成功
vi /etc/rc.d/rc.local后，將上述命令行添加到mysql啟動命令的下面
3.5.6編輯mysql_monitor上的配置文件mmm_mon.conf
vi /etc/mysql-mmm/mmm_mon.conf
Mmm-mon.conf代碼 ???? 執(zhí)行如下啟動命令：
Linux命令行代碼 ???? 如果出現(xiàn)如下示例信息：
??? 則說明配置成功
vi /etc/rc.d/rc.local后，將上述命令行添加于此
3.5.8重啟所有服務(wù)器系統(tǒng)后測試
1）在mysql_monitor上執(zhí)行如下命令，查看各監(jiān)控機的運行狀態(tài)
Linux命令行代碼 ????? 理想情況下，所有的MySQL都應(yīng)該處于“ONLINE”狀態(tài)，這里的結(jié)果與第1節(jié)中的目標(biāo)清單有一定誤差，因為202和203這個“讀”IP浮動到slave正好與預(yù)期結(jié)果相反，這和MySQL的啟動順序有關(guān)，而且最重要的是在mmm_common.conf中沒有作嚴(yán)格的控制，對于兩個slave(231和232)和兩個slave_backup(234和235)來說，得到202和203這兩個"讀"IP的機會是均等的。
???? 現(xiàn)在重新執(zhí)行2.2.2節(jié)的測試場景3），停掉maste后稍等片刻，再執(zhí)行mmm_control show得到如下結(jié)果：
???? 原來的master已處于不可用（HARD_OFFLINE）狀態(tài)，master_backup(233)成為了新的master，此時再在各slave和slave_backup上執(zhí)行SHOW SLAVE STATUS;
???? 可以看出，不用再自己手動定位，就可以讓Master_Host和Master_Server_Id自動定位到當(dāng)前處于“ONLINE”狀態(tài)的Master_Backup上。
??? 1）在Master_Backup上更新數(shù)據(jù)，在所有的slave和slave_backup上可以很快的查詢到最新的數(shù)據(jù)；
??? 2）重啟Master并稍等片刻后，在這臺主機上也可以查詢到最新的數(shù)據(jù)，此時writer權(quán)限仍在Master_Backup上。
4.最終架構(gòu)
5.總結(jié)
?????? 接3.5.8測試場景2），雖然Master已恢復(fù)了“ONLINE”狀態(tài)，但整個架構(gòu)是“非搶占式”的，writer權(quán)限仍在Master_Backup上，所以在Master上更新數(shù)據(jù)不會同步到其它主機上。因此，在實際使用過程中，除進行數(shù)據(jù)庫維護用真實IP訪問之外，其余操作都只使用VIP來進行，201為wirter，202和203為reader。
?????? 從第4節(jié)的架構(gòu)圖中看出，Mmm_Mnitor存在單點問題，當(dāng)Mmm_Mnitor處于不可運行時，整個主從結(jié)構(gòu)將不能正常運行。可以部署多個監(jiān)控，結(jié)合Keepalived來擴展。
?????? "主-主"和“主-從”架構(gòu)通常有兩個目的：第一是為了進行容災(zāi)備份，當(dāng)數(shù)據(jù)庫發(fā)生不可預(yù)知的錯誤導(dǎo)致不可運行甚至丟失數(shù)據(jù)時，其余的備份機可以繼續(xù)對外提供數(shù)據(jù)讀寫服務(wù)。第二是為了分?jǐn)倲?shù)據(jù)庫壓力實現(xiàn)"讀寫分離"。
?????? 讀寫分離會帶來數(shù)據(jù)延遲達到的問題。假設(shè)有一個業(yè)務(wù)，當(dāng)數(shù)據(jù)插入到數(shù)據(jù)庫后要立即又從數(shù)據(jù)庫中將此數(shù)據(jù)查詢出來，因此當(dāng)數(shù)據(jù)插入到Master庫后，由于網(wǎng)絡(luò)的延遲，Slave庫中不會立即得到這條最新的數(shù)據(jù)，此時應(yīng)用程序查詢Slave庫將得不到預(yù)期結(jié)果。
?????? 通常有如下兩個方案解決上述問題：
?????? 1）將此類業(yè)務(wù)控制在一個數(shù)據(jù)庫事務(wù)中進行，讀寫都在master中進行。因此，在mmm_common.conf配置文件中，還需要將db1和db2同時配置在reader組：
Mmm_common.conf配置摘要代碼 ???? 2）使用Zookeeper來解決分布式一致性問題，后續(xù)單獨再來介紹。
總結(jié)
- 上一篇： CentOS Linux解决Device
- 下一篇： Tomcat8中的并发Concurren