您好,登錄后才能下訂單哦!
這篇文章給大家分享的是有關MySQL中延遲問題和數據刷盤策略流程的示例分析的內容。小編覺得挺實用的,因此分享給大家做個參考,一起跟隨小編過來看看吧。
官方文檔流程如下:
MySQL延遲問題和數據刷盤策略
1、絕對的延時,相對的同步
2、純寫操作,線上標準配置下,從庫壓力大于主庫,最起碼從庫有relaylog的寫入。
1、主庫DML請求頻繁
原因:主庫并發寫入數據,而從庫為單線程應用日志,很容易造成relaylog堆積,產生延遲。
解決思路:做sharding,打散寫請求。考慮升級到MySQL5.7+,開啟基于邏輯時鐘的并行復制。
2、主庫執行大事務
原因:類似主庫花費很長時間更新了一張大表,在主從庫配置相近的情況下,從庫也需要花幾乎同樣的時間更新這張大表,此時從庫延遲開始堆積,后續的events無法更新。
解決思路:拆分大事務,及時提交。
3、主庫對大表執行DDL語句
原因:DDL未開始執行,被阻塞,檢查到位點不變;DDL正在執行,單線程應用導致延遲增加,位點不變。
解決思路:找到被阻塞DDL或是寫操作的查詢,干掉該查詢,讓DDL正常在從庫上執行;業務低峰期執行,盡量使用支持OnlineDDL的高版本MySQL。
4、主從實例配置不一致
原因:硬件上:主庫實例服務器使用SSD,而從庫實例服務器使用普通SAS盤、cpu主頻不一致等;配置上:如RAID卡寫策略不一致,OS內核參數設置不一致,MySQL落盤策略(innodb_flush_log_at_trx_commit和sync_binlog等)不一致等
解決思路:盡量統一DB機器的配置(包括硬件及選項參數);甚至對于某些OLAP業務,從庫實例硬件配置高于主庫等。
5、從庫自身壓力過大
原因:從庫執行大量select請求,或業務大部分select請求被路由到從庫實例上,甚至大量OLAP業務,或者從庫正在備份等,此時可能造成cpu負載過高,io利用率過高等,導致SQLThread應用過慢。
解決思路:建立更多西安數據庫培訓從庫,打散讀請求,降低現有從庫實例的壓力。
也可以調整innodb_flush_log_at_trx_commit=0和sync_binlog=0刷盤參數來緩解IO壓力來降低主從延遲。
現象:
高并發導致CPU負載過高,處理請求時間拉長,逐步積壓,最終導致服務不可用;大量的慢SQL導致CPU負載過高。
解決思路:
基本上是禁止或是慎重考慮數據庫主從切換,這個解決不了根本問題,需要研發配合根治SQL問題,也可以服務降級,容器的話可以動態擴容CPU;和業務協商啟動pt-kill查殺只讀慢SQL;查看是否可以通過增加一般索引或是聯合索引來解決慢SQL問題,但此時要考慮DDL對數據庫影響。
MySQL的innodb_flush_method這個參數控制著innodb數據文件及redolog的打開、刷寫模式,對于這個參數,文檔上是這樣描述的:
有三個值:fdatasync(默認),O_DSYNC,O_DIRECT
默認是fdatasync,調用fsync()去刷數據文件與redolog的buffer
為O_DSYNC時,innodb會使用O_SYNC方式打開和刷寫redolog,使用fsync()刷寫數據文件
為O_DIRECT時,innodb使用O_DIRECT打開數據文件,使用fsync()刷寫數據文件跟redolog
首先文件的寫操作包括三步:open,write,flush
上面最常提到的fsync(intfd)函數,該函數作用是flush時將與fd文件描述符所指文件有關的buffer刷寫到磁盤,并且flush完元數據信息(比如修改日期、創建日期等)才算flush成功。
使用O_DSYNC方式打開redo文件表示當write日志時,數據都write到磁盤,并且元數據也需要更新,才返回成功。
O_DIRECT則表示我們的write操作是從MySQLinnodbbuffer里直接向磁盤上寫。
這三種模式寫數據方式具體如下:
fdatasync模式:寫數據時,write這一步并不需要真正寫到磁盤才算完成(可能寫入到操作系統buffer中就會返回完成),真正完成是flush操作,buffer交給操作系統去flush,并且文件的元數據信息也都需要更新到磁盤。
O_DSYNC模式:寫日志操作是在write這步完成,而數據文件的寫入是在flush這步通過fsync完成
O_DIRECT模式:數據文件的寫入操作是直接從mysqlinnodbbuffer到磁盤的,并不用通過操作系統的緩沖,而真正的完成也是在flush這步,日志還是要經過OS緩沖。
MySQL延遲問題和數據刷盤策略
1、在類unix操作系統中,文件的打開方式為O_DIRECT會最小化緩沖對io的影響,該文件的io是直接在用戶空間的buffer上操作的,并且io操作是同步的,因此不管是read()系統調用還是write()系統調用,數據都保證是從磁盤上讀取的;所以IO方面壓力最小,對于CPU處理壓力上也最小,對物理內存的占用也最小;但是由于沒有操作系統緩沖的作用,對于數據寫入磁盤的速度會降低明顯(表現為寫入響應時間的拉長),但不會明顯造成整體SQL請求量的降低(這有賴于足夠大的innodb_buffer_pool_size)。
2、O_DSYNC方式表示以同步io的方式打開文件,任何寫操作都將阻塞到數據寫入物理磁盤后才返回。這就造成CPU等待加長,SQL請求吞吐能力降低,insert時間拉長。
3、fsync(intfiledes)函數只對由文件描述符filedes指定的單一文件起作用,并且等待寫磁盤操作結束,然后返回。fdatasync(intfiledes)函數類似于fsync,但它只影響文件的數據部分。而除數據外,fsync還會同步更新文件的元信息到磁盤。
O_DSYNC對CPU的壓力最大,datasync次之,O_DIRECT最小;整體SQL語句處理性能和響應時間看,O_DSYNC較差;O_DIRECT在SQL吞吐能力上較好(僅次于datasync模式),但響應時間卻是最長的。
默認datasync模式,整體表現較好,因為充分利用了操作系統buffer和innodb_buffer_pool的處理性能,但帶來的負面效果是free內存降低過快,最后導致頁交換頻繁,磁盤IO壓力大,這會嚴重影響大并發量數據寫入的穩定性。
感謝各位的閱讀!關于“MySQL中延遲問題和數據刷盤策略流程的示例分析”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,讓大家可以學到更多知識,如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。