JavaScript must be enabled in order for you to see "WP Copy Data Protect" effect. However, it seems JavaScript is either disabled or not supported by your browser. To see full result of "WP Copy Data Protector", enable JavaScript by changing your browser options, then try again.

Category Archives: Replication

實作MySQL Replication(Master/Slave) on CentOS 6.2 x64


有使用過資料庫的朋友們,一定多少有耳聞MySQL,當資料量越來越大,或是需要即時的備份時(熱備份),可以透過一些MySQL的負載方式來解決這些問題,如Master/Slave架構MMM架構HeartBeat/DRBDCluster等等都是,而要如何挑選哪種架構比較好呢?看了ㄚ忠部落格的建議,最好是在Master/Slave的架構上,加上HeartBeat/DRBD做Master的備援與加上幾台Memcached來加快搜尋速度等等是個不錯的辦法,但若是要運用在實際運作中的主機,需考慮資料一致性的問題,若要檢視細部的資訊,可參考MySQL的官方網站,而這裡要介紹的為Master/Slave實作部分,而這個架構的優點在於當Statement Level(每一條會修改數據的sql都會記錄到master的bin-log中)下可以解決了Row Level(一條紀錄)上的缺點,因為不需要記錄每一行數據的變化,它只需要記錄在Master上所執行的語句的細節,以及執行語句時候的上下文的信息即可,也可以減少bin-log日誌容量,進而節省I/O並提高性能;至於它的缺點在於當Row Level下,所有的執行的語句當記錄到日誌中的時候,都將以每行記錄的修改來記錄,這樣可能會產生大量的日誌內容,比如說有一條update語句:update product set owner_member_id = ‘b’ where owner_member_id = ‘a’,在執行之後,日誌中記錄的不是這條update語句所對應的額外事件(MySQL以事件的形式來記錄bin-log日誌)做處理,而是這條語句所更新的每一條記錄的變化情況,這樣就記錄成很多條記錄被更新的很多個事件。自然bin-log日誌的量就會很大,尤其是當執行alter table之類的語句的時候,產生的日誌量是驚人的。因為MySQL對於alter table之類的表結構變更語句的處理方式是整個表的每一條記錄都需要變動,實際上就是重建了整個表,那麼該表的每一條記錄都會被記錄到日誌中,進而Slave在複製的時候,SQL的Process會解析成和原來Master端執行過的相同的sql來再次執行;另一的缺點由於它是記錄執行的語句,所以為了讓這些語句在Slave端也能正確執行,那麼他還必須記錄每條語句在執行的時候的一些相關信息,也就是上下文信息,以保證所有語句在Slave端執行的時候能夠得到和在Master端執行時候相同的結果,另外還有因為MySQL發展速度較快,很多的新功能不斷的加入,使得MySQL的複製遇到了不小的挑戰,自然複製的時候涉及到越複雜的內容,bug也就越容易出現,像是在Statement Level下,目前已經發現有不少的情況會造成MySQL的複製出現問題,主要都是修改數據的時候使用了某些特定的函數或者功能時會出現,比如sleep()函數在有些版本中就不能被正確地複製、在儲存過程中使用了last_insert_id()函數,可能會使Slave和Master上得到不一致的ID等等的問題,但在Row Level上是基於每一行都用記錄的變化,所以不會出現類似的問題;上面說了那麼多,我相信一定很多人有看沒有懂,直接上一次實作可能會比較了解內容與架構,如下: Read more »

This site is protected by WP-CopyRightPro