問題1:Mysql是如何保證不丟數(shù)據(jù)的?

眾所周知,事務一旦提交,則對數(shù)據(jù)的改變將永久有效,這是數(shù)據(jù)庫持久性的特性.那么Mysql是如何做到不丟數(shù)據(jù)的?什么是commit?事務commit時Mysql又做了什么?

數(shù)據(jù)的持久性機制依賴server層的binlog以及InnoDB存儲引擎層的redolog.
事務的commit操作本身,包含兩個階段的處理:
準備階段:
server調(diào)用InnoDB寫入redolog

完成階段:
1.server寫入binlog
2.server調(diào)用InnoDB,寫入commit標簽(在redolog中)

其中,事務提交是否成功,以binlog是否成功落盤為準.
場景1:
準備階段失敗,redolog沒有寫入,則提交失敗,且數(shù)據(jù)一致.

場景2:
準備階段成功,redolog寫入,完成階段server寫入binlog失敗,則提交失敗.此時數(shù)據(jù)不一致(存在redolog但不存在binlog).宕機恢復時,因為不存在binlog,因此需要對事務進行回滾.

場景3
完成階段server寫入binlog成功,server調(diào)用InnoDB,寫入commit標簽失敗,則提交成功.此時數(shù)據(jù)不一致(redolog中缺少commit標志).宕機恢復時,補償寫入commit標簽以及后續(xù)處理.

總結(jié),提交時的兩階段處理,可以保證數(shù)據(jù)的持久性,以及binlog和redolog內(nèi)部的一致性.

問題2:如何提高Mysql可用性?

Mysql的ACID的特性保證了其單機的可靠性,但是存在單點風險.
由此引出了主從架構(gòu)和復制的概念.

所謂復制,就是slave負責從master讀取binlog,并寫入自己的relaylog中,之后通過relaylog進行重放,已達到數(shù)據(jù)同步的目的.

問題3:Mysql支持哪些復制以及對應的優(yōu)缺點?

生產(chǎn)環(huán)境中常見的復制包含異步復制和半同步復制兩種.

異步復制就是在master事務提交后,立即給客戶端返回結(jié)果,將復制操作變?yōu)楫惒降?優(yōu)點是不會影響客戶端的響應時效,缺點是無法保證主從間的數(shù)據(jù)一致性.如果master宕機,則slave可能會丟失數(shù)據(jù).

半同步復制就是在事務提交后,結(jié)果返回給客戶端之前,增加了與slave見的復制和確認過程,只有接到slave的ack后,才會返回給客戶端結(jié)果.相比異步復制,它增加了等待的時間,也即降低了客戶端響應失效,但是保證了master與slave間的強一致性.

注意:如果master等待slave的ack時超時,則會降級為異步復制模式,所以生產(chǎn)中要將超時時間設置的足夠大,來保證半同步的有效性.

問題4:Mysql5.7之前半同步存在的問題?

Mysql5.7之前,半同步的復制流程為:
prepare(寫redolog)->寫binlog->寫commit標志->復制->確認.
這對應rpl_semi_sync_master_point=AFTER_COMMIT的配置.

復制發(fā)生在commit完成之后,因此在復制期間,客戶端拿到結(jié)果之前,事務結(jié)果已經(jīng)可見了.也就是說,其他會話會先于當前會話看到事務結(jié)果.

為了解決這一問題,Mysql5.7增加了rpl_semi_sync_master_point=AFTER_SYNC的配置,將復制流程變?yōu)?
prepare(寫redolog)->寫binlog->復制->確認->寫commit標志.
也就是說復制和確認發(fā)生在binlog寫入成功之后,InnoDBcommit之前,由此,在復制完成之前,其他會話不會看到當前事務的結(jié)果.

問題5:主從架構(gòu)下,如何保證可用性的同時,確保數(shù)據(jù)一致性?

前文所述,事務的持久性是以binlog寫入是否成功為準的.如果master在binlog寫入成功之后,復制之前發(fā)生宕機,則slave沒有拿到master的binlog.此時如果為了高可用而進行slave升主操作時,會導致丟數(shù)據(jù).

通常的解決方案是:在升主之前進行主從之間的數(shù)據(jù)對比校驗,以確保數(shù)據(jù)一致性.

問題6:數(shù)據(jù)校驗期間Mysql不可寫如何解決?

通常通過多主從組,加數(shù)據(jù)分片和路由解決.當某個master宕機時,將寫入請求導入另外的master,并在此期間對故障master進行恢復和數(shù)據(jù)校驗.

另外,為了對機房斷電進行容災,通常采用一機房雙master-slave,外加多機房的部署架構(gòu).