MySQL中延遲問(wèn)題和數(shù)據(jù)刷盤(pán)策略流程的示例分析-創(chuàng)新互聯(lián)

這篇文章給大家分享的是有關(guān)MySQL中延遲問(wèn)題和數(shù)據(jù)刷盤(pán)策略流程的示例分析的內(nèi)容。小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過(guò)來(lái)看看吧。

創(chuàng)新互聯(lián)建站是網(wǎng)站建設(shè)技術(shù)企業(yè)，為成都企業(yè)提供專(zhuān)業(yè)的成都網(wǎng)站制作、成都做網(wǎng)站，網(wǎng)站設(shè)計(jì)，網(wǎng)站制作，網(wǎng)站改版等技術(shù)服務(wù)。擁有十余年豐富建站經(jīng)驗(yàn)和眾多成功案例，為您定制適合企業(yè)的網(wǎng)站。十余年品質(zhì)，值得信賴(lài)！一、MySQL復(fù)制流程

官方文檔流程如下：

MySQL延遲問(wèn)題和數(shù)據(jù)刷盤(pán)策略

1、絕對(duì)的延時(shí)，相對(duì)的同步

2、純寫(xiě)操作，線(xiàn)上標(biāo)準(zhǔn)配置下，從庫(kù)壓力大于主庫(kù)，最起碼從庫(kù)有relaylog的寫(xiě)入。

二、MySQL延遲問(wèn)題分析

1、主庫(kù)DML請(qǐng)求頻繁

原因：主庫(kù)并發(fā)寫(xiě)入數(shù)據(jù)，而從庫(kù)為單線(xiàn)程應(yīng)用日志，很容易造成relaylog堆積，產(chǎn)生延遲。

解決思路：做sharding，打散寫(xiě)請(qǐng)求?？紤]升級(jí)到MySQL5.7+，開(kāi)啟基于邏輯時(shí)鐘的并行復(fù)制。

2、主庫(kù)執(zhí)行大事務(wù)

原因：類(lèi)似主庫(kù)花費(fèi)很長(zhǎng)時(shí)間更新了一張大表，在主從庫(kù)配置相近的情況下，從庫(kù)也需要花幾乎同樣的時(shí)間更新這張大表，此時(shí)從庫(kù)延遲開(kāi)始堆積，后續(xù)的events無(wú)法更新。

解決思路：拆分大事務(wù)，及時(shí)提交。

3、主庫(kù)對(duì)大表執(zhí)行DDL語(yǔ)句

原因：DDL未開(kāi)始執(zhí)行，被阻塞，檢查到位點(diǎn)不變；DDL正在執(zhí)行，單線(xiàn)程應(yīng)用導(dǎo)致延遲增加，位點(diǎn)不變。

解決思路：找到被阻塞DDL或是寫(xiě)操作的查詢(xún)，干掉該查詢(xún)，讓DDL正常在從庫(kù)上執(zhí)行；業(yè)務(wù)低峰期執(zhí)行，盡量使用支持OnlineDDL的高版本MySQL。

4、主從實(shí)例配置不一致

原因：硬件上：主庫(kù)實(shí)例服務(wù)器使用SSD，而從庫(kù)實(shí)例服務(wù)器使用普通SAS盤(pán)、cpu主頻不一致等；配置上：如RAID卡寫(xiě)策略不一致，OS內(nèi)核參數(shù)設(shè)置不一致，MySQL落盤(pán)策略(innodb_flush_log_at_trx_commit和sync_binlog等)不一致等

解決思路：盡量統(tǒng)一DB機(jī)器的配置（包括硬件及選項(xiàng)參數(shù)）；甚至對(duì)于某些OLAP業(yè)務(wù)，從庫(kù)實(shí)例硬件配置高于主庫(kù)等。

5、從庫(kù)自身壓力過(guò)大

原因：從庫(kù)執(zhí)行大量select請(qǐng)求，或業(yè)務(wù)大部分select請(qǐng)求被路由到從庫(kù)實(shí)例上，甚至大量OLAP業(yè)務(wù)，或者從庫(kù)正在備份等，此時(shí)可能造成cpu負(fù)載過(guò)高，io利用率過(guò)高等，導(dǎo)致SQLThread應(yīng)用過(guò)慢。

解決思路：建立更多西安數(shù)據(jù)庫(kù)培訓(xùn)從庫(kù)，打散讀請(qǐng)求，降低現(xiàn)有從庫(kù)實(shí)例的壓力。

也可以調(diào)整innodb_flush_log_at_trx_commit=0和sync_binlog=0刷盤(pán)參數(shù)來(lái)緩解IO壓力來(lái)降低主從延遲。

三、大促期間CPU過(guò)高問(wèn)題

現(xiàn)象：

高并發(fā)導(dǎo)致CPU負(fù)載過(guò)高，處理請(qǐng)求時(shí)間拉長(zhǎng)，逐步積壓，最終導(dǎo)致服務(wù)不可用；大量的慢SQL導(dǎo)致CPU負(fù)載過(guò)高。

解決思路：

基本上是禁止或是慎重考慮數(shù)據(jù)庫(kù)主從切換，這個(gè)解決不了根本問(wèn)題，需要研發(fā)配合根治SQL問(wèn)題，也可以服務(wù)降級(jí)，容器的話(huà)可以動(dòng)態(tài)擴(kuò)容CPU；和業(yè)務(wù)協(xié)商啟動(dòng)pt-kill查殺只讀慢SQL；查看是否可以通過(guò)增加一般索引或是聯(lián)合索引來(lái)解決慢SQL問(wèn)題，但此時(shí)要考慮DDL對(duì)數(shù)據(jù)庫(kù)影響。

四、InnoDB刷盤(pán)策略

MySQL的innodb_flush_method這個(gè)參數(shù)控制著innodb數(shù)據(jù)文件及redolog的打開(kāi)、刷寫(xiě)模式，對(duì)于這個(gè)參數(shù)，文檔上是這樣描述的：

有三個(gè)值：fdatasync(默認(rèn))，O_DSYNC，O_DIRECT

默認(rèn)是fdatasync，調(diào)用fsync()去刷數(shù)據(jù)文件與redolog的buffer

為O_DSYNC時(shí)，innodb會(huì)使用O_SYNC方式打開(kāi)和刷寫(xiě)redolog,使用fsync()刷寫(xiě)數(shù)據(jù)文件

為O_DIRECT時(shí)，innodb使用O_DIRECT打開(kāi)數(shù)據(jù)文件，使用fsync()刷寫(xiě)數(shù)據(jù)文件跟redolog

首先文件的寫(xiě)操作包括三步：open,write,flush

上面最常提到的fsync(intfd)函數(shù)，該函數(shù)作用是flush時(shí)將與fd文件描述符所指文件有關(guān)的buffer刷寫(xiě)到磁盤(pán)，并且flush完元數(shù)據(jù)信息(比如修改日期、創(chuàng)建日期等)才算flush成功。

使用O_DSYNC方式打開(kāi)redo文件表示當(dāng)write日志時(shí)，數(shù)據(jù)都write到磁盤(pán)，并且元數(shù)據(jù)也需要更新，才返回成功。

O_DIRECT則表示我們的write操作是從MySQLinnodbbuffer里直接向磁盤(pán)上寫(xiě)。

這三種模式寫(xiě)數(shù)據(jù)方式具體如下：

fdatasync模式：寫(xiě)數(shù)據(jù)時(shí)，write這一步并不需要真正寫(xiě)到磁盤(pán)才算完成（可能寫(xiě)入到操作系統(tǒng)buffer中就會(huì)返回完成），真正完成是flush操作，buffer交給操作系統(tǒng)去flush,并且文件的元數(shù)據(jù)信息也都需要更新到磁盤(pán)。

O_DSYNC模式：寫(xiě)日志操作是在write這步完成，而數(shù)據(jù)文件的寫(xiě)入是在flush這步通過(guò)fsync完成

O_DIRECT模式：數(shù)據(jù)文件的寫(xiě)入操作是直接從mysqlinnodbbuffer到磁盤(pán)的，并不用通過(guò)操作系統(tǒng)的緩沖，而真正的完成也是在flush這步,日志還是要經(jīng)過(guò)OS緩沖。

MySQL延遲問(wèn)題和數(shù)據(jù)刷盤(pán)策略

1、在類(lèi)unix操作系統(tǒng)中，文件的打開(kāi)方式為O_DIRECT會(huì)最小化緩沖對(duì)io的影響，該文件的io是直接在用戶(hù)空間的buffer上操作的，并且io操作是同步的，因此不管是read()系統(tǒng)調(diào)用還是write()系統(tǒng)調(diào)用，數(shù)據(jù)都保證是從磁盤(pán)上讀取的；所以IO方面壓力最小，對(duì)于CPU處理壓力上也最小，對(duì)物理內(nèi)存的占用也最?。坏怯捎跊](méi)有操作系統(tǒng)緩沖的作用，對(duì)于數(shù)據(jù)寫(xiě)入磁盤(pán)的速度會(huì)降低明顯（表現(xiàn)為寫(xiě)入響應(yīng)時(shí)間的拉長(zhǎng)），但不會(huì)明顯造成整體SQL請(qǐng)求量的降低（這有賴(lài)于足夠大的innodb_buffer_pool_size）。

2、O_DSYNC方式表示以同步io的方式打開(kāi)文件，任何寫(xiě)操作都將阻塞到數(shù)據(jù)寫(xiě)入物理磁盤(pán)后才返回。這就造成CPU等待加長(zhǎng)，SQL請(qǐng)求吞吐能力降低，insert時(shí)間拉長(zhǎng)。

3、fsync(intfiledes)函數(shù)只對(duì)由文件描述符filedes指定的單一文件起作用，并且等待寫(xiě)磁盤(pán)操作結(jié)束，然后返回。fdatasync(intfiledes)函數(shù)類(lèi)似于fsync，但它只影響文件的數(shù)據(jù)部分。而除數(shù)據(jù)外，fsync還會(huì)同步更新文件的元信息到磁盤(pán)。

O_DSYNC對(duì)CPU的壓力大，datasync次之，O_DIRECT最小；整體SQL語(yǔ)句處理性能和響應(yīng)時(shí)間看，O_DSYNC較差；O_DIRECT在SQL吞吐能力上較好（僅次于datasync模式），但響應(yīng)時(shí)間卻是最長(zhǎng)的。

默認(rèn)datasync模式，整體表現(xiàn)較好，因?yàn)槌浞掷昧瞬僮飨到y(tǒng)buffer和innodb_buffer_pool的處理性能，但帶來(lái)的負(fù)面效果是free內(nèi)存降低過(guò)快，最后導(dǎo)致頁(yè)交換頻繁，磁盤(pán)IO壓力大，這會(huì)嚴(yán)重影響大并發(fā)量數(shù)據(jù)寫(xiě)入的穩(wěn)定性。

感謝各位的閱讀！關(guān)于“MySQL中延遲問(wèn)題和數(shù)據(jù)刷盤(pán)策略流程的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！

文章名稱(chēng)：MySQL中延遲問(wèn)題和數(shù)據(jù)刷盤(pán)策略流程的示例分析-創(chuàng)新互聯(lián)
瀏覽路徑：http://bm7419.com/article28/ijdcp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供手機(jī)網(wǎng)站建設(shè)、用戶(hù)體驗(yàn)、網(wǎng)站設(shè)計(jì)公司、商城網(wǎng)站、定制開(kāi)發(fā)、自適應(yīng)網(wǎng)站

廣告

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