91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

MySQL中延遲問題和數據刷盤策略流程的示例分析

發布時間:2021-07-29 09:56:59 來源:億速云 閱讀:276 作者:小新 欄目:MySQL數據庫

這篇文章給大家分享的是有關MySQL中延遲問題和數據刷盤策略流程的示例分析的內容。小編覺得挺實用的,因此分享給大家做個參考,一起跟隨小編過來看看吧。

一、MySQL復制流程

官方文檔流程如下:

MySQL延遲問題和數據刷盤策略

1、絕對的延時,相對的同步

2、純寫操作,線上標準配置下,從庫壓力大于主庫,最起碼從庫有relaylog的寫入。

二、MySQL延遲問題分析

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過高問題

現象:

高并發導致CPU負載過高,處理請求時間拉長,逐步積壓,最終導致服務不可用;大量的慢SQL導致CPU負載過高。

解決思路:

基本上是禁止或是慎重考慮數據庫主從切換,這個解決不了根本問題,需要研發配合根治SQL問題,也可以服務降級,容器的話可以動態擴容CPU;和業務協商啟動pt-kill查殺只讀慢SQL;查看是否可以通過增加一般索引或是聯合索引來解決慢SQL問題,但此時要考慮DDL對數據庫影響。

四、InnoDB刷盤策略

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中延遲問題和數據刷盤策略流程的示例分析”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,讓大家可以學到更多知識,如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

阳西县| 吉首市| 德州市| 台南市| 莱阳市| 大洼县| 时尚| 乐昌市| 内乡县| 教育| 海宁市| 安溪县| 信宜市| 商都县| 崇仁县| 龙门县| 崇阳县| 合江县| 青川县| 田阳县| 措勤县| 望城县| 佛学| 庆云县| 莱西市| 盈江县| 湛江市| 深水埗区| 洪湖市| 明光市| 邯郸市| 江川县| 灌云县| 黔江区| 乌兰浩特市| 郧西县| 蒲江县| 乌拉特后旗| 云安县| 亚东县| 深泽县|