GTID中MySQL啟動時間慢是什么原因

本篇內容介紹了“GTID中MySQL啟動時間慢是什么原因”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

我們如何找到問題

我們正在研究在啟用GTID模式的低端，基于磁盤的MySQL 5.7.21部署中緩慢的MySQL啟動時間。該系統是主從對的一部分，并且處于適度的寫入負載下。在計劃維護期間重新啟動時，我們注意到數據庫服務器需要5-10分鐘才能啟動并開始接受連接。這種延遲沒有意義，所以我們開始調查。

調試慢速MySQL啟動時間

我們使用流行的Percona工具pt-ioprofile來查看數據庫正在做什么。pt-ioprofile是Percona 用于調試MySQL問題的流行工具包中非常重要的實用程序，您可以在其文檔中看到完整的功能列表。pt-ioprofile工具使用strace和lsof來監視進程的I / O并打印出一個文件和I / O活動表。

所以，我們啟動MySQL，等待mysqld進程生成，并啟動pt-ioprofile以查看問題可能是：

＃ PT - ioprofile  - 個人資料- 過程 的mysqld  - 運行- 時間 200

周二 年10月 9  15：42：24  UTC  2018

跟蹤 進程 ID  18677

total       pread        read      pwrite       write       fsync   fdatasync        open       close    getdents       lseek       fcntl  filename

...

216.550641    0.000000   216.550565    0.000000    0.000000    0.000000    0.000000    0.000015    0.000040    0.000000    0.000021    0.000000  / mysql_data / binlogs / mysql - bin。000014

...

你的MySQL重啟的原因是什么？

在多次運行時，我們觀察到以下情況：

• mysqld進程大部分時間都在閱讀最新的二進制日志文件。即使服務器已經正常停止并且不需要崩潰恢復等，情況也是如此。

• 服務器也花了相當多的時間加載InnoDB數據文件，但與讀取最新的二進制日志文件所花費的時間相比，這個時間要小得多。

• 如果服務器立即重新啟動，則后續重啟會更快。

• 由于數據庫關閉會刷新二進制日志并在啟動時創建一個新日志，因此我們進行了另一項實驗 - 在關閉服務器之前，我們刷新了二進制日志。后續服務器啟動再次快速。

這些觀察清楚地指出MySQL正在花費大量時間閱讀最新的二進制日志文件。如果文件很小，就像在關機之前刷新日志文件那樣，啟動速度很快。

了解Binlog GTID恢復

事實證明，為了填充gtid_executed和gtid_purged的值，MySQL服務器必須解析二進制日志文件。

以下是基于FALSE或TRUE讀數的MySQL 5.7 文檔方法建議的摘要：

當binlog_gtid_simple_recovery = FALSE時：

要計算gtid_executed：

• 從最新的迭代二進制日志文件，停止在具有Previous_gtids_log_event條目的第一個文件。

• 從此二進制日志文件中使用Previous_gtids_log_event和Gtid_log_events中的所有GTID ，并在內部存儲此GTID集。它被稱為gtids_in_binlog。

• 價值gtid_executed被計算為工會gtids_in_binlog并在該GTIDs mysql.gtid_executed表。

如果存在大量沒有GTID的二進制日志文件（例如，在gtid_mode = OFF 時創建），則此過程可能非常耗時。

同樣，要計算gtid_purged：

• 迭代從最舊到最新的二進制日志文件，停止在包含非空的Previous_gtids_log_event（至少有一個GTID）或至少有一個Gtid_log_event的第一個二進制日志中。

• 從此文件中讀取Previous_gtids_log_event。計算內部變量gtids_in_binlog_not_purged，因為此gTID集從gtids_in_binlog中減去。

• 價值gtid_purged設置為gtid_executed，減去gtids_in_binlog_not_purged。

因此，這構成了我們理解舊版本中工作原理的基礎。但是，當binlog_gtid_simple_recovery為TRUE 時，可以進行某些優化。我們感興趣的是這種情況：

當binlog_gtid_simple_recovery = TRUE時：

（注意，這是MySQL 5.7.7及更高版本中的默認設置）

• 只讀最舊和最新的二進制日志文件。

• 從最早的二進制日志文件中找到的Previous_gtids_log_event或Gtid_log_event計算gtid_purged。

• 從最新的二進制日志文件中找到的Previous_gtids_log_event或Gtid_log_event計算gtid_executed。

• 因此，在服務器重新啟動或清除二進制日志期間，只讀取兩個二進制日志文件。

因此，對于MySQL 5.7.7及更高版本，在系統啟動期間始終讀取最新和舊的二進制日志文件，以正確初始化GTID系統變量。讀取最舊的二進制日志文件并不昂貴，因為MySQL正在尋找的事件，Previous_gtids_log_event，始終是二進制日志文件中的第一個事件。

但是，為了正確計算gtid_executed，服務器必須讀取整個最新的二進制日志文件并收集該文件中的所有事件。因此，系統啟動時間與最新二進制日志文件的大小成正比。

請注意，當binlog_gtid_simple_recovery為FALSE 時，情況會更糟。由于它不再是最近版本中的默認選項，因此并不是一個值得關注的問題。

如何解決您的慢啟動時間

了解了我們遇到的問題的原因，我們決定的解決方案相當明顯 - 減少二進制日志文件的大小。二進制日志文件的默認大小為1GB。在啟動期間解析此大小的文件需要花費時間，因此將max_binlog_size的值減小到較低值是有意義的。

如果不能減小二進制日志文件的大小，那么在維護關閉mysqld進程之前刷新二進制日志文件有助于減少binlog GTID恢復時間。

“GTID中MySQL啟動時間慢是什么原因”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！