mysql 主從服務器

                        mysql系列之複製1----原理篇

原做品出處：http://nolinux.blog.51cto.com/4824967/1528519

MySQL 複製介紹：

       MySQL支持單向、異步複製，複製過程當中一個服務器充當主服務器，而一個或多個其它服務器充當從服務器。

       MySQL主服務器將更新寫入二進制日誌文件，並維護文件的一個索引以跟蹤日誌循環。這些日誌能夠記錄發送到從服務器的更新。當一個從服務器鏈接主服務器時，它通知主服務器從服務器在日誌中讀取的最後一次成功更新的位置。從服務器接收從那時起發生的任何更新，而後封鎖並等待主服務器通知新的更新。

       在當前的生產工做中，大多數應用的 MySQL 主從同步都是異步的複製方式，即不是嚴格實時的數據同步。

       若是你想要設置鏈式複製服務器，從服務器自己也能夠充當主服務器。

       須要注意的是，當你在進行復制時，全部對複製中的表的更新必須在主服務器上進行，這樣作的目的是爲了不用戶對主服務器上的表進行的更新與對從服務器上的表所進行的更新之間產生衝突。

MySQL複製架構介紹

       MySQL的複製架構除了上面說的主從複製（同步）以外，還有主主複製（同步）以及多主環狀複製（同步）。

       假設，咱們使用了環狀或者鏈式級聯複製，那麼咱們的從（Slave）服務器自己除了充當從服務器以外，還須要同時充當其下面從服務器的主服務器。

       相關主從複製架構，主主複製架構以及環狀、鏈式級聯複製架構圖，咱們能夠看下面的圖例：

一、單向主從同步邏輯架構圖

二、雙向主主同步邏輯架構圖

三、線性級聯單向雙主同步邏輯架構圖

四、環狀級聯單向多主同步邏輯架構圖

五、環狀級聯單向多主多從同步邏輯架構圖

MySQL 複製的優點：

這裏主要以 主從複製 的爲例：

MySQL 主從複製有利於增長整個數據庫的健壯性、提高訪問速度，而且易於維護管理。

一、增長健壯性

      主服務器/從服務器設置增長了健壯性。主服務器出現問題時，你能夠切換到從服務器做爲備份。

二、提高訪問速度

       經過在主服務器和從服務器之間切分處理客戶查詢的負荷，能夠獲得更好的客戶響應時間。SELECT 查詢能夠發送到從服務器以下降主服務器的查詢處理負荷。但修改數據的語句仍然應發送到主服務器，以便主服務器和從服務器保持同步。若是非更新查詢爲主，該負載均衡策略頗有效，但通常是更新查詢。這也正是咱們生產經常使用的讀寫分離。

三、易於維護管理

       公司內部開發和維護人員，能夠在一臺從服務器上作後臺訪問、數據分析和腳本操做，特別是使用一個從服務器執行備份，這樣就不會干擾主服務器的運行性能。在備份過程當中，主服務器能夠繼續處理更新操做。

MySQL 複製的應用場景：

這裏仍是主要以 主從複製 的生產應用場景爲例：

1）主從服務器互爲備份

       主從服務器架構的設置，能夠大大的增強數據庫架構的健壯性。例如：當主服務器出現問題時，咱們能夠人工或自動切換到從服務器繼續提供服務。

 2）主從服務器讀寫分離，分擔網站壓力

       主從服務器架構可經過程序或代理軟件對用戶（客戶端）的請求實現讀寫分離，即經過在從服務器上僅僅處理用戶的select查詢請求，下降用戶查詢響應時間及讀寫同時在主服務器帶來的壓力。對於更新的數據（update，insert，delete）仍然交給主服務器處理，確保主服務器和從服務器保持實時同步。

       若是網站是以非更新（以瀏覽爲主）爲主的業務，如博客或者首頁展現等業務，查詢請求比較多，此時從服務器的讀寫分離、負載均衡策略就會很是有效，這就是讀寫分離數據庫結構了。

3）根據服務器拆分業務獨立並分擔壓力

       生產中能夠把幾個不一樣的從服務器，根據公司的業務進行拆分。例如：有爲外部用戶提供查詢服務的從服務器，有DBA用來備份的從服務器，還有提供公司內部人員訪問的後臺、腳本，日誌分析及開發人員服務的從服務器。這樣的拆分不只會減輕主服務器的壓力，並且使對外用戶瀏覽、對內處理公司內部用戶業務以及 DBA 備份業務互不影響。

請看以下主從架構生產環境從服務器分業務拆分使用案例：

1 2 3 4 5

master ┌ --> Slave1 --> 對外部用戶提供服務（瀏覽帖子、遊覽博客、瀏覽文章）              ├ --> Slave2 --> 對外部用戶提供服務（瀏覽帖子、遊覽博客、瀏覽文章）              ├ --> Slave3 --> 對外部用戶提供服務（瀏覽帖子、遊覽博客、瀏覽文章）              ├ --> Slave4 --> 對內部管理人員提供服務（後臺訪問、腳本任務、數據分析、開發人員瀏覽）              └ --> Slave5 --> 開啓從服務器 binlog 功能，可實現增量備份及恢復

MySQL 數據複製的原理

       MySQL 複製基於主服務器在二進制日誌中跟蹤全部對數據庫的更改(更新、刪除等等)。所以，要進行復制，必須在主服務器上啓用二進制日誌。

       每一個從服務器從主服務器接收主服務器已經記錄到其二進制日誌的保存的更新，以便從服務器能夠對其數據拷貝執行相同的更新。

       認識到二進制日誌只是一個從啓用二進制日誌的固定時間點開始的記錄很是重要。任何設置的從服務器須要主服務器上的（在主服務器上啓用二進制日誌時的）數據庫拷貝。若是啓動從服務器時，其數據庫與主服務器上的啓動二進制日誌時的狀態不相同，從服務器極可能失敗。

       將主服務器的數據拷貝到從服務器的經常使用途徑是，使用mysqldump對主服務器上的SQL進行轉儲，而後在從服務器上進行恢復。須要注意的是，在主服務器使用mysqldump進行SQL轉儲以前，須要進行鎖表操做，並記錄當時的binlog日誌及位置點！

       MySQL數據複製的原理圖大體以下：(此圖來自於高性能MySQL這本書)

從上圖，咱們能夠看出 MySQL 數據庫的複製須要啓動三個線程來實現：

       其中一個在主服務器上，另兩個在從服務器上。

一、當從服務器執行 START SLAVE 時，就表示開啓主從複製開關

二、此時，從服務器自己會建立一個 I/O 線程，經過主服務器上受權的複製用戶權限請求鏈接主服務器，並請求從指定 Binlog 日誌文件的指定位置點（日誌文件名和位置點信息就是在配置主從複製服務時，執行change master命令時給定的）以後發送 binlog 日誌（即SQL語句）；

三、主服務器接收到來自從服務器的I/O線程請求以後，主服務器會建立一個 Binlog dump 線程，該線程會根據從服務器I/O線程請求的信息去讀取指定Binlog 日誌文件中指定位置點以後的 Binlog 日誌信息，而後返回給從服務器的 I/O 線程。返回的信息中，除了 Binlog 日誌內容以外，還有包括主服務器上最新的 Binlog 文件名以及在該 Binlog 中的最新的指定更新位置點（即下一次從服務器請求的Binlog文件名和位置點信息）。

四、當從服務器的 I/O 線程獲取到主服務器上 Binlog dump 線程發送過來的日誌內容及最新的日誌文件名及位置點以後，它會將 Binlog 日誌內容依次寫入到從服務器自己的Relay Log（即中繼日誌）文件（Mysql-relay-bin.xxxx）的最末端，並將新的 Binlog 文件名和位置點信息記錄到 master-info 文件中，以便下一次讀取主服務器的最新 Binlog 日誌時，可以告訴主服務器須要從最新 Binlog 日誌的哪一個文件的哪一個位置點開始請求新的 Binlog 日誌內容。

五、從服務器的 SQL 線程會實時的檢測本地 Relay Log 中是否有新增長的日誌內容，若是有它會就及時的把 Relay Log 文件中的內容解析成在主服務器曾經執行過的 SQL 語句內容，並在從服務器自身按語句的順序執行對應的這些 SQL 語句，應用完畢後會自動清理應用過的日誌。

     這樣一來，在從服務器上讀取和執行語句被分紅兩個獨立的任務。若是語句執行較慢則語句讀取任務沒有慢下來。例如，若是從服務器有一段時間沒有運行了，當從服務器啓動時，其I/O線程能夠很快地從主服務器索取全部二進制日誌內容，即便 SQL 線程遠遠滯後。若是從服務器在 SQL 線程執行完全部索取的語句前中止，I/O 線程至少已經索取了全部內容，以便語句的安全拷貝保存到本地從服務器的中繼日誌中，供從服務器下次啓動時執行。這樣就容許清空主服務器上的二進制日誌，由於再也不須要等候從服務器來索取其內容。

六、通過了上面的一系列過程，Mysql就可以確保在主服務器和從服務器上都執行了一樣的 SQL 語句。在複製狀態正常的狀況下，主服務器和從服務器的數據是徹底同樣的。雖然 Mysql 的同步機制會有一些特殊的狀況，但大多數狀況都有解決方案，所以無須擔憂。至於更多的詳細信息和更權威的信息，請參考官方手冊的說明。

     

本文出自 「Not Only Linux」 博客，請務必保留此出處http://nolinux.blog.51cto.com/4824967/1528519