共計 2781 個字符,預計需要花費 7 分鐘才能閱讀完成。
這篇文章給大家分享的是有關 MySQL 中延遲問題和數據刷盤策略流程的示例分析的內容。丸趣 TV 小編覺得挺實用的,因此分享給大家做個參考,一起跟隨丸趣 TV 小編過來看看吧。
一、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 中延遲問題和數據刷盤策略流程的示例分析”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,讓大家可以學到更多知識,如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!