怎么解決Mysql中Slave延遲很大并且不動了問題

123次閱讀

共計 4114 個字符，預計需要花費 11 分鐘才能閱讀完成。

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

問題描述

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

Slave_IO_State: Waiting for master to send event
Master_Log_File: mysql-bin.000605 — 當前 master 的 binlog

Read_Master_Log_Pos: 305864 —master binlog 位置

Relay_Log_File: mysql-relay-bin.003224
Relay_Log_Pos: 295105
Relay_Master_Log_File: mysql-bin.000604 —- 當前 salve 同步到的 master 的 binlog 日志

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_Errno: 0
Last_Error:
Exec_Master_Log_Pos: 294959 —– 當前 slave 執(zhí)行到的 master 的 binlog 的 pos

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 一直不動。

點擊 (此處) 折疊或打開

Relay_Master_Log_File: mysql-bin.000604

Exec_Master_Log_Pos: 294959

Relay_Log_Space: 4139172581

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

在 master 上查看相應 binlog，確認都在干神馬事：

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

–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

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

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

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

[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 |

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

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

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

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

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

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

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

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

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

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

怎么解決

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

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

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

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

正文完