MySQL主從同步

一、Replication 線程

Mysql的 Replication 是一個異步的複製過程（mysql5.1.7以上版本分爲異步複製和半同步兩種模式），從一個 Mysql instace(咱們稱之爲 Master)複製到另外一個 Mysql instance(咱們稱之 Slave)。在 Master 與 Slave 之間的實現整個複製過程主要由三個線程來完成，其中兩個線程(Sql線程和IO線程)在 Slave 端，另一個線程(IO線程)在 Master 端。

要實現 MySQL 的 Replication ，首先必須打開 Master 端的Binary Log(mysql-bin.xxxxxx)功能，不然沒法實現。由於整個複製過程實際上就是Slave從Master端獲取該日誌而後再在本身身上徹底 順序的執行日誌中所記錄的各類操做。打開 MySQL 的 Binary Log 能夠經過在啓動 MySQL Server 的過程當中使用 「—log-bin」 參數選項，或者在 my.cnf 配置文件中的 mysqld 參數組([mysqld]標識後的參數部分)增長 「log-bin」 參數項。

二、MySQL 複製的基本過程以下：

2.1．Slave 上面的IO線程鏈接上 Master，並請求從指定日誌文件的指定位置(或者從最開始的日誌)以後的日誌內容；

2.2. Master 接收到來自 Slave 的 IO 線程的請求後，經過負責複製的 IO 線程根據請求信息讀取指定日誌指定位置以後的日誌信息，返回給 Slave 端的 IO 線程。返回信息中除了日誌所包含的信息以外，還包括本次返回的信息在 Master 端的 Binary Log 文件的名稱以及在 Binary Log 中的位置；

2.3. Slave 的 IO 線程接收到信息後，將接收到的日誌內容依次寫入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端，並將讀取到的Master端的bin-log的文件名和位置記錄到master- info文件中，以便在下一次讀取的時候可以清楚的高速Master「我須要從某個bin-log的哪一個位置開始日後的日誌內容，請發給我」

2.4. Slave 的 SQL 線程檢測到 Relay Log 中新增長了內容後，會立刻解析該 Log 文件中的內容成爲在 Master 端真實執行時候的那些可執行的 Query 語句，並在自身執行這些 Query。這樣，實際上就是在 Master 端和 Slave 端執行了一樣的 Query，因此兩端的數據是徹底同樣的。

三、Mysql複製的幾種模式

3.1.從 MySQL 5.1.12 開始，能夠用如下三種模式來實現：

– 基於SQL語句的複製(statement-based replication, SBR)，

– 基於行的複製(row-based replication, RBR)，

– 混合模式複製(mixed-based replication, MBR)。

相應地，binlog的格式也有三種：STATEMENT，ROW，MIXED。 MBR 模式中，SBR 模式是默認的。

在運行時能夠動態改動 binlog的格式，除了如下幾種狀況：

1.存儲流程或者觸發器中間

2.啓用了NDB

3.當前會話試用 RBR 模式，而且已打開了臨時表

若是binlog採用了 MIXED 模式，那麼在如下幾種狀況下會自動將binlog的模式由 SBR 模式改爲 RBR 模式：

1.當DML語句更新一個NDB表時

2.當函數中包含 UUID() 時

3.2個及以上包含 AUTO_INCREMENT 字段的表被更新時

4.行任何 INSERT DELAYED 語句時

5.用 UDF 時

6.視圖中必需要求運用 RBR 時，例如創建視圖是運用了 UUID() 函數

3.2.設定主從複製模式：

log-bin=mysql-bin

#binlog_format="STATEMENT"

#binlog_format="ROW"

binlog_format="MIXED"

也能夠在運行時動態修改binlog的格式。例如

mysql> SET SESSION binlog_format = 'STATEMENT';

mysql> SET SESSION binlog_format = 'ROW';

mysql> SET SESSION binlog_format = 'MIXED';

mysql> SET GLOBAL binlog_format = 'STATEMENT';

mysql> SET GLOBAL binlog_format = 'ROW';

mysql> SET GLOBAL binlog_format = 'MIXED';

3.3.兩種模式各自的優缺點：

SBR 的優勢：

歷史悠久，技能成熟

binlog文件較小

binlog中包含了全部數據庫修改信息，能夠據此來審覈數據庫的安全等狀況

binlog能夠用於實時的還原，而不只僅用於複製

主從版本能夠不同，從服務器版本能夠比主服務器版本高

SBR 的缺點：

不是全部的UPDATE語句都能被複制，尤爲是包含不肯定操做的時候。

調用具備不肯定因素的 UDF 時複製也可能出疑問

運用如下函數的語句也不能被複制：

* LOAD_FILE()

* UUID()

* USER()

* FOUND_ROWS()

* SYSDATE() (除非啓動時啓用了 –sysdate-is-now 選項)

INSERT … SELECT 會產生比 RBR 更多的行級鎖

複製需要執行 全表掃描(WHERE 語句中沒有運用到索引)的 UPDATE 時，需要比 RBR 請求更多的行級鎖

對於有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 語句會阻塞其餘 INSERT 語句

對於一些複雜的語句，在從服務器上的耗資源狀況會更嚴重，而 RBR 模式下，只會對那個發生變化的記錄產生影響

存儲函數(不是存儲流程 )在被調用的同時也會執行一次 NOW() 函數，這個能夠說是壞事也多是好事

肯定了的 UDF 也需要在從服務器上執行

數據表必須幾乎和主服務器保持一致才行，不然可能會致使複製出錯

執行復雜語句若是出錯的話，會消耗更多資源

 

RBR 的優勢：

任何狀況均可以被複制，這對複製來講是最安全可靠的

和其餘大多數數據庫系統的複製技能同樣

多數狀況下，從服務器上的表若是有主鍵的話，複製就會快了不少

複製如下幾種語句時的行鎖更少：

* INSERT … SELECT

* 包含 AUTO_INCREMENT 字段的 INSERT

* 沒有附帶條件或者並無修改不少記錄的 UPDATE 或 DELETE 語句

執行 INSERT，UPDATE，DELETE 語句時鎖更少

從服務器上採用多線程來執行復製成爲可能

RBR 的缺點：

binlog 大了不少

複雜的回滾時 binlog 中會包含大量的數據

主服務器上執行 UPDATE 語句時，全部發生變化的記錄都會寫到 binlog 中，而 SBR 只會寫一次，這會致使頻繁發生 binlog 的併發寫疑問

UDF 產生的大 BLOB 值會致使複製變慢

不能從 binlog 中看到都複製了寫什麼語句(加密過的)

當在非事務表上執行一段堆積的SQL語句時，最好採用 SBR 模式，不然很容易致使主從服務器的數據不一致狀況發生

另外，針對系統庫 mysql 裏面的表發生變化時的處理準則以下：

若是是採用 INSERT，UPDATE，DELETE 直接操做表的狀況，則日誌格式根據 binlog_format 的設定而記錄

若是是採用 GRANT，REVOKE，SET PASSWORD 等管理語句來作的話，那麼不管如何 都採用 SBR 模式記錄。

注：採用 RBR 模式後，能處理不少原先出現的主鍵重複問題。實例:

對於insert into db_allot_ids select * from db_allot_ids 這個語句:

在BINLOG_FORMAT=STATEMENT 模式下:

BINLOG日誌信息爲:

—————————————–

BEGIN

/*!*/;

# at 173

#090612 16:05:42 server id 1 end_log_pos 288 Query thread_id=4 exec_time=0 error_code=0

SET TIMESTAMP=1244793942/*!*/;

insert into db_allot_ids select * from db_allot_ids

/*!*/;

—————————————–

在BINLOG_FORMAT=ROW 模式下:

BINLOG日誌信息爲:

—————————————–

BINLOG '

hA0yShMBAAAAMwAAAOAAAAAAAA8AAAAAAAAAA1NOUwAMZGJfYWxsb3RfaWRzAAIBAwAA

hA0yShcBAAAANQAAABUBAAAQAA8AAAAAAAEAAv/8AQEAAAD8AQEAAAD8AQEAAAD8AQEAAAA=

'/*!*/;

—————————————–

四、Mysql主從的優缺點

MySQL的主從同步是一個很成熟的架構，優勢爲：①在從服務器能夠執行查詢工做(即咱們常說的讀功能)，下降主服 務器壓力;②在從主服務器進行備份，避免備份期間影響主服務器服務;③當主服務器出現問題時，能夠切換到從服務器。因此我在項目部署和實施中常常會採用這種方案;鑑於生產環境下的mysql的嚴謹性。

實際上，在老版本中，MySQL 的複製實如今 Slave 端並非由 SQL 線程和 IO 線程這兩個線程共同協做而完成的，而是由單獨的一個線程來完成全部的工做。可是 MySQL 的工程師們很快發現，這樣作存在很大的風險和性能問題，主要以下：

首先，若是經過一個單一的線程來獨立實現這個工做的話，就使複製 Master 端的，Binary Log日誌，以及解析這些日誌，而後再在自身執行的這個過程成爲一個串行的過程，性能天然會受到較大的限制，這種架構下的 Replication 的延遲天然就比較長了。

其次，Slave 端的這個複製線程從 Master 端獲取 Binary Log 過來以後，須要接着解析這些內容，還原成 Master 端所執行的原始 Query，而後在自身執行。在這個過程當中，Master端極可能又已經產生了大量的變化並生成了大量的 Binary Log 信息。若是在這個階段 Master 端的存儲系統出現了沒法修復的故障，那麼在這個階段所產生的全部變動都將永遠的丟失，沒法再找回來。這種潛在風險在Slave 端壓力比較大的時候尤爲突出，由於若是 Slave 壓力比較大，解析日誌以及應用這些日誌所花費的時間天然就會更長一些，可能丟失的數據也就會更多。

因此，在後期的改造中，新版本的 MySQL 爲了儘可能減少這個風險，並提升複製的性能，將 Slave 端的複製改成兩個線程來完成，也就是前面所提到的 SQL 線程和 IO 線程。最先提出這個改進方案的是Yahoo!的一位工程師「Jeremy Zawodny」。經過這樣的改造，這樣既在很大程度上解決了性能問題，縮短了異步的延時時間，同時也減小了潛在的數據丟失量。

固然，即便是換成了如今這樣兩個線程來協做處理以後，一樣也仍是存在 Slave 數據延時以及數據丟失的可能性的，畢竟這個複製是異步的。只要數據的更改不是在一個事務中，這些問題都是存在的。

若是要徹底避免這些問題，就只能用 MySQL 的 Cluster 來解決了。不過 MySQL的 Cluster 知道筆者寫這部份內容的時候，仍然仍是一個內存數據庫的解決方案，也就是須要將全部數據包括索引所有都 Load 到內存中，這樣就對內存的要求就很是大的大，對於通常的大衆化應用來講可實施性並非太大。MySQL 如今正在不斷改進其 Cluster 的實現，其中很是大的一個改動就是容許數據不用所有 Load 到內存中，而僅僅只是索引所有 Load 到內存中，我想信在完成該項改造以後的 MySQL Cluster 將會更加受人歡迎，可實施性也會更大。

五、Mysql的半同步模式（Semisynchronous Replication）

咱們知道在5.5以前，MySQL的複製實際上是異步操做，而不是同步，也就意味着容許主從之間的數據存在必定的延遲，mysql當初這樣設計的目的可能也是基於可用性的考慮，爲了保證master不受slave的影響，而且異步複製使得master處於一種性能最優的狀態：寫完binlog後便可提交而不須要等待slave的操做完成。這樣存在一個隱患，當你使用slave做爲備份時，若是master掛掉，那麼會存在部分已提交的事務未能成功傳輸到slave的可能，這就意味着數據丟失！

在MySQL5.5版本中，引入了半同步複製模式（Semi-synchronous Replication）可以成功（只是相對的）避免上述數據丟失的隱患。在這種模式下：master會等到binlog成功傳送並寫入至少一個slave的relay log以後纔會提交，不然一直等待，直到timeout（默認10s）。當出現timeout的時候，master會自動切換半同步爲異步，直到至少有一個slave成功收到併發送Acknowledge，master會再切換回半同步模式。結合這個新功能，咱們能夠作到，在容許損失必定的事務吞吐量的前提下來保證同步數據的絕對安全，由於當你設置timeout爲一個足夠大的值的狀況下，任何提交的數據都會安全抵達slave。

mysql5.5 版本支持半同步複製功能（Semisynchronous Replication），但還不是原生的支持，是經過plugin來支持的，而且默認是沒有安裝這個插件的。不管是二進制發佈的，仍是本身源代碼編譯的，都會默認生成這個插件，一個是針對master 的一個是針對slave的，在使用以前須要先安裝這倆plugins。

2、Mysql主從複製的過濾

複製的過濾主要有２種方式：

1、在主服務器在把事件從進二制日誌中過濾掉，相關的參數是:binlog_do_db和binlog_ignore_db。

2、在從服務器上把事件從中繼日誌中過濾掉，相關的參數是replicate_*。

複製只能擴展讀取，不能擴展寫入，對數據進行分區能夠進行擴展寫入。

複製的優化：

在mysql複製環境中,有8個參數可讓咱們控制,須要複製或須要忽略不進行復制的DB或table分別爲:

下面二項須要在Master上設置：

Binlog_Do_DB:設定哪些數據庫須要記錄Binlog

Binlog_Ignore_DB:設定哪裏數據庫不須要記錄Binlog

優勢是Master端的Binlog記錄所帶來的Io量減小，網絡IO減小，還會讓slave端的IO線程,SQL線程減小，從而大幅提升複製性能,

缺點是mysql判斷是否須要複製某個事件不是根據產生該事件的查詢所在的DB,而是根據執行查詢時刻所在的默認數據庫（也就是登陸時指定的庫名或運行"use database"中指定的DB）,只有當前默認DB和配置中所設定的DB徹底吻合時IO線程纔會將該事件讀取給slave的IO線程.因此,若是在默認DB和設定需要複製的DB不同的狀況下改變了需要複製的DB中某個Table中的數據,該事件是不會被複制到Slave中去的,這樣就會形成Slave端的數據和Master的數據不一致.一樣,在默認的數據庫下更改了不需要複製的數據庫中的數據,則會被複制到slave端,當slave端並無該數據庫時,則會形成複製出錯而中止。

下面六項須要在slave上設置：

Replicate_Do_DB:設定須要複製的數據庫,多個DB用逗號分隔

Replicate_Ignore_DB:設定能夠忽略的數據庫.

Replicate_Do_Table:設定須要複製的Table

Replicate_Ignore_Table:設定能夠忽略的Table

Replicate_Wild_Do_Table:功能同Replicate_Do_Table,但能夠帶通配符來進行設置。

Replicate_Wild_Ignore_Table:功能同Replicate_Do_Table,功能同Replicate_Ignore_Table,能夠帶通配符。

優勢是在slave端設置複製過濾機制,能夠保證不會出現由於默認的數據庫問題而形成Slave和Master數據不一致或複製出錯的問題.

缺點是性能方面比在Master端差一些.緣由在於:無論是否需要複製,事件都會被IO線程讀取到Slave端,這樣不只增長了網絡IO量,也給Slave端的IO線程增長了Relay Log的寫入量。

注：在實際的生產應用中發現，在mysql5.0之前的版本，mysql的這個過濾設置幾乎是形同虛設，不起做用：無論你在主庫或是從庫上設置了忽略某個數據庫或是表，他依然會進行同步，因此在作5.0之前版本的主從同步時，必定保持主從數據庫的一致性，主上有的庫或是表從上必定要有，不然在同步的過程會出錯。

3、Mysql主從同步的配置

主庫IP：192.168.1.2

從庫IP：192.168.1.3

添加一個用於主從同步的用戶：

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY ‘1q2w3e4r’;

若是監控mysql主從的話，請加上一個super權限：

GRANT SUPER, REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY '1q2w3e4r';

一、主庫的配置

1.1．mysql5.0如下版本的配置

 修改主庫mysql配置配置文件，在[mysqld]段添加如下內容：

server-id = 1

log-bin=/home/mysql/logs/binlog/bin-log

max_binlog_size = 500M

binlog_cache_size = 128K

binlog-do-db = adb

binlog-ignore-db = mysql

log-slave-updates

1.2. mysql5.0以上版本的配置

 修改主庫mysql配置配置文件，在[mysqld]段添加如下內容：

server-id = 1

log-bin=/home/mysql/logs/binlog/bin-log

max_binlog_size = 500M

binlog_cache_size = 128K

binlog-do-db = adb

binlog-ignore-db = mysql

log-slave-updates

expire_logs_day=2

binlog_format="MIXED"

1.3.各個參數的含義和相關注意項：

server-id = 1 #服務器標誌號，注意在配置文件中不能出現多個這樣的標識，若是出現多個的話mysql以第一個爲準，一組主從中此標識號不能重複。

log-bin=/home/mysql/logs/binlog/bin-log #開啓bin-log，並指定文件目錄和文件名前綴。

max_binlog_size = 500M #每一個bin-log最大大小，當此大小等於500M時會自動生成一個新的日誌文件。一條記錄不會寫在2個日誌文件中，因此有時日誌文件會超過此大小。

binlog_cache_size = 128K #日誌緩存大小

binlog-do-db = adb #須要同步的數據庫名字，若是是多個，就以此格式在寫一行便可。

binlog-ignore-db = mysql  #不須要同步的數據庫名字，若是是多個，就以此格式在寫一行便可。

log-slave-updates  #當Slave從Master數據庫讀取日誌時更新新寫入日誌中，若是隻啓動log-bin 而沒有啓動log-slave-updates則Slave只記錄針對本身數據庫操做的更新。

expire_logs_day=2 #設置bin-log日誌文件保存的天數，此參數mysql5.0如下版本不支持。

binlog_format="MIXED"   #設置bin-log日誌文件格式爲：MIXED，能夠防止主鍵重複。

二、從庫的配置

2.1.mysql5.1.7之前版本

修改從庫mysql配置配置文件，在[mysqld]段添加如下內容：

server-id=2

master-host=192.168.1.2

master-user=repl

master-password=1q2w3e4r

master-port=3306

master-connect-retry=30

slave-skip-errors=1062

replicate-do-db = adb

replicate-ignore-db = mysql

slave-skip-errors=1007,1008,1053,1062,1213,1158,1159

master-info-file = /home/mysql/logs/master.info

relay-log = /home/mysql/logs/relay-bin

relay-log-index = /home/mysql/logs/relay-bin.index

relay-log-info-file = /home/mysql/logs/relay-log.info

若是修改了鏈接主庫相關信息，重啓以前必定要刪除master.info文件，不然重啓以後因爲鏈接信息改變從庫而不會自動鏈接主庫，形成同步失敗。此文件是保存鏈接主庫信息的。

2.2.mysql5.1.7之後版本

Mysql5.1.7版本在叢庫上面的配置不多，主要是採用了新的同步信息記錄方式，他不在支持在配置文件中配置鏈接主庫的相關信息，而是把鏈接等相關信息記錄在master-info-file = /home/mysql/logs/master.info文件中，若是入庫變了，直接在mysql命令行執行鏈接信息的改變便可生效，比較靈活了，而不用去重啓mysql。修改從庫mysql配置配置文件，在[mysqld]段添加如下內容：

slave-skip-errors=1007,1008,1053,1062,1213,1158,1159

2.3. 各個參數的含義和相關注意項

這裏只講一下2個參數，其餘所有是從庫鏈接主庫的信息和中間日誌relay-log的設置。

master-connect-retry=30 #這個選項控制重試間隔，默認爲60秒。

slave-skip-errors=1007,1008,1053,1062,1213,1158,1159 #這個是在同步過程當中忽略掉的錯誤，這些錯誤不會影響數據的完整性，有事常常出現的錯誤，通常設置忽略。其中1062爲主鍵重複錯誤。

三、實現主從同步

3.1.實現數據庫的統一

檢查主從數據庫的配置文件，查看是否已正確配置。首次實現 同步要備份主庫上須要同步的數據庫，而後完整的導入到從庫中。注：mysql5.0以前的版本涉及到mysql自己複製過濾存在問題，須要把全部的數據庫都備份導入到叢庫，保持。

3.2.查看並記錄主庫bin-log信息

進入主庫mysql中，執行：show master status;顯示信息以下：

mysql> show master status;

+-------------+----------+--------------+------------------+

| File        | Position | Binlog_do_db | Binlog_ignore_db |

+-------------+----------+--------------+------------------+

| bin-log.003 | 4        | adb          | mysql            |

+-------------+----------+--------------+------------------+

1 row in set (0.00 sec)

記錄File 和Position信息；

3.3.在從庫上執行同步語句

進入mysql，執行如下語句：

slave stop;

change master to

master_host='192.168.1.2',

master_user='repl',

master_password='1q2w3e4r',

master_port=3306,

master_log_file='bin-log.003',

master_log_pos=4;

slave start;

3.4.查看主從同步狀態

    進入mysql，執行show slave status\G;顯示以下（mysql版本不一樣查詢的結果不一樣，可是重要的指標仍是同樣的）：

Mysql5.0以前的版本以下：

 

Mysql5.5以前的版本以下：

 

Mysql5.5的版本以下：

 

重要的指標爲：

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Master_Log_File: bin-log.003

Relay_Master_Log_File: bin-log.003

Read_Master_Log_Pos: 4

Exec_master_log_pos: 4

Seconds_Behind_Master: 0（5.0以前版本沒有這個選項）

以上選項是兩兩對應的，只要結果是一致的，就說明主從同步成功。

3.5.同步中的常見的錯誤和處理

1、現象：在從庫上面show slave status\G;出現下列狀況，

          Slave_IO_Running: Yes

          Slave_SQL_Running: No

          Seconds_Behind_Master: NULL

緣由：

a.程序可能在slave上進行了寫操做；

b.也多是slave機器重起後，事務回滾形成的；

c．有多是在同步過程當中遇到某種錯誤，這個會在查看從庫中狀態時看到錯誤提示，最少見的就是主鍵重複1062的錯誤。

解決方法：

進入master

mysql> show master status;

+----------------------+----------+--------------+------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+----------------------+----------+--------------+------------------+

| mysql-bin.000040 | 324 |adb | mysql|

+----------------------+----------+--------------+------------------+

而後到slave服務器上執行手動同步

slave stop;

change master to

master_host='10.14.0.140',

master_user='repl',

master_password='1q2w3e4r',

master_port=3306,

master_log_file='mysql-bin.000040',

master_log_pos=324;

slave start;

show slave status\G;

2、現象：從數據庫沒法同步，show slave status顯示:

          Slave_IO_Running: No

          Slave_SQL_Running: Yes

          Seconds_Behind_Master: NULL

   解決：首先查看數據庫的err日誌，查看是什麼錯誤提示，看從庫鏈接主庫的IP、用戶、密碼等相關信息是否有誤，若是有誤，從新執行同步；若是確認無誤，重啓主數據庫。

mysql> show master status;

+------------------+----------+--------------+------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+------------------+----------+--------------+------------------+

| mysql-bin.000001 | 98 | adb| mysql|

+------------------+----------+--------------+------------------+

進入從庫mysql，執行：

slave stop;

change master to Master_Log_File='mysql-bin.000001',Master_Log_Pos=98;

slave start;

或是這樣：

stop slave;

set global sql_slave_skip_counter =1;

start slave;

這個現象主要是master數據庫存在問題，因爲鏈接主庫信息錯誤、主庫數據庫掛掉若是說常見錯等緣由引發的，我在實際的操做中先重啓master後重啓slave便可解決這問題，出現此問題，必需要要重啓master數據庫。

4、mysql主主和主主集羣

一、mysql主主的實現

    在實際的生產應用中，爲了在主庫出現崩潰或是主服務器出現嚴重故障時快速的恢復業務，會直接切換到從庫上，當主庫故障處理完成後讓他直接做爲叢庫來運行，此時主主就是一個不錯的選擇。

  

5、mysql主從的監控

在mysql主從的應用中，只要進行了合理設置，基本上不會出現問題，可是對他的監控是必不可少的，以避免因爲真的出現問題又不知道而形成沒必要要的數據損失。

一、mysql主從監控的主要思路

Mysql主從的監控，其主要是監控從庫上的一些重要參數：

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Master_Log_File: bin-log.003

Relay_Master_Log_File: bin-log.003

Read_Master_Log_Pos: 4

Exec_master_log_pos: 4

Seconds_Behind_Master: 0（5.0以前版本沒有這個選項）

經過以上的參數能夠反映出主庫和從庫狀態是否正常，從庫是否落後於主庫等。值得一提的是在mysql5.0之前的版本，Slave_IO_Running這個狀態指標不可靠，會在主庫直接掛掉的狀況下不會變成NO，Seconds_Behind_Master參數也不存在。監控以上參數便可監控mysql主從。

二、mysql主從監控的實現

無論mysql是那個版本，其中的從庫上的Exec_master_log_pos、Exec_master_log_pos；主庫上的 Master上的Log_File， Position，這四個參數能夠判斷出當前主從的狀態。如下是適用於mysql全部版本的主從監控shell腳本：

#/bin/sh

user=repl

passwd=123415

master_ip="192.168.1.2"

log="/data3/check_repl.log"

value()

{

 master=`/usr/local/mysql/bin/mysql -u$user -p$passwd -h$master_ip -e "show master status\G;"|egrep "File|Position"`

 #mysql 4.0

 slave=`/usr/local/mysql/bin/mysql -u$user -p$passwd -h127.0.0.1 -e "show slave status\G;"|egrep "Relay_Master_Log_File|Exec_master_log_pos"`

 #mysql 5.0

 #slave=`mysql -u$user -p$passwd -e "show slave status\G;"|egrep "Relay_Master_Log_File|Exec_Master_Log_Pos"`

 #取主庫上的bin-log號及寫入的當前日誌位置   

 Master_Log=`echo $master |awk '{print $2}'|awk -F "." '{print $2}'`

 Master_Log_Pos=`echo $master |awk '{print $4}'`

 #取從庫上當前同步主庫的位置

 Relay_Master_Log_File=`echo $slave |awk '{print $2}'|awk -F "." '{print $2}'`

 Exec_Master_Log_Pos=`echo $slave |awk '{print $4}'`

 echo "Master_Log:"$Master_Log>>$log

 echo "Master_Log_Pos:"$Master_Log_Pos>>$log

 echo "Relay_Master_Log_File:"$Relay_Master_Log_File>>$log

 echo "Exec_Master_Log_Pos:"$Exec_Master_Log_Pos>>$log

}

for((i=1;i<=10;i++));

do

 echo "#################################">>$log

 value

 time=`date +"%Y-%m-%d %H:%M:%S"`

 if [ $Master_Log -eq $Relay_Master_Log_File ];then

       A=`expr $Master_Log_Pos - $Exec_Master_Log_Pos`

       if [ $A -lt 0 ];then

             A=`expr 0 - $A`

       fi

       echo $A>>$log

       if [ $A -lt 10000 ];then

             echo "$time Master-Slave is OK.">>$log

             #echo "$i"

             break

       else

             if [ $i ge 3 ];then              

                  echo "$time Warning:Slave-Master lag $A " >>$log

                  echo "$i"

             fi

             sleep 30

             continue

       fi

 else

       sleep 60

       fi

       if [ $i -eq 10 ];then

             echo "$i"

             echo "$time Error:Slave-Master must be check !" >>$log

       fi

done

在mysql5.0之後的版本，mysql主從已經至關的成熟了，能夠只監控Slave_IO_Running，Slave_SQL_Running，Seconds_Behind_Master狀態就能夠了，這裏再也不作說明。

本文出自 「王偉」 博客，請務必保留此出處http://wangwei007.blog.51cto.com/68019/965575

45195470六、vbbb62五、aha45

8人

了這篇文章