《高性能MySQL》の複製

0x00前言

本書講述到定稿前的MySQL5.5版，因此下面內容的適用範圍止步於MySQL5.5。本文僅僅強調書中講述的重中之重， 以便快速查閱，詳細的內容還請認真閱讀書本和MySQL的官方文檔。

0x01簡介

本章闡述全部與複製相關的內容

• 簡要介紹複製如何工做
• 討論基本的複製服務搭建
  1. 與複製相關的配置
  2. 如何管理和優化複製服務器

0x02複製概述

• MySQL支持兩種複製方式：基於行的複製和基於語句的複製。
• 都是經過主庫上記錄二進制日誌，雖然有開銷，可是不會很大。
• 同一時間點備庫上的數據可能與主庫存在不一致性，並沒有法保證主備之間的延遲。
• 經過複製能夠將讀操做指向備庫來得到更好地讀擴展。
• 目前備庫只能串行化執行。

複製解決的問題

• 數據分佈
• 負載均衡
• 備份
• 高可用性和故障切換
• MySQL升級

複製如何工做

• 主庫把數據更改記錄到二進制日誌中。
• 備庫將主庫上的日誌複製到本身的中繼日誌中。
• 備庫讀取中繼日誌中的事件，將其重放到備庫數據之上。

<!-- more -->

0x03配置複製（略）

0x04複製的原理

如今通常使用基於行的複製更佳。

基於語句的複製（邏輯複製）

優勢

• 實現至關簡單
• 不用太多帶寬
• 容易理解

缺點

• 不少狀況沒法正確複製，如使用了now()等函數
• 若使用了觸發器或者存儲過程也最好不要使用

基於行的複製

優勢

• 減小鎖的使用，更高效地複製數據
• 佔用更少的CPU
• 解決數據不一致的狀況

缺點

• 沒法知道服務器正在作什麼
• 沒法處理諸如在備庫修改表的schema的狀況
• 帶寬較高

0x05複製拓撲（日後補充圖）

MySQL的複製有一個限制：每一個備庫只能有一個主庫，可是能夠用一些其餘方法來解決這樣的限制。

一主庫多備庫（多用於備份和讀寫分離）

備庫之間根本沒有交互。有如下用途：

• 爲不一樣的角色使用不一樣的備庫
• 可把一個備庫當作代用的主庫
• 把備庫放在遠程數據中心，用做災難恢復
• 備份，培訓，開發，測試

主動-主動模式下的主-主複製

用於兩個處於不一樣地理位置的辦公室，而且都須要一份可寫的數據拷貝。弊大於利。

主動-被動模式下的主-主複製

切換主動被動服務器很方便。

擁有備庫的主-主結構（用於增長冗餘）

環形複製（要避免成環）

主庫、分發主庫以及備庫

• 當備庫足夠多時。會對主庫形成很大的負載，因而須要採用blackhole存儲引擎的分發主庫。
• 不必定只使用一個分發主庫。
• blackhole表沒有任何數據，可是目前有bug

樹或金字塔形

定製的複製方案

• 選擇複製性
• 分離功能（分離OLTP和OLAP）
• 數據歸檔
• 將備庫用做全文索引
• 只讀備庫
• 模擬多主庫複製
• 建立沒有數據的日誌服務器

0x06複製和容量規劃

主備庫的模式下，並非增長備庫就能線性增長讀寫功能。而且在開啓複製功能時，要考慮監控延時，可用性。

0x07 MySQL複製的高級特性

半同步複製

能夠幫助確保備庫擁有主庫數據的拷貝，減小潛在的數據丟失危機。有助於備庫提供更好地冗餘度和持久性。 半同步複製在提交過程當中增長一個延遲：當提交事務時，在客戶端接收到查詢結束反饋前必須保證二進制日誌已經傳輸 到至少一臺備庫上。

• 在主庫上已經完成事務提交，只有通知客戶端被延遲了。
• 備庫在接收到事務後發送反饋而非（備庫）完成事務後發送。
• 若是備庫一直沒有迴應已收到事件，會超時並轉化爲正常的異步複製模式。

複製心跳

保持備庫一直與主庫相聯繫，避免悄無聲息地斷開鏈接。

0x08小結

• KISS原則（Keep It Simple Stupid），用簡單的就好。
• 監控，監控，監控，重要的事情說三遍。
• 理解複製的異步本質，且設計你的應用避免或容忍從備庫讀取髒數據。
• 在一個複製拓撲中不要寫入多於一個服務器，把備庫配置爲只讀，並下降權限以阻止對數據的改變。
• 打開本章鎖討論的明智且安全的設置。（日後補充）

引用

《高性能MySQL · 第三版》