服務(wù)器Mysql主從復(fù)制原理——指南篇

什么是主從復(fù)制?

主從復(fù)制的原理 : 簡(jiǎn)而言之，MySQL-A在進(jìn)行寫操作時(shí)，都會(huì)更新數(shù)據(jù)庫(kù)A的二進(jìn)制sql日志,通過(guò)網(wǎng)絡(luò)傳輸將二進(jìn)制sql日志傳遞給數(shù)據(jù)庫(kù)B，B再將二進(jìn)制sql日志寫入B數(shù)據(jù)庫(kù)，完成主從復(fù)制。

Mysql主從復(fù)制原理

從庫(kù)生成兩個(gè)線程，一個(gè)I/O線程，一個(gè)SQL線程；

i/o線程去請(qǐng)求主庫(kù) 的binlog，并將得到的binlog日志寫到relay log（中繼日志） 文件中；

主庫(kù)會(huì)生成一個(gè) log dump 線程，用來(lái)給從庫(kù) i/o線程傳binlog；

SQL 線程，會(huì)讀取relay log文件中的日志，并解析成具體操作，來(lái)實(shí)現(xiàn)主從的操作一致，而最終數(shù)據(jù)一致；

Mysql支持的復(fù)制類型:

(1)：基于語(yǔ)句的復(fù)制： 在主服務(wù)器上執(zhí)行的SQL語(yǔ)句(寫入bin log中)，在從服務(wù)器上執(zhí)行同樣的語(yǔ)句。MySQL默認(rèn)采用基于語(yǔ)句的復(fù)制，效率比較高。binlog_format = ‘STATEMENT’

(2)：基于行的復(fù)制：把改變的內(nèi)容(寫入bin log中)復(fù)制過(guò)去，而不是把命令在從服務(wù)器上執(zhí)行一遍. 從mysql5.0開(kāi)始支持。binlog_format = ‘ROW’

(3)：混合類型的復(fù)制: 默認(rèn)采用基于語(yǔ)句的復(fù)制，一旦發(fā)現(xiàn)基于語(yǔ)句的無(wú)法精確的復(fù)制時(shí)，就會(huì)采用基于行的復(fù)制。binlog_format = ‘MIXED’

Mysql主從復(fù)制優(yōu)點(diǎn)

健壯性:主服務(wù)器出現(xiàn)故障時(shí),可以切到從服務(wù)器作為備份

速度快:更新操作在主服務(wù)器端,查詢操作在從服務(wù)器端,可以加快用戶的響應(yīng)時(shí)間

備份:避免影響業(yè)務(wù)

主從復(fù)制分析

問(wèn)題1：master的寫操作，slaves被動(dòng)的進(jìn)行一樣的操作，保持?jǐn)?shù)據(jù)一致性，那么slave是否可以主動(dòng)的進(jìn)行寫操作？

假設(shè)slave可以主動(dòng)的進(jìn)行寫操作，slave又無(wú)法通知master，這樣就導(dǎo)致了master和slave數(shù)據(jù)不一致了。因此slave不應(yīng)該進(jìn)行寫操作，至少是slave上涉及到復(fù)制的數(shù)據(jù)庫(kù)不可以寫。實(shí)際上，這里已經(jīng)揭示了讀寫分離的概念。

問(wèn)題2：主從復(fù)制中，可以有N個(gè)slave,可是這些slave又不能進(jìn)行寫操作，要他們干嘛？

可以實(shí)現(xiàn)數(shù)據(jù)備份。

類似于高可用的功能，一旦master掛了，可以讓slave頂上去，同時(shí)slave提升為master。

異地容災(zāi)，比如master在北京，地震掛了，那么在上海的slave還可以繼續(xù)。

主要用于實(shí)現(xiàn)scale out,分擔(dān)負(fù)載,可以將讀的任務(wù)分散到slaves上。

【很可能的情況是，一個(gè)系統(tǒng)的讀操作遠(yuǎn)遠(yuǎn)多于寫操作，因此寫操作發(fā)向master，讀操作發(fā)向slaves進(jìn)行操作】

問(wèn)題4：如果mysql proxy , direct , master他們中的某些掛了怎么辦？

總統(tǒng)一般都會(huì)弄個(gè)副總統(tǒng)，以防不測(cè)。同樣的，可以給這些關(guān)鍵的節(jié)點(diǎn)來(lái)個(gè)備份。

問(wèn)題5：當(dāng)master的二進(jìn)制日志每產(chǎn)生一個(gè)事件，都需要發(fā)往slave，如果我們有N個(gè)slave,那是發(fā)N次，還是只發(fā)一次？

如果只發(fā)一次，發(fā)給了slave-1，那slave-2,slave-3,…它們?cè)趺崔k？

顯 然，應(yīng)該發(fā)N次。實(shí)際上，在MYSQL master內(nèi)部，維護(hù)N個(gè)線程，每一個(gè)線程負(fù)責(zé)將二進(jìn)制日志文件發(fā)往對(duì)應(yīng)的slave。master既要負(fù)責(zé)寫操作，還的維護(hù)N個(gè)線程，負(fù)擔(dān)會(huì)很重?？?以這樣，slave-1是master的從，slave-1又是slave-2,slave-3,…的主，同時(shí)slave-1不再負(fù)責(zé)select。 slave-1將master的復(fù)制線程的負(fù)擔(dān)，轉(zhuǎn)移到自己的身上。這就是所謂的多級(jí)復(fù)制的概念。

問(wèn)題6：當(dāng)一個(gè)select發(fā)往mysql proxy，可能這次由slave-2響應(yīng)，下次由slave-3響應(yīng)，這樣的話，就無(wú)法利用查詢緩存了。

應(yīng)該找一個(gè)共享式的緩存，比如memcache來(lái)解決。將slave-2,slave-3,…這些查詢的結(jié)果都緩存至mamcache中。

問(wèn)題7：隨著應(yīng)用的日益增長(zhǎng)，讀操作很多，我們可以擴(kuò)展slave，但是如果master滿足不了寫操作了，怎么辦呢？

scale on ?更好的服務(wù)器？ 沒(méi)有最好的，只有更好的，太貴了。。。

scale out ? 主從復(fù)制架構(gòu)已經(jīng)滿足不了。

可以分庫(kù)【垂直拆分】，分表【水平拆分】