您是否在GTID模式下遇到MySQL啟動時間較慢的問題？我們最近在我們的一個MySQL託管部署中遇到了這個問題，並著手解決這個問題。在本文中，我們分解了可能會減慢MySQL重啟時間，如何除錯部署以及如何減少啟動時間和提高對基於GTID的複製的理解的問題。

我們如何找到問題

我們正在研究在啟用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啟動時間慢？二進位制日誌檔案大小可能是問題