更新時(shí)間：2012-02-29
1、MySQL Replication復(fù)制進(jìn)程
MySQL數(shù)據(jù)庫的復(fù)制（replication）是一個(gè)異步的復(fù)制，從一個(gè)MySQL instace（稱之為Master）復(fù)制到另一個(gè)MySQL instance（稱之Slave）。實(shí)現(xiàn)整個(gè)復(fù)制操作主要由三個(gè)進(jìn)程完成的，其中兩個(gè)進(jìn)程在Slave（Sql進(jìn)程和IO進(jìn)程），另外一個(gè)進(jìn)程在Master（IO進(jìn)程）上。
要實(shí)施復(fù)制，首先必須打開Master端的binary log（bin-log）功能，否則無法實(shí)現(xiàn)。因?yàn)檎麄�(gè)復(fù)制過程實(shí)際上就是Slave從Master端獲取該日志然后再在自己身上完全順序的執(zhí)行日志中所記錄的各種操作。
MySQL Replication復(fù)制的基本過程如下：
1)、Slave上面的IO進(jìn)程連接上Master，并請(qǐng)求從指定日志文件的指定位置（或者從最開始的日志）之后的日志內(nèi)容；
2)、Master接收到來自Slave的IO進(jìn)程的請(qǐng)求后，通過負(fù)責(zé)復(fù)制的IO進(jìn)程根據(jù)請(qǐng)求信息讀取制定日志指定位置之后的日志信息，返回給Slave的IO進(jìn)程。返回信息中除了日志所包含的信息之外，還包括本次返回的信息已經(jīng)到Master端的bin-log文件的名稱以及bin-log的位置；
3)、Slave的IO進(jìn)程接收到信息后，將接收到的日志內(nèi)容依次添加到Slave端的relay-log文件的最末端，并將讀取到的Master端的bin-log的文件名和位置記錄到master-info文件中，以便在下一次讀取的時(shí)候能夠清楚的高速M(fèi)aster“我需要從某個(gè)bin-log的哪個(gè)位置開始往后的日志內(nèi)容，請(qǐng)發(fā)給我”；
4)、Slave的Sql進(jìn)程檢測到relay-log中新增加了內(nèi)容后，會(huì)馬上解析relay-log的內(nèi)容成為在Master端真實(shí)執(zhí)行時(shí)候的那些可執(zhí)行的內(nèi)容，并在自身執(zhí)行。
實(shí)際上在老版本的MySQL的復(fù)制實(shí)現(xiàn)在Slave端并不是兩個(gè)進(jìn)程完成的，而是由一個(gè)進(jìn)程完成。但是后來發(fā)現(xiàn)這樣做存在較大的風(fēng)險(xiǎn)和性能問題，主要如下：
首先，一個(gè)進(jìn)程就使復(fù)制bin-log日志和解析日志并在自身執(zhí)行的過程成為一個(gè)串行的過程，性能受到了一定的限制，異步復(fù)制的延遲也會(huì)比較長。
另外，Slave端從Master端獲取bin-log過來之后，需要接著解析日志內(nèi)容，然后在自身執(zhí)行。在這個(gè)過程中，Master端可能又產(chǎn)生了大量變化并聲稱了大量的日志。如果在這個(gè)階段Master端的存儲(chǔ)出現(xiàn)了無法修復(fù)的錯(cuò)誤，那么在這個(gè)階段所產(chǎn)生的所有變更都將永遠(yuǎn)無法找回。如果在Slave端的壓力比較大的時(shí)候，這個(gè)過程的時(shí)間可能會(huì)比較長。
所以，后面版本的MySQL為了解決這個(gè)風(fēng)險(xiǎn)并提高復(fù)制的性能，將Slave端的復(fù)制改為兩個(gè)進(jìn)程來完成。提出這個(gè)改進(jìn)方案的人是Yahoo!的一位工程師“Jeremy Zawodny”。這樣既解決了性能問題，又縮短了異步的延時(shí)時(shí)間，同時(shí)也減少了可能存在的數(shù)據(jù)丟失量。當(dāng)然，即使是換成了現(xiàn)在這樣兩個(gè)線程處理以后，同樣也還是存在slave數(shù)據(jù)延時(shí)以及數(shù)據(jù)丟失的可能性的，畢竟這個(gè)復(fù)制是異步的。只要數(shù)據(jù)的更改不是在一個(gè)事物中，這些問題都是會(huì)存在的。如果要完全避免這些問題，就只能用MySQL的cluster來解決了。不過MySQL的cluster是內(nèi)存數(shù)據(jù)庫的解決方案，需要將所有數(shù)據(jù)都load到內(nèi)存中，這樣就對(duì)內(nèi)存的要求就非常大了，對(duì)于一般的應(yīng)用來說可實(shí)施性不是太大。
2、MySQL Replication復(fù)制實(shí)現(xiàn)級(jí)別
MySQL Replication復(fù)制可以是基于一條語句（Statement level），也可以是基于一條記錄（Row level），可以在MySQL的配置參數(shù)中設(shè)定這個(gè)復(fù)制級(jí)別，不同復(fù)制級(jí)別的設(shè)置會(huì)影響到Master端的bin-log記錄成不同的形式。
Row Level：日志中會(huì)記錄成每一行數(shù)據(jù)被修改的形式，然后在slave端再對(duì)相同的數(shù)據(jù)進(jìn)行修改。
優(yōu)點(diǎn)：在row level模式下，bin-log中可以不記錄執(zhí)行的sql語句的上下文相關(guān)的信息，僅僅只需要記錄那一條記錄被修改了，修改成什么樣了。所以row level的日志內(nèi)容會(huì)非常清楚的記錄下每一行數(shù)據(jù)修改的細(xì)節(jié)，非常容易理解。而且不會(huì)出現(xiàn)某些特定情況下的存儲(chǔ)過程，或function，以及trigger的調(diào)用和觸發(fā)無法被正確復(fù)制的問題。
缺點(diǎn)：row level下，所有的執(zhí)行的語句當(dāng)記錄到日志中的時(shí)候，都將以每行記錄的修改來記錄，這樣可能會(huì)產(chǎn)生大量的日志內(nèi)容，比如有這樣一條update語句：update product set owner_member_id = ‘b’ where owner_member_id = ‘a(chǎn)’，執(zhí)行之后，日志中記錄的不是這條update語句所對(duì)應(yīng)額事件（MySQL以事件的形式來記錄bin-log日志），而是這條語句所更新的每一條記錄的變化情況，這樣就記錄成很多條記錄被更新的很多個(gè)事件。自然，bin-log日志的量就會(huì)很大。尤其是當(dāng)執(zhí)行alter table之類的語句的時(shí)候，產(chǎn)生的日志量是驚人的。因?yàn)镸ySQL對(duì)于alter table之類的表結(jié)構(gòu)變更語句的處理方式是整個(gè)表的每一條記錄都需要變動(dòng)，實(shí)際上就是重建了整個(gè)表。那么該表的每一條記錄都會(huì)被記錄到日志中。
Statement Level:每一條會(huì)修改數(shù)據(jù)的sql都會(huì)記錄到 master的bin-log中。slave在復(fù)制的時(shí)候sql進(jìn)程會(huì)解析成和原來master端執(zhí)行過的相同的sql來再次執(zhí)行。
優(yōu)點(diǎn)：statement level下的優(yōu)點(diǎn)首先就是解決了row level下的缺點(diǎn)，不需要記錄每一行數(shù)據(jù)的變化，減少bin-log日志量，節(jié)約IO，提高性能。因?yàn)樗恍枰涗浽贛aster上所執(zhí)行的語句的細(xì)節(jié)，以及執(zhí)行語句時(shí)候的上下文的信息。
缺點(diǎn)：由于他是記錄的執(zhí)行語句，所以，為了讓這些語句在slave端也能正確執(zhí)行，那么他還必須記錄每條語句在執(zhí)行的時(shí)候的一些相關(guān)信息，也就是上下文信息，以保證所有語句在slave端杯執(zhí)行的時(shí)候能夠得到和在master端執(zhí)行時(shí)候相同的結(jié)果。另外就是，由于MySQL現(xiàn)在發(fā)展比較快，很多的新功能不斷的加入，使MySQL得復(fù)制遇到了不小的挑戰(zhàn)，自然復(fù)制的時(shí)候涉及到越復(fù)雜的內(nèi)容，bug也就越容易出現(xiàn)。在statement level下，目前已經(jīng)發(fā)現(xiàn)的就有不少情況會(huì)造成MySQL的復(fù)制出現(xiàn)問題，主要是修改數(shù)據(jù)的時(shí)候使用了某些特定的函數(shù)或者功能的時(shí)候會(huì)出現(xiàn)，比如：sleep()函數(shù)在有些版本中就不能真確復(fù)制，在存儲(chǔ)過程中使用了last_insert_id()函數(shù)，可能會(huì)使slave和master上得到不一致的id等等。由于row level是基于每一行來記錄的變化，所以不會(huì)出現(xiàn)類似的問題。
從官方文檔中看到，之前的MySQL一直都只有基于statement的復(fù)制模式，直到5.1.5版本的MySQL才開始支持row level的復(fù)制。從5.0開始，MySQL的復(fù)制已經(jīng)解決了大量老版本中出現(xiàn)的無法正確復(fù)制的問題。但是由于存儲(chǔ)過程的出現(xiàn)，給MySQL Replication復(fù)制又帶來了更大的新挑戰(zhàn)。另外，看到官方文檔說，從5.1.8版本開始，MySQL提供了除Statement Level和Row Level之外的第三種復(fù)制模式：Mixed，實(shí)際上就是前兩種模式的結(jié)合。在Mixed模式下，MySQL會(huì)根據(jù)執(zhí)行的每一條具體的sql語句來區(qū)分對(duì)待記錄的日志形式，也就是在Statement和Row之間選擇一種。新版本中的Statment level還是和以前一樣，僅僅記錄執(zhí)行的語句。而新版本的MySQL中隊(duì)row level模式也被做了優(yōu)化，并不是所有的修改都會(huì)以row level來記錄，像遇到表結(jié)構(gòu)變更的時(shí)候就會(huì)以statement模式來記錄，如果sql語句確實(shí)就是update或者delete等修改數(shù)據(jù)的語句，那么還是會(huì)記錄所有行的變更。
3、MySQL Replication復(fù)制常用架構(gòu)
MySQL Replication復(fù)制環(huán)境90%以上都是一個(gè)Master帶一個(gè)或者多個(gè)Slave的架構(gòu)模式，主要用于讀壓力比較大的應(yīng)用的數(shù)據(jù)庫端廉價(jià)擴(kuò)展解決方案。因?yàn)橹灰猰aster和slave的壓力不是太大（尤其是slave端壓力）的話，異步復(fù)制的延時(shí)一般都很少很少。尤其是自slave端的復(fù)制方式改成兩個(gè)進(jìn)程處理之后，更是減小了slave端的延時(shí)。而帶來的效益是，對(duì)于數(shù)據(jù)實(shí)時(shí)性要求不是特別的敏感度的應(yīng)用，只需要通過廉價(jià)的pc server來擴(kuò)展slave的數(shù)量，將讀壓力分散到多臺(tái)slave的機(jī)器上面，即可解決數(shù)據(jù)庫端的讀壓力瓶頸。這在很大程度上解決了目前很多中小型網(wǎng)站的數(shù)據(jù)庫壓力瓶頸問題，甚至有些大型網(wǎng)站也在使用類似方案解決數(shù)據(jù)庫瓶頸。
一個(gè)Master帶多個(gè)slave的架構(gòu)實(shí)施非常簡單，多個(gè)slave和單個(gè)slave的實(shí)施并沒有太大區(qū)別。在Master端并不care有多少個(gè)slave連上了master端，只要有slave進(jìn)程通過了連接認(rèn)證，向他請(qǐng)求binlog信息，他就會(huì)按照連接上來的io進(jìn)程的要求，讀取自己的binlog信息，返回給slave的IO進(jìn)程。對(duì)于slave的配置細(xì)節(jié)，在MySQL的官方文檔上面已經(jīng)說的很清楚了，甚至介紹了多種實(shí)現(xiàn)slave的配置方法。
MySQL不支持一個(gè)Slave instance從屬于多個(gè)Master的架構(gòu)。就是說，一個(gè)slave instance只能接受一個(gè)master的同步源，聽說有patch可以改進(jìn)這樣的功能，但沒有實(shí)踐過。MySQL AB之所以不實(shí)現(xiàn)這樣的功能，主要是考慮到?jīng)_突解決的問題。
MySQL也可以搭建成dual master模式，也就是說兩個(gè)MySQL instance互為對(duì)方的Master，也同時(shí)為對(duì)方的Slave。不過一般這種架構(gòu)也是只有一端提供服務(wù)，避免沖突問題。因?yàn)榧词乖趦蛇厛?zhí)行的修改有先后順序，由于復(fù)制的異步實(shí)現(xiàn)機(jī)制，同樣會(huì)導(dǎo)致即使在晚做的修改也可能會(huì)被早做的修改所覆蓋，就像如下情形：
時(shí)間點(diǎn) MySQL A MySQL B
1 更新x表y記錄為10
2 更新x表y記錄為20
3 獲取到A日志并應(yīng)用，更新x表的y記錄為10（不符合期望）
4 獲取B日志更新x表y記錄為20（符合期望）
這樣，不僅在B庫上面的數(shù)據(jù)不是用戶所期望的結(jié)果，A和B兩邊的數(shù)據(jù)也出現(xiàn)了不一致的情況。除非能將寫操作根據(jù)某種條件固定分開在A和B兩端，保證不會(huì)交叉寫入，才能夠避免上面的問題。
