【文章內容簡介】 ve從Master端獲取該日志然后再在自己身上完全順序的執(zhí)行日志中所記錄的各種操作。復制的基本過程如下：1)、Slave上面的IO進程連接上Master，并請求從指定日志文件的指定位置（或者從最開始 的日志）之后的日志內容；2)、Master接收到來自Slave的IO進程的請求后，通過負責復制的IO進程根據(jù)請求信息讀取制定日志指定位置之后的日志信息，返回給Slave 的IO進程。返回信息中除了日志所包含的信息之外，還包括本次返回的信息已經到Master端的binlog文件的名稱以及binlog的位置；3)、Slave的IO進程接收到信息后，將接收到的日志內容依次添加到Slave端的relaylog文件的最末端，并將讀取到的Master端的 binlog的文件名和位置記錄到masterinfo文件中，以便在下一次讀取的時候能夠清楚的高速Master“我需要從某個binlog的哪個位置開始往后的日志內容，請發(fā)給我”；4)、Slave的Sql進程檢測到relaylog中新增加了內容后，會馬上解析relaylog的內容成為在Master端真實執(zhí)行時候的那些可執(zhí)行的內容，并在自身執(zhí)行。實際上在老版本的Mysql的復制實現(xiàn)在Slave端并不是兩個進程完成的，而是由一個進程完成。但是后來發(fā)現(xiàn)這樣做存在較大的風險和性能問題，主要如下：首先，一個進程就使復制binlog日志和解析日志并在自身執(zhí)行的過程成為一個串行的過程，性能受到了一定的限制，異步復制的延遲也會比較長。另外，Slave端從Master端獲取binlog過來之后，需要接著解析日志內容，然后在自身執(zhí)行。在這個過程中，Master端可能又產生了大量變化并聲稱了大量的日志。如果在這個階段Master端的存儲出現(xiàn)了無法修復的錯誤，那么在這個階段所產生的所有變更都將永遠無法找回。如果在Slave端的壓力比較大的時候，這個過程的時間可能會比較長。所以，后面版本的Mysql為了解決這個風險并提高復制的性能，將Slave端的復制改為兩個進程來完成。提出這個改進方案的人是Yahoo!的一位工程 師“Jeremy Zawodny”。這樣既解決了性能問題，又縮短了異步的延時時間，同時也減少了可能存在的數(shù)據(jù)丟失量。當然，即使是換成了現(xiàn)在這樣兩個線程處理以后，同 樣也還是存在slave數(shù)據(jù)延時以及數(shù)據(jù)丟失的可能性的，畢竟這個復制是異步的。只要數(shù)據(jù)的更改不是在一個事物中，這些問題都是會存在的。如果要完全避免 這些問題，就只能用mysql的cluster來解決了。不過mysql的cluster是內存數(shù)據(jù)庫的解決方案，需要將所有數(shù)據(jù)都load到內存中，這樣就對內存的要求就非常大了，對于一般的應用來說可實施性不是太大。復制實現(xiàn)級別 Mysql的復制可以是基于一條語句（Statement level），也可以是基于一條記錄（Row level），可以在Mysql的配置參數(shù)中設定這個復制級別，不同復制級別的設置會影響到Master端的binlog記錄成不同的形式。Row Level：日志中會記錄成每一行數(shù)據(jù)被修改的形式，然后在slave端再對相同的數(shù)據(jù)進行修改。優(yōu)點： 在row level模式下binlog中可以不記錄執(zhí)行的sql語句的上下文相關的信息，僅僅只需要記錄那一條記錄被修改了，修改成什么樣了。所以row level的日志內容會非常清楚的記錄下每一行數(shù)據(jù)修改的細節(jié)，非常容易理解。而且不會出現(xiàn)某些特定情況下的存儲過程，或function，以及 trigger的調用和觸發(fā)無法被正確復制的問題。缺點：row level下，所有的執(zhí)行的語句當記錄到日志中的時 候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日志內容，比如有這樣一條update語句：update product set owner_member_id = ‘b’ where owner_member_id = ‘a’，執(zhí)行之后，日志中記錄的不是這條update語句所對應額事件（mysql以事件的形式來記錄binlog日志），而是這條語句所更新的每一條 記錄的變化情況，這樣就記錄成很多條記錄被更新的很多個事件。自然，binlog日志的量就會很大。尤其是當執(zhí)行alter table之類的語句的時候，產生的日志量是驚人的。因為Mysql對于alter table之類的表結構變更語句的處理方式是整個表的每一條記錄都需要變動，實際上就是重建了整個表。那么該表的每一條記錄都會被記錄到日志中。Statement Level:每一條會修改數(shù)據(jù)的sql都會記錄到 master的binlog中。slave在復制的時候sql進程會解析成和原來master端執(zhí)行過的相同的sql來再次執(zhí)行。優(yōu)點：statement level下的優(yōu)點首先就是解決了row level下的缺點，不需要記錄每一行數(shù)據(jù)的變化，減少binlog日志量，節(jié)約IO，提高性能。因為他只需要記錄在Master上所執(zhí)行的語句的細節(jié)，以及執(zhí)行語句時候的上下文的信息。缺點：由于他是記錄的執(zhí)行語句，所以，為了讓這些語句在slave端也能正確執(zhí)行，那么他還必須記錄每條語句在執(zhí)行的時候的一些相關信息，也就是上下文信 息，以保證所有語句在slave端杯執(zhí)行的時候能夠得到和在master端執(zhí)行時候相同的結果。另外就是，由于Mysql現(xiàn)在發(fā)展比較快，很多的新功能不 斷的加入，使mysql得復制遇到了不小的挑戰(zhàn)，自然復制的時候涉及到越復雜的內容，bug也就越容易出現(xiàn)。在statement level下，目前已經發(fā)現(xiàn)的就有不少情況會造測試環(huán)境信息服務器信息項項 值操作系統(tǒng)CentOS release 64位Mysql Cluster 版本內存2GCPU網(wǎng)絡環(huán)境100M局域網(wǎng)部署2個master節(jié)點，兩個slave節(jié)點，一個proxy節(jié)點，兩個lvs+heartbeat節(jié)點機器IP數(shù)據(jù)節(jié)點編號34master節(jié)點信息slave節(jié)點信息機器IP數(shù)據(jù)節(jié)點編號12Mysql proxy節(jié)點信息機器IP數(shù)據(jù)節(jié)點編號5Lvs+heartbeat 節(jié)點信息機器IP數(shù)據(jù)節(jié)點編號67Lvs虛擬ip節(jié)點信息機器IP數(shù)據(jù)節(jié)點編號8機器安裝環(huán)境機器IP用戶名、密碼安裝路徑路徑說明sqlmy/sqlmy/home/sqlmy/mysqlstandlonemysql程序安裝路徑/home/sqlmy/data/mysqldslave節(jié)點數(shù)據(jù)路徑/home/mysql/conf配置文件路徑sqlmy/sqlmy/home/sqlmy/mysqlstandlonemysql程序安裝路徑/home/sqlmy/data/mysqldslave節(jié)點數(shù)據(jù)路徑/home/sqlmy/data/proxyproxy節(jié)點數(shù)據(jù)路徑/home/mysql/conf配置文件路徑sqlmy/sqlmy/home/sqlmy/mysqlstandlonemysql程序安裝路徑/home/sqlmy/data/mysqldmaster節(jié)點數(shù)據(jù)路徑/home/mysql/conf配置文件路徑sqlmy/sqlmy/home/sqlmy/mysqlstandlonemysql程序安裝路徑/home/sqlmy/data/mysqldmaster節(jié)點數(shù)據(jù)路徑/home/mysql/conf配置文件路徑root/htcdtest/etc/Heartbeat配置文件路徑/etc/Lvs配置文件路徑root/htcdtest/etc/Heartbeat配置文件路徑/etc/Lvs配置文件路徑測試環(huán)境架構圖架構圖說明 架構圖分為了五個區(qū)域：客戶端、proxy節(jié)點、lvs+heartbeat節(jié)點、master節(jié)點、slave節(jié)點?？蛻舳耍簩τ贛ySQL簇，它們與標準的（非簇類）MySQL沒有區(qū)別。換句話講，能夠從用PHP、Perl、C、C++、Java、Python、Ruby等編寫的現(xiàn)有MySQL應用程序訪問MySQL簇。proxy節(jié)點：MySQL Proxy就是這么一個中間層代理，簡單的說，MySQL Proxy就是一個連接池，負責將前臺應用的連接請求轉發(fā)給后臺的數(shù)據(jù)庫，并且通過使用lua腳本，可以實現(xiàn)復雜的連接控制和過濾，從而實現(xiàn)讀寫分離和負 載平衡。對于應用來說，MySQL Proxy是完全透明的，應用則只需要連接到MySQL Proxy的監(jiān)聽端口即可。當然，這樣proxy機器可能成為單點失效，但完全可以使用多個proxy機器做為冗余，在應用服務器的連接池配置中配置到多個proxy的連接參數(shù)即可。 MySQL Proxy更強大的一項功能是實現(xiàn)“讀寫分離”，基本原理是讓主數(shù)據(jù)庫處理事務性查詢，讓從庫處理SELECT查詢。數(shù)據(jù)庫復制被用來把事務性查詢導致的變更同步到集群中的從庫。Lvs+heartbeat：由于mysql+replication方案中master和slave的關系是一對多的關系，整個系統(tǒng)中只有一個master節(jié)點（寫入節(jié)點），多個slave節(jié)點，那么master節(jié)點一旦down機后，整個系統(tǒng)的數(shù)據(jù)寫入操作將癱瘓，對系統(tǒng)造成嚴重后果。為此引入了lvs和heartbeat工具，讓這個系統(tǒng)的master和slave關系是多對多的關系，對master節(jié)點進行雙機熱備，以達到整個系統(tǒng)的高可用性。其中heartbeat工具負責對兩個master節(jié)點進行不間斷監(jiān)聽，一旦工作中的master節(jié)點停止工作后，那么備份master節(jié)點就會接管 ，讓這個系統(tǒng)正常工作。Lvs工具的目的是向外提供一個虛擬ip以供proxy訪問master，虛擬ip對應了兩個實ip的maser節(jié)點，lvs還有一個功能是就是在兩個master之間進行負載均衡。Master節(jié)點：Master節(jié)點中有兩個master服務器，服務器之間是雙機熱備。Master服務器主要提供數(shù)據(jù)的寫入功能，并將數(shù)據(jù)操作記錄為二進制日志文件，當收到slave節(jié)點數(shù)據(jù)同步請求后master節(jié)點將會根據(jù)slave請求將制定的日志文件和該日志文件制定的位置以后的日志信息發(fā)送給slave節(jié)點以達到數(shù)據(jù)同步的目的。兩個master之間的數(shù)據(jù)同步也是通過日志文件來進行數(shù)據(jù)同步，