Mysql主從複製集羣搭建（理論）

Mysql主從複製集羣

爲何要使用Mysql主從複製集羣

咱們知道單個Mysql引用的性能是有極限的，隨着應用業務數據不斷的增大，隨之讀寫操做併發量巨大，致使應用的響應速度不斷降低，甚至會形成數據庫直接不可用。咱們知道數據寫操做會形成表鎖，或者行鎖來實現數據庫的事務隔離。單個Mysql應用要同時處理讀、寫操做，勢必會形成數據庫的性能更進一步的降低。在使用大多數應用中咱們發現大多數的請求都是查詢操做。此時，咱們能夠將數據庫擴展成主從複製模式 ，將讀操做和寫操做分離開來，多臺數據庫分攤請求，從而減小單庫的訪問壓力，進而應用獲得優化，響應速度提高。

Mysql主從複製的原理

MySQL數據庫的主從複製方案，使用的是scp/rsync等命令進行的文件級別複製相似，都是數據的遠程傳輸，只不過MySQL的主從複製是其自帶的功能，無需藉助第三方工具。並且，MySQL的主從複製並非數據庫磁盤上的文件直接拷貝，而是經過邏輯的binlog日誌複製到要同步的服務器本地，而後由本地的線程讀取日誌裏面的SQL語句從新應用到MySQL數據庫中。

Mysql主從複製的底層流程細節

主從複製的流程

MySQL同步操做經過3個線程實現，其基本步驟以下：

1. 主服務器將數據的更新記錄到二進制日誌（Binary log）中，用於記錄二進制日誌事件，這一步由主庫線程完成；
2. 從庫將主庫的二進制日誌複製到本地的中繼日誌（Relay log），這一步由 從庫 I/O 線程 完成；
3. 從庫讀取中繼日誌中的事件，將其重放到數據中，這一步由從庫 SQL線程 完成。

Mysql主從複製集羣搭建

基於Docker compose搭建

詳細文檔見同目錄文件：Mysql主從複製集羣搭建-基於DockerCompose.md

基於原生linux mysql 搭建

詳細文檔見同目錄文件：Mysql主從複製集羣搭建-Linux版.md

Mysql主從複製集羣的優缺點

優勢

1. 負載均衡

一般狀況下，會使用 主服務器 對數據進行 更新、刪除 和 新建 等操做，而將 查詢 工做落到 從庫 頭上。

2. 異地容災備份

能夠將主服務器上的數據同步到 異地從服務器 上，極大地提升了 數據安全性。

3. 高可用

數據庫的複製功能實現了 主服務器 與 從服務器間 的數據同步，一旦主服務器出了 故障，從服務器當即擔當起主服務器的角色，保障系統持續穩定運做。

4. 高擴展性

主從複製 模式支持 2 種擴展方式:

• scale-up

向上擴展或者 縱向擴展，主要是提供比如今服務器 性能更好 的服務器，好比 增長 CPU 和 內存 以及 磁盤陣列等，由於有多臺服務器，因此可擴展性比單臺更大。

• scale-out

向外擴展或者 橫向擴展，是指增長 服務器數量 的擴展，這樣主要能分散各個服務器的壓力。

缺點

1. 成本增長

搭建主從確定會增長成本，畢竟一臺服務器和兩臺服務器的成本徹底不一樣，另外因爲主從必需要開啓 二進制日誌，因此也會形成額外的 性能消耗。

2. 數據延遲

從庫從主庫 複製數據確定是會有必定的 數據延遲 的。因此當剛插入就出現查詢的狀況，可能查詢不出來。固然若是是插入者本身查詢，那麼能夠直接從 主庫 中查詢出來，固然這個也是須要用代碼來控制的。

3. 寫入更慢

主從複製 主要是針對 讀遠大於寫 或者對 數據備份實時性 要求較高的系統中。由於 主服務器 在寫中須要更多操做，並且 只有一臺 能夠寫入的 主庫，因此寫入的壓力並不能被分散。

MySQL主從複製的複製方式

MySQL的主從複製並不完美，存在着幾個由來已久的問題，首先一個問題是複製方式：

• 基於SQL語句的複製（statement-based replication,SBR）
• 基於行的複製（row-based replication,RBR）
• 混合模式複製（mixed-based replication,MBR）
• 全局事務標識符 GTID（Global Transaction Identifier,GTID）
• 基於SQL語句的方式是最古老的方式，也是目前默認的複製方式，後來的三種是MySQL 5之後纔出現的複製方式。

SBR方式的優缺點

SBR的優勢

• 歷史悠久，技術成熟
• binlog文件較小
• binlog中包含了全部數據庫更改信息，能夠據此來審覈數據庫的安全等狀況
• binlog能夠用於實時的還原，而不只僅用於複製
• 主從版本能夠不同，從服務器版本能夠比主服務器版本高

SBR的缺點：

• 不是全部的UPDATE語句都能被複制，尤爲是包含不肯定操做的時候
• 複製須要進行全表掃描(WHERE 語句中沒有使用到索引)的 UPDATE 時，須要比 RBR 請求更多的行級鎖
• 對於一些複雜的語句，在從服務器上的耗資源狀況會更嚴重，而 RBR 模式下，只會對那個發生變化的記 錄產生影響
• 數據表必須幾乎和主服務器保持一致才行，不然可能會致使複製出錯
• 執行復雜語句若是出錯的話，會消耗更多資源

RBR方式的優缺點

RBR的優勢

• 任何狀況均可以被複制，這對複製來講是最安全可靠的
• 和其餘大多數數據庫系統的複製技術同樣
• 多數狀況下，從服務器上的表若是有主鍵的話，複製就會快了不少

RBR 的缺點：

• binlog 大了不少
• 複雜的回滾時 binlog 中會包含大量的數據
• 主服務器上執行 UPDATE 語句時，全部發生變化的記錄都會寫到 binlog 中，而 SBR 只會寫一次，這會
• 致使頻繁發生 binlog 的併發寫問題
• 沒法從 binlog 中看到都複製了寫什麼語句

混合方式

混合方式就是有mysql自動選擇RBR方式和SBR方式，可以充分發揮兩種方式的優勢，通常狀況下都使用該種方式實現主從複製

Mysql主從複製注意事項

1. 主從服務器 操做系統版本 和 位數 一致。
2. 主數據庫和從數據庫的 版本 要一致。
3. 主數據庫和從數據庫中的 數據 要一致。
4. 主數據庫 開啓 二進制日誌，主數據庫和從數據庫的 server_id 在局域網內必須 惟一

Mysql其餘集羣方式

• MyCat 數據庫中間件