MySQL：從MySQL看主從架構高可用性實現(xiàn)
從進入互聯(lián)網(wǎng)時代開始，我們從單機走向集群再到當前的微服務架構，我們已經(jīng)很少再使用單機架構來實現(xiàn)業(yè)務邏輯，即使沒有使用微服務，但是主備、主從等集群已經(jīng)屬于是業(yè)務側必備能力。
但是，無論是主備還是主從架構，實際上就是為了系統(tǒng)的高可用性實現(xiàn)的一個策略，防止主機因為某些故障導致異常下線，這時候備份或者從實例就會通過選擇或者其他策略成為主服務實例，對外繼續(xù)提供服務。
在MySQL的正常情況下，只要主庫執(zhí)行更新生成的所有binlog全部被正確的傳到備庫并且被正確執(zhí)行，備庫就能和主庫數(shù)據(jù)一致，實現(xiàn)最終一致性。但是最終一致性并不能滿足線上的性能需求，還需要保證集群的可用性。
1 主備延遲
1.1 主備延遲
在發(fā)生主備延遲時，與數(shù)據(jù)同步的時間點主要包括：
- 主庫 A 執(zhí)行完成一個事務，寫入 binlog，我們把這個時刻記為 T1;
- 之后傳給備庫 B，我們把備庫 B 接收完這個 binlog 的時刻記為 T2;
- 備庫 B 執(zhí)行完成這個事務，我們把這個時刻記為 T3。
主備延遲，就是同一個事務，在備庫執(zhí)行完成的時間和主庫執(zhí)行完成的時間之間的差值，就是T3-T1。
在備庫執(zhí)行show slave status會得到seconds_behind_master，表示備庫延遲的時間，計算方法為：
- 每個事務的binlog都有一個時間字段，用于記錄主庫寫入時間；
- 備庫取出當前正在執(zhí)行的事務的時間字段的值，計算與當前系統(tǒng)時間差值，就是該值，單位為秒；
如果主備庫機器的系統(tǒng)時間設置不一致，不會導致主備延遲的值不準。因為，備庫連接到主庫的時候，會通過執(zhí)行 SELECT UNIX_TIMESTAMP() 函數(shù)來獲得當前主庫的系統(tǒng)時間。如果這時候發(fā)現(xiàn)主庫的系統(tǒng)時間與自己不一致，備庫在執(zhí)行 seconds_behind_master 計算的時候會自動扣掉這個差值。
但是：如果備庫已經(jīng)連接主庫后，修改主庫的系統(tǒng)時間，備庫同步的時候就不會再做時間的自動修正了，因此，時間修正只有第一次建連的時候才會執(zhí)行。
在網(wǎng)絡正常的時候，日志從主庫傳給備庫所需的時間是很短的，即 T2-T1 的值是非常小的。也就是說，網(wǎng)絡正常情況下，主備延遲的主要來源是備庫接收完 binlog 和執(zhí)行完這個事務之間的時間差。所以說，主備延遲最直接的表現(xiàn)是，備庫消費中轉日志（relay log）的速度，比主庫生產(chǎn) binlog 的速度要慢。
1.2 主備延遲的來源
1.2.1 主備機性能有差距
備庫所在機器性能比主庫的機器性能差，此時一般將備庫設置為“非雙1”模式【犧牲備庫的一點可靠性，減少寫盤次數(shù)，增強IO能力】，更新過程中觸發(fā)大量讀操作，可能會導致主備延遲。
現(xiàn)在這種情況比較少，因為現(xiàn)在都是主從部署，可能隨時發(fā)生主從切換，因此一般都是對稱部署。
1.2.2 備庫壓力大
一般出現(xiàn)的原因是讀寫分離場景，備庫對外提供讀能力，查詢耗費大量CPU資源，影響了同步速度，造成主備延遲。
此時的處理措施是：
- 一主多從，用從庫分擔壓力；
- 通過binlog輸出到外部系統(tǒng)，比如Hadoop系統(tǒng)，提供統(tǒng)計類查詢能力；
從庫和備庫在概念上其實差不多。在我們這個專欄里，為了方便描述，我把會在 HA 過程中被選成新主庫的，稱為備庫，其他的稱為從庫。
1.2.3 大事務
主庫必須等事務執(zhí)行完成后才能寫入binlog，再傳給備庫，造成主備延遲。
比如說大量數(shù)據(jù)的刪除就會造成大事務，一般是要求分批執(zhí)行。之所以刪除會造成大事務，是因為無論是否有索引，存儲引擎都是一條條數(shù)據(jù)查詢并加鎖，返回給執(zhí)行引擎，執(zhí)行引擎標記數(shù)據(jù)刪除。所有的數(shù)據(jù)都處理完成后，才會提交事務釋放鎖。
另一種就是大表DDL。
1.3 主備延遲的排查思路
1）查數(shù)據(jù)庫在干什么
pager cat - | grep -v Sleep | sort -rn -k 12 | head -n 20
show full processlist;
select * from information_schema.processlist
where 1=1 order by TIME desc limit 10;2）查看sql_thread在干什么
slave上查看狀態(tài)：
show slave status\G;查看relay_master_log_file以及exec_master_log_pos
master上解析binglog日志：
mysqlbinlog -v --base64-output=decode-rows --start-position=exec_master_log_pos relay_master_log_file如果發(fā)現(xiàn)卡在操作某表上：
1））檢查表結構
- 沒有索引：stop slave 可能會卡主，建議關閉mysql，啟動后先加索引，然后start slave
- 有索引：只能等，大事務需要做拆分，不要操作太多數(shù)據(jù)
2））大事務：M上session回話使用statement格式，使用語句級別的復制
3）查看MySQL狀態(tài)
- 機器性能（CPU、IO等）：從庫配置適當高一點，使用新硬件PCI-E或SSD設備
- 表結構: 設計要合理，必須有主鍵，主鍵要短小，為查詢字段建索引
- 業(yè)務程序：適當使用緩存，減少數(shù)據(jù)庫壓力
分析MySQL進程并結合源碼：
perf top `pidof mysqld`4）參數(shù)臨時優(yōu)化
- 主庫開啟group commit
- 從庫開啟writeset
- 從庫設置sync_binlog=0 && innodb_flush_log_at_trx_commit=2
5）檢查鎖情況
show engine innodb status\G;2 主備切換策略
2.1 可靠性優(yōu)先策略
在雙M結構下，主備切換的流程如圖：
圖片
- 判斷備庫 B 現(xiàn)在的 seconds_behind_master（SBM），如果小于某個值（比如 5 秒）繼續(xù)下一步，否則持續(xù)重試這一步；這里主從延遲時間短，說明當前沒有大事務，延遲比較低，減少因為延遲造成數(shù)據(jù)不可靠的幾率；
- 把主庫 A 改成只讀狀態(tài)，即把 readonly 設置為 true；
- 判斷備庫 B 的 seconds_behind_master 的值，直到這個值變成 0 為止；
- 把備庫 B 改成可讀寫狀態(tài)，也就是把 readonly 設置為 false；
- 把業(yè)務請求切到備庫 B。
這個切換流程，一般是由專門的 HA 系統(tǒng)來完成的，我們暫時稱之為可靠性優(yōu)先流程。
圖片
這個切換流程中是有不可用時間的。因為在步驟 2 之后，主庫 A 和備庫 B 都處于 readonly 狀態(tài)，也就是說這時系統(tǒng)處于不可寫狀態(tài)，直到步驟 5 完成后才能恢復。
在這個不可用狀態(tài)中，比較耗費時間的是步驟 3，可能需要耗費好幾秒的時間。這也是為什么需要在步驟 1 先做判斷，確保 seconds_behind_master 的值足夠小。
2.2 可用性優(yōu)先策略
如果是直接將第4和第5步提前，保證了系統(tǒng)幾乎么有不可用時間，但是可能造成數(shù)據(jù)不一致。
其實這就是CAP中的C和A，MySQL主庫在寫完binlog后就給客戶端響應了，沒等binlog同步到一個或多個備庫，這種策略是在C和A之間選擇了A，犧牲了C，如果主庫宕機了，但binlog的最后一個或幾個事務沒同步到備庫，那備庫成為主庫后，數(shù)據(jù)就丟了。其它的NoSQL很多是給用戶提供了選擇，比如Mongo，用戶可以設置日志同步到幾個Slave后再給客戶端響應，同步的Slave越多，C越強，A越弱，比如同步到X個Slave后再給客戶端響應，那即使任何X個節(jié)點宕機，集群中仍然有1個節(jié)點有最新日志，它會成為主節(jié)點，數(shù)據(jù)沒丟，集群還可以工作。
在滿足數(shù)據(jù)可靠性的前提下，MySQL 高可用系統(tǒng)的可用性，是依賴于主備延遲的。延遲的時間越小，在主庫故障的時候，服務恢復需要的時間就越短，可用性就越高。
2.3 常見切換技術
semi-sync在網(wǎng)絡故障超時的情況下會退化成async，這個時候如果剛好主庫掉電了，有些binlog還沒有傳給從庫，從庫無法判斷數(shù)據(jù)跟主庫是否一致，如果強行切換可能會導致丟數(shù)據(jù)，在金融業(yè)務場景下只能＂人工智能＂來做切換，服務中斷時間長。AliSQL采用雙通道復制更容易判斷主備數(shù)據(jù)是否一致，如果一致可以自動切換，如果不一致才需要人工恢復數(shù)據(jù)。
