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

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

我們?nèi)绾握业絾?wèn)題

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

調(diào)試慢速M(fèi)ySQL啟動(dòng)時(shí)間

我們使用流行的Percona工具pt-ioprofile來(lái)查看數(shù)據(jù)庫(kù)正在做什么。pt-ioprofile是Percona 用于調(diào)試MySQL問(wèn)題的流行工具包中非常重要的實(shí)用程序，您可以在其文檔中看到完整的功能列表。pt-ioprofile工具使用strace和lsof來(lái)監(jiān)視進(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  - 運(yùn)行- 時(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重啟的原因是什么？

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

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

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

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

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

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

了解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時(shí)：

要計(jì)算gtid_executed：

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

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

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

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

同樣，要計(jì)算gtid_purged：

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

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

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

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

當(dāng)binlog_gtid_simple_recovery = TRUE時(shí)：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

廣告

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