概述

Mysql的Replication(復(fù)制)是一個(gè)異步的復(fù)制過(guò)程，從一個(gè) Mysql instance(我們稱(chēng)之為 Master)復(fù)制到另一個(gè)Mysql instance(我們稱(chēng)之 Slave)。在 Master 與 Slave之間的實(shí)現(xiàn)整個(gè)復(fù)制過(guò)程主要由三個(gè)線程來(lái)完成，其中兩個(gè)線程(Sql線程和IO線程)在 Slave 端，另外一個(gè)線程(IO線程)在Master端。

主從同步需求

要實(shí)現(xiàn) MySQL 的 Replication ，首先必須打開(kāi) Master 端的BinaryLog(mysql-bin.xxxxxx)功能，否則無(wú)法實(shí)現(xiàn)。因?yàn)檎麄€(gè)復(fù)制過(guò)程實(shí)際上就是Slave從Master端獲取該日志然后再在自己身上完全順序的執(zhí)行日志中所記錄的各種操作。打開(kāi) MySQL 的 Binary Log 可以通過(guò)在啟動(dòng) MySQL Server 的過(guò)程中使用“—log-bin” 參數(shù)選項(xiàng)，或者在 my.cnf 配置文件中的 mysqld 參數(shù)組([mysqld]標(biāo)識(shí)后的參數(shù)部分)增加“l(fā)og-bin” 參數(shù)項(xiàng)。

主從同步過(guò)程

MySQL 復(fù)制的基本過(guò)程如下：

1.Slave上面的IO線程連接上Master，并請(qǐng)求從指定日志文件的指定位置(或者從最開(kāi)始的日志)之后的日志內(nèi)容;
2.Master接收到來(lái)自Slave的IO線程的請(qǐng)求后，通過(guò)負(fù)責(zé)復(fù)制的IO線程根據(jù)請(qǐng)求信息讀取指定日志指定位置之后的日志信息，返回給Slave端的 IO線程。返回信息中除了日志所包含的信息之外，還包括本次返回的信息在Master端的Binary Log文件的名稱(chēng)以及在Binary Log中的位置;
3.Slave的IO線程接收到信息后，將接收到的日志內(nèi)容依次寫(xiě)入到 Slave 端的RelayLog文件(mysql-relay-bin.xxxxxx)的最末端，并將讀取到的Master端的bin-log的文件名和位置記錄到master-info文件中，以便在下一次讀取的時(shí)候能夠清楚的告訴Master“我需要從某個(gè)bin-log的哪個(gè)位置開(kāi)始往后的日志內(nèi)容，請(qǐng)發(fā)給我”。
4.Slave的SQL線程檢測(cè)到Relay Log中新增加了內(nèi)容后，會(huì)馬上解析該Log文件中的內(nèi)容成為在Master 端真實(shí)執(zhí)行時(shí)候的那些可執(zhí)行的Query語(yǔ)句，并在自身執(zhí)行這些Query。這樣，實(shí)際上就是在Master端和Slave端執(zhí)行了同樣的Query，所以兩端的數(shù)據(jù)是完全一樣的。

實(shí)際上，在老版本中，MySQL 的復(fù)制實(shí)現(xiàn)在 Slave 端并不是由 SQL 線程和 IO線程這兩個(gè)線程共同協(xié)作而完成的，而是由單獨(dú)的一個(gè)線程來(lái)完成所有的工作。但是 MySQL的工程師們很快發(fā)現(xiàn)，這樣做存在很大的風(fēng)險(xiǎn)和性能問(wèn)題，主要如下：

1.首先，如果通過(guò)一個(gè)單一的線程來(lái)獨(dú)立實(shí)現(xiàn)這個(gè)工作的話，就使復(fù)制 Master 端的，BinaryLog日志，以及解析這些日志，然后再在自身執(zhí)行的這個(gè)過(guò)程成為一個(gè)串行的過(guò)程，性能自然會(huì)受到較大的限制，這種架構(gòu)下的Replication 的延遲自然就比較長(zhǎng)了。

3.其次，Slave 端的這個(gè)復(fù)制線程從 Master 端獲取 Binary Log 過(guò)來(lái)之后，需要接著解析這些內(nèi)容，還原成Master 端所執(zhí)行的原始 Query，然后在自身執(zhí)行。在這個(gè)過(guò)程中，Master端很可能又已經(jīng)產(chǎn)生了大量的變化并生成了大量的Binary Log 信息。如果在這個(gè)階段 Master端的存儲(chǔ)系統(tǒng)出現(xiàn)了無(wú)法修復(fù)的故障，那么在這個(gè)階段所產(chǎn)生的所有變更都將永遠(yuǎn)的丟失，無(wú)法再找回來(lái)。這種潛在風(fēng)險(xiǎn)在Slave端壓力比較大的時(shí)候尤其突出，因?yàn)槿绻?Slave壓力比較大，解析日志以及應(yīng)用這些日志所花費(fèi)的時(shí)間自然就會(huì)更長(zhǎng)一些，可能丟失的數(shù)據(jù)也就會(huì)更多。

所以，在后期的改造中，新版本的 MySQL 為了盡量減小這個(gè)風(fēng)險(xiǎn)，并提高復(fù)制的性能，將 Slave端的復(fù)制改為兩個(gè)線程來(lái)完成，也就是前面所提到的 SQL 線程和 IO線程。最早提出這個(gè)改進(jìn)方案的是Yahoo!的一位工程師“JeremyZawodny”。通過(guò)這樣的改造，這樣既在很大程度上解決了性能問(wèn)題，縮短了異步的延時(shí)時(shí)間，同時(shí)也減少了潛在的數(shù)據(jù)丟失量。

當(dāng)然，即使是換成了現(xiàn)在這樣兩個(gè)線程來(lái)協(xié)作處理之后，同樣也還是存在 Slave數(shù)據(jù)延時(shí)以及數(shù)據(jù)丟失的可能性的，畢竟這個(gè)復(fù)制是異步的。只要數(shù)據(jù)的更改不是在一個(gè)事務(wù)中，這些問(wèn)題都是存在的。

總結(jié)

初步了解了MySQL主從復(fù)制的原理。

最新評(píng)論