MySQL複製之理論篇

標籤：lib   格式   用途   自己   伺服器   部分   compress   邏輯   中繼   

一、MySQL複製概述

      MySQL支援兩種複製方式：基於行的複製和基於語句的複製（邏輯複製）。這兩種方式都是通過在主庫上記錄

二進位日誌、在備庫重放日誌的方式來實現非同步資料複製，其工作原理如：

      同一時間點主庫和備庫的資料可能存在不一致。複製通常不會增加主庫的開銷，主要是啟用二進位日誌帶來的開

銷。通過複製可以將讀操作指向備庫來獲得更好的讀擴充，但對於寫操作，除非設計得當，否則並不適合通過複製來

擴充寫操作。在一主庫多備庫的架構中，寫操作會被執行多次，這時候整個系統的效能取決於寫入最慢的那部分。

   複製解決的問題（用途）：資料分布、、負載平衡、備份、高可用性和故障切換、MySQL升級測試等等。

 

二、MySQL複製原理

1. 基於語句的複製：

       主庫記錄那些造成資料更改的查詢，當備庫讀取並重放這些事件時，實際上只是把主庫上執行過的SQL再執行一遍。

   好處：實現簡單、二進位日誌裡事件更加緊湊。當主備庫模式不同時，邏輯複製能在多種情況下工作。容易理解，

出現問題可以很好定位。

       缺點：存在一些無法被正確複製的SQL，例如當使用了CURRENT_USER()函數時。更新必須是串列的，這需要更多的

鎖。預存程序和觸發器在使用基於語句的複製模式時也可能存在問題。

2. 基於行的複製：
       基於行的複製將實際資料記錄在二進位日誌中。

       好處：可以正確地複製每一行。無須重放更新主庫資料的查詢，更高效。減少鎖的使用。

       缺點：很難進行時間點恢複、開銷有時大有時小。無法判斷執行了哪些SQL。出現問題很難定位。無法處理諸如在

備庫修改表的schema這樣的情況。

       沒有那種模式對所有情況都是完美的，MySQL能夠在這兩種複製模式間動態切換。預設情況下使用的是基於語句的

複製方式，但如果發現語句無法被正確地複製，就切換到基於行的複製模式。

3. 複製使用的檔案：

（1）二進位檔案、中繼二進位檔案（檔案名稱可在mysql設定檔中配置）

（2）mysql-bin.index：記錄所有的二進位記錄檔名，不能刪除，MySQL依賴這個檔案識別二進位記錄檔。

（3）mysql-relay-bin.index：記錄所有中繼日誌的索引檔案，同樣不能刪除。

（4）master.info：儲存備庫串連到主庫所需要的資訊，格式為純文字，記錄了複製使用者的密碼。

（5）relay-log.info：記錄當前備庫複製的二進位日誌和中繼日誌座標。

4. 發送制事件到其他備庫：

      log_slave_updates選項可以讓備庫變成其他伺服器的主庫。在設定該選項後，MySQL會將其執行過的事件記錄到

它自己的二進位日誌中，這樣它的備庫就可以從其日誌中檢索並執行事件。原理圖如下：

註：

   當複製SQL線程讀中繼日誌時，會丟棄事件中記錄的伺服器ID和該伺服器本身ID相同的事件，從而打破了複製過程中

的無限迴圈。

5. 複製過濾器：

       複製過濾器選項允許僅複製伺服器上一部分資料。有兩種過濾方式：在主庫上過濾記錄到二進位日誌中的事件、在

備庫上過濾記錄到中繼日誌中的事件。原理圖如下：

註：

       除非萬不得已，不要使用複製過濾，因為它很容易中斷複製並導致問題，在需要災難恢複時也會帶來極大的不方便。

 

三、複寫拓撲
      可以在任意個主庫和備庫之間建立複製，只有一個限制：每一個備庫只能有一個主庫。各種拓撲結構的基本原則：

（1）一個MySQL備庫執行個體只能有一個主庫。

（2）每個備庫必須有一個唯一的伺服器ID。

（3）一個主庫可以有多個備庫。

（4）如果開啟了log_slave_updates選項，一個備庫可以把其主庫上的資料變化傳播到其他備庫。

1. 一主庫多備庫：

      在有少量寫和大量讀時，這種配置是非常有用的。可以把讀分攤到多個備庫上，直到備庫給主庫造成了太大的負擔，

或者主備之間的頻寬成為瓶頸為止。

2. 主動-主動模式下的主-主複製：
      也叫雙主複製或雙向複製，包含兩台伺服器，每一個都被配置成對方的主庫和備庫。

      這種配置最大的問題是如何解決衝突，例如，兩台伺服器同時修改一行記錄，或同時在兩台伺服器上向一個包含

auto_increment列的表裡插入資料。

      允許向兩個伺服器寫入所帶來的麻煩遠遠大於其帶來的好處。

3. 主動-被動模式下的主-主複製：

   把“主動-主動模式下的主-主複製”中的的一台伺服器配置成唯讀被動伺服器。

       這種方式使得反覆切換主動和被動伺服器非常方便，因為伺服器的配置是對稱的，這使得容錯移轉和故障恢複很容易。

4. 擁有備庫的主-主結構：

   為主-主複製中的每個主庫增加一個備庫。

       這種配置的優點是增加了冗餘，對於不同地理位置的複寫拓撲結構，能夠消除網站單點失效的問題。

5. 環形複製：
       每個伺服器都是在它之前的伺服器的備庫，是在它之後的伺服器的主庫。完全依賴於環上的每一個可用節點，大大增

加了整個系統失效的幾率。如果從環中移除一個節點，這個節點發起的事件就會陷入無限迴圈。

       可用通過為每個節點增加備庫的方式來減少環形複製的風險。

6. 主庫、分發主庫以及備庫：

       當備庫足夠多時，會對主庫造成很大的負載。這種拓撲使用一個備庫專門來進行複製的分發，移除主庫的負載。

   為了避免在分發主庫上做實際的查詢，可以將它的表修改為blackhole儲存引擎。如果主庫接近滿負載，不應該為其

建立10個以上的備庫。可以通過設定slave_compressed_protocol來節約一些主庫寬頻。可以通過分發主庫實現其他目的，例

如對二進位日誌事件執行過濾和重寫規則。

       使用分發主庫一個主要的缺點是無法使用一個備庫來代替主庫，因為由於分發主庫的存在，導致各個備庫與原始主庫

的二進位日誌座標已經不相同。

7. 樹或金字塔形：

        減輕了主庫的負擔，但它的缺點是中介層出現的任何錯誤都會影響到多個伺服器，中介層次越多，處理故障會更困難、

更複雜。

MySQL複製之理論篇