Mysql數據庫主從心得整理
管理mysql主從有2年多了，管理過200多組mysql主從，幾乎涉及到各個版本的主從，本博文屬于總結性的，有一部分是摘自網絡，大部分是根據自己管理的心得和經驗所寫，整理了一下，分享給各位同行，希望對大家有幫助，互相交流。
Mysql的 Replication 是一個異步的復制過程（mysql5.1.7以上版本分為異步復制和半同步兩種模式），從一個 Mysql instace(我們稱之為 Master)復制到另一個 Mysql instance(我們稱之 Slave)。在 Master 與 Slave 之間的實現(xiàn)整個復制過程主要由三個線程來完成，其中兩個線程(Sql線程和IO線程)在 Slave 端，另外一個線程(IO線程)在 Master 端。
要實現(xiàn) MySQL 的 Replication ，首先必須打開 Master 端的Binary Log(mysql-bin.xxxxxx)功能，否則無法實現(xiàn)。因為整個復制過程實際上就是Slave從Master端獲取該日志然后再在自己身上完全 順序的執(zhí)行日志中所記錄的各種操作。打開 MySQL 的 Binary Log 可以通過在啟動 MySQL Server 的過程中使用 “—log-bin” 參數選項，或者在 my.cnf 配置文件中的 mysqld 參數組([mysqld]標識后的參數部分)增加 “l(fā)og-bin” 參數項。
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的哪個位置開始往后的日志內容，請發(fā)給我”
2.4. Slave 的 SQL 線程檢測到 Relay Log 中新增加了內容后，會馬上解析該 Log 文件中的內容成為在 Master 端真實執(zhí)行時候的那些可執(zhí)行的 Query 語句，并在自身執(zhí)行這些 Query。這樣，實際上就是在 Master 端和 Slave 端執(zhí)行了同樣的 Query，所以兩端的數據是完全一樣的。
3.1.從 MySQL 5.1.12 開始，可以用以下三種模式來實現(xiàn)：
– 基于SQL語句的復制(statement-based replication, SBR)，
– 基于行的復制(row-based replication, RBR)，
– 混合模式復制(mixed-based replication, MBR)。
相應地，binlog的格式也有三種：STATEMENT，ROW，MIXED。 MBR 模式中，SBR 模式是默認的。
在運行時可以動態(tài)改動 binlog的格式，除了以下幾種情況：
1.存儲流程或者觸發(fā)器中間
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"
也可以在運行時動態(tài)修改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.兩種模式各自的優(yōu)缺點：
SBR 的優(yōu)點：
歷史悠久，技能成熟
binlog文件較小
binlog中包含了所有數據庫修改信息，可以據此來審核數據庫的安全等情況
binlog可以用于實時的還原，而不僅僅用于復制
主從版本可以不一樣，從服務器版本可以比主服務器版本高
SBR 的缺點：
不是所有的UPDATE語句都能被復制，尤其是包含不確定操作的時候。
調用具有不確定因素的 UDF 時復制也可能出疑問
運用以下函數的語句也不能被復制：
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非啟動時啟用了 –sysdate-is-now 選項)
INSERT … SELECT 會產生比 RBR 更多的行級鎖
復制須要執(zhí)行 全表掃描(WHERE 語句中沒有運用到索引)的 UPDATE 時，須要比 RBR 請求更多的行級鎖
對于有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 語句會阻塞其他 INSERT 語句
對于一些復雜的語句，在從服務器上的耗資源情況會更嚴重，而 RBR 模式下，只會對那個發(fā)生變化的記錄產生影響
存儲函數(不是存儲流程 )在被調用的同時也會執(zhí)行一次 NOW() 函數，這個可以說是壞事也可能是好事
確定了的 UDF 也須要在從服務器上執(zhí)行
數據表必須幾乎和主服務器保持一致才行，否則可能會導致復制出錯
執(zhí)行復雜語句如果出錯的話，會消耗更多資源
RBR 的優(yōu)點：
任何情況都可以被復制，這對復制來說是最安全可靠的
和其他大多數數據庫系統(tǒng)的復制技能一樣
多數情況下，從服務器上的表如果有主鍵的話，復制就會快了很多
復制以下幾種語句時的行鎖更少：
* INSERT … SELECT
* 包含 AUTO_INCREMENT 字段的 INSERT
* 沒有附帶條件或者并沒有修改很多記錄的 UPDATE 或 DELETE 語句
執(zhí)行 INSERT，UPDATE，DELETE 語句時鎖更少
從服務器上采用多線程來執(zhí)行復制成為可能
RBR 的缺點：
binlog 大了很多
復雜的回滾時 binlog 中會包含大量的數據
主服務器上執(zhí)行 UPDATE 語句時，所有發(fā)生變化的記錄都會寫到 binlog 中，而 SBR 只會寫一次，這會導致頻繁發(fā)生 binlog 的并發(fā)寫疑問
UDF 產生的大 BLOB 值會導致復制變慢
不能從 binlog 中看到都復制了寫什么語句(加密過的)
當在非事務表上執(zhí)行一段堆積的SQL語句時，最好采用 SBR 模式，否則很容易導致主從服務器的數據不一致情況發(fā)生
另外，針對系統(tǒng)庫 mysql 里面的表發(fā)生變化時的處理準則如下：
如果是采用 INSERT，UPDATE，DELETE 直接操作表的情況，則日志格式根據 binlog_format 的設定而記錄
如果是采用 GRANT，REVOKE，SET PASSWORD 等管理語句來做的話，那么無論如何 都采用 SBR 模式記錄。
注：采用 RBR 模式后，能處理很多原先出現(xiàn)的主鍵重復問題。實例:
對于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的主從同步是一個很成熟的架構，優(yōu)點為：①在從服務器可以執(zhí)行查詢工作(即我們常說的讀功能)，降低主服 務器壓力;②在從主服務器進行備份，避免備份期間影響主服務器服務;③當主服務器出現(xiàn)問題時，可以切換到從服務器。所以我在項目部署和實施中經常會采用這種方案;鑒于生產環(huán)境下的mysql的嚴謹性。
實際上，在老版本中，MySQL 的復制實現(xiàn)在 Slave 端并不是由 SQL 線程和 IO 線程這兩個線程共同協(xié)作而完成的，而是由單獨的一個線程來完成所有的工作。但是 MySQL 的工程師們很快發(fā)現(xiàn)，這樣做存在很大的風險和性能問題，主要如下：
首先，如果通過一個單一的線程來獨立實現(xiàn)這個工作的話，就使復制 Master 端的，Binary Log日志，以及解析這些日志，然后再在自身執(zhí)行的這個過程成為一個串行的過程，性能自然會受到較大的限制，這種架構下的 Replication 的延遲自然就比較長了。
其次，Slave 端的這個復制線程從 Master 端獲取 Binary Log 過來之后，需要接著解析這些內容，還原成 Master 端所執(zhí)行的原始 Query，然后在自身執(zhí)行。在這個過程中，Master端很可能又已經產生了大量的變化并生成了大量的 Binary Log 信息。如果在這個階段 Master 端的存儲系統(tǒng)出現(xiàn)了無法修復的故障，那么在這個階段所產生的所有變更都將永遠的丟失，無法再找回來。這種潛在風險在Slave 端壓力比較大的時候尤其突出，因為如果 Slave 壓力比較大，解析日志以及應用這些日志所花費的時間自然就會更長一些，可能丟失的數據也就會更多。
所以，在后期的改造中，新版本的 MySQL 為了盡量減小這個風險，并提高復制的性能，將 Slave 端的復制改為兩個線程來完成，也就是前面所提到的 SQL 線程和 IO 線程。最早提出這個改進方案的是Yahoo!的一位工程師“Jeremy Zawodny”。通過這樣的改造，這樣既在很大程度上解決了性能問題，縮短了異步的延時時間，同時也減少了潛在的數據丟失量。
當然，即使是換成了現(xiàn)在這樣兩個線程來協(xié)作處理之后，同樣也還是存在 Slave 數據延時以及數據丟失的可能性的，畢竟這個復制是異步的。只要數據的更改不是在一個事務中，這些問題都是存在的。
如果要完全避免這些問題，就只能用 MySQL 的 Cluster 來解決了。不過 MySQL的 Cluster 知道筆者寫這部分內容的時候，仍然還是一個內存數據庫的解決方案，也就是需要將所有數據包括索引全部都 Load 到內存中，這樣就對內存的要求就非常大的大，對于一般的大眾化應用來說可實施性并不是太大。MySQL 現(xiàn)在正在不斷改進其 Cluster 的實現(xiàn)，其中非常大的一個改動就是允許數據不用全部 Load 到內存中，而僅僅只是索引全部 Load 到內存中，我想信在完成該項改造之后的 MySQL Cluster 將會更加受人歡迎，可實施性也會更大。
5、Mysql的半同步模式（Semisynchronous Replication） 我們知道在5.5之前，MySQL的復制其實是異步操作，而不是同步，也就意味著允許主從之間的數據存在一定的延遲，mysql當初這樣設計的目的可能也是基于可用性的考慮，為了保證master不受slave的影響，并且異步復制使得master處于一種性能最優(yōu)的狀態(tài)：寫完binlog后即可提交而不需要等待slave的操作完成。這樣存在一個隱患，當你使用slave作為備份時，如果master掛掉，那么會存在部分已提交的事務未能成功傳輸到slave的可能，這就意味著數據丟失！
在MySQL5.5版本中，引入了半同步復制模式（Semi-synchronous Replication）能夠成功（只是相對的）避免上述數據丟失的隱患。在這種模式下：master會等到binlog成功傳送并寫入至少一個slave的relay log之后才會提交，否則一直等待，直到timeout（默認10s）。當出現(xiàn)timeout的時候，master會自動切換半同步為異步，直到至少有一個slave成功收到并發(fā)送Acknowledge，master會再切換回半同步模式。結合這個新功能，我們可以做到，在允許損失一定的事務吞吐量的前提下來保證同步數據的絕對安全，因為當你設置timeout為一個足夠大的值的情況下，任何提交的數據都會安全抵達slave。
mysql5.5 版本支持半同步復制功能（Semisynchronous Replication），但還不是原生的支持，是通過plugin來支持的，并且默認是沒有安裝這個插件的。不論是二進制發(fā)布的，還是自己源代碼編譯的，都會默認生成這個插件，一個是針對master 的一個是針對slave的，在使用之前需要先安裝這倆plugins。
復制的過濾主要有２種方式：
1、在主服務器在把事件從進二制日志中過濾掉，相關的參數是:binlog_do_db和binlog_ignore_db。
2、在從服務器上把事件從中繼日志中過濾掉，相關的參數是replicate_*。
復制只能擴展讀取，不能擴展寫入，對數據進行分區(qū)可以進行擴展寫入。
復制的優(yōu)化：
在mysql復制環(huán)境中,有8個參數可以讓我們控制,需要復制或需要忽略不進行復制的DB或table分別為:
下面二項需要在Master上設置：
Binlog_Do_DB:設定哪些數據庫需要記錄Binlog
Binlog_Ignore_DB:設定哪里數據庫不需要記錄Binlog
優(yōu)點是Master端的Binlog記錄所帶來的Io量減少，網絡IO減少，還會讓slave端的IO線程,SQL線程減少，從而大幅提高復制性能,
缺點是mysql判斷是否需要復制某個事件不是根據產生該事件的查詢所在的DB,而是根據執(zhí)行查詢時刻所在的默認數據庫（也就是登錄時指定的庫名或運行"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,可以帶通配符。
優(yōu)點是在slave端設置復制過濾機制,可以保證不會出現(xiàn)因為默認的數據庫問題而造成Slave和Master數據不一致或復制出錯的問題.
缺點是性能方面比在Master端差一些.原因在于:不管是否須要復制,事件都會被IO線程讀取到Slave端,這樣不僅增加了網絡IO量,也給Slave端的IO線程增加了Relay Log的寫入量。
注：在實際的生產應用中發(fā)現(xiàn)，在mysql5.0以前的版本，mysql的這個過濾設置幾乎是形同虛設，不起作用：不管你在主庫或是從庫上設置了忽略某個數據庫或是表，他依然會進行同步，所以在做5.0以前版本的主從同步時，一定保持主從數據庫的一致性，主上有的庫或是表從上一定要有，否則在同步的過程會出錯。
主庫IP：192.168.1.2
從庫IP：192.168.1.3
添加一個用于主從同步的用戶：
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY ‘1q2w3e4r’;
如果監(jiān)控mysql主從的話，請加上一個super權限：
GRANT SUPER, REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY '1q2w3e4r';
修改主庫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
修改主庫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"
server-id = 1 #服務器標志號，注意在配置文件中不能出現(xiàn)多個這樣的標識，如果出現(xiàn)多個的話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，可以防止主鍵重復。
修改從庫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文件，否則重啟之后由于連接信息改變從庫而不會自動連接主庫，造成同步失敗。此文件是保存連接主庫信息的。
Mysql5.1.7版本在叢庫上面的配置很少，主要是采用了新的同步信息記錄方式，他不在支持在配置文件中配置連接主庫的相關信息，而是把連接等相關信息記錄在master-info-file = /home/mysql/logs/master.info文件中，如果入庫變了，直接在mysql命令行執(zhí)行連接信息的改變即可生效，比較靈活了，而不用去重啟mysql。修改從庫mysql配置配置文件，在[mysqld]段添加以下內容：
slave-skip-errors=1007,1008,1053,1062,1213,1158,1159
這里只講一下2個參數，其他全部是從庫連接主庫的信息和中間日志relay-log的設置。
master-connect-retry=30 #這個選項控制重試間隔，默認為60秒。
slave-skip-errors=1007,1008,1053,1062,1213,1158,1159 #這個是在同步過程中忽略掉的錯誤，這些錯誤不會影響數據的完整性，有事經常出現(xiàn)的錯誤，一般設置忽略。其中1062為主鍵重復錯誤。
檢查主從數據庫的配置文件，查看是否已正確配置。首次實現(xiàn) 同步要備份主庫上需要同步的數據庫，然后完整的導入到從庫中。注：mysql5.0之前的版本涉及到mysql本身復制過濾存在問題，需要把所有的數據庫都備份導入到叢庫，保持。
進入主庫mysql中，執(zhí)行：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信息；
進入mysql，執(zhí)行以下語句：
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;
進入mysql，執(zhí)行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之前版本沒有這個選項）
以上選項是兩兩對應的，只要結果是一致的，就說明主從同步成功。
1、現(xiàn)象：在從庫上面show slave status\G;出現(xiàn)下列情況，
Slave_IO_Running: Yes
Slave_SQL_Running: No
Seconds_Behind_Master: NULL
原因：
a.程序可能在slave上進行了寫操作；
b.也可能是slave機器重起后，事務回滾造成的；
c．有可能是在同步過程中遇到某種錯誤，這個會在查看從庫中狀態(tài)時看到錯誤提示，最少見的就是主鍵重復1062的錯誤。
解決方法：
進入master
mysql> show master status;
+----------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+----------------------+----------+--------------+------------------+
| mysql-bin.000040 | 324 |adb | mysql|
+----------------------+----------+--------------+------------------+
然后到slave服務器上執(zhí)行手動同步
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、現(xiàn)象：從數據庫無法同步，show slave status顯示:
Slave_IO_Running: No
Slave_SQL_Running: Yes
Seconds_Behind_Master: NULL
解決：首先查看數據庫的err日志，查看是什么錯誤提示，看從庫連接主庫的IP、用戶、密碼等相關信息是否有誤，如果有誤，重新執(zhí)行同步；如果確認無誤，重啟主數據庫。
mysql> show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 | 98 | adb| mysql|
+------------------+----------+--------------+------------------+
進入從庫mysql，執(zhí)行：
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;
這個現(xiàn)象主要是master數據庫存在問題，由于連接主庫信息錯誤、主庫數據庫掛掉如果說常見錯等原因引起的，我在實際的操作中先重啟master后重啟slave即可解決這問題，出現(xiàn)此問題，必須要要重啟master數據庫。
四、mysql主主和主主集群
1、mysql主主的實現(xiàn)
在實際的生產應用中，為了在主庫出現(xiàn)崩潰或是主服務器出現(xiàn)嚴重故障時快速的恢復業(yè)務，會直接切換到從庫上，當主庫故障處理完成后讓他直接作為叢庫來運行，此時主主就是一個不錯的選擇。
在mysql主從的應用中，只要進行了合理設置，基本上不會出現(xiàn)問題，但是對他的監(jiān)控是必不可少的，以免由于真的出現(xiàn)問題又不知道而造成不必要的數據損失。
Mysql主從的監(jiān)控，其主要是監(jiān)控從庫上的一些重要參數：
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之前版本沒有這個選項）
通過以上的參數可以反映出主庫和從庫狀態(tài)是否正常，從庫是否落后于主庫等。值得一提的是在mysql5.0以前的版本，Slave_IO_Running這個狀態(tài)指標不可靠，會在主庫直接掛掉的情況下不會變成NO，Seconds_Behind_Master參數也不存在。監(jiān)控以上參數即可監(jiān)控mysql主從。
2、mysql主從監(jiān)控的實現(xiàn) 不管mysql是那個版本，其中的從庫上的Exec_master_log_pos、Exec_master_log_pos；主庫上的 Master上的Log_File， Position，這四個參數可以判斷出當前主從的狀態(tài)。以下是適用于mysql所有版本的主從監(jiān)控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主從已經相當的成熟了，可以只監(jiān)控Slave_IO_Running，Slave_SQL_Running，Seconds_Behind_Master狀態(tài)就可以了，這里不再做說明。
本文出自 “王偉” 博客，請務必保留此出處http://wangwei007.blog.51cto.com/68019/965575
