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

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

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

Mysql主從復(fù)制原理

從庫生成兩個線程，一個I/O線程，一個SQL線程；

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

主庫會生成一個 log dump 線程，用來給從庫 i/o線程傳binlog；

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

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

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

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

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

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

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

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

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

主從復(fù)制分析

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

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

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

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

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

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

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

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

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

總統(tǒng)一般都會弄個副總統(tǒng)，以防不測。同樣的，可以給這些關(guān)鍵的節(jié)點來個備份。

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

如果只發(fā)一次，發(fā)給了slave-1，那slave-2,slave-3,…它們怎么辦？

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

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

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

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

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

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

可以分庫【垂直拆分】，分表【水平拆分】