1. 概述
讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領域值得信任、有價值的長期合作伙伴，公司提供的服務項目有：申請域名、雅安服務器托管、營銷軟件、網站建設、綏濱網站維護、網站推廣。
我們在考慮MySQL數(shù)據(jù)庫的高可用的架構時，主要要考慮如下幾方面：
如果數(shù)據(jù)庫發(fā)生了宕機或者意外中斷等故障，能盡快恢復數(shù)據(jù)庫的可用性，盡可能的減少停機時間，保證業(yè)務不會因為數(shù)據(jù)庫的故障而中斷。
用作備份、只讀副本等功能的非主節(jié)點的數(shù)據(jù)應該和主節(jié)點的數(shù)據(jù)實時或者最終保持一致。
當業(yè)務發(fā)生數(shù)據(jù)庫切換時，切換前后的數(shù)據(jù)庫內容應當一致，不會因為數(shù)據(jù)缺失或者數(shù)據(jù)不一致而影響業(yè)務。
關于對高可用的分級在這里我們不做詳細的討論，這里只討論常用高可用方案的優(yōu)缺點以及高可用方案的選型。
2. 高可用方案
2.1. 主從或主主半同步復制
使用雙節(jié)點數(shù)據(jù)庫，搭建單向或者雙向的半同步復制。在5.7以后的版本中，由于lossless replication、logical多線程復制等一些列新特性的引入，使得MySQL原生半同步復制更加可靠。
常見架構如下：
通常會和proxy、keepalived等第三方軟件同時使用，即可以用來監(jiān)控數(shù)據(jù)庫的 健康 ，又可以執(zhí)行一系列管理命令。如果主庫發(fā)生故障，切換到備庫后仍然可以繼續(xù)使用數(shù)據(jù)庫。
優(yōu)點：
架構比較簡單，使用原生半同步復制作為數(shù)據(jù)同步的依據(jù)；
雙節(jié)點，沒有主機宕機后的選主問題，直接切換即可；
雙節(jié)點，需求資源少，部署簡單；
缺點：
完全依賴于半同步復制，如果半同步復制退化為異步復制，數(shù)據(jù)一致性無法得到保證；
需要額外考慮haproxy、keepalived的高可用機制。
2.2. 半同步復制優(yōu)化
半同步復制機制是可靠的。如果半同步復制一直是生效的，那么便可以認為數(shù)據(jù)是一致的。但是由于網絡波動等一些客觀原因，導致半同步復制發(fā)生超時而切換為異步復制，那么這時便不能保證數(shù)據(jù)的一致性。所以盡可能的保證半同步復制，便可提高數(shù)據(jù)的一致性。
該方案同樣使用雙節(jié)點架構，但是在原有半同復制的基礎上做了功能上的優(yōu)化，使半同步復制的機制變得更加可靠。
可參考的優(yōu)化方案如下：
2.2.1. 雙通道復制
半同步復制由于發(fā)生超時后，復制斷開，當再次建立起復制時，同時建立兩條通道，其中一條半同步復制通道從當前位置開始復制，保證從機知道當前主機執(zhí)行的進度。另外一條異步復制通道開始追補從機落后的數(shù)據(jù)。當異步復制通道追趕到半同步復制的起始位置時，恢復半同步復制。
2.2.2. binlog文件服務器
搭建兩條半同步復制通道，其中連接文件服務器的半同步通道正常情況下不啟用，當主從的半同步復制發(fā)生網絡問題退化后，啟動與文件服務器的半同步復制通道。當主從半同步復制恢復后，關閉與文件服務器的半同步復制通道。
優(yōu)點：
雙節(jié)點，需求資源少，部署簡單；
架構簡單，沒有選主的問題，直接切換即可;
相比于原生復制，優(yōu)化后的半同步復制更能保證數(shù)據(jù)的一致性。
缺點：
需要修改內核源碼或者使用mysql通信協(xié)議。需要對源碼有一定的了解，并能做一定程度的二次開發(fā)。
依舊依賴于半同步復制，沒有從根本上解決數(shù)據(jù)一致性問題。
2.3. 高可用架構優(yōu)化
將雙節(jié)點數(shù)據(jù)庫擴展到多節(jié)點數(shù)據(jù)庫，或者多節(jié)點數(shù)據(jù)庫集群?？梢愿鶕?jù)自己的需要選擇一主兩從、一主多從或者多主多從的集群。
由于半同步復制，存在接收到一個從機的成功應答即認為半同步復制成功的特性，所以多從半同步復制的可靠性要優(yōu)于單從半同步復制的可靠性。并且多節(jié)點同時宕機的幾率也要小于單節(jié)點宕機的幾率，所以多節(jié)點架構在一定程度上可以認為高可用性是好于雙節(jié)點架構。
但是由于數(shù)據(jù)庫數(shù)量較多，所以需要數(shù)據(jù)庫管理軟件來保證數(shù)據(jù)庫的可維護性?？梢赃x擇MMM、MHA或者各個版本的proxy等等。常見方案如下：
2.3.1. MHA+多節(jié)點集群
MHA Manager會定時探測集群中的master節(jié)點，當master出現(xiàn)故障時，它可以自動將最新數(shù)據(jù)的slave提升為新的master，然后將所有其他的slave重新指向新的master，整個故障轉移過程對應用程序完全透明。
MHA Node運行在每臺MySQL服務器上，主要作用是切換時處理二進制日志，確保切換盡量少丟數(shù)據(jù)。
MHA也可以擴展到如下的多節(jié)點集群：
優(yōu)點：
可以進行故障的自動檢測和轉移;
可擴展性較好，可以根據(jù)需要擴展MySQL的節(jié)點數(shù)量和結構;
相比于雙節(jié)點的MySQL復制，三節(jié)點/多節(jié)點的MySQL發(fā)生不可用的概率更低
缺點：
至少需要三節(jié)點，相對于雙節(jié)點需要更多的資源;
邏輯較為復雜，發(fā)生故障后排查問題，定位問題更加困難;
數(shù)據(jù)一致性仍然靠原生半同步復制保證，仍然存在數(shù)據(jù)不一致的風險;
可能因為網絡分區(qū)發(fā)生腦裂現(xiàn)象;
2.3.2. zookeeper+proxy
Zookeeper使用分布式算法保證集群數(shù)據(jù)的一致性，使用zookeeper可以有效的保證proxy的高可用性，可以較好的避免網絡分區(qū)現(xiàn)象的產生。
優(yōu)點：
較好的保證了整個系統(tǒng)的高可用性，包括proxy、MySQL;
擴展性較好，可以擴展為大規(guī)模集群;
缺點：
數(shù)據(jù)一致性仍然依賴于原生的mysql半同步復制;
引入zk，整個系統(tǒng)的邏輯變得更加復雜;
2.4. 共享存儲
共享存儲實現(xiàn)了數(shù)據(jù)庫服務器和存儲設備的解耦，不同數(shù)據(jù)庫之間的數(shù)據(jù)同步不再依賴于MySQL的原生復制功能，而是通過磁盤數(shù)據(jù)同步的手段，來保證數(shù)據(jù)的一致性。
2.4.1. SAN共享儲存
SAN的概念是允許存儲設備和處理器（服務器）之間建立直接的高速網絡（與LAN相比）連接，通過這種連接實現(xiàn)數(shù)據(jù)的集中式存儲。常用架構如下：
使用共享存儲時，MySQL服務器能夠正常掛載文件系統(tǒng)并操作，如果主庫發(fā)生宕機，備庫可以掛載相同的文件系統(tǒng)，保證主庫和備庫使用相同的數(shù)據(jù)。
優(yōu)點：
兩節(jié)點即可，部署簡單，切換邏輯簡單；
很好的保證數(shù)據(jù)的強一致性；
不會因為MySQL的邏輯錯誤發(fā)生數(shù)據(jù)不一致的情況；
缺點：
需要考慮共享存儲的高可用；
價格昂貴；
2.4.2. DRBD磁盤復制
DRBD是一種基于軟件、基于網絡的塊復制存儲解決方案，主要用于對服務器之間的磁盤、分區(qū)、邏輯卷等進行數(shù)據(jù)鏡像，當用戶將數(shù)據(jù)寫入本地磁盤時，還會將數(shù)據(jù)發(fā)送到網絡中另一臺主機的磁盤上，這樣的本地主機(主節(jié)點)與遠程主機(備節(jié)點)的數(shù)據(jù)就可以保證實時同步。常用架構如下：
當本地主機出現(xiàn)問題，遠程主機上還保留著一份相同的數(shù)據(jù)，可以繼續(xù)使用，保證了數(shù)據(jù)的安全。
DRBD是linux內核模塊實現(xiàn)的快級別的同步復制技術，可以與SAN達到相同的共享存儲效果。
優(yōu)點：
兩節(jié)點即可，部署簡單，切換邏輯簡單；
相比于SAN儲存網絡，價格低廉；
保證數(shù)據(jù)的強一致性；
缺點：
對io性能影響較大；
從庫不提供讀操作；
2.5. 分布式協(xié)議
分布式協(xié)議可以很好解決數(shù)據(jù)一致性問題。比較常見的方案如下：
2.5.1. MySQL cluster
MySQL cluster是官方集群的部署方案，通過使用NDB存儲引擎實時備份冗余數(shù)據(jù)，實現(xiàn)數(shù)據(jù)庫的高可用性和數(shù)據(jù)一致性。
優(yōu)點：
全部使用官方組件，不依賴于第三方軟件；
可以實現(xiàn)數(shù)據(jù)的強一致性；
缺點：
國內使用的較少；
配置較復雜，需要使用NDB儲存引擎，與MySQL常規(guī)引擎存在一定差異；
至少三節(jié)點；
2.5.2. Galera
基于Galera的MySQL高可用集群， 是多主數(shù)據(jù)同步的MySQL集群解決方案，使用簡單，沒有單點故障，可用性高。常見架構如下：
優(yōu)點：
多主寫入，無延遲復制，能保證數(shù)據(jù)強一致性；
有成熟的社區(qū)，有互聯(lián)網公司在大規(guī)模的使用；
自動故障轉移，自動添加、剔除節(jié)點；
缺點：
需要為原生MySQL節(jié)點打wsrep補丁
只支持innodb儲存引擎
至少三節(jié)點；
2.5.3. POAXS
Paxos 算法解決的問題是一個分布式系統(tǒng)如何就某個值（決議）達成一致。這個算法被認為是同類算法中最有效的。Paxos與MySQL相結合可以實現(xiàn)在分布式的MySQL數(shù)據(jù)的強一致性。常見架構如下：
優(yōu)點：
多主寫入，無延遲復制，能保證數(shù)據(jù)強一致性；
有成熟理論基礎；
自動故障轉移，自動添加、剔除節(jié)點；
缺點：
只支持innodb儲存引擎
至少三節(jié)點；
3. 總結
隨著人們對數(shù)據(jù)一致性的要求不斷的提高，越來越多的方法被嘗試用來解決分布式數(shù)據(jù)一致性的問題，如MySQL自身的優(yōu)化、MySQL集群架構的優(yōu)化、Paxos、Raft、2PC算法的引入等等。
而使用分布式算法用來解決MySQL數(shù)據(jù)庫數(shù)據(jù)一致性的問題的方法，也越來越被人們所接受，一系列成熟的產品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越來越多的被大規(guī)模使用。
隨著官方MySQL Group Replication的GA，使用分布式協(xié)議來解決數(shù)據(jù)一致性問題已經成為了主流的方向。期望越來越多優(yōu)秀的解決方案被提出，MySQL高可用問題可以被更好的解決。
這方面沒有做過， 不過其他的web集群倒是做過， 希望跟樓主學習 。
這方面還真不太懂。
不過， 以后要是遇到了Linux服務器的問題， 都可以一起研究探討啊。
在實際的生產中，為了解決Mysql的單點故障，一般都會采用「主備模式」。
MySQL幾乎所有的高可用架構，都直接依賴于 binlog。雖然這些高可用架構已經呈現(xiàn)出越來越復雜的趨勢，但都是從最基本的一主一備演化過來的。
下圖為主備切換流程
在狀態(tài) 1 中，客戶端的讀寫都直接訪問節(jié)點 A，而節(jié)點 B 是 A 的備庫，只是將 A 的更新都同步過來，到本地執(zhí)行。這樣可以保持節(jié)點 B 和 A 的數(shù)據(jù)是相同的。
當需要切換的時候，就切成狀態(tài) 2。這時候客戶端讀寫訪問的都是節(jié)點 B，而節(jié)點 A 是 B 的備庫。
在狀態(tài) 1 中，雖然節(jié)點 B 沒有被直接訪問，但是依然建議把節(jié)點 B（也就是備庫）設置成只讀（readonly）模式。這樣做，有以下幾個考慮：
圖下圖 中畫出的就是一個 update 語句在節(jié)點 A 執(zhí)行，然后同步到節(jié)點 B 的完整流程圖。
備庫 B 跟主庫 A 之間維持了一個長連接。主庫 A 內部有一個線程，專門用于服務備庫 B 的這個長連接。一個事務日志同步的完整過程是這樣的：
在備庫 B 上通過 change master 命令，設置主庫 A 的 IP、端口、用戶名、密碼，以及要從哪個位置開始請求 binlog，這個位置包含文件名和日志偏移量。
在備庫 B 上執(zhí)行 start slave 命令，這時候備庫會啟動兩個線程，就是圖中的 io_thread 和 sql_thread。其中 io_thread 負責與主庫建立連接。
主庫 A 校驗完用戶名、密碼后，開始按照備庫 B 傳過來的位置，從本地讀取 binlog，發(fā)給 B。
備庫 B 拿到 binlog 后，寫到本地文件，稱為中轉日志（relay log）。
sql_thread 讀取中轉日志，解析出日志里的命令，并執(zhí)行。
主庫需要復制新增binlog到從庫才能完成同步，這個同步過程就是同步延遲。主從延遲最直接的表現(xiàn)是，備庫消費中轉日志（relay log）的速度，比主庫生產 binlog 的速度要慢。
「同步策略」：Master會等待所有的Slave都回應后才會提交，這個主從的同步的性能會嚴重的影響。
「半同步策略」：Master至少會等待一個Slave回應后提交。
「異步策略」：Master不用等待Slave回應就可以提交。
「延遲策略」：Slave要落后于Master指定的時間。
對于不同的業(yè)務需求，有不同的策略方案，但是一般都會采用最終一致性，不會要求強一致性，畢竟強一致性會嚴重影響性能。
重慶分公司
重慶分公司
