MyCat權威指南閱讀筆記(進階篇)

1?讀寫分離

1.1 MySQL 主從復制的幾種方案

數據庫讀寫分離對于大型系統或者訪問量很高的互聯網應用來說，是必不可少的一個重要功能。

從數據庫的角度來說，對于大多數應用來說，從集中到分布，最基本的一個需求不是數據存儲的瓶頸，而是

在于計算的瓶頸，即 SQL 查詢的瓶頸，我們知道，正常情況下，Insert SQL 就是幾十個毫秒的時間內寫入完成，

而系統中的大多數 Select SQL 則要幾秒到幾分鐘才能有結果，很多復雜的 SQL，其消耗服務器 CPU 的能力超

強，不亞于死循環的威力。在沒有讀寫分離的系統上，很可能高峰時段的一些復雜 SQL 查詢就導致數據庫服務器

CPU 爆表，系統陷入癱瘓，嚴重情況下可能導致數據庫崩潰。因此，從保護數據庫的角度來說，我們應該盡量避

免沒有主從復制機制的單節點數據庫。

對于 MySQL 來說，標準的讀寫分離是主從模式，一個寫節點 Master 后面跟著多個讀節點，讀節點的數量取

決于系統的壓力，通常是 1-3 個讀節點的配置，如下圖所示：

MySQL 支持更多的主從復制的拓撲關系，如下圖所示，但通常我們不會采用雙向主從同步以及環狀的拓撲：

MySQL 主從復制的原理如下：

第一步是在主庫上記錄二進制日志（稍后介紹如何設置）。在每次準備提交事務完成數 據更新前，主庫將數

據更新的事件記錄到二進制日志中。MySQL 會按事務提交的順序 而非每條語句的執行順序來記錄二進制日志。

在記錄二進制日志后，主庫會告訴存儲引 擎可以提交事務了。 下一步，備庫將主庫的二進制日志復制到其本地的

中繼日志中。首先，備庫會啟動一個 工作線程，稱為 I/O 線程，I/O 線程跟主庫建立一個普通的客戶端連接，然

后在主庫上啟 動一個特殊的二進制轉儲(binhg dump、線程（該線程沒有對應的 SQL 命令），這個二 進制轉儲

線程會讀取主庫上二進制日志中的事件。它不會對事件進行輪詢。如果該線程 追趕上了主庫，它將進入睡眠狀

態，直到主庫發送信號量通知其有新的事件產生時才會 被喚醒，備庫 I/O 線程會將接收到的事件記錄到中繼日志

中。

備庫的 SQL 線程執行最后一步，該線程從中繼日志中讀取事件并在備庫執行，從而實現 備庫數據的更新。當

SQL 線程追趕上 I/O 線程時，中繼日志通常已經在系統緩存中，所 以中繼日志的開銷很低。SQL 線程執行的事件

也可以通過配置選項來決定是否寫入其自 己的二進制日志中，它對于我們稍后提到的場景非常有用。這種復制架

構實現了獲取事件和重放事件的解耦，允許這兩個過程異步進行。也就是說 I/o 線程能夠獨立于 SQL 線程之外工

作。但這種架構也限制了復制的過程，其中最重要 的一點是在主庫上并發運行的査詢在備庫只能串行化執行，因

為只有一個 SQL 線程來重 放中繼日志中的事件。后面我們將會看到，這是很多工作負載的性能瓶頸所在。雖然有

一些針對該問題的解決方案，但大多數用戶仍然受制于單線程。MySQL5.6 以后，提供了基于 GTID 多開啟多線

程同步復制的方案，即每個庫有一個單獨的(sql thread)

進行同步復制，這將大大改善 MySQL 主從同步的數據延遲問題，配合 Mycat 分片，可以更好的將一個超級

大表的數據同步的時延降低到最低。此外，用 GTID 避免了在傳送 binlog 邏輯上依賴文件名和物理偏移量，能夠

更好的支持自動容災切換，對運維人員來說應該是一件令人高興的事情，因為傳統的方式里，你需要找到 binlog

和 POS 點，然后 change master to 指向，而不是很有經驗的運維，往往會將其找錯，造成主從同步復制報錯，

在 mysql5.6 里，無須再知道 binlog 和 POS 點，需要知道 master 的 IP、端口，賬號密碼即可，因為同步復制是

自動的，mysql 通過內部機制 GTID 自動找點同步。

即使是并發復制機制、仍然無法避免主從數據庫的數據瞬間不同步的問題，因此又有了一種增強的方案，即

galera for mysql、percona-cluster 或者 mariadb cluster 等集群機制，他們是一種多主同步復制的模式，可以

在任意節點上進行讀寫、自動控制成員，自動刪除故障節點、自動加入節點、真正給予行級別的并發復制等強大

能力!

下圖是其原理圖，通常是采用 3 個 MySQL 節點作為一個 Cluster，即提供了 3 倍的數據庫讀的并發能

力.galera for mysql 集群這種方式，是犧牲了數據的寫入速度，以換取最大程度的數據并發訪問能力，類似

Mycat 里的全局表，并且保證了數據同時存在幾個有效的副本，從而具有非常高的可靠性，因此在某種程度上，

可以替代 Oracle 的一些關鍵場景，**目前開源中間件中，只有 Mycat 很完美的支持了 galera for mysql 集群模

式。

1.2 MySQL 主從復制的幾個問題

MySQL 主從復制并不完美，存在著幾個由來已久的問題，首先一個問題是復制方式：

? 基于 SQL 語句的復制(statement-based replication, SBR)；

? 基于行的復制(row-based replication, RBR)；

? 混合模式復制(mixed-based replication, MBR)；

? 基于 SQL 語句的方式最古老的方式，也是目前默認的復制方式，后來的兩種是 MySQL 5 以后才出現的復

制方式。

RBR 的優點：

? 任何情況都可以被復制，這對復制來說是最安全可靠的；

? 和其他大多數數據庫系統的復制技術一樣；

? 多數情況下，從服務器上的表如果有主鍵的話，復制就會快了很多。

RBR 的缺點：

? binlog 大了很多；

? 復雜的回滾時 binlog 中會包含大量的數據；

? 主服務器上執行 UPDATE 語句時，所有發生變化的記錄都會寫到 binlog 中，而 SBR 只會寫一次，這會

導致頻繁發生 binlog 的并發寫問題；

? 無法從 binlog 中看到都復制了寫什么語句。

SBR 的優點：

? 歷史悠久，技術成熟；

? binlog 文件較小；

? binlog 中包含了所有數據庫更改信息，可以據此來審核數據庫的安全等情況；

? binlog 可以用于實時的還原，而不僅僅用于復制；

? 主從版本可以不一樣，從服務器版本可以比主服務器版本高。

SBR 的缺點：

? 不是所有的 UPDATE 語句都能被復制，尤其是包含不確定操作的時候；

? 復制需要進行全表掃描(WHERE 語句中沒有使用到索引)的 UPDATE 時，需要比 RBR 請求更多的行級

鎖；

? 對于一些復雜的語句，在從服務器上的耗資源情況會更嚴重，而 RBR 模式下，只會對那個發生變化的記

錄產生影響；

? 數據表必須幾乎和主服務器保持一致才行，否則可能會導致復制出錯；

? 執行復雜語句如果出錯的話，會消耗更多資源。

選擇哪種方式復制，會影響到復制的效率以及服務器的損耗，甚以及數據一致性性問題，目前其實沒有很好

的客觀手手段去評估一個系統更適合哪種方式的復制，Mycat 未來希望能通過智能調優模塊給出更科學的建議。

第二個問題是關于主從同步的監控問題，Mysql 有主從同步的狀態信息，可以通過命令 show slave status

獲取，除了獲知當前是否主從同步正常工作，另外一個重要指標就是 Seconds_Behind_Master，從字面理解，它

表示當前 MySQL 主從數據的同步延遲，單位是秒，但這個指標從 DBA 的角度并不能簡單的理解為延遲多少秒，

感興趣的同學可以自己去研究，但對于應用來說，簡單的認為是主從同步的時間差就可以了，另外，當主從同步

停止以后，重新啟動同步，這個數值可能會是幾萬秒，取決于主從同步停止的時間長短，我們可以認為數據此時

有很多天沒有同步了，而這個數值越接近零，則說明主從同步延遲最小，我們可以采集這個指標并匯聚曲線圖，

來分析我們的數據庫的同步延遲曲線，然后根據此曲線，給出一個合理的閥值，主從同步的時延小于閥值時，我

們認為從庫是同步的，此時可以安全的從從庫讀取數據。Mycat 未來將支持這種優化，讓應用更加可靠的讀取到

預期的從庫數據。

1.3 Mycat 支持的讀寫分離

1. 配置 mysql 端主從的數據自動同步，mycat 不負責任何的數據同步問題。

2. Mycat 配置讀寫分離，具體參數參加前面章節。

writeType="0" dbType="mysql" dbDriver="native">

select user()

weight="1" />

或者

writeType="0" dbType="mysql" dbDriver="native">

select user()

以上兩種取模第一種當寫掛了讀不可用，第二種可以繼續使用，事務內部的一切操作都會走寫節點，所以讀

操作不要加事務，如果讀延時較大，使用根據主從延時的讀寫分離，或者強制走寫節點：

1.3.1應用強制走寫：

一個查詢 SQL 語句以/*balance*/注解來確定其是走讀節點還是寫節點。

1.6 以后添加了強制走讀走寫處理：

強制走從：

/*!mycat:db_type=slave*/ select * from travelrecord

/*#mycat:db_type=slave*/ select * from travelrecord

強制走寫：

/*#mycat:db_type=master*/ select * from travelrecord

/*!mycat:db_type=master*/ select * from travelrecord

1.3.2根據主從延時切換：

1.4 開始支持 MySQL 主從復制狀態綁定的讀寫分離機制，讓讀更加安全可靠，配置如下：

MyCAT 心跳檢查語句配置為 show slave status ，dataHost 上定義兩個新屬性： switchType="2" 與

slaveThreshold="100"，此時意味著開啟 MySQL 主從復制狀態綁定的讀寫分離與切換機制，Mycat 心跳機

制通過檢測 show slave status 中的 "Seconds_Behind_Master", "Slave_IO_Running",

"Slave_SQL_Running" 三個字段來確定當前主從同步的狀態以及 Seconds_Behind_Master 主從復制時延，

當 Seconds_Behind_Master>slaveThreshold 時，讀寫分離篩選器會過濾掉此 Slave 機器，防止讀到很久之

前的舊數據，而當主節點宕機后，切換邏輯會檢查 Slave 上的 Seconds_Behind_Master 是否為 0，為 0 時則

表示主從同步，可以安全切換，否則不會切換。

writeType="0" dbType="mysql" dbDriver="native" switchType="2"

slaveThreshold="100">

show slave status

password="123456">

password="123456" />

1.4.1 開始支持 MySQL 集群模式，讓讀更加安全可靠，配置如下：

MyCAT 心跳檢查語句配置為 show status like ‘wsrep%’ ，

dataHost 上定義兩個新屬性： switchType="3"

此時意味著開啟 MySQL 集群復制狀態狀態綁定的讀寫分離與切換機制，Mycat 心跳機制通過檢測集群復制時延

時，如果延時過大或者集群出現節點問題不會負載改節點。

dataHost name="localhost1" maxCon="1000" minCon="10" balance="0"

writeType="0" dbType="mysql" dbDriver="native" switchType="3" >

show status like ‘wsrep%’

user="root"password="123456">

host="hostS1"url="localhost:3316"user="root"password="123456" >

2.?高可用與集群

2.1 MySQL 高可用的幾種方案

首先我們看看 MySQL 高可用的幾種方案：

對于數據實時性要求不是特別嚴格的應用，只需要通過廉價的 pc server 來擴展 Slave 的數量，將讀壓力分

散到多臺 Slave 的機器上面，即可通過分散單臺數據庫服務器的讀壓力來解決數據庫端的讀性能瓶頸，畢竟在大

多數數據庫應用系統中的讀壓力還是要比寫壓力大很多。這在很大程度上解決了目前很多中小型網站的數據庫壓

力瓶頸問題，甚至有些大型網站也在使用類似方案解決數據庫瓶頸。

MySQL Cluster 由一組計算機構成，每臺計算機上均運行著多種進程，包括 MySQL 服務器，NDB Cluster

的數據節點，管理服務器，以及（可能）專門的數據訪問程序。NDB” 是一種“內存中”的存儲引擎，它具有可

用性高和數據一致性好的特點。MySQL Cluster 要實現完全冗余和容錯，至少需要 4 臺物理主機，其中兩個為管

理節點。MySQL Cluster 使用不那么廣泛，除了自身構架因素、適用的業務有限之外，另一個重要的原因是其安

裝配置管理相對復雜繁瑣，總共有幾十個操作步驟，需要 DBA 花費幾個小時才能搭建或完成。重啟 MySQL

Cluster 數據庫的管理操作之前需要執行 46 個手動命令，需要耗費 DBA 2.5 小時的時間，而依靠 MySQL

Cluster Manager 只需一個命令即可完成，但 MySQL Cluster Manager 僅作為商用 MySQL Cluster 運營商級

版本 (CGE) 數據庫的一部分提供，需要購買。其官方的說明，若應用中的 SQL 操作為主鍵數據庫訪問，包含一些

JOIN 操作而非對整個表執行常規掃描和 JOIN 而返回數萬行數據，則適合 Cluster，否則不合適，從這一條限制

來看，表明大多數業務場景并不合適 MySQL Cluster，業內有資深人士也憑評價：NDB 不適合大多數業務場景，

而且有安全問題。

heartbeat 是 Linux-HA 工程的一個組件,heartbeat 最核心的包括兩個部分：心跳監測和資源接管。在指定

的時間內未收到對方發送的報文，那么就認為對方失效，這時需啟動資源接管模塊來接管運 行在對方主機上的資

源或者服務。

DRBD 是通過網絡來實現塊設備的數據鏡像同步的一款開源 Cluster 軟件，它自動完成網絡中兩個不同服務

器上的磁盤同步，相對于 binlog 日志同步，它是更底層的磁盤同步，理論上 DRDB 適合很多文件型系統的高可

用。

Lvs 是一個虛擬的服務器集群系統，可以實現 LINUX 平臺下的簡單負載均衡。keepalived 是一個類似于

layer3, 4 & 5 交換機制的軟件，主要用于主機與備機的故障轉移，這是一種適用面很廣的負載均衡和高可用方

案，最常用于 Web 系統。

這種 gluster 模式可以說是全新的一種高可用方案，前面也提到其優點，它的缺點不多，不支持 XA，不支持

Lock Table，只能用 InnoDB 引擎。

2.2 Mycat 高可用方案

Mycat 作為一個代理層中間件，Mycat 系統的高可用涉及到 Mycat 本身的高可用以及后端 MySQL 的高可

用，前面章節所講的 MySQL 高可用方案都可以在此用來確保 Mycat 所連接的后端 MySQL 服務的高可用性。在

大多數情況下，建議采用標準的 MySQL 主從復制高可用性配置并交付給 Mycat 來完成后端 MySQL 節點的主從

自動切換。

如圖所示，MySQL 節點開啟主從復制的配置方案，并將主節點配置為 Mycat 的 dataHost 里的

writeNode，從節點配置為 readNode，同時 Mycat 內部定期對一個 dataHost 里的所有 writeHost 與

readHost 節點發起心跳檢測，正常情況下，Mycat 會將第一個 writeHost 作為寫節點，所有的 DML SQL 會發送

給此節點，若 Mycat 開啟了讀寫分離，則查詢節點會根據讀寫分離的策略發往 readHost(+writeHost)執行，當

一個 dataHost 里面配置了兩個或多個 writeHost 的情況下，如果第一個 writeHost 宕機，則 Mycat 會在默認的

3 次心跳檢查失敗后，自動切換到下一個可用的 writeHost 執行 DML SQL 語句，并在 conf/dnindex.properties

文件里記錄當前所用的 writeHost 的 index（第一個為 0，第二個為 1，依次類推），注意，此文件不能刪除和擅

自改變，除非你深刻理解了它的作用以及你的目的。

那么問題來了，當原來配置的 MySQL 寫節點宕機恢復以后，怎么重新加入 Mycat，要不要恢復為原來的寫

節點？關于這個問題，我們也曾與 DBA 討論很久，最終的建議方案是，保持現有狀態不變，改旗易幟，恢復后的

MySQL 節點作為從節點，跟隨新的主節點，重新配置主從同步，原先跟隨該節點做同步的其他節點也同樣換帥，

重新配置同步源，這些節點的數據手工完成同步以后，再加入 Mycat 里。目前 1.3 版本的 Mycat 還沒有實現監控

MySQL 主從同步狀態的功能，因此這個過程里，DBA 可以先修改 MySQL 的密碼，讓 Mycat 無法鏈接故障服務

器，等同步完成以后，恢復密碼，這樣 Mycat 就自動重新將修復好的 Mycat 納管進來了。

說完了 MySQL 部分，接下來我們看看 Mycat 自身的高可用性，由于 Mycat 自身是屬于無狀態的中間件（除

了主從切換過程中記錄的 dnindex.properties 文件），因此 Mycat 很容易部署為集群方式，提供高可用方案。

原先有規劃 Mycat-balance 組件，專門用于 Mycat 負載均衡，但由于缺乏志愿者，也沒有經過生產實踐驗證，

163

因此暫時不建議使用，官方建議是采用基于硬件的負載均衡器或者軟件方式的 HAproxy，HAProxy 相比 LVS 的

使用要簡單很多，功能方面也很豐富，免費開源，穩定性也是非常好，可以與 LVS 相媲美，根據官方文檔，

HAProxy 可以跑滿 10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom’s 10GbE NICs (Myri-

10G PCI-Express)，這個作為軟件級負載均衡，也是比較驚人的，下圖是 HAproxy+Mycat 集群+MySQL 主從

所組成的高可用性方案：

如果還擔心 HAproxy 的穩定性和單點問題，則可以用 keepalived 的 VIP 的浮動功能，加以強化：

2.3 Galary Cluster 配置

Mycat1.4.1 開始支持 galary cluster 集群的配置，提高心跳可用。

配置如下：

1.4.1 開始支持 MySQL 集群模式，讓讀更加安全可靠，配置如下：

MyCAT 心跳檢查語句配置為 show status like ‘wsrep%’ ，

dataHost 上定義兩個新屬性： switchType="3"

此時意味著開啟 MySQL 集群復制狀態狀態綁定的讀寫分離與切換機制，Mycat 心跳機制通過檢測集群復制時延時，如

果延時過大或者集群出現節點問題不會負載改節點。

dataHost name="localhost1" maxCon="1000" minCon="10" balance="0"

writeType="0" dbType="mysql" dbDriver="native" switchType="3" >

show status like ‘wsrep%’

user="root"password="123456">

host="hostS1"url="localhost:3316"user="root"password="123456" >

MySQL SQL

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。