關鍵詞：mysql高可用概述，mysql高可用架構
常用高可用方案
20190918 現在業內常用的MySQL高可用方案有哪些？
目前來說，用的比較多的開源方案分內置高可用與外部實現，內置高可用有如下：
1、官方版本分支：MGR（首推）
2、percona分支：PXC
3、MariaDB：Galera Cluster
外部實現方案：
1、orchestrator(GTID)
2、replication-manager(GTID)
3、MHA(傳統復制)
4、MOHA(支持多AZ部署)
5、其他...
【1】Mysql Replication ：Mysql復制
【1.1.1】mysql支持的復制類型
基於binlog的3種模式（詳情參考：binlog的3種日志記錄模式），oracle在mysql5.5版本收購
【1.1】statement：基於語句的復制（5.5.6之前默認），主服務器執行的SQL語句，在從服務器執行同樣的語句
【1.2】row：基於行的復制（5.5.7之后默認），把改變的內容復制到從庫，而不是把SQL命令在從庫重新執行一遍。mysql5.0就開始支持
【1.3】mixed：混合類型的復制，默認是使用 statement 語句方式復制，一旦發現基於語句無法精確復制時（比如now() 因為主從有延遲導致數據不一致）就會采用基於 row 行的方式復制。
【1.1.2】mysql的4種同步方式介紹
以下圖片均引用自《深入淺出mysql開發、優化與管理維護》
【1.2.1】異步復制（和MSSQL的高性能模式鏡像一樣）：（3.23 native）
主庫只管binlog dump數據到從庫，不保證主從完全一致，斷電、崩潰等情況會丟失數據。
【1.2.2】全同步復制：
【2.2.1】核心概念：主從復制，主庫要等到從庫重做事務並且提交成功，接受到ACK成功確認標識后，主庫才能提交事務。
【2.2.2】與半同步的區別：半同步是只需要持久化到relay log階段即可返回ACK成功標識給主庫，而全同步需要等待從庫SQL進程完整的運行完該事務內容才能返回ACK成功標識。
【2.2.3】原理：
主庫事務寫入redo log和 binlog 文件后，binlog dump線程提取binlog數據給IO線程，IO線程把數據加載回從庫的relay log文件。
從庫SQL線程開啟事務重做應用relay log數據操作，等從庫提交完后，返回ACK確認標識，主庫才會提交。
【1.2.3】傳統半同步復制：（自5.5開始，插件）
【1.2.3.1】原理：
master事務commit 指令已經寫入binlog（注意，這里已經提交了，再去同步，只是在等一個ACK）和 binlog 文件后，binlog dump線程提取binlog數據給IO線程，IO線程把數據加載回從庫的relay log文件。
只要IO線程-》slave的relay log已經flush disk 磁盤落地，slave就返回ACK確認標識給master。
【1.2.3.2】特性：
這里的commit主庫上是已經在 binlog、redo log 中提交了的，其他session都可以看到。
但需要等待從庫返回ACK確認標識才會把事務提交到存儲引擎持久化（即 ibdata、ibd等磁盤數據文件）且返回到client一個commit成功的指令。
【1.2.3.3】宕機情況：
master上這個事務其實是已經提交了並且落盤master的binlog了，master的其他Session是可以看到這個提交后的事務的，而slave還沒有commit。
這個時候master掛了，master上的數據和slave不一致。master crash后，master根據redo重做提交了這個事務.
在切換到從后，slave因為沒有commit而回滾了這個事務導致數據丟失。導致主從不一致。
【1.2.4】增強半同步復制（mysql 5.7.4及以上才可以用，與MSSQL鏡像高安全模式相同）：
與【1.2.3】傳統半同步復制大致一樣。唯一的區別就是，在事務提交過來后：
核心區別：主庫會等從庫在relay log 階段持久化該事務到該文件后，接受ACK成功確認標識后，再進行提交（commit指令寫入binlog/redolog）
【1.2.4.1】傳統的半同步復制：
master 會把事務在主庫先提交了，其他訪問可以查看到，只是等從庫返回ACK標識才反饋給client 事務提交成功信息。
【1.2.4.2】增強半同步復制：
master 只會寫binlog，然后等slave的IO線程把事務持久化（flush disk）到 relay log 上后，返回ACK確認標識。
master收到確認標識后才會commit 寫入到binlog 和 redo log，並返回給客戶端commit成功的指令。
【1.2.4.3】宕機情況：
主庫上這個事務因為沒有寫入redo log，所以這個事務被認為是未提交。master的其他session是不可以看到這個事務的。
這個時候主庫掛了，master上的數據和slave一致，master crash后，slave不丟數據。
【1.2.5】GTID 復制（mysql 在 5.6.2 及之后開始支持GTID）：
【1.2.5.1】GTID（Global Transaction Identifiers）概念：
對於一個已提交事務的編號，事務的唯一編號，並且是一個全局唯一的編號。GTID和事務會記錄到binlog中，用來標識事務。
GTID是用來替代以前，傳統復制方法（binlog+position），mysql 5.6.2開始支持GTID。
mysql支持GTID后，一個事務在集群中就不再孤單，在每一個節點中，如果存在具相同標識符的情況，可以避免同一個事務，在同一個節點出現多次的情況。
（可以初步理解成row模式的，和statement的區別，前者記得是具體做了什么事，后者記錄的是位置）
GTID的出現最直接的效果就是，每一個事物在集群中具有了唯一性的意義，相對於行復制來講數據安全性更高，故障切換更簡單。
【1.2.5.2】簡單案例解釋概念：
比如，當我們一主2從，主出故障后切換到從DB1上去了，那么另外2台機器，需要重新手動構建主從；
具體為：
-- 使用傳統方式構建的主庫宕機重新搭建 -- 麻煩點：每台機器的Binlog名字和Postion位置點都不一樣，需要重新定位文件在哪里，位置在哪里 change master to master_host='xxx', master_user='xxx', master_password='xxx', master_port='xxx', master_log_file='xxx', master_log_pos='xxx'; -- 使用GTID方式的主庫宕機重新搭建 -- 優勢點：每台機器上的GTID都是一樣的，不需要管文件是哪個，位置在哪里，可以自動根據GTID定位 change master to master_host='xxx', master_user='xxx', master_password='xxx', master_port='xxx', master_auto_postion=1;
【1.2.5.3】GTID的組成
GTID 是由 server_uuid：Sequence_Number 組成；
（1）server_uuid：是一個mysql實例的全局唯一表示；存放在 ${datadir}/auto.cnf
（2）Sequence_Number：是mysql內部的一個事務的標號，一個mysql實例不會重復的序列號（保證服務器內唯一），也表示在該實例上已經提交事務的數量，並且隨着事務提交而遞增。
（3）根據GTID可以知道事務最初是在哪個實例上提交的，方便故障排查和切換
【1.3】復制之間的區別
【2】MGR（Mysql Group Replication）
Mysql群組復制（mysql 5.7.19）
相關介紹參考：https://www.cnblogs.com/luoahong/articles/8043035.html
【2.1】基本概念介紹
由MySQL基於Paxos所開發的，基本復制理念如下圖
所有機器都是主，為了避免數據沖突在執行提交一個事務后，會先進行數據沖突驗證，然后才進行binlog寫入與relay log復制。
由若干個節點共同組成一個復制組，一個事務的提交，必須經過組內大多數節點（N / 2 + 1）決議並通過，才能得以提交。如上圖所示，由3個節點組成一個復制組，Consensus層為一致性協議層，在事務提交過程中，發生組間通訊，由2個節點決議(certify)通過這個事務，事務才能夠最終得以提交並響應。
引入組復制，主要是為了解決傳統異步復制和半同步復制可能產生數據不一致的問題。組復制依靠分布式一致性協議(Paxos協議的變體)，實現了分布式下數據的最終一致性，提供了真正的數據高可用方案(是否真正高可用還有待商榷)。其提供的多寫方案，給我們實現多活方案帶來了希望。
除了多master和數據驗證以外，可以暫時理解成后面的所有步驟和半同步復制一樣。
【2.2】MGR架構
（1）整體架構
（2）replication plugin 插件
（3）GCS
【2.3】MGR的模式
【2.3.1】單主模式（single primary mode）
（1）單主模式基本架構與形式概念
（2）單主模式的運行機制
【2.3.2】多主同步模式
（1）多主同步模式的沖突檢測（核心是基於主鍵），這個檢測就是certify
這個沖突檢測就是最開始運行原理的certify
如果真有主鍵相同的操作執行了怎么辦？先執行的提交，后執行的沖突回滾，如圖
（2）多主同步模式下的限制
限制和規則
•僅InnoDB Engine(Transactional and row level lock)
•表必須有主鍵
•gtid-mode=ON
•binlog格式為Row-based
•對於同一個對象執行DDL和DML應在同一成員上執行，不支持在不同服務器上執行DDL
•不支持具有多級外鍵依賴關系的表，特別是已定義CASCADING外鍵約束的表
•不支持“serializable”隔離級別
【2.4】MGR的監視
（1）常用系統表監視
兩個performance_schema表
•replication_group_members
•replication_group_member_stats
本地成員狀態
•擴展Replication performance_schema 表
•group_replication_recovery channel information
•group_replication_applier channel information
•新的全局變量
•group_replication_primary_member
（2）MGR群組復制的高可用性
更好的容錯度
群組復制的高可用性
–故障（Ｆ）所需的服務器數量（N）N = 2F + 1.
–最多支持9個成員
•允許4個成員故障。
–沒有腦裂的問題
•僅當大多數成員（N/2+1）在線時，群組才可用，如下圖
【2.5】 腦裂問題
（1）什么是腦裂？（2）MGR為什么會出現腦裂？
（1）什么是腦裂：我理解的就是，一個大腦控制變成了2個大腦控制，各做各的。產生了不同步，不一致的操作與選擇。
（2）MGR為什么會出現腦裂：大多數情況是因為網絡連接問題。如下圖
檢測網絡分區：Performance_Schema.replication_group_members
有2個可能-》《1》真就另外3台掛掉了 《2》另外3台沒掛，是因為和這2台連不上了無法通信
我們這里說《2》這種情況
即，本來MGR群組的5台機器都能互相連通，突然，S3-S5這3台機器與S1-S2機器失去了連接。
只有這S1-S2這2台機器被監控到在線，但其他3台機器是多數節點，它們也可能有連接在使用。對於S3-S5而言，S1-S2是宕機概念的。
然后對於S3-S5而言的MGR是可以正常運行的，就把其S1-S2丟失了。
這個時候S1-S2 這2台 查詢可以正常運行，但不可以進行增刪改（如果發生增刪改，就無法再次回到MGR群主里了），如下圖
如何處理呢？強制指定節點生成一個新的MGR。
【2.6】MGR讀取一致性參數解析
group_replication_consistency8.0.14之后
•EVENTUAL，BEFORE，AFTER和BEFORE_AND_AFTER
（1）EVENTUAL（默認值）事務在執行之前不等待先前的事務應用，也不等待其他成員應用其更改。這是8.0.14之前的
（2）BEFORE
事務將在開始執行之前等待所有先前的事務完成。這可確保此事務將在最新的數據快照上執行，而不用管是哪個成員。
（3）AFTER
事務將等待其更改已應用於其他成員。這可確保一旦此事務完成，所有后續事務都會讀取包含其更改的數據庫狀態，而不管它們在哪個成員上執行。
（4）BEFORE_AND_AFTER
•此事務將等到：
1）所有先前的事務在開始執行之前完成;
2）其變更已適用於其他成員。這可確保：
1）此事務將在最新的數據快照上執行;
2）一旦此事務完成，所有后續事務都會讀取包含其更改的數據庫狀態，而不管它們在哪個成員上執行
【2.7】了解MGR節點狀態
參考：https://blog.csdn.net/d6619309/article/details/70432640
【3】MHA（Master High Availability）
主庫高可用，實現故障轉移與主從分離，在MySQL故障切換過程中。
MHA能做到在0~30 秒之內自動完成數據庫的故障切換操作，並且在故障切換過程中，MHA能在最大程度上保證數據的一致性。
【3.1】MHA的組成概念與部署概念
MHA由兩部分組成：MHA Manager（管理節點）和MHA Node（數據節點）。
MHA Manager可單獨部署在一台機器上管理多個master-slave集群，也可以部署在一台slave節點上。
MHA Node運行在每台MySQL服務器上，MHA Manager會定時探測集群中的master節點。
當master出現故障時，它可以自動將最新數據的slave提升為新的master，然后將所有其他的slave重新指向新的master，整個故障轉移過程對應用程序完全透明。
MHA Manager：
（1）master自動切換及故障轉移命令運行
（2）其他的幫助腳本運行：手動切換master；master/slave 狀態監測
MHA Node：
（1）復制主節點的binlog數據
（2）對比節點的中繼日志文件
（3）無需停止從節點的SQL線程，定時刪除中繼日志
【3.2】MHA的基本工作原理
（1）從宕機崩潰的master保存二進制日志事件（binlog events）
（2）識別含有最新更新的slave；
（3）應用差異的中繼日志到其他的slave；
（4）應用從master保存的二進制日志事件（binlog events）；
（5）提升一個slave為新的master；
（6）是其他的slave連接新的master進行復制；
【3.3】MHA常用架構
服務器資源：
（1）至少5台PC，其中2台mysql主庫，2台mysql從庫，1台MHA Monitor
（2）其中的MHA Monitor 可以選擇低配（即為 MHA MANAGER）
（3）如果不采用F5等作為從庫的負載均衡器，可用2台PC SERVER部署LVS 或 HAProxy + Keepalived組合來代替；
優點：雙主熱備，讀寫分離，SLAVE集群可以線性擴展
缺點：讀寫分離需要再程序段解決，但Master大批量寫操作時會產生主從延時。
實際架構方案《1》《2》
《1》1主3從
數據庫層面：一主三從，選定某一台從為故障切換后的主。
客戶端-》VIP-》負載均衡-》中間件讀寫分離-》主PC1寫
-》從PC2~PC4讀，PC2指定為故障切換的master
《2》2主2從
數據庫層面：2主構成VIP，現在正在寫的主庫把所有數據同步到另外3台機器。
一般情況下，只有一台主工作，另外一台主空閑待機。
【3.4】MHA的優缺點
優點：
由Perl語言開發的開源工具
由master自動監控和故障轉移
master crash 不會導致主從數據不一致
可以支持基於 GTID的復制模式（MYSQL 5.7）
MHA在進行故障轉移時更不易產生數據丟失
同一個監控節點可以監控多個集群
MHA加強了數據的安全性
缺點：
需要編寫腳本或利用第三方工具來實現VIP的配置
MHA啟動后，只會對主數據庫進行監控
需要基於SSH免認證配置，存在一定的安全隱患
沒有提供從服務器的讀負載均衡功能
【3.5】MHA的工具組件中的常用腳本
（1）Manager工具組件：
masterha_check_ssl：檢查MHA的SSH配置
masterha_check_repl：檢查mysql復制
masterha_manager：啟動MHA
masterha_check_status：檢測當前MHA運行狀態
masterha_master_monitor：監測Master是否宕機
masterha_master_switch：控制故障轉移（自動或者手動）
masterha_conf_host：添加或刪除配置的server信息
（2）Node工具組件：（這些通常由MHA Manager的腳本出發，無需人工操作）
save_binary_logs：保存和復制master的二進制日志
apply_diff_relay_logs：識別差異的中繼日志事件兵並用於其他slave
filter_mysqlbinlog：清除不必要的rollback事件（MHA已經不再使用它）
purge_relay_logs：定期清除中繼日志（不會阻塞SQL線程）
（3）自定義擴展
secondary_check_script：通過多條網絡路由檢測master的可用性；
master_ip_failover_script：更新application使用的masterip（需要修改）
shutdown_script：強制關閉master節點
report_script：發送報告；
init_conf_load_script：加載初始配置參數；
master_ip_online_change：更新Master節點IP地址
【4】雙主KeepAlived
【4.0】概念
MySQL的高可用方案有很多，比如Cluster、MMM、MHA、DRBD，以及Oracle官方推出的Fabric等，這些方案各有優劣，但都比較復雜，安裝配置有一定難度，對線上庫實施動靜太大。就我們的具體情況而言，並不需要這么復雜的環境，實施簡單、對現有架構影響最小、能迅速解決問題的方案才是最適合的。比如我們現在只是配置了MySQL Replication，加上如Keepalived這樣的高可用軟件，就能實現我們的需求。
MySQL架構為Master/Slave，當Master故障時，虛IP漂移到Slave上提供服務，簡單環境如圖1所示。在這種架構中，故障自動切換以后，需要采取手動操作的方式與新的Master進行復制。當然也可以設置為Active-Passive模式下的雙Master復制。
利用KeepAlived實現故障轉移（功能上類似於MSSQL的鏡像，形式上類似於windows的故障轉移群集）
【4.1】keepalived 簡介
（4.1.1）起源
keepalived軟件起初是專門為了LVS負載均衡軟件設計的，用來管理並監控LVS集群系統中各個服務節點的狀態，后台又加入了可以實現高可用的VRRP功能。（VRRP：全稱 virtual router redundancy protocol，虛擬路由冗余協議）
因此Keepalived除了能夠管理LVS軟件外，還可以作為其他服務（如：Nginx/Haproxy/Mysql）的高可用解決方案軟件；
（4.1.2）實現與組成
keepalived 軟件主要是通過VRRP協議實現高可用功能的。
VRRP是 virtual route redundancyProtocol（虛擬路由器榮譽協議）的縮寫，VRRP出現的目的就是為了解決靜態路由單點故障問題，它能夠保證當個別節點宕機時，整個網絡可以不間斷的運行。
（4.1.3）常見運作場景
一個web服務器至少有2台PC運行Keepalived，一台作為主服務器(master)，一台作為備份服務器（Backup），但是對外表現為一個虛擬IP，在Keepalived服務政策工作時，主Master節點會不斷地向備節點發送（多播的方式，組播地址為224.0.0.18）心跳消息，用以告訴備節點自己還活着。
當主Master節點發生故障時，就無法發送心跳消息，備節點也就因此無法繼續監測到來自主Master節點的心跳，於是調用自身接管程序，接管主Master節點的IP資源及服務。
而當主Master節點恢復時，備Backup節點又會釋放主節點故障時自身接管的IP資源及服務，恢復到原來的備用角色。（搶占模式）（也可以設置成非搶占模式，讓其保持主，而不釋放資源給原主，具體見4.1.7）
所以，keepAlived，一方面具有配置管理LVS的功能，同時還具有對LVS下面節點進行健康檢查的功能，另一方面也可以實現系統網絡服務的高可用功能，而且Keepalived是可以工作在網絡的 Layer3,4&7，即網絡層（IP層），傳輸層（TCP層），及應用層，再后面就直接在很多場景下代替了原始的LVS軟件方案。
（4.1.4）keepalived服務的三個重要功能
（1）管理LVS負載均衡軟件
（2）實現LVS集群節點的健康檢查
（3）作為系統網絡服務的高可用性（failover）
（4.1.5）Keepalived服務的工作原理
Keepalived服務對之間通過VRRP進行通信的，VRRP是通過競選機制來確定主備的（有點像故障轉移群集中的投票仲裁形式），主的優先級高於備，因此工作時主會優先獲得所有的資源，備節點處於等待狀態，當主掛了的時候，備節點就會接管主節點的資源，然后頂替主節點對外服務。
在Keepalived服務對之間，只有作為主的服務器會一直發送VRRP廣播包，告訴備它還活着，此時備不會搶占主，當主不可用（也就是備沒有受到VRRP廣播包信息），就會啟動相關服務接管資源，保證業務的連續性，接管速度最快可以小於1秒。
（4.1.6）keepalived 的三個核心模塊
分別是core/check/vrrp
core：keepalived的核心，負責主進程的啟動、維護以及全局配置文件的加載和解析。
check：負責健康檢查，包括常見的各種檢查方式。
vrrp：是用來實現VRRP協議的；（VRRP：全稱 virtual router redundancy protocol，虛擬路由冗余協議）
（4.1.7）什么是VRRP？
VRRP,全稱 virtual router redundancy protocol，虛擬路由冗余協議。
VRRP的出現就是為了解決靜態路由的單點故障問題，VRRP是通過一種競選機制來將路由的任務交給某台VRRP路由器的。
（1）VRRP是怎么解決通信問題的？
在現實的網絡環境中，兩台需要通信的主機（end-host）大多數情況下並沒有直接地物理連接。對於這樣的情況，它們之間的路由怎么選擇？通常有兩種方法解決如何選定到達目的主機的下一跳路由問題：
使用動態路由協議，如RIP、OSPF等。
配置靜態路由。
很明顯，在主機上配置動態路由，因為管理、維護成本以及是否支持等諸多問題是不切實際的。那么配置靜態路由就變得很流行。
實際上，這種方式一直沿用至今。但是，路由器，或者說默認網關（default gateway）卻經常成為單故障點。就算配置了多個靜態路由，卻因為必須重啟網絡才能生效而變得不實用。
VRRP（虛擬路由冗余協議，Virtual Router Redundancy Protocol)的目的就是為了解決靜態路由單點故障問題。
它通過一種競選（election）協議動態地將路由任務交給LAN中虛擬路由器中的某台VRRP路由器。這里有兩個關鍵名詞：VRRP路由器和虛擬路由器。
VRRP路由器：VRRP路由器就是一台路由器，只不過上面運行了VRRPD程序來實現VRRP協議而已，是物理的路由器。一台VRRP路由器可以位於多個虛擬路由器中。
虛擬路由器：所謂虛擬，就是說並不是實際存在的，是一個邏輯而不是物理的路由器。
虛擬路由器通常由多台VRRP路由器通過某種方式組成，就好像將這些物理路由器都丟到一個池里面去，整個池對外看起來就像是一台路由器，但其實內部有多台。虛擬路由器的標識稱為VRID。
在一個VRRP虛擬路由中，有多台物理的VRRP路由器，但是這多台物理路由並不同時工作，而是由一台稱為master的負責路由工作，其它的都是backup。
master並非一成不變，VRRP協議讓每個VRRP路由器參與競選，最終獲勝的就是master。master有一些特權，比如擁有虛擬路由器的IP地址，我們的主機就是用這個IP地址作為靜態路由的。
擁有特權的master要負責轉發發送給網關地址的包和響應ARP請求。
（2）VRRP的工作機制
VRRP通過競選協議來實現虛擬路由器的功能，所有的協議報文都是通過IP多播（multicast）包形式發送的，多播地址為224.0.0.18。虛擬路由器由VRID（范圍0-255）和一組IP地址組成，對外表現為一個眾所周知的MAC地址：00-00-5E-00-01-{VRID}。所以，在一個虛擬路由器中，不管誰是master，對外都是相同的MAC和IP（稱之為VIP）。客戶端主機並不需要因為master的改變而修改自己的路由配置，對它們來說，這種主從的切換是透明的。
在一個虛擬路由器中，只有作為master的VRRP路由器會一直發送VRRP廣告包（VRRP Advertisement Message），backup不會搶占master，除非它的優先級更高。
當master不可用時，backup收不到廣告包，多台backup中優先級最高的這台會搶占為master。這種搶占是非常快速的（<1秒），以保證服務的連續性。出於安全性考慮，VRRP包使用了加密協議進行加密
（3）keepalived的實現模式
Keepalived通過組播（默認）、單播（自定義），實現keepalived主備推選，工作模式分為搶占和非搶占。
《1》搶占模式
主服務器正常工作時，虛擬IP會在主上，備不提供服務，當主服務優先級低於備的時候，備會自動搶占虛擬IP，這時，主提供服務，備提供服務。
也就是說，搶占模式下，不分主備，只管優先級。
不管 keepalived.conf 里的 state 配置成 master 還是 backup ，只看誰的priority 優先級高， priority 優先級高的那一個，在故障恢復后，會自動將VIP資源再次搶回來。
《2》非搶占模式
這種方式通過參數nopreempt（一般設置在advert_int 的那一行下面）來控制。不管priority優先級，只要master機器發生故障，VIP資源就會被切換到backup上。
並且，當master機器恢復后，也不會將VIP資源搶回來。除非Backup機器發生故障，才能自動把VIP等資源切換會主庫。
nopreempt 這個參數只能用戶state為backup的情況，所以在配置的時候要把master和backup的state都設置成backup，這樣才會實現keepalived的非搶占模式！
也就是說
a）當state狀態一個為master，一個為backup的時候，加不加nopreempt 這個參數都是一樣的效果。
即都是根據priority優先級來決定誰搶占VIP資源，屬於搶占模式！
b）當state狀態都設置成backup，如果不配置nopreempt參數。
也是根據priority優先級來決定誰搶占VIP資源，屬於搶占模式！
c）當state狀態都設置成backup，如果配置了 nopreempt 參數，那么久不會去考慮priority優先級了。
是非搶占模式！ 即只有VIP當前所在機器發生故障，另一台機器才能接管VIP。 不考慮優先級問題。
【4.2】Keepalived在MySQL上有什么作用？
mysql雙主復制，即互為Master-Slave（只有一個Master提供寫操作），可以實現數據庫服務器的熱備。
但一個Master宕機后不能實現動態切換，使用Keepalived，可以通過虛擬IP，實現雙主對外的統一接口以及自動檢查、失敗切換機制，從而實現MySQL數據庫的高可用方案。
《1》架構1：主備集群架構（雙主HA+keepalived）
方案：mysql 雙主 或者 主從+keepalived 主從自動切換
服務器：2台PC
優點：架構簡單，節省資源
缺點：無法線性擴展，主從失敗后需要手動恢復主從架構
【5】PXC（Percona XtraDB Cluster）
Galera高可用集群
【6】分庫、分表、分庫分表分庫
【7】MMM（Master-Master replication manager for MySQL）
是一套支持雙主故障切換和雙主日常管理的腳本程序
【8】mysql innodb cluster
參考自《mysql高可用解決方案_社區》PDF--出自徐軼韜
【8.1】What is MySQL InnoDB Cluster？
•由以下的組件構成MySQL的高可用框架
•MySQL Group Replication：提供DB的擴展、自動故障轉移
•MySQL Router：提供應用程序連接目標的故障轉移
•MySQL Shell：設置群組復制的環境、設置Router
•2017年4月12日GA
•以下產品可以單獨安裝使用
•MySQL 5.7.19 (2017-07-17)
•MySQL Router 2.1.4 (2017-07-24)
•MySQL Shell 1.0.10 (2017-07-28)
【8.2】mysql innodb cluster 架構概念
【8.3】組成部分介紹
【8.3.1】mysql route
可以實現負載均衡，讀寫分離，自動故障切換等功能，是原生支持MGR的官網組件產品。
MySQL Router 能夠在不影響現有應用的前提下，將單獨的MySQL實例輕易地遷移到具有高可用性的InnoDB分布式集群。
在8.0的改進
原生支持InnoDB集群
•獲取Group Replication 的架構
•使用存在於各組成員的元數據
•Bootstraps 時設定InnoDB客戶端的路由
•智能的將客戶端路由到InnoDB集群
•支持多主和單主模式
•重要的改進
•日志
•監控
•性能
•安全性
【8.3.2】mysql shell
注意，mysql shell 是8.x 推出的集成功能，是替代mysql utilities（5.7及之前）的產品，並集成了很多新功能（8.x版本已經沒有mysql utilities 了）
在mysql innodb cluster中，可以使用它來設計、管理、監控
多語言: JavaScript, Python, SQL
–支持編寫腳本
•支持Document 和關系型數據庫模式
•完整的開發和管理API
mysql shell 管理API：
mysql-js> dba.help() •通過全局對象‘dba’使用MySQL管理接口 •執行DBA的操作 •管理MySQL InnoDBclusters •Create clusters •Deploy MySQLinstances •Get cluster info •Start/Stop MySQLInstances •Validate MySQLinstances …
【8.4】核心組成部分MGR
【8.4.1】MySQL Group Replication: 它提供些什么功能?
•高可用分布式MySQL數據庫服務
•不需人工操作服務器的固障移轉
•提供分布式容錯能力
•支持多主更新的架構
•自動重配置(加入/移除節點,崩潰,失敗)
•自動偵測和處理沖突
【8.4.2】MGR的發展現狀與未來趨勢
Step1（已實現）：實現組復制高可用，現在已經實現
Step2（正在進行中當前版奔8.0.17）：在實現組復制高可用的基礎上，實現異步復制做只讀，並且異步復制只讀從庫會隨着組復制中的故障轉移而自動把異步復制的主庫設置成被故障轉移的主庫。
總結起來就一句話：MGR里的自動故障轉移后，異步復制從庫自動連上新主庫。詳細見圖
Step3（還沒開始實現）：基於Step1和Step2下的分片MGR，也就是說把每個分片做一個MGR，再根據步驟1（分片內的MGR實現HA）和步驟2（MGR下的異步復制+自動故障轉移后從庫自動連上新主庫）
最終目標：
【8.4.3】MGR/InnnoDB Cluster的當前用戶（2019.08.16 記錄時間）
參考文件：
《mysql高可用解決方案_社區》PDF--徐軼韜
《深入淺出MySQL數據庫開發、優化與管理維護》第2版（唐漢明、翟振興）
博客園~關於MGR的博文：https://www.cnblogs.com/luoahong/articles/8043035.html