MySQL保證復(fù)制高可用的重要參數(shù)有哪些

這篇文章主要介紹MySQL保證復(fù)制高可用的重要參數(shù)有哪些，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

expire_logs_days ，binlog清理的時(shí)間。
從庫上relay-log-recovery = 1和relay-log-info-repository = TABLE; 保證了主從數(shù)據(jù)的一致性，不論從機(jī)怎么出錯(cuò)都能保證，主從一致。

為什么呢？
首先說SQL線程，SQL線程apply應(yīng)用二進(jìn)制日志，并且將binlog應(yīng)用到的位置記錄到relay-info.log中。

并且并不是relay log應(yīng)用一次就刷盤寫relay-log.info一次，而是一個(gè)參數(shù)指定，如下，意思是說回放events 10000次寫一次盤。這個(gè)就是為什么從庫crash了，出現(xiàn)1062錯(cuò)誤。因?yàn)閺膸煲呀?jīng)插入了數(shù)據(jù)，但是文件relay-log.info并沒有記錄文件，當(dāng)重啟后文件告訴數(shù)據(jù)庫還要執(zhí)行一次操作，就會(huì)出現(xiàn)這個(gè)主鍵重復(fù)插入的錯(cuò)誤。所以這個(gè)參數(shù)設(shè)置為table的，就滿足了一致性，避免了數(shù)據(jù)庫和文件的不同步問題。

IO線程：
和relay_log_info_repository不同的是，單單把master_info_repository設(shè)置成table是不能解決，備庫crash了，從IO線程接收日志的一致性問題，因?yàn)镮O線程接收日志寫的文件是relay log文件，而數(shù)據(jù)庫接收到主庫的日志到哪里寫的是master-info.log文件，(同步情況由sync_master_info決定)這是兩個(gè)不同的文件，比如當(dāng)relay接收到了日志，為event2，但是此時(shí)master-info.log記錄的是1，此時(shí)crash了，當(dāng)重新啟動(dòng)從庫時(shí)，master-info.log告訴數(shù)據(jù)庫我才接收到1，又重新接收了一次2，這樣就重復(fù)了，即便是master_info_repository設(shè)置成table一樣不解決問題。但是報(bào)錯(cuò)時(shí)，show slave status。最終作用到的都是SQL線程報(bào)錯(cuò)。所以還要設(shè)置另外一個(gè)參數(shù) relay-log-recovery=1



最后一個(gè)非常重要的參數(shù)：

把當(dāng)前接收到的relay log清理掉。然后從SQL Thread應(yīng)用到的位置，重新拉取relay log。

但是要保證主庫binlog要保留，保留時(shí)間要夠，因?yàn)槲乙娺^的有的公司主從延遲一個(gè)月之久。
還有read-only的設(shè)置，5.7有個(gè)新的權(quán)限super_read_only參數(shù)，設(shè)置為on，大家都沒有權(quán)限，dba也沒有。

SQL線程高可用

將SQL回放的位置寫到relay-info.log中，沒執(zhí)行到一個(gè)event，就寫一次這個(gè)文件，那么性能會(huì)不會(huì)很差啊？因?yàn)闆]有fsync所以文件記錄的會(huì)落后，將relay_log_info_repository=TABLE(5.6才有)，將這次造作放在數(shù)據(jù)庫，原子操作。（從庫配置）

寫10000個(gè)event才fsync一次寫盤，那么就有一問題，如果設(shè)置為1，有用嗎？沒用，有丟失一條記錄的可能。

sync_relay_log_info：這個(gè)參數(shù)和sync_relay_log參數(shù)一樣，當(dāng)設(shè)置為1時(shí)，slave的I/O線程每次接收到master發(fā)送過來的binlog日志都要寫入系統(tǒng)緩沖區(qū)，然后刷入relay-log.info里，這樣是最安全的，因?yàn)樵诒罎⒌臅r(shí)候，你最多會(huì)丟失一個(gè)事務(wù)，但會(huì)造成磁盤的大量I/O。當(dāng)設(shè)置為0時(shí)，并不是馬上就刷入relay-log.info里，而是由操作系統(tǒng)決定何時(shí)來寫入，雖然安全性降低了，但減少了大量的磁盤I/O操作。

IO線程的高可用

接收到一個(gè)event，寫master.log文件，表示接受到的位置，然后再去寫relay log file，這時(shí)候發(fā)送crash，又會(huì)有問題，同樣可以存表master_info_repository。

master log文件會(huì)落后，IO線程會(huì)重新拉master log文件中后的binlog，重復(fù)拉日志，SQL線程就報(bào)錯(cuò)了，最終錯(cuò)誤的顯示都是SQL線程。

Relay-log-recovery=1，將當(dāng)前接受到的所有relay log 清除掉。然后以SQL線程運(yùn)行到的位置重新拉取thread。SQL線程是可靠的，那么，還有什么問題呢？如果主庫上的二進(jìn)制日志沒有了，那么也來不過來了，就有問題了，即便是基于SQL線程。但是線上有落后很久的情形。

master_info_repository=TABLE 從開啟并行復(fù)制，也一定設(shè)置為table，性能有一倍的差距。

Read_only與super_read_only的區(qū)別，有super_priv權(quán)限的用戶設(shè)置read_only還是可以寫入的，

從庫super_read_only也打

以上是“MySQL保證復(fù)制高可用的重要參數(shù)有哪些”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！