GTID中MySQL啟動(dòng)時(shí)間慢是什么原因

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

我們如何找到問(wèn)題

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

調試慢速MySQL啟動(dòng)時(shí)間

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

所以，我們啟動(dòng)MySQL，等待mysqld進(jìn)程生成，并啟動(dòng)pt-ioprofile以查看問(wèn)題可能是：

＃ PT - ioprofile  - 個(gè)人資料- 過(guò)程 的mysqld  - 運行- 時(shí)間 200

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

跟蹤 進(jìn)程 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重啟的原因是什么？

在多次運行時(shí)，我們觀(guān)察到以下情況：

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

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

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

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

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

了解Binlog GTID恢復

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

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

當binlog_gtid_simple_recovery = FALSE時(shí)：

要計算gtid_executed：

• 從最新的迭代二進(jìn)制日志文件，停止在具有Previous_gtids_log_event條目的第一個(gè)文件。

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

• 價(jià)值gtid_executed被計算為工會(huì )gtids_in_binlog并在該GTIDs mysql.gtid_executed表。

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

同樣，要計算gtid_purged：

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

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

• 價(jià)值gtid_purged設置為gtid_executed，減去gtids_in_binlog_not_purged。

因此，這構成了我們理解舊版本中工作原理的基礎。但是，當binlog_gtid_simple_recovery為T(mén)RUE 時(shí)，可以進(jìn)行某些優(yōu)化。我們感興趣的是這種情況：

當binlog_gtid_simple_recovery = TRUE時(shí)：

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

• 只讀最舊和最新的二進(jìn)制日志文件。

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

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

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

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

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

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

如何解決您的慢啟動(dòng)時(shí)間

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

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