同步复制与异步复制
主從復制:其中一種設計,包括一個同步的從節點,和一個異步的從節點。
從節點2在接收復制日志之前有一段很長的延遲。通常情況下,復制速度會非常快,例如多數數據庫系統可以在一秒之內完成所有從節點的更新。但是,系統其實并沒有保證一定會在多長時間內完成復制。有些情況下,從節點可能落后主節點幾分鐘甚至更長時間,例如,由于從節點剛從故障中恢復,或者系統已經接近最大設計上限,或者節點之間的網絡出現問題。
同步復制的優點是:一旦向用戶確認,從節點可以明確保證完成了與主節點的更新同步,數據已經處于最新版本。萬一主節點發生故障,總是可以在從節點繼續訪問最新數據。缺點則是:如果同步的從節點無法完成確認(例如:由于從節點發生崩潰,或者網絡故障,或任何其他原因),寫入就不能視為成功。主節點會阻塞其后所有的寫操作,直到同步副本確認已完成。
因此,把所有從節點都配置為同步復制有些不切實際。因為這樣子的話,任何一個同步節點的中斷都會導致整個系統更新停滯不前。**實踐中,如果數據庫啟用了同步復制,通常意味著其中某一個從節點是同步的,而其他節點這是異步模式。**萬一同步的從節點變得不可用或性能下降,則將另一個異步的從節點提升為同步模式。這樣可以保證至少有兩個節點(即主節點和一個同步從節點)擁有最新的數據副本。這種配置有時候也叫做半同步。
主從復制還經常會被配置為全異步模式。此時如果主節點發生失敗且不可恢復,則所有尚未復制到從節點的寫請求都會丟失。這意味著即使向客戶端確認了寫操作,卻無法保證數據的持久化。但是全異步配置的優點則是,不管從節點上數據多么滯后,主節點總是可以繼續響應寫請求,系統的吞吐性能更好、
異步模式這種弱化的持久性聽起來是一個非常不靠譜的折中設計,但是異步復制還是被廣泛使用,特別是那些從節點數量巨大或者分布于廣域地理環境。我們常見的問題,會有復制滯后問題
配置新的從節點:
當如果出現以下情況下,如需要增加副本數以提高容錯能力,或者替換失敗的副本,就需要考慮增加新的從節點。但是如何確保新的從節點和主節點保持數據一致呢?
簡單地將數據文件從一個節點復制到另一個節點通常是不夠的,主要是因為客戶端仍在不斷得向數據庫寫入新數據,數據始終處于不斷變化之中,因此常規的文件拷貝方式將會導致不同節點上呈現出不同時間點的數據,這不是我們所期待的。
或許應該考慮鎖定數據庫(使其不可寫)來使磁盤上的文件保持一致,但是這會違反高可用的設計目標。好在我們可以做到在不停機,數據服務不中斷的前提下完成從節點的設置。邏輯上的主要操作步驟如下:
從節點失效:追趕式恢復
主節點失效:節點切換
上述這些問題,包括節點失效,網絡不可靠,副本一致性,持久性,可用性與延遲之間各種細微的權衡,實際上正是分布式系統核心的基本問題。
基于行的邏輯日志復制 mySql
另一種方法就是復制和存儲引擎采用不同的日志格式,這樣復制與存儲邏輯剝離,這種復制日志稱為邏輯日志,用來區分物理存儲引擎的數據表示。
關系型數據庫的邏輯日志通常是指一系列記錄來描述數據表行級別的寫請求:
主鍵,就需要記錄所有列的舊值
3.對于行更新,日志包含足夠的信息來唯一表示更新的行,以及所有列的新值(或者至少包含所有已經更新列的新值)
如果一條事務設計多行的修改,則會產生多個這樣的日志記錄,并在后面跟著一條記錄,指出該事務已經提交。Mysql的二進制日志binlog(當配置為基于行的復制時)使用該方式。
從節點最終會趕上并且與主節點保持一致,這種效應也被稱為最終一致性。正常情況下,主節點和從節點上完成寫操作之間的時間延遲(復制滯后)可能不足1秒,這樣子的滯后,在實踐中中通常不會導致太大的影響。但是,如果系統已經接近設計上線,或者網絡存在問題,則滯后可能輕松增加到幾秒甚至幾分鐘不等。
離線客戶端操作:
另一種多主復制比較適合的場景是:應用在于網絡斷開后還需要繼續工作。
總結
- 上一篇: 写了一个3D彩票软件!
- 下一篇: 初识IndexedDB本地存储