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

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

我們?nèi)绾握业絾栴}

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

調(diào)試慢速MySQL啟動時間

我們使用流行的Percona工具pt-ioprofile來查看數(shù)據(jù)庫正在做什么。pt-ioprofile是Percona 用于調(diào)試MySQL問題的流行工具包中非常重要的實用程序，您可以在其文檔中看到完整的功能列表。pt-ioprofile工具使用strace和lsof來監(jiān)視進程的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進程大部分時間都在閱讀最新的二進制日志文件。即使服務(wù)器已經(jīng)正常停止并且不需要崩潰恢復(fù)等，情況也是如此。

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

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

• 由于數(shù)據(jù)庫關(guān)閉會刷新二進制日志并在啟動時創(chuàng)建一個新日志，因此我們進行了另一項實驗 - 在關(guān)閉服務(wù)器之前，我們刷新了二進制日志。后續(xù)服務(wù)器啟動再次快速。

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

了解Binlog GTID恢復(fù)

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

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

當(dāng)binlog_gtid_simple_recovery = FALSE時：

要計算gtid_executed：

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

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

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

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

同樣，要計算gtid_purged：

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

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

• 價值gtid_purged設(shè)置為gtid_executed，減去gtids_in_binlog_not_purged。

因此，這構(gòu)成了我們理解舊版本中工作原理的基礎(chǔ)。但是，當(dāng)binlog_gtid_simple_recovery為TRUE 時，可以進行某些優(yōu)化。我們感興趣的是這種情況：

當(dāng)binlog_gtid_simple_recovery = TRUE時：

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

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

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

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

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

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

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

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

如何解決您的慢啟動時間

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

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

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