Mysql數(shù)據(jù)庫(kù)中的redo?log?寫(xiě)入策略和binlog?寫(xiě)入策略
redo log的寫(xiě)入策略
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直接持久化到磁盤(pán); - 設(shè)置為
2的時(shí)候,表示每次事務(wù)提交時(shí)都只是把redo log寫(xiě)到page cache。
查看mysql變量:show VARIABLES LIKE 'innodb_flush_log_at_trx_commit'
binlog的寫(xiě)入策略
binlog的寫(xiě)入策略,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瓶頸的場(chǎng)景里,將sync_binlog設(shè)置成一個(gè)比較大的值,可以提升性能。在實(shí)際的業(yè)務(wù)場(chǎng)景中,考慮到丟失日志量的可控性,一般不建議將這個(gè)參數(shù)設(shè)成0,比較常見(jiàn)的是將其設(shè)置為100~1000中的某個(gè)數(shù)值。
但是,將sync_binlog設(shè)置為N,對(duì)應(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,也就是說(shuō),一個(gè)事務(wù)完整提交前,需要等待兩次刷盤(pán),一次是redo log,一次是binlog。
性能瓶頸
如果你的MySQL現(xiàn)在出現(xiàn)了性能瓶頸,而且瓶頸在IO上,可以通過(guò)哪些方法來(lái)提升性能呢?
針對(duì)這個(gè)問(wèn)題,可以考慮以下三種方法:
- 設(shè)置
binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count參數(shù),減少binlog的寫(xiě)盤(pán)次數(shù)。這個(gè)方法是基于“額外的故意等待”來(lái)實(shí)現(xiàn)的,因此可能會(huì)增加語(yǔ)句的響應(yīng)時(shí)間,但沒(méi)有丟失數(shù)據(jù)的風(fēng)險(xiǎn)。 - 將
sync_binlog設(shè)置為大于1的值(比較常見(jiàn)是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寫(xiě)到文件系統(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 寫(xiě)入策略和binlog 寫(xiě)入策略的文章就介紹到這了,更多相關(guān)Mysq寫(xiě)入策略內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
MySQL數(shù)據(jù)庫(kù)配置優(yōu)化的方案
我們總是希望MySQL能夠獲得更高的查詢性能,最好的辦法是弄清楚MySQL是如何優(yōu)化和執(zhí)行查詢的。本文講解MySQL在各個(gè)方面的優(yōu)化方向,方便后端開(kāi)發(fā)人員在調(diào)優(yōu)和問(wèn)題排查過(guò)程中找到切入點(diǎn)2023-02-02
mysql查詢上下級(jí)機(jī)構(gòu)的方法實(shí)例
大家應(yīng)該都知道表里有上下級(jí)機(jī)構(gòu)的,下面這篇文章主要給大家介紹了關(guān)于mysql查詢上下級(jí)機(jī)構(gòu)的相關(guān)資料,文中通過(guò)實(shí)例代碼介紹的非常詳細(xì),需要的朋友可以參考下2022-04-04
MySql存儲(chǔ)表情報(bào)錯(cuò)的排查解決
隨著互聯(lián)網(wǎng)的發(fā)展,產(chǎn)生了許多新類(lèi)型的字符,例如emoji這種類(lèi)型的符號(hào),也就是我們通常在聊天時(shí)發(fā)的小黃臉表情,下面這篇文章主要給大家介紹了關(guān)于MySql存儲(chǔ)表情報(bào)錯(cuò)的排查解決,需要的朋友可以參考下2022-07-07
MySQL實(shí)現(xiàn)查詢某個(gè)字段含有字母數(shù)字的值
這篇文章主要介紹了MySQL實(shí)現(xiàn)查詢某個(gè)字段含有字母數(shù)字的值方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2024-07-07
ERROR 1222 (21000): The used SELECT statements have a differ
常用的SQL例句 數(shù)據(jù)庫(kù)開(kāi)發(fā)所需知識(shí)

