寫在前面
愛奇藝每天都爲數以億計的用戶提供7*24小時不間斷的視頻服務。通過愛奇藝的平臺，用戶可以方便的獲取海量、優質、高清的視頻資源。但如果服務平臺出現故障，會有大量的用戶將無法正常播放視頻，因此我們的應用服務以及數據庫服務都必須具備高可用架構。
愛奇藝技術產品團隊對各類應用劃分了不同的重要等級，對不同重要等級的應用使用數據庫服務提供了不同的 SLA 保障。比如 S 級應用 RTO 控制在分鐘級別的保障；對 A 級應用 RTO 在 10 分鐘級別的保障等。本文將主要介紹我們的 MySQL 高可用實現方案。
自研MySQL HA系統
1. 基於MHA二次開發
MHA是目前比較成熟及流行的MySQL高可用解決方案，很多互聯網公司正是直接使用或者基於MHA的架構進行改造實現MySQL的高可用。MHA能在30秒內對故障進行轉移，並最大程度的保障數據的一致性。MHA由兩個模塊組成：Manager和 Node。
Manager部署在獨立的機器上，負責檢查MySQL複製狀態、主庫狀態以及執行切換操作。Node運行在每臺MySQL機器上，主要負責保存和複製master binlog、識別主庫宕機時各Slave差異的中繼日誌並將差異的事務應用到其他的Slave，同時還負責清除Slave上的relay_log。
它的部署架構如下圖所示：
MHA雖然已經比較成熟，但也存在一些的缺點：
- 使用配置文件管理主備關係、不能重複切換
- 實例增減需要重啓Manager
- Manager是單點，雖然有standby的節點，但不能自動切換
另外我們的MySQL部署環境複雜，存在跨DC跨地域的部署，新主的選舉需要更多的規則。並且集羣數量較爲龐大，如果直接採用MHA做高可靠用，會大大增加管理成本。因此我們自研了一套MySQL的高可用方案。
2. MySQL HA架構簡介
愛奇藝自研MysQL HA系統由HA Master和HA Agent兩部分組成。三個HA Master組成一個最小集羣單元，這個最小集羣單元對應MHA的Manager，通過raft協議實現高可用，解決Manager單點和不能重複切換的問題。HA Agent功能和MHA Node功能類似，負責責故障檢測、解析和傳輸 binlog、清理 relay log 以 及負責 MGR 的高可用。
(1) HA Master
HA Master使用了raft的java實現—copycat框架來進行Leader選舉和Session監聽，HA Master多機房部署。HA Master有三個重要模塊：狀態機、心跳模塊和切換模塊，狀態機保存當前raft leader的地址，心跳模塊和Agent保持10秒1次的心跳檢查，收到Agent心跳後會更新心跳時間戳和實例狀態。每次Leader重選，新的Leader會更新狀態機的leader地址。Agent註冊到各個HA Master的狀態機內，如果狀態機裏的Leader地址發生了變更，則發佈變更數據給每個註冊的Agent，Agent再向新的Leader發送rpc心跳。
切換模塊則負責具體的故障切換，通過定期輪訓badinstance集合，對符合條件的實例進行切換。支持自動和手動兩種切換方式。對於自動切換，需要在CMDB裏配置好切換策略，可選同DC切換、跨DC切換還是跨地域切換。
切換流程如圖所示：
除了對主庫支持故障切換外，也具備對從庫故障切換的能力。在從庫故障宕機時，通過檢測故障，再操作域名的方式實現Slave的高可用。
(2) HA Agent
Agent負責監控CMDB裏狀態爲online的實例，通過檢查mysqld進程是否存在等規則判斷實例是否存活，如果判斷實例宕機則向HA Master發送包含badinstance的RPC心跳。如果是機器宕機，HA Master會收到Agent的超時事件，並對心跳超時的Agent所在服務器上的實例進行切換。爲了儘量避免網絡抖動造成誤切，我們把Agent超時時長設置爲1分鐘，1分鐘內的閃斷或者抖動不做切換。
Agent還負責對MGR的Primary節點進行監控和域名切換。MGR在主節點發生切換後，客戶端需要去捕獲這個切換信息，再把請求重新指向新的主節點，這對於業務來說不友好。因此我們給Agent增加一個功能，當發現主節點發生過切換後，就把源主節點上的域名重綁到新的主節點上，從而實現MGR故障切換對業務的透明。
3. HA的選主規則
HA需要一套複雜的選主規則，用以適配我們複雜的部署環境，選主規則如下：
- 排除在bad slaves裏的slave
- 選擇所有latest slaves優先級最高的candidate master
- 如果從庫沒有設置優先級，選出所有非bad slaves的slave
- 根據切換策略，依次選擇同DC->同region->跨region的slave。
- 對滿足條件的從庫，排除從庫所在機器Master個數和Slave個數太多的salve，在剩下的slave中選擇機器剩餘磁盤空間最大的slave。
通過以上規則，選出一個最優的主進行切換。如果沒有滿足條件的slave，則會通過電話告警的方式通知DBA進行人工干預。
4. 補全diff binlog
在Master切換過程中，會存在3種類型的diff binlog：
- 從庫io thread接收到的relay log不完整，不是一個完整的事務或完整的binlog event。
- lastest slave與其他slave存在的diff relay log。
- 如果dead master機器還能訪問, 則還包括dead master未發送的diff binlog。
diff binlog的恢復順序如圖所示：
如果是使用gtid複製，需要生成3種diff binlog文件，然後順序apply diff binlog文件，恢復從庫。非gtid複製，先change master到lastest slave，先讓slave從lastest slave恢復數據，然後再apply dead master未發送的diff binlog 文件，完成binlog補齊。
5. 數據一致性的重要性
如果採用半同步複製，且主庫宕機瞬間沒有發生網絡超時，則HA能保證切換以後數據的一致性。但如果主庫宕機瞬間，網絡存在超時會導致半同步複製退化爲異步複製，此時發生切換就可能丟失數據。這種情況需要業務端具備補償機制，對數據進行補齊。但如果是MGR，不會存在數據丟失的問題。
結束語
我們結合愛奇藝多種內部監控系統、資產管理系統、CMDB、鏈路追蹤以及混沌工程平臺開發一個面向業務的應用運維平臺，提供一站式服務撥測、巡檢、資源使用分析、調用鏈路追蹤以及故障演練等功能。通過混沌工程平臺提供的故障注入能力，對S級業務的數據庫進行攻防演練。經過不斷的迭代優化，數據庫的攻防演練會成爲常態，通過不斷的演練提升應用的可用性和安全性，真正做到有備無患。
本文轉載自公衆號愛奇藝技術產品團隊（ID：iQIYI-TP）。
原文鏈接：