innodb_flush_log_at_trx_commit和sync_binlog 兩個(gè)參數(shù)是控制MySQL磁盤寫入策略以及數(shù)據(jù)安全性的關(guān)鍵參數(shù)。
show variables like "innodb_flush_log_at_trx_commit";

innodb_flush_log_at_trx_commit:
0: 由mysql的main_thread每秒將存儲(chǔ)引擎log buffer中的redo日志寫入到log file,并調(diào)用文件系統(tǒng)的sync操作,將日志刷新到磁盤。
1:每次事務(wù)提交時(shí),將存儲(chǔ)引擎log buffer中的redo日志寫入到log file,并調(diào)用文件系統(tǒng)的sync操作,將日志刷新到磁盤。
2:每次事務(wù)提交時(shí),將存儲(chǔ)引擎log buffer中的redo日志寫入到log file,并由存儲(chǔ)引擎的main_thread 每秒將日志刷新到磁盤。
show variables like "sync_binlog";

sync_binlog:
0 :存儲(chǔ)引擎不進(jìn)行binlog的刷新到磁盤,而由操作系統(tǒng)的文件系統(tǒng)控制緩存刷新。
1:每提交一次事務(wù),存儲(chǔ)引擎調(diào)用文件系統(tǒng)的sync操作進(jìn)行一次緩存的刷新,這種方式最安全,但性能較低。
n:當(dāng)提交的日志組=n時(shí),存儲(chǔ)引擎調(diào)用文件系統(tǒng)的sync操作進(jìn)行一次緩存的刷新。
sync_binlog=0或sync_binlog大于1,事務(wù)被提交,而尚未同步到磁盤。因此,在電源故障或操作系統(tǒng)崩潰時(shí)有可能服務(wù)器已承諾尚未同步一些事務(wù)到二進(jìn)制日志。因此它是不可能執(zhí)行例行程序恢復(fù)這些事務(wù),他們將會(huì)丟失二進(jìn)制日志。
innodb_flush_log_at_trx_commit和sync_binlog 都為 1 時(shí)是最安全的,在mysqld 服務(wù)崩潰或者服務(wù)器主機(jī)crash的情況下,binary log 只有可能丟失最多一個(gè)語句或者一個(gè)事務(wù)。但是魚與熊掌不可兼得,雙1,1 會(huì)導(dǎo)致頻繁的io操作,因此該模式也是最慢的一種方式。
實(shí)際使用時(shí),要考慮業(yè)務(wù)方對性能和安全性的需求,綜合考量設(shè)置,兩個(gè)參數(shù)。上圖中是我們線上機(jī)器的參數(shù)。
以上就是如何區(qū)分MySQL的innodb_flush_log_at_trx_commit和sync_binlog的詳細(xì)內(nèi)容,更多關(guān)于MySQL的innodb_flush_log_at_trx_commit和sync_binlog的資料請關(guān)注腳本之家其它相關(guān)文章!
您可能感興趣的文章:- MySQL InnoDB架構(gòu)的相關(guān)總結(jié)
- MySQL InnoDB ReplicaSet(副本集)簡單介紹
- 詳解MySQL InnoDB存儲(chǔ)引擎的內(nèi)存管理
- MySQL Innodb關(guān)鍵特性之插入緩沖(insert buffer)
- MySQL InnoDB 鎖的相關(guān)總結(jié)
- Mysql InnoDB的鎖定機(jī)制實(shí)例詳解
- Mysql技術(shù)內(nèi)幕之InnoDB鎖的深入講解
- 修改MySQL數(shù)據(jù)庫引擎為InnoDB的操作
- 簡述MySQL InnoDB存儲(chǔ)引擎
- MySQL InnoDB表空間加密示例詳解
- MySQL InnoDB 事務(wù)鎖源碼分析