redo log的寫入策略

InnoDB提供了innodb_flush_log_at_trx_commit參數(shù)，它有三種可能取值：

• 設(shè)置為0的時候，表示每次事務(wù)提交時都只是把redo log留在redo log buffer中;
• 設(shè)置為1的時候，表示每次事務(wù)提交時都將redo log直接持久化到磁盤；
• 設(shè)置為2的時候，表示每次事務(wù)提交時都只是把redo log寫到page cache。

查看mysql變量：show VARIABLES LIKE 'innodb_flush_log_at_trx_commit'

binlog的寫入策略

binlog的寫入策略，write 和fsync的時機，是由參數(shù)sync_binlog控制的：

• sync_binlog=0的時候，表示每次提交事務(wù)都只write，不fsync；
• sync_binlog=1的時候，表示每次提交事務(wù)都會執(zhí)行fsync；
• sync_binlog=N(N>1)的時候，表示每次提交事務(wù)都write，但累積N個事務(wù)后才fsync。

因此，在出現(xiàn)IO瓶頸的場景里，將sync_binlog設(shè)置成一個比較大的值，可以提升性能。在實際的業(yè)務(wù)場景中，考慮到丟失日志量的可控性，一般不建議將這個參數(shù)設(shè)成0，比較常見的是將其設(shè)置為100~1000中的某個數(shù)值。

但是，將sync_binlog設(shè)置為N，對應(yīng)的風(fēng)險是：如果主機發(fā)生異常重啟，會丟失最近N個事務(wù)的binlog日志。

生產(chǎn)配置

通常情況下，生產(chǎn)都是" 雙1 "的配置，也就是sync_binlog 和 innodb_flush_log_at_trx_commit 的配置都是1，也就是說，一個事務(wù)完整提交前，需要等待兩次刷盤，一次是redo log，一次是binlog。

性能瓶頸

如果你的MySQL現(xiàn)在出現(xiàn)了性能瓶頸，而且瓶頸在IO上，可以通過哪些方法來提升性能呢？

針對這個問題，可以考慮以下三種方法：

• 設(shè)置 binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count參數(shù)，減少binlog的寫盤次數(shù)。這個方法是基于“額外的故意等待”來實現(xiàn)的，因此可能會增加語句的響應(yīng)時間，但沒有丟失數(shù)據(jù)的風(fēng)險。
• 將sync_binlog 設(shè)置為大于1的值（比較常見是100~1000）。這樣做的風(fēng)險是，主機掉電時會丟binlog日志。
• 將innodb_flush_log_at_trx_commit設(shè)置為2。這樣做的風(fēng)險是，主機掉電的時候會丟數(shù)據(jù)。

我不建議你把innodb_flush_log_at_trx_commit 設(shè)置成0。因為把這個參數(shù)設(shè)置成0，表示redo log只保存在內(nèi)存中，這樣的話MySQL本身異常重啟也會丟數(shù)據(jù)，風(fēng)險太大。而redo log寫到文件系統(tǒng)的page cache的速度也是很快的，所以將這個參數(shù)設(shè)置成2跟設(shè)置成0其實性能差不多，但這樣做MySQL異常重啟時就不會丟數(shù)據(jù)了，相比之下風(fēng)險會更小。

到此這篇關(guān)于Mysql redo log 寫入策略和binlog 寫入策略的文章就介紹到這了,更多相關(guān)Mysq寫入策略內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論