FAQ系列 如何保證主從複製數據一致性

2021-02-28 老葉茶館
導讀

MySQL主從複製環境中,如何才能保證主從數據的一致性呢?

關於主從複製

現在常用的MySQL高可用方案,十有八九是基於 MySQL的主從複製(replication)來設計的,包括常規的一主一從、雙主模式,或者半同步複製(semi-sync replication)。

我們常常把MySQL replication說成是MySQL同步(sync),但事實上這個過程是異步(async)的。大概過程是這樣的:

在master上提交事務後,並且寫入binlog,返回事務成功標記;

將binlog發送到slave,轉儲成relay log;

在slave上再將relay log讀取出來應用。

步驟1和步驟3之間是異步進行的,無需等待確認各自的狀態,所以說MySQL replication是異步的。

MySQL semi-sync replication在之前的基礎上做了加強完善,整個流程變成了下面這樣:

首先,master和至少一個slave都要啟用semi-sync replication模式;

某個slave連接到master時,會主動告知當前自己是否處於semi-sync模式;

在master上提交事務後,寫入binlog後,還需要通知至少一個slave收到該事務,等待寫入relay log並成功刷新到磁碟後,向master發送「slave節點已完成該事務」確認通知;

master收到上述通知後,才可以真正完成該事務提交,返回事務成功標記;

在上述步驟中,當slave向master發送通知時間超過rpl_semi_sync_master_timeout設定值時,主從關係會從semi-sync模式自動調整成為傳統的異步複製模式。

半同步複製看起來很美好有木有呢,但如果網絡質量不高,是不是出現抖動,觸發上述第5條的情況,會從半同步複製降級為普通複製;此外,採用半同步複製,會導致master上的tps性能下降非常嚴重,最嚴重的情況下可能會損失50%以上。

這樣來看,除非需要非常嚴格保證數據一致性等迫不得已的場景,就不太建議使用半同步複製了。當然了,事實上我們也可以通過加強程序端的邏輯控制,來避免主從數據不一致時發生邏輯錯誤,比如說如果在從上讀取到的數據和主不一致的話,那麼就觸發主從間的一次數據修復工作。或者,我們也可以用 pt-table-checksum & pt-table-sync 兩個工具來校驗並修複數據,只要運行頻率適當,是可行的。

真想要提高多節點間的數據一致性,可以考慮採用PXC方案。現在已知用PXC規模較大的有qunar、sohu,如果團隊裡初期沒有人能比較專注PXC的話,還是要謹慎些,畢竟和傳統的主從複製差異很大,出現問題時需要花費更多精力去排查解決。

如何保證主從複製數據一致性

上面說完了異步複製、半同步複製、PXC,我們回到主題:在常規的主從複製場景裡,如何能保證主從數據的一致性,不要出現數據丟失等問題呢?

在MySQL中,一次事務提交後,需要寫undo、寫redo、寫binlog,寫數據文件等等。在這個過程中,可能在某個步驟發生crash,就有可能導致主從數據的不一致。為了避免這種情況,我們需要調整主從上面相關選項配置,確保即便發生crash了,也不能發生主從複製的數據丟失。

1. 在master上修改配置

innodb_flush_log_at_trx_commit = 1sync_binlog = 1

上述兩個選項的作用是:保證每次事務提交後,都能實時刷新到磁碟中,尤其是確保每次事務對應的binlog都能及時刷新到磁碟中,只要有了binlog,InnoDB就有辦法做數據恢復,不至於導致主從複製的數據丟失。

2. 在slave上修改配置

master_info_repository = "TABLE"relay_log_info_repository = "TABLE"relay_log_recovery = 1

上述前兩個選項的作用是:確保在slave上和複製相關的元數據表也採用InnoDB引擎,受到InnoDB事務安全的保護,而後一個選項的作用是開啟relay log自動修復機制,發生crash時,會自動判斷哪些relay log需要重新從master上抓取回來再次應用,以此避免部分數據丟失的可能性。

通過上面幾個選項的調整,就可以確保主從複製數據不會發生丟失了。但是,這並不能保證主從數據的絕對一致性,因為,有可能設置了ignore\do\rewrite等replication規則,或者某些SQL本身存在不確定因素,或者人為在slave上修改數據,最終導致主從數據不一致。這種情況下,可以採用pt-table-checksum 和 pt-table-sync 工具來進行數據的校驗和修復。

關於MySQL的方方面面大家想了解什麼,可以直接留言回復,我會從中選擇一些熱門話題進行分享。 同時希望大家多多轉發,多一些閱讀量是老葉繼續努力分享的絕佳助力,謝謝大家 :)

最後打個廣告,運維圈人士專屬鐵觀音茶葉微店上線了,訪問:http://yuhongli.com 獲得專屬優惠


相關焦點

  • 面試官:Redis 主從複製時網絡開小差了怎麼整?
    今天主要講的是主從複製數據一致性相關以及面對網絡中斷如何進行數據同步的問題。不 BB 了,直接上鍾吧!- 思維導圖 -主從模式配置對於 Redis 主從大家可能並不陌生,但是配置的話日常工作中並不會經常操作。在這裡簡單介紹下主從的相關配置。
  • redis學習筆記(四)主從數據同步
    在redis恢復數據時我們可以依賴於aof日誌或rdb日誌,但是redis在運行中該如何保證服務的可靠性,就需要依賴redis主從和哨兵集群
  • 冗餘數據一致性,到底如何保證?
    如何實施數據的冗餘,以及如何保證數據的一致性,是今天將要討論的內容。 二,如何進行數據冗餘(1)服務同步雙寫顧名思義,由服務層同步寫冗餘數據,如上圖1-4流程:業務方調用服務,新增數據服務先插入T1數據服務再插入T2數據服務返回業務方新增數據成功
  • UCloud高可用資料庫UDB主從複製延時的解決
    延時問題的重要性主從複製機制廣泛應用在UDB的內部實現中:UDB創建的從庫和主庫就採用了「主從複製」的數據複製;另外,UDB的主打產品「UDB MySQL高可用實例」,也是採用 2 個資料庫互為主從的「雙主模式」來進行數據複製,而雙主模式的核心就是主從複製機制。如果主從複製之間出現延時,就會影響主從數據的一致性。
  • zookeeper如何保證數據一致性?剖析Zap協議
    這種模式較為簡單,比較適合於單元測試、測試環境中採用,但是不能保證高可用性和恢復性。在生產環境中的ZooKeeper通常以"複製模式"(replicated mode)運行於一個計算機集群上,這個計算機集群被稱為一個"集合體"(ensemble)。
  • 如何實現redis主從複製?
    主從複製,主要優勢在於實現了數據備份(主機和從機數據同步一致)、讀寫分離(主機主要負責寫入數據,從機讀數據,在讀大於寫的項目中提高了性能)。最後也為後續集成哨兵機制和集群的實現提供了依據。一、多臺伺服器上配置主從複製Redis從5.0以後主從配置屬性發生了變化,在5.0之前配置的是slaveof,5.0以後變成了replicaof伺服器用途redis埠號備註centos7 192.168.1.6主機Master(寫)6379redis5.0centos7 192.168.1.4從機Slave(讀)6379redis5.0centos7 192.168.1.5
  • 驗證MySQL主從一致性(pt-table-checksum&pt-table-sync)
    percona-toolkit-2.2.8-1.noarch.rpm有兩個工具可以驗證MySQL主從數據的一致性安裝tookkit需要一些依賴包yum install perl perl-DBI perl-DBD-MySQL perl-IO-Socket-SSL perl-Time-HiRes -y實驗環境
  • MySQL 5.7基於GTID及多線程主從複製
    MySQL主從同步原理MySQL主從同步是在MySQL主從複製(Master-Slave
  • 面試被問MySQL 主從複製,怎麼破?
    此時,我們可以將資料庫擴展成主從複製模式,將讀操作和寫操作分離開來,多臺資料庫分攤請求,從而減少單庫的訪問壓力,進而應用得到優化。本次測試使用兩個虛擬機:ip:192.168.2.21(主) ip:192.168.2.22(從)二、主從複製原理同步操作通過 3 個線程實現,其基本步驟如下:主伺服器將數據的更新記錄到二進位日誌中(記錄被稱作二進位日誌事件)-- 主庫線程;從庫將主庫的二進位日誌複製到本地的中繼日誌(relay
  • 淺談Redis主從複製
    但Redis目前存在的一個問題是主從複製在遇到網絡不穩定的情況下,Slave和Master斷開(包括閃斷)會導致Master需要將內存中的數據全部重新生成rdb文件(快照文件),然後傳輸給Slave。Slave接收完Master傳遞過來的rdb文件以後會將自身的內存清空,把rdb文件重新加載到內存中。
  • 面試系列 - Redis 持久化和主從複製總結(二)
    yes #是否壓縮,主從複製會非常快,建議yes rdbchecksum yes #默認對RDB文件進行校驗,建議yes,系統才會真正複製一份專用副本給該調用者,而其他調用者所見到的最初的資源仍然保持不變);全量複製:當設置了主從模式時,Redis 會在複製初始化時進行自動快照,若關閉 RDB 存儲模式,也會在初始主從複製時進行一次 RDB 存儲;debug reload:提供 debug 級別的重啟,不清空內存的一種重啟
  • 主從哨兵集群終於給你說明白了
    Redis有三種集群模式,第一個就是主從模式,第二種「哨兵」模式,第三種是 Cluster 集群模式。今天就和大家細細聊聊這三種模式。主從複製當其中一臺伺服器更新之後,伺服器會自動的將這臺更新的數據同步到另外一臺伺服器上。通過持久化的功能,redis可以保證就算是服務宕機重啟了,也只有少量的數據會丟失。
  • [MySQL FAQ]系列 — 5.6版本GTID複製異常處理一例
    正常滴,在MySQL 5.6啟用GTID後,部署REPLICATION複製時,可以設定 MASTER_AUTO_POSITION = 1,讓 SLAVE 根據 GTID 自動選擇適當的事務點進行複製,DBA基本上無需關注和擔心主從不一致的問題,還是很讓DBA省心的。
  • Raft實戰(番外篇)—— 線性一致性介紹
    很多讀者對「線性一致性」存在誤解,為幫助大家更好的理解先詳細介紹下其概念。系列快速連結:在前面5篇文章中,我們分別介紹了 Raft 基本概念、Raft 選主機制、Raft 基於日誌複製實現狀態機機制、Raft 選主及狀態機維護的安全性、Raft 集群變更防腦裂 & 解決數據膨脹,系統學習 Raft 建議從頭閱讀。
  • Docker搭建MySQL主從複製(一主一從)
    3、開啟Master-Slave主從複製上面兩步Master和Slave都配置成功了,而且Master也為Slave讀取Master數據專門設置了一個帳號,下面就來實現同步。show slave status命令從這張圖很明顯看出,對於Slave的兩個線程都成功了,那就說明整個MYSQL主從搭建成功了。如果有一個為NO,那就需要到後面看錯誤日誌,是什麼原因出錯了,解決下就好了。
  • 一文講透微服務架構下如何保證事務的一致性
    而微服務架構是將單個服務拆分成一系列小服務,且這些小服務都擁有獨立的進程,彼此獨立,很好地解決了傳統單體應用的上述問題,但是在微服務架構下如何保證事務的一致性呢?本文作者將為大家詳細解答。從本地事務到分布式事務的演變什麼是事務?回答這個問題之前,我們先來看一個經典的場景:支付寶等交易平臺的轉帳。
  • 面試必備:什麼是一致性Hash算法?
    一、Redis集群的使用我們在使用Redis的時候,為了保證Redis的高可用,提高Redis的讀寫性能,最簡單的方式我們會做主從複製,組成Master-Master或者Master-Slave的形式,或者搭建Redis集群,進行數據的讀寫分離,類似於資料庫的主從複製和讀寫分離。
  • MySQL主從複製高級進階
    本文介紹MySQL主從複製高級進階。延時從庫介紹及配置SQL線程延時:數據已經寫入relaylog中了,SQL線程稍後執行。一般企業建議3-6小時,具體看公司運維人員對於故障的反應時間執行之前在需要先stop slave,否則會報錯,無法執行;stop slave;設置master_delay並重新開啟複製start slave後,,MySQL從庫會清空原有的relay log
  • Redis緩存與資料庫數據一致性
    無論步驟1.1是否刪除成功,後續的刷新操作是有保證的。缺點:只適合簡單業務(每次需要刷新的數據,都來自單表單行),複雜業務容易發生並發問題。為什麼複雜業務就不行呢?缺點1的改進針對單庫多表單次更新的改進:利用事務當AB表的更新發生在一個事務內時,不管線程1、線程2如何讀取,他們都能獲取兩張表的最新數據,所以刷新緩存的數據都是符合要求的。
  • 高性能Mysql主從架構的複製原理及配置詳解
    複製解決的問題MySQL複製技術有以下一些特點:數據分布 (Data distribution )負載平衡(load balancing)備份(Backups)高可用性和容錯行 High availability and failover複製如何工作整體上來說,複製有3個步驟:master將改變記錄到二進位日誌(binary log)中(這些記錄叫做二進位日誌事件