MySQL主從問題

標籤：blog   http   io   ar   os   使用   sp   for   strong   

Mysql資料庫主從心得整理

     管理mysql主從有2年多了，管理過200多組mysql主從，幾乎涉及到各個版本的主從，本博文屬於總結性的，有一部分是摘自網路，大部分是根據自己管理的心得和經驗所寫，整理了一下，分享給各位同行，希望對大家有協助，互相交流。 一、mysql主從的原理 1、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” 參數項。 2、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，所以兩端的資料是完全一樣的。 3、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.啟用了NDB3.當前會話試用 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=0SET TIMESTAMP=1244793942/*!*/;insert into db_allot_ids select * from db_allot_ids/*!*/;—————————————–在BINLOG_FORMAT=ROW 模式下:BINLOG日誌資訊為:—————————————–BINLOG ‘hA0yShMBAAAAMwAAAOAAAAAAAA8AAAAAAAAAA1NOUwAMZGJfYWxsb3RfaWRzAAIBAwAAhA0yShcBAAAANQAAABUBAAAQAA8AAAAAAAEAAv/8AQEAAAD8AQEAAAD8AQEAAAD8AQEAAAA=‘/*!*/;—————————————– 4、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 將會更加受人歡迎，可實施性也會更大。 5、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。 二、Mysql主從複製的過濾複製的過濾主要有２種方式：1、在主伺服器在把事件從進二制日誌中過濾掉，相關的參數是:binlog_do_db和binlog_ignore_db。2、在從伺服器上把事件從中繼日誌中過濾掉，相關的參數是replicate_*。複製只能擴充讀取，不能擴充寫入，對資料進行分區可以進行擴充寫入。複製的最佳化：在mysql複製環境中,有8個參數可以讓我們控制,需要複製或需要忽略不進行複製的DB或table分別為:下面二項需要在Master上設定：Binlog_Do_DB:設定哪些資料庫需要記錄BinlogBinlog_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:設定需要複製的TableReplicate_Ignore_Table:設定可以忽略的TableReplicate_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以前版本的主從同步時，一定保持主從資料庫的一致性，主上有的庫或是表從上一定要有，否則在同步的過程會出錯。 三、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.1．mysql5.0以下版本的配置 修改主庫mysql配置設定檔，在[mysqld]段添加以下內容：server-id = 1log-bin=/home/mysql/logs/binlog/bin-logmax_binlog_size = 500Mbinlog_cache_size = 128Kbinlog-do-db = adbbinlog-ignore-db = mysqllog-slave-updates 1.2. mysql5.0以上版本的配置 修改主庫mysql配置設定檔，在[mysqld]段添加以下內容：server-id = 1log-bin=/home/mysql/logs/binlog/bin-logmax_binlog_size = 500Mbinlog_cache_size = 128Kbinlog-do-db = adbbinlog-ignore-db = mysqllog-slave-updatesexpire_logs_day=2binlog_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、從庫的配置 2.1.mysql5.1.7以前版本修改從庫mysql配置設定檔，在[mysqld]段添加以下內容：server-id=2master-host=192.168.1.2master-user=replmaster-password=1q2w3e4rmaster-port=3306master-connect-retry=30slave-skip-errors=1062replicate-do-db = adbreplicate-ignore-db = mysqlslave-skip-errors=1007,1008,1053,1062,1213,1158,1159master-info-file = /home/mysql/logs/master.inforelay-log = /home/mysql/logs/relay-binrelay-log-index = /home/mysql/logs/relay-bin.indexrelay-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、實現主從同步 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 tomaster_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: YesSlave_SQL_Running: YesMaster_Log_File: bin-log.003Relay_Master_Log_File: bin-log.003Read_Master_Log_Pos: 4Exec_master_log_pos: 4Seconds_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的錯誤。解決方案：進入mastermysql> show master status;+----------------------+----------+--------------+------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |+----------------------+----------+--------------+------------------+| mysql-bin.000040 | 324 |adb | mysql|+----------------------+----------+--------------+------------------+然後到slave伺服器上執行手動同步slave stop;change master tomaster_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資料庫。 四、mysql主主和主主叢集 1、mysql主主的實現    在實際的生產應用中，為了在主庫出現崩潰或是主伺服器出現嚴重故障時快速的恢複業務，會直接切換到從庫上，當主庫故障處理完成後讓他直接作為叢庫來運行，此時主主就是一個不錯的選擇。   五、mysql主從的監控在mysql主從的應用中，只要進行了合理設定，基本上不會出現問題，但是對他的監控是必不可少的，以免由於真的出現問題又不知道而造成不必要的資料損失。 1、mysql主從監控的主要思路Mysql主從的監控，其主要是監控從庫上的一些重要參數：Slave_IO_Running: YesSlave_SQL_Running: YesMaster_Log_File: bin-log.003Relay_Master_Log_File: bin-log.003Read_Master_Log_Pos: 4Exec_master_log_pos: 4Seconds_Behind_Master: 0（5.0之前版本沒有這個選項）通過以上的參數可以反映出主庫和從庫狀態是否正常，從庫是否落後於主庫等。值得一提的是在mysql5.0以前的版本，Slave_IO_Running這個狀態指標不可靠，會在主庫直接掛掉的情況下不會變成NO，Seconds_Behind_Master參數也不存在。監控以上參數即可監控mysql主從。 2、mysql主從監控的實現不管mysql是那個版本，其中的從庫上的Exec_master_log_pos、Exec_master_log_pos；主庫上的 Master上的Log_File， Position，這四個參數可以判斷出當前主從的狀態。以下是適用於mysql所有版本的主從監控shell指令碼：#/bin/shuser=replpasswd=123415master_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       fidone在mysql5.0以後的版本，mysql主從已經相當的成熟了，可以只監控Slave_IO_Running，Slave_SQL_Running，Seconds_Behind_Master狀態就可以了，這裡不再做說明。

本文出自 “王偉” 部落格，請務必保留此出處http://wangwei007.blog.51cto.com/68019/965575

MySQL主從問題