這篇文章主要介紹“怎么解決MySQL中Slave延遲很大并且不動了問題”，在日常操作中，相信很多人在怎么解決Mysql中Slave延遲很大并且不動了問題問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么解決Mysql中Slave延遲很大并且不動了問題”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

創(chuàng)新互聯(lián)專注于余江網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供余江營銷型網(wǎng)站建設(shè)，余江網(wǎng)站制作、余江網(wǎng)頁設(shè)計、余江網(wǎng)站官網(wǎng)定制、微信小程序開發(fā)服務(wù)，打造余江網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供余江網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。

問題描述

收到SLAVE延遲時間一直很大的報警，于是檢查一下SLAVE狀態(tài)（無關(guān)狀態(tài)我給隱去了）：

1.  Slave_IO_State: Waiting for master to send event       Master_Log_File: mysql-bin.000605                ---當(dāng)前master的binlog   

2. Read_Master_Log_Pos: 305864                          ---master binlog位置        

3.  Relay_Log_File: mysql-relay-bin.003224           Relay_Log_Pos: 295105   Relay_Master_Log_File: mysql-bin.000604                ----當(dāng)前salve同步到的master的binlog日志 

4.        Slave_IO_Running: Yes       Slave_SQL_Running: Yes              Last_Errno: 0              Last_Error:     Exec_Master_Log_Pos: 294959                          -----當(dāng)前slave執(zhí)行到的master的binlog 的pos 

5.         Relay_Log_Space: 4139172581   Seconds_Behind_Master: 10905                           ---延遲 一般是Read_Master_Log_Pos-Exec_Master_Log_Pos

可以看到，延遲確實很大，而且從多次show slave status的結(jié)果來看，發(fā)現(xiàn)binlog的position一直不動。

點擊(此處)折疊或打開

1. Relay_Master_Log_File: mysql-bin.000604

2.   Exec_Master_Log_Pos: 294959

3.       Relay_Log_Space: 4139172581

檢查processlist 也沒發(fā)現(xiàn)異常sql語句

在master上查看相應(yīng)binlog，確認都在干神馬事：

1. [yejr@imysql.com]# mysqlbinlog -vvv --base64-output=decode-rows-j 294959 mysql-bin.000604| more

2. --base64-output=decode-rows --去除一些不必要的二進制日志展示/*!40019 SET @@session.max_insert_delayed_threads=0*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; **# at 294959** #160204  6:16:30 server id 1  end_log_pos 295029     **Query    thread_id=461151**    **exec_time=2144**    error_code=0 SET TIMESTAMP=1454537790/*!*/; SET @@session.pseudo_thread_id=461151/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=0/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C latin1 *//*!*/; SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=33/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; BEGIN /*!*/; # at 295029 # at 295085 # at 296040 # at 297047 # at 298056 # at 299068 # at 300104

3. 上面這段內(nèi)容的幾個關(guān)鍵信息：

4. # at 294959   — binlog起點
   thread_id=461151    — master上執(zhí)行的線程ID
   exec_time=2144    — 該事務(wù)執(zhí)行總耗時

再往下看都是一堆的binlog position信息，通過這種方式可讀性不強，我們換一種姿勢看看

1. [yejr@imysql.com (test)]> show binlog events in 'mysql-bin.000604' from 294959 limit 10;+------------------+--------+-------------+-----------+-------------+----------------------------+ | Log_name         | Pos    | Event_type  | Server_id | End_log_pos | Info                       | +------------------+--------+-------------+-----------+-------------+----------------------------+ | mysql-bin.000604 | 294959 | Query       |         1 |      295029 | BEGIN                      | | mysql-bin.000604 | 295029 | Table_map   |         1 |      295085 | table_id: 84 (bacula.File) | | mysql-bin.000604 | 295085 | Delete_rows |         1 |      296040 | table_id: 84               | | mysql-bin.000604 | 296040 | Delete_rows |         1 |      297047 | table_id: 84               | | mysql-bin.000604 | 297047 | Delete_rows |         1 |      298056 | table_id: 84               | | mysql-bin.000604 | 298056 | Delete_rows |         1 |      299068 | table_id: 84               | | mysql-bin.000604 | 299068 | Delete_rows |         1 |      300104 | table_id: 84               | | mysql-bin.000604 | 300104 | Delete_rows |         1 |      301116 | table_id: 84               | | mysql-bin.000604 | 301116 | Delete_rows |         1 |      302147 | table_id: 84               | | mysql-bin.000604 | 302147 | Delete_rows |         1 |      303138 | table_id: 84               |

可以看到，這個事務(wù)不干別的，一直在刪除數(shù)據(jù)。
這是一個Bacula備份系統(tǒng)，會每天自動刪除一個月前的過期數(shù)據(jù)。
事實上，這個事務(wù)確實非常大，從binlog的294959開始，一直到這個binlog結(jié)束4139169218，一直都是在干這事，總共大概有3.85G的binlog要等著apply。

1. -rw-rw---- 1 mysql mysql 1.1G Feb  3 03:07 mysql-bin.000597

2. -rw-rw---- 1 mysql mysql 1.1G Feb  3 03:19 mysql-bin.000598

3. -rw-rw---- 1 mysql mysql 2.1G Feb  3 03:33 mysql-bin.000599

4. -rw-rw---- 1 mysql mysql 1.4G Feb  3 03:45 mysql-bin.000600

5. -rw-rw---- 1 mysql mysql 1.8G Feb  3 04:15 mysql-bin.000601

6. -rw-rw---- 1 mysql mysql 1.3G Feb  3 04:53 mysql-bin.000602

7. -rw-rw---- 1 mysql mysql 4.5G Feb  4 06:16 mysql-bin.000603

8. -rw-rw---- 1 mysql mysql 3.9G Feb  4 06:52 mysql-bin.000604

9. -rw-rw---- 1 mysql mysql 1.2K Feb  4 06:52 mysql-bin.000605

怎么解決

由于這是Bacula備份系統(tǒng)內(nèi)置生成的大事務(wù)，除非去修改它的源碼，否則沒有太好的辦法。

對于我們一般的應(yīng)用而言，最好是攢夠一定操作后，就先提交一下事務(wù)，比如刪除幾千條記錄后提交一次，而不是像本例這樣，一個刪除事務(wù)消耗了將近3.9G的binlog日質(zhì)量，這種就非?？膳铝?。

除了會導(dǎo)致SLAVE看起來一直不動以外，還可能會導(dǎo)致某些數(shù)據(jù)行（data rows）被長時間鎖定不釋放，而導(dǎo)致大量行鎖等待發(fā)生。

到此，關(guān)于“怎么解決Mysql中Slave延遲很大并且不動了問題”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>

網(wǎng)頁題目：怎么解決Mysql中Slave延遲很大并且不動了問題
瀏覽路徑：http://aaarwkj.com/article26/iipijg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站導(dǎo)航、做網(wǎng)站、網(wǎng)站制作、網(wǎng)站營銷、移動網(wǎng)站建設(shè)、搜索引擎優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)