什么是主從復(fù)制

這篇文章給大家介紹什么是主從復(fù)制，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

復(fù)制的方式

在集群中實(shí)現(xiàn)復(fù)制主要通過(guò)兩種方式：

• 狀態(tài)轉(zhuǎn)移(State Transfer)：主機(jī)(Primary)將自己所有的狀態(tài)，拷貝并發(fā)送給備機(jī)(Backup)，一般是增量備份;

• 復(fù)制狀態(tài)機(jī)(Replicated State Machine)：將備機(jī)視為一個(gè)確定的狀態(tài)機(jī)——client  發(fā)送操作到主機(jī)，主機(jī)按順序發(fā)送到備機(jī)，所有備機(jī)執(zhí)行所有的操作，如果從同一起始狀態(tài)，以相同的順序輸入相同的操作，它們的輸出將是相同的。

VMware FT 使用了復(fù)制狀態(tài)機(jī)的方法。

狀態(tài)轉(zhuǎn)移傳輸?shù)目赡苁莾?nèi)存，而復(fù)制狀態(tài)機(jī)傳輸來(lái)自客戶端的操作或者其他外部事件，人們傾向于使用復(fù)制狀態(tài)機(jī)的原因是，外部操作或事件通常比服務(wù)的內(nèi)存狀態(tài)要小。例如，如果是一個(gè)數(shù)據(jù)庫(kù)，它的內(nèi)存狀態(tài)可能達(dá)到  GB 級(jí)別。

復(fù)制的挑戰(zhàn)

要考慮的幾個(gè) Big Question：

• 我們要復(fù)制哪些狀態(tài)?

• 主機(jī)必須等待備機(jī)備份完嗎?

• 什么時(shí)候切換到備機(jī)?

• 切換時(shí)能否看到異常情況?

• 如果有個(gè)副本故障了，我們需要重新添加一個(gè)新的副本，這可能是一個(gè)代價(jià)很高的行為，因?yàn)楦北究赡芊浅４?，如何提升添加新副本的速?

讓我們看看虛擬化巨頭 VMware 是怎么做的。

VMware FT 論文總結(jié)

總覽

如圖 1，約定：主虛擬機(jī)(Primary VM)簡(jiǎn)稱為主機(jī)，Backup VM 簡(jiǎn)稱為備機(jī)。

VMware FT 需要兩臺(tái)物理服務(wù)器，主機(jī)與備機(jī)保持同步，虛擬機(jī)的虛擬磁盤(pán)在共享存儲(chǔ)上。

所有的輸入(如網(wǎng)絡(luò)、鼠標(biāo)、鍵盤(pán)等)都會(huì)輸入到主機(jī)，然后通過(guò) Logging channel  轉(zhuǎn)發(fā)到備機(jī)，對(duì)于非確定性的操作，還將發(fā)送額外的信息，確保備機(jī)以確定性的方式執(zhí)行這些操作。

兩臺(tái)虛擬機(jī)都會(huì)執(zhí)行輸入操作，但只有主機(jī)的輸出會(huì)返回客戶端，備機(jī)的輸出會(huì)被管理程序丟棄。

確定性重放(Deterministic replay)

不確定性(Non-Deterministic)事件比如虛擬中斷，不確定性操作比如從處理器讀取時(shí)鐘周期計(jì)數(shù)器，可能會(huì)讓主機(jī)和備機(jī)的運(yùn)行結(jié)果不一樣。

這帶來(lái)三個(gè)挑戰(zhàn)：

• 正確捕獲所有輸入和必要的不確定性輸入來(lái)保證備機(jī)確定性執(zhí)行;

• 正確在備機(jī)執(zhí)行不確定性輸入;

• 不降低系統(tǒng)的性能;

VMware 確定性重放(deterministic  replay)能夠捕獲所有輸入和可能的不確定性輸入，并寫(xiě)到日志文件記錄下來(lái)。通過(guò)讀取日志文件，可以準(zhǔn)確重放虛擬機(jī)的執(zhí)行。

對(duì)于不確定性輸入，必須記錄足夠的信息來(lái)重放，但是論文中沒(méi)有描述具體的日志格式，Robert 教授猜測(cè)可能有三種記錄：

事件發(fā)生時(shí)的指令序號(hào);

日志類型?？赡苁瞧胀ǖ木W(wǎng)絡(luò)數(shù)據(jù)輸入，也可能是怪異的指令;

數(shù)據(jù)。

FT 協(xié)議(FT Protocol)

VMware FT 通過(guò)確定性重放來(lái)產(chǎn)生相關(guān)的日志條目，但不將日志寫(xiě)入磁盤(pán)，而是通過(guò) logging channel  發(fā)送給備機(jī)。備機(jī)實(shí)時(shí)重放日志項(xiàng)。

為了容錯(cuò)，必須在 loggin channel 上實(shí)現(xiàn)嚴(yán)格的容錯(cuò)協(xié)議，有以下要求：

輸出要求：如果備機(jī)在主機(jī)故障后接管，備機(jī)將以和主機(jī)已經(jīng)向外界發(fā)送的輸出完全一致的方式繼續(xù)運(yùn)行。

最簡(jiǎn)單的方式是對(duì)每一個(gè)輸出操作創(chuàng)建一個(gè)特殊的日志項(xiàng)。

但有一種情況，假設(shè)虛擬機(jī)運(yùn)行的是數(shù)據(jù)庫(kù)，主機(jī)備機(jī)的數(shù)據(jù)都是 10。現(xiàn)在客戶端發(fā)送自增請(qǐng)求，主機(jī)做了 +1 并回復(fù)給客戶端  11，之后馬上宕機(jī)了，更糟糕的是主機(jī)發(fā)送給備機(jī)的 +1 操作也丟包了。這時(shí)候備機(jī)還是 10，并接管了主機(jī)的工作，客戶端再次請(qǐng)求 +1，又會(huì)收到 11  的回復(fù)?？蛻舳藭?huì)得到一個(gè)怪異的結(jié)果(自增兩次還是 11)。

所以要求：

輸出規(guī)則：主機(jī)直到備機(jī)接收并確認(rèn)了和輸出相關(guān)的日志的時(shí)候，才發(fā)送輸出給外界。

這樣做的目的是，只要備機(jī)收到了所有的日志條目，即使主機(jī)宕機(jī)了，備機(jī)仍能夠重放到客戶端最后看到的狀態(tài)。

如圖 2 所示，向外界的輸出會(huì)被延遲，直到主機(jī)收到來(lái)自備機(jī)的確認(rèn)。

幾乎每一個(gè)復(fù)制系統(tǒng)都有這個(gè)問(wèn)題：在某個(gè)時(shí)間點(diǎn)，主機(jī)必須停下來(lái)等待備機(jī)，這肯定會(huì)限制性能。

注意：因?yàn)闆](méi)有兩階段提交事務(wù)，不能保證所有的輸出只被生成一次。備機(jī)無(wú)法判斷主機(jī)是在宕機(jī)之前還是之后發(fā)送了最后的輸出，備機(jī)可能會(huì)重新執(zhí)行一次輸出操作。不過(guò)，VMware  通過(guò)其網(wǎng)絡(luò)基礎(chǔ)設(shè)施來(lái)檢測(cè)重復(fù)數(shù)據(jù)包，并防止輸出重傳到客戶端。

發(fā)現(xiàn)與處理故障

主機(jī)和備機(jī)必須快速知道另一方故障，通過(guò) udp 心跳包和監(jiān)控 logging channel 上的流量相結(jié)合來(lái)檢測(cè)，如果心跳超時(shí)或 logging  channel 流量停止則表明故障。

如果備機(jī)故障，主機(jī)就會(huì)停止向 logging channel 發(fā)送日志，繼續(xù)正常運(yùn)行。

在這之后備機(jī)怎么追上主機(jī)呢?VMware有一個(gè)工具叫 VMotion，它能夠在最小程度上中斷虛擬機(jī)的執(zhí)行，克隆一個(gè)虛擬機(jī)。

如果主機(jī)故障，備機(jī)必須先重放，直到消耗完最后一個(gè)日志項(xiàng)。然后備機(jī)接替主機(jī)，開(kāi)始向客戶端生產(chǎn)輸出。

為了確保一次只有一個(gè)虛擬機(jī)成為主機(jī)，避免出現(xiàn)腦裂，VMware 在共享存儲(chǔ)上執(zhí)行一個(gè)原子的 test-and-set  鎖指令。該操作每次只能對(duì)其中一臺(tái)機(jī)器返回成功，這在主機(jī)和備機(jī)因?yàn)榫W(wǎng)絡(luò)分區(qū)都想接替工作時(shí)很有用。但如果共享存儲(chǔ)因?yàn)榫W(wǎng)絡(luò)問(wèn)題不能訪問(wèn)，那么無(wú)論如何都不能正常工作。

當(dāng)其中一臺(tái)虛擬機(jī)發(fā)生故障時(shí)，VMware FT 會(huì)在另一臺(tái)物理機(jī)上自動(dòng)啟動(dòng)新的備份虛擬機(jī)來(lái)恢復(fù)冗余。

FT 的實(shí)際實(shí)現(xiàn)細(xì)節(jié)

上一節(jié)描述了容錯(cuò)的基礎(chǔ)設(shè)計(jì)和協(xié)議，但為了創(chuàng)建一個(gè)可用的、健壯的自動(dòng)化系統(tǒng)，還需要設(shè)計(jì)和實(shí)現(xiàn)許多其他組件。

啟動(dòng)和重啟 FT VMs

一個(gè)挑戰(zhàn)是，如何在主機(jī)運(yùn)行時(shí)，以和主機(jī)相同的狀態(tài)啟動(dòng)備機(jī)?為了解決這個(gè)問(wèn)題，VMware 提供一個(gè)名為 VMware VMotion  的工具，允許在最小化中斷的代價(jià)下，將運(yùn)行中的虛擬機(jī)從一臺(tái)服務(wù)器遷移到另一臺(tái)服務(wù)器。為了容錯(cuò)，該工具被重新設(shè)計(jì)為 FT  VMotion，以允許將虛擬機(jī)克隆到遠(yuǎn)程主機(jī)上，這種克隆操作打斷主機(jī)的時(shí)間不超過(guò) 1 秒。

管理 Logging Channel

上圖 3 說(shuō)明了日志從主機(jī)產(chǎn)生到在備機(jī)上消費(fèi)的過(guò)程。

虛擬機(jī)管理程序維護(hù)了一個(gè)大的日志緩沖(log buffer)，保存主機(jī)和備機(jī)的日志。主機(jī)會(huì)產(chǎn)生日志項(xiàng)到日志緩沖，備機(jī)從日志緩沖消費(fèi)日志。

如果備機(jī)讀到空的日志緩沖，則會(huì)暫停運(yùn)行直到日志緩沖有日志;如果主機(jī)寫(xiě)日志的時(shí)候發(fā)現(xiàn)日志緩沖滿了，也會(huì)暫停運(yùn)行直到日志項(xiàng)被清除——這種暫停會(huì)影響虛擬機(jī)的客戶端。因此，我們的實(shí)現(xiàn)必須最小化主機(jī)日志緩沖寫(xiě)滿的可能性。

通常，主機(jī)日志緩沖滿的原因：

• 帶寬太小，建議日志通道帶寬 1Gbit/s;

• 備機(jī)執(zhí)行速度太慢，從而消費(fèi)日志太慢時(shí)，主機(jī)的日志緩沖也可能會(huì)被填滿;

在 VMware FT 中已經(jīng)實(shí)現(xiàn)了一種機(jī)制，當(dāng)備機(jī)遠(yuǎn)遠(yuǎn)落后時(shí)(根據(jù)論文中的說(shuō)法，落后超過(guò)1秒)，可以減緩主機(jī)的執(zhí)行速度。通過(guò)減少主機(jī)的 CPU  資源來(lái)減慢速度。

注意對(duì)于主機(jī)的減速是很罕見(jiàn)的，通常只在系統(tǒng)處于極端壓力的情況下發(fā)生。

磁盤(pán) IO 實(shí)現(xiàn)問(wèn)題

有一些和磁盤(pán) IO 相關(guān)的細(xì)微的實(shí)現(xiàn)問(wèn)題。

問(wèn)題 1：非阻塞的磁盤(pán)操作可以并行執(zhí)行，因此對(duì)同一磁盤(pán)位置的同時(shí)訪問(wèn)可能導(dǎo)致不確定性。

解決方案：檢測(cè)所有這類 IO 競(jìng)爭(zhēng)，然后強(qiáng)制這些競(jìng)爭(zhēng)的磁盤(pán)操作以相同的方式在主機(jī)和備機(jī)上順序執(zhí)行。

怎么檢測(cè)?論文也沒(méi)說(shuō)。

問(wèn)題 2：虛擬機(jī)上的應(yīng)用程序(或操作系統(tǒng))的磁盤(pán)操作也可能導(dǎo)致內(nèi)存的競(jìng)爭(zhēng)

解決方案：通過(guò) Bounce buffer—— 一個(gè)和磁盤(pán)操作正在訪問(wèn)的內(nèi)存大小一致的臨時(shí)緩沖來(lái)解決。磁盤(pán)讀操作被修改為在 bounce buffer  中讀取特定數(shù)據(jù)，并且數(shù)據(jù)僅在IO操作完成并傳遞完成的時(shí)候拷貝到虛擬機(jī)內(nèi)存。類似的，對(duì)于磁盤(pán)寫(xiě)操作，將要被發(fā)送的數(shù)據(jù)會(huì)先拷貝到 bounce  buffer，磁盤(pán)寫(xiě)操作修改為寫(xiě)數(shù)據(jù)到 bounce buffer。

Bounce buffer 的使用會(huì)減慢磁盤(pán)操作，但是論文表示還沒(méi)有看到任何明顯的性能差異。

問(wèn)題3：磁盤(pán) IO 因主機(jī)故障在主機(jī)上沒(méi)有完成，備份接管后怎么辦?

解決方案：發(fā)送錯(cuò)誤來(lái)表明 IO 失敗，然后重試錯(cuò)誤的 IO。

替代方案

本節(jié)討論一些替代方案，以及他們所做的權(quán)衡。

共享磁盤(pán)與非共享磁盤(pán)：VMware FT  使用了一個(gè)主備機(jī)都能訪問(wèn)的共享存儲(chǔ)。一個(gè)替代方案是使用單獨(dú)(非共享)的虛擬磁盤(pán)，主備機(jī)分別寫(xiě)入這些磁盤(pán)。這種設(shè)計(jì)可以用在共享存儲(chǔ)不能同時(shí)被主、備機(jī)訪問(wèn)，或者共享存儲(chǔ)太貴的情況下。缺點(diǎn)是需要做額外的工作，必須同步磁盤(pán)狀態(tài)。

在備機(jī)上執(zhí)行磁盤(pán)讀?。涸谀壳皩?shí)現(xiàn)中，備機(jī)絕不會(huì)從磁盤(pán)進(jìn)行讀取，磁盤(pán)操作被認(rèn)為是一種輸入。一個(gè)替代的設(shè)計(jì)是，備機(jī)可以執(zhí)行磁盤(pán)讀取，當(dāng)有大量磁盤(pán)讀的工作負(fù)載時(shí)，這種方法可以幫助減少日志通道的流量。然而，這種方法有兩個(gè)主要挑戰(zhàn)：

可能會(huì)減慢備機(jī)的執(zhí)行速度，因?yàn)閭錂C(jī)必須執(zhí)行所有的磁盤(pán)讀;

如果讀取在主機(jī)上成功，但在備機(jī)上失敗(反之亦然)怎么辦?必須做一些額外的工作來(lái)處理失敗的磁盤(pán)讀操作。

VMware 的性能評(píng)估顯示，在備機(jī)上執(zhí)行磁盤(pán)讀取會(huì)降低 1-4% 的吞吐量，但同時(shí)也降低了日志帶寬。

FAQ

來(lái)自：https://pdos.csail.mit.edu/6.824/papers/vm-ft-faq.txt

Q: GFS 和 VMware FT 都提供了容錯(cuò)性，哪一個(gè)更好?

FT 提供計(jì)算容錯(cuò)，你能用它為任何已有的網(wǎng)絡(luò)服務(wù)器提供容錯(cuò)性。FT 提供了相當(dāng)嚴(yán)格的一致性而且對(duì)客戶端和服務(wù)器都是透明的。例如，你可以將 FT  應(yīng)用于一個(gè)已有的郵件服務(wù)器并為其提供容錯(cuò)性。

GFS 只提供存儲(chǔ)容錯(cuò)，因?yàn)?GFS 只針對(duì)特定的簡(jiǎn)單服務(wù)(存儲(chǔ))提供容錯(cuò)性，它的備份策略會(huì)比 FT 更高效。例如，GFS  不需要使中斷都以完全相同的指令發(fā)生在所有的副本上。GFS 通常只會(huì)用于一個(gè)對(duì)外提供完整容錯(cuò)服務(wù)的系統(tǒng)的一部分。例如，VMware FT  本身也依賴了一個(gè)在主備機(jī)間共享的有容錯(cuò)性的存儲(chǔ)服務(wù)，而你則可以用類似于 GFS 的東西來(lái)實(shí)現(xiàn)這個(gè)共享存儲(chǔ)(雖然從細(xì)節(jié)上來(lái)講 GFS 不太適用于 FT)。

Q: 共享存儲(chǔ)上的原子 test-and-set 指令是什么?

在共享存儲(chǔ)上的一個(gè)服務(wù)，最初狀態(tài)為 false，主機(jī)或備機(jī)認(rèn)為對(duì)方宕機(jī)了，自己應(yīng)該接管的時(shí)候，首先要向共享存儲(chǔ)發(fā)送一個(gè) test-and-set  操作，偽代碼是：

test-and-set() {     acquire_lock()     if flag == true:       release_lock()       return false     else:       flag = true       release_lock()       return true

只有當(dāng)返回 true 時(shí)才能接管主機(jī)。主要為了避免當(dāng)主、備機(jī)出現(xiàn)網(wǎng)絡(luò)分區(qū)，都想接管時(shí)出現(xiàn)腦裂(即同時(shí)有兩個(gè)主機(jī))的情況。

這有點(diǎn)像一個(gè)分布式鎖。問(wèn)題是：偽代碼沒(méi)有展示什么時(shí)候 flag會(huì)被設(shè)為 false!

老師解釋：論文沒(méi)有提及什么時(shí)候?qū)?flag 重設(shè)為 false，也許是管理員人為的操作，也許是交給機(jī)器來(lái)清理。

關(guān)于什么是主從復(fù)制就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。