高可用
高可用(High Availabiltity)
- 應用提供持續不間斷(可用)的服務的能力
- 系統高可用性的評價通常用可用率表示
造成不可用的原因
- 硬件故障(各種)
- 預期中的系統軟硬件維護
- 軟件缺陷(應用代碼，服務程序都可能存在bug)
- 攻擊，泄露，認為失誤...等安全事件
- 對於系統來說，不可用時間是各關鍵組件不可用時間的總和.....
提高可用性的主要手段
- 冗余，Redundancy
- 關鍵軟硬件通過備用冗余避免故障時長時間的不可用
- 數據軟件，硬件，存儲的數據，都需要通過冗余確保故障時可替換
mysql高可用常見方案：
- 數據庫服務在冗余實現上有其特殊性
-
- 數據：服務＂有狀態＂與數據冗余
- 數據庫可用性考慮兩部分：數據可用性，服務可用性；
- 實現方式多種多樣，同一種數據也會有多種實現方案
- 可用性目標循序漸進
-
- 任何故障都不會造成數據丟失－＞可以較快速恢復服務（高可用）
高可用方案
1.mysql--基於共享存儲的單活方案(不常用)
- SAN，方案比較昂貴；因此不常用；
- 且數據庫備用機，只是機器活着，但是沒有沒有起mysql服務；
-
- 因為大部分共享存儲或數據庫是不允許同一份數據被不同數據使用的；
- 本地數據通過RAID等手段保證數據安全
2.基於存儲復制的數據冗余單活(不常用)
- 存在一定浪費，備用機器一直不在用，等待主機掛掉，才會使用備用機；
- 而且DRBD（兩台機器間通過網絡，備份數據），不是100%的保證數據不丟失；
3.基於集群提交通信協議的多主復制(一定場景適用)
基於主從復制的高可用方案
4.基於Mysql主從復制(常用，普適)
- 備庫，在線上也會提供服務，避免浪費；
- 而主從復制，也保證了數據不會丟失。
mysql主從復制高可用方案需要改進的問題
- 主從服務器各自有IP地址，發生主從切換后應用需要修改重啟；
- 如何讓應用快速找到從庫；VIP/DNS
- 人工判斷主庫是否故障再發起切換需要花較多時間
- 如何自動探知；監控探知並自動VIP/DNS;
- 主從復制存在客觀延遲，切換后可能造成事務數據丟失。
- 由於網絡延時，如何避免數據丟失。
1.為了避免應用人工修改切換IP，引入VIP（virtual ip）漂移方案：
方案二：
DNS，應用服務器，使用域名；
平時，將域名注冊在主庫上，而主庫掛掉，將域名注冊到從庫就可以了；
2.為了減少人工介入處理的時間開銷引入自動
探活處理機制
高可用中間層與RDS
- VIP/DNS解決 應用切換問題
- 監控和管理服務器解決自動判斷故障切換和VIP/DNS漂移
- VIP/DNS管理+探活+主從關系切換 = 高可用中間層
-
- 透明切換管理+靠譜數據探活+使用切換 = 高可用中間層
- 雲環境+高可用中間層+底層數據庫=一種PaaS=基本RDS、
高可用中間層
- MHA
-
- 自動選擇復制延遲最小的從節點並試圖補全日志（但大部分主機故障下行不通）
- 通常要求兩從以上，會進行主從關系切換
- 不提供VIP管理方案
- MMM
-
- 提供了基本的VIP管理功能
- 適合雙主配置的一對主機，不會主動切換主從關系
- 不支持主從數據延遲判斷和補全
一般使用MHA，開源；
3.mysql主從復制延遲
為什么日志傳輸延遲
為什么主從復制，主從庫會數據不一致；
解決方案：
mysql半同步技術：
主庫一次commit，要等到主庫持久化完成，以及從庫也持久化完成，才給主鍵放回commit成功。
但是問題：
主庫等待從庫的時間是不可控的；
主庫發現從庫寫不進去了，可以等待幾秒，之后主庫復制自動降級成異步復制；但這也可能導致數據不一致；
較完善的mysql高可用方案
- 半同步復制+高可用中間層+VIP管理方案
- 高可用中間層=靠譜探活+主從切換+使用VIP管理的接口
例如：
- 半同步復制+MHA（高可用中間層）+Keeplive（VIP管理方案）
- 半同步復制+RDS
總結
- 高可用指標至少3個9目標4個9
- 高可用核心就是使用冗余
- 數據庫高可用兩個部分
-
- 數據可用性--數據有狀態
- 服務可用性
- 高可用方案
-
- 基於共享存儲SAN的單活方案
-
- SAN,設備昂貴
- 單活，備用機浪費，因為同一份數據不能被不同mysql實例使用；
- 本地數據可以通過RAID等手段保證
- 基於DRBD存儲復制的數據冗余單活
-
- 基於SAN方案的改進，不使用SAN設備
- 單活，備用機浪費
- DRBD基於兩台機器間通過網絡備份數據，數據不能100%保證
- 多主復制--mysql cluster
- 基於mysql主從復制（常用，普適）
-
- 備份，在線上可提供只讀服務，避免浪費；
- 主從復制，也保證了數據不會丟失
- 基於mysql主從復制的問題
-
- 主從服務器各有IP地址，發生主從切換后應用需要修改重啟；
-
- 使用VIP(virtual IP)/DNS管理方案，當發生切換是，只需要將VIP從主庫漂移到從庫，對應用來說是透明的。
- 人工判斷主庫是否故障，在發起切換需要時間長
-
- 使用監控服務器，自動靠譜探知+自動主從切換
- 主從復制存在客觀延遲，切換后可能造成事務數據丟失
-
- 使用半同步復制技術，但也要考慮到從庫宕機，主庫應該自動降級成異步復制；
- 解決問題后的mysql高可用方案
-
- VIP管理方案+高可用中間層+半同步復制
- 高可用中間層
-
- VIP/DNS管理+靠譜探活+主從關系切換=高可用中間層
- 雲環境+高可用中間層+底層數據庫=一種paas=基本RDS
- MHA/MMM
- MHA
-
- 自動選擇復制延遲最小的從節點並試圖補全日志（主機故障下行不通）
- 自動探活
- 自動主從切換
- 不提供VIP管理方案，但提供使用VIP方案的接口