redo log的寫入策略

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

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

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

binlog的寫入策略

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

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

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

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

生產(chǎn)配置

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

性能瓶頸

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

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

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

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

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

最新評(píng)論