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