【MySQL】保證複製高可用的一些重要引數

expire_logs_day s ，binlog清理的時間。
從庫上relay-log-recovery = 1和relay-log-info-repository = TABLE; 保證了主從資料的一致性，不論從機怎麼出錯都能保證，主從一致。

為什麼呢？
首先說SQL執行緒，SQL執行緒apply應用二進位制日誌，並且將binlog應用到的位置記錄到relay-info.log中。

並且並不是relay log應用一次就刷盤寫relay-log.info一次，而是一個引數指定，如下，意思是說回放events 10000次寫一次盤。這個就是為什麼從庫crash了，出現1062錯誤。因為從庫已經插入了資料，但是檔案relay-log.info並沒有記錄檔案，當重啟後檔案告訴資料庫還要執行一次操作，就會出現這個主鍵重複插入的錯誤。所以這個引數設定為table的，就滿足了一致性，避免了資料庫和檔案的不同步問題。

IO執行緒：
和relay_log_info_repository不同的是，單單把master_info_repository設定成table是不能解決，備庫crash了，從IO執行緒接收日誌的一致性問題，因為IO執行緒接收日誌寫的檔案是relay log檔案，而資料庫接收到主庫的日誌到哪裡寫的是master-info.log檔案，(同步情況由sync_master_info決定)這是兩個不同的檔案，比如當relay接收到了日誌，為event2，但是此時master-info.log記錄的是1，此時crash了，當重新啟動從庫時，master-info.log告訴資料庫我才接收到1，又重新接收了一次2，這樣就重複了，即便是 master_info_repository設定成table一樣不解決問題。 但是報錯時，show slave status。最終作用到的都是SQL執行緒報錯。所以還要設定另外一個引數 relay-log-recovery=1



最後一個非常重要的引數：

把當前接收到的relay log清理掉。 然後從SQL Thread應用到的位置，重新拉取relay log。

但是要保證主庫binlog要保留，保留時間要夠，因為我見過的有的公司主從延遲一個月之久。
還有read-only的設定，5.7有個新的許可權super_read_only引數，設定為on，大家都沒有許可權，dba也沒有。

SQL 執行緒高可用

將 SQL 回放的位置寫到 relay-info.log 中，沒執行到一個 event ，就寫一次這個檔案，那麼效能會不會很差啊？因為沒有 fsync 所以檔案記錄的會落後，將 relay_log_info_repository=TABLE(5.6 才有 ) ，將這次造作放在資料庫，原子操作。（從庫配置）

寫10000個event才fsync一次寫盤，那麼就有一問題，如果設定為1，有用嗎？沒用，有丟失一條記錄的可能。

sync_relay_log_info：這個引數和sync_relay_log引數一樣，當設定為1時，slave的I/O執行緒每次接收到master傳送過來的binlog日誌都要寫入系統緩衝區，然後刷入relay-log.info裡，這樣是最安全的，因為在崩潰的時候，你最多會丟失一個事務，但會造成磁碟的大量I/O。當設定為0時，並不是馬上就刷入relay-log.info裡，而是由作業系統決定何時來寫入，雖然安全性降低了，但減少了大量的磁碟I/O操作。

IO 執行緒的高可用

 

接收到一個 event ，寫 master.log 檔案，表示接受到的位置，然後再去寫 relay log file ，這時候傳送 crash ，又會有問題，同樣可以存表 master_info_repository 。

 

master log 檔案會落後， IO 執行緒會重新拉 master log 檔案中後的 binlog ，重複拉日誌， SQL 執行緒就報錯了，最終錯誤的顯示都是 SQL 執行緒。

Relay-log-recovery=1 ，將當前接受到的所有 relay log 清除掉。然後以 SQL 執行緒執行到的位置重新拉取 thread 。 SQL 執行緒是可靠的，那麼，還有什麼問題呢？如果主庫上的二進位制日誌沒有了，那麼也來不過來了，就有問題了，即便是基於 SQL 執行緒。但是線上有落後很久的情形。

master_info_repository=TABLE 從開啟並行複製，也一定設定為 table ，效能有一倍的差距。

Read_only 與 super_read_only 的區別，有 super_priv 許可權的使用者設定 read_only 還是可以寫入的，

從庫 super_read_only 也打

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29990276/viewspace-2057301/，如需轉載，請註明出處，否則將追究法律責任。