【MySQL】sync_binlog innodb_flush_log_at_trx_commit 淺析
innodb_flush_log_at_trx_commit和sync_binlog 兩個引數是控制MySQL 磁碟寫入策略以及資料安全性的關鍵引數。本文從引數含義,效能,安全形度闡述兩個引數為不同的值時對db 效能,資料的影響.
一 引數意義
innodb_flush_log_at_trx_commit
如果innodb_flush_log_at_trx_commit設定為0,log buffer將每秒一次地寫入log file中,並且log file的flush(刷到磁碟)操作同時進行.該模式下,在事務提交的時候,不會主動觸發寫入磁碟的操作。如果innodb_flush_log_at_trx_commit設定為1,每次事務提交時MySQL都會把log buffer的資料寫入log file,並且flush(刷到磁碟)中去.
如果innodb_flush_log_at_trx_commit設定為2,每次事務提交時MySQL都會把log buffer的資料寫入log file.但是flush(刷到磁碟)操作並不會同時進行。該模式下,MySQL會每秒執行一次 flush(刷到磁碟)操作。
注意:
由於程式排程策略問題,這個“每秒執行一次 flush(刷到磁碟)操作”並不是保證100%的“每秒”。
sync_binlog
sync_binlog 的預設值是0,像作業系統刷其他檔案的機制一樣,MySQL不會同步到磁碟中去而是依賴作業系統來重新整理binary log。
當sync_binlog =N (N>0) ,MySQL 在每寫 N次 二進位制日誌binary log時,會使用fdatasync()函式將它的寫二進位制日誌binary log同步到磁碟中去。
注:
如果啟用了autocommit,那麼每一個語句statement就會有一次寫操作;否則每個事務對應一個寫操作。
根據上述描述,我做了一張圖,可以方便大家檢視。
二 效能
兩個引數在不同值時對db的純寫入的影響表現如下:
測試場景1
innodb_flush_log_at_trx_commit=2
sync_binlog=1000
測試場景2
innodb_flush_log_at_trx_commit=1
sync_binlog=1000
測試場景3
innodb_flush_log_at_trx_commit=1
sync_binlog=1
測試場景4
innodb_flush_log_at_trx_commit=1
sync_binlog=1000
測試場景5
innodb_flush_log_at_trx_commit=2
sync_binlog=1000
場景 | TPS |
場景1 | 41000 |
場景2 | 33000 |
場景3 | 26000 |
場景4 | 33000 |
由此可見,當兩個引數設定為雙1的時候,寫入效能最差,sync_binlog=N (N>1 ) innodb_flush_log_at_trx_commit=2 時,(在當前模式下)MySQL的寫操作才能達到最高效能。
三 安全
當innodb_flush_log_at_trx_commit和sync_binlog 都為 1 時是最安全的,在mysqld 服務崩潰或者伺服器主機crash的情況下,binary log 只有可能丟失最多一個語句或者一個事務。但是魚與熊掌不可兼得,雙11 會導致頻繁的io操作,因此該模式也是最慢的一種方式。
當innodb_flush_log_at_trx_commit設定為0,mysqld程式的崩潰會導致上一秒鐘所有事務資料的丟失。
當innodb_flush_log_at_trx_commit設定為2,只有在作業系統崩潰或者系統掉電的情況下,上一秒鐘所有事務資料才可能丟失。
當innodb_flush_log_at_trx_commit設定為2,只有在作業系統崩潰或者系統掉電的情況下,上一秒鐘所有事務資料才可能丟失。
雙1適合資料安全性要求非常高,而且磁碟IO寫能力足夠支援業務,比如訂單,交易,充值,支付消費系統。雙1模式下,當磁碟IO無法滿足業務需求時 比如11.11 活動的壓力。推薦的做法是 innodb_flush_log_at_trx_commit=2 ,sync_binlog=N (N為500 或1000) 且使用帶蓄電池後備電源的快取cache,防止系統斷電異常。
四 小結
系統效能和資料安全是業務系統高可用穩定的必要因素。我們對系統的優化需要尋找一個平衡點,合適的才是最好的,根據不同的業務場景需求,可以將兩個引數做組合調整,以便是db系統的效能達到最優化。
參考文章
如果您覺得從這篇文章受益,可以贊助 北在南方 一瓶飲料 ^_^
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29254281/viewspace-1143472/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【MySQL】五、sync_binlog innodb_flush_log_at_trx_commit 淺析MySqlMIT
- MySql(一) 淺析MySql索引MySql索引
- 【MySQL】八、double write 淺析.MySql
- MySQL事務原理淺析MySql
- 淺析MySQL replace into 的用法MySql
- MySql(四) InnoDB事務淺析MySql
- 淺析MySQL 8.0直方圖原理MySql直方圖
- mysql8.0插入慢之sync_binlog(一)MySql
- 淺析MySQL InnoDB的隔離級別MySql
- 技術分享 | MySQL : SSL 連線淺析MySql
- 淺析MySQL事務中的redo與undoMySql
- MySQL的共享鎖阻塞會話案例淺析MySql會話
- MySQL伺服器連線過程淺析MySql伺服器
- iOS Block淺淺析iOSBloC
- MySQL 查詢語句執行過程淺析MySql
- MyEclipse中連線MySQL的問題淺析ZPEclipseMySql
- MySQL效能最佳化淺析及線上案例MySql
- MySQL 備庫可以設定 sync_binlog 非 1 嗎?【轉】MySql
- RunLoop 淺析OOP
- 淺析 ReentrantLockReentrantLock
- Unstated淺析
- 淺析SharedPreferences
- Nginx淺析Nginx
- 淺析PromisePromise
- ejs 淺析JS
- 淺析KubernetesStatefulSet
- AIDL淺析AI
- MongoDB淺析MongoDB
- 淺析 JWTJWT
- 淺析RedisRedis
- Jvm 淺析JVM
- ArrayList淺析
- CGLib淺析CGLib
- 淺析XMLXML
- 淺析 DDD
- [玩轉MySQL之二]MySQL連線機制淺析及運維MySql運維
- 淺析Oracle(rownum)和Mysql(limit)分頁的區別OracleMySqlMIT
- 淺析MySQL語句優化中的explain引數MySql優化AI
- koa原理淺析