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

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、微信小程序開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了泰山免費(fèi)建站歡迎大家使用！

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

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

調(diào)試慢速M(fèi)ySQL啟動時間

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

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

＃ PT - ioprofile  - 個人資料- 過程 的mysqld  - 運(yùn)行- 時間 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重啟的原因是什么？

在多次運(yùn)行時，我們觀察到以下情況：

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

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

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

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

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

了解Binlog GTID恢復(fù)

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

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

當(dāng)binlog_gtid_simple_recovery = FALSE時：

要計算gtid_executed：

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

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

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

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

同樣，要計算gtid_purged：

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

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

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

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

當(dāng)binlog_gtid_simple_recovery = TRUE時：

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

• 只讀最舊和最新的二進(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ù)器重新啟動或清除二進(jìn)制日志期間，只讀取兩個二進(jìn)制日志文件。

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

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

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

如何解決您的慢啟動時間

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

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

“GTID中MySQL啟動時間慢是什么原因”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！

文章標(biāo)題：GTID中MySQL啟動時間慢是什么原因-創(chuàng)新互聯(lián)
標(biāo)題URL：http://chinadenli.net/article32/dioosc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)建站、品牌網(wǎng)站制作、微信小程序、定制開發(fā)、移動網(wǎng)站建設(shè)、電子商務(wù)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)