【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/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- MySQL怎麼保證高可用MySql
- MySQL 同步複製及高可用方案總結MySql
- MySQL 5.7 複製的過濾引數MySql
- MySQL進階:主主複製+Keepalived高可用MySql
- MySQL主主複製+MMM實現高可用(一)MySql
- MySQL主主複製+Keepalived打造高可用MySQL叢集MySql
- MySQL高可用之組複製技術(3):配置多主模型的組複製MySql模型
- MySQL高可用之組複製技術(2):配置單主模型的組複製MySql模型
- mysql5.6主主複製及keepalived 高可用MySql
- mysql主主複製+keepalived 打造高可用mysql叢集薦MySql
- MySQL高可用方案的一些思考MySql
- MySQL主主複製+slave+MMM實現高可用(二)MySql
- Mysql重要配置引數的整理MySql
- MySQL高可用工具Orchestrator系列二:複製拓撲的發現MySql
- 二、如何保證訊息佇列的高可用?佇列
- [轉]使用複製來提升MySQL的高可用性和處理能力MySql
- 【Mysql】MySQL 主主複製 + LVS + Keepalived 實現 MySQL 高可用性MySql
- MySQL主從複製結構中常用引數MySql
- 微服務9:服務治理來保證高可用微服務
- 面試題剖析,如何保證訊息佇列的高可用?面試題佇列
- 海量資料架構下如何保證Mycat的高可用?架構
- 分散式服務高可用實現:複製分散式
- MySQL 的主從複製(高階篇)MySql
- 雲網路對等連線產品的高可用保證
- MySQL主從複製配置引數 -- logs-slave-updatesMySql
- 關於redis的幾件小事(五)redis保證高併發以及高可用Redis
- mysql一些引數的介紹MySql
- MySQL高可用方案MHA的一些總結和思考MySql
- MySQL 複製全解析 Part10 基於GTID的MySQL複製的一些限制MySql
- oracle goldengate 雙活複製避免迴圈複製引數OracleGo
- 關於高階複製的一些資料同步
- MySQL中Redo Log相關的重要引數總結MySql
- MySQL的主從複製與MySQL的主主複製MySql
- 非同步流複製模式如何保證不丟資料?非同步模式
- 關於MQ的幾件小事(二)如何保證訊息佇列的高可用MQ佇列
- 【中介軟體】Redis 實戰之主從複製、高可用、分散式Redis分散式
- java函式陣列引數的複製問題Java函式陣列
- PostgreSQL基於PG內建流複製的,靠譜的PostgreSQL高可用方案SQL