【正文】 不一致性的檢測 5 不一致性檢測和解決方法 ? 檢測方法 – 采用版本號 ? 允許對數(shù)據(jù)項操作的站點的副本是主副本 , 其它是孤立或隔離的副本 ? 正常工作期間 , 全部副本都是主副本 , 并且互相一致 , 每份副本維持一個原版號和一個當前版本號 ? 網(wǎng)絡(luò)分割時 , 每個孤立副本的原版本號被置為當前版本號值 , 并且 , 直到分割修復為止 , 此原版號不會改變 不一致性的檢測 5 不一致性檢測和解決方法 ? 例子 – 已知前提 ? 數(shù)據(jù)項 x的副本 x1, x2, x3 存儲在三個不同站點 ? V1, V2, V3分別是 x1, x2, x3的版本號 – 初始時 , 三份副本一致 , 所以有 : ? V1=(0, 2)， V2 =(0, 2)， V3=(0, 2)，假設(shè)經(jīng)過了兩次更新 ? （原版本號，當前版本號） – 發(fā)生一次分割 , 把 x3從其它兩個副本分開 , 多數(shù)法選擇 x2和 x1為主副本 , 版本號變?yōu)? ? V1=(0, 2)， V2 =(0, 2)， V3=(2, 2) – 網(wǎng)絡(luò)分割期間 , 假設(shè)只更新主副本 , 版本號為 ? V1=(0, 3)， V2 =(0, 3) ， V3=(2, 2) ? 修復后 , 可以看出 x3未曾修改 不一致性的檢測 5 不一致性檢測和解決方法 – 假設(shè)分割時 , 只更新 x3, 版本號為 ? V1=(0, 2) V2 =(0, 2) V3=(2, 3) ? 此時若沒有其它孤立副本 , 則可以用 x3的更新施加到主副本 , ? 但若還有 x4， V4=(2,3)， 則即使 x3與 x4版本號相同也不能說其是一致的 – 若主副本與孤立副本都更新過 , 版本號為 ? V1=(0, 3) V2 =(0, 3) V3=(2, 3) ? 那么，此孤立副本的原版本號和當前版本號是不同的，而且此孤立副本的原版本號也與主副本的當前版本號不同 不一致性的檢測 5 不一致性檢測和解決方法 ? 網(wǎng)絡(luò)分割已修復和不一致性已檢測出來后，必須給同一數(shù)據(jù)項的全部拷貝賦予一共同的值，不一致性解法的問題是如何決定這個值 ? 不一致的解決辦法與應用相關(guān) – 航空訂票系統(tǒng) ? 暫停訂票 , 收集旅客請求 , 網(wǎng)絡(luò)修復后再集中訂票 ? 賦予各訂票點的訂票數(shù)小于總數(shù) 不一致性的解決方法 5 不一致性檢測和解決方法 ? 在分布式數(shù)據(jù)庫中，冷啟動是比較罕見的 ? 一般來說，當網(wǎng)絡(luò)中的一個站點丟失了運行記錄信息之后，就要求冷啟動 ? 分布式數(shù)據(jù)庫冷啟動中 , 一個站點要建立一早期狀態(tài) , 那么所有其它站點也必須建立起與該站點一致的早期狀態(tài) , 這意味著此恢復過程本質(zhì)上是全局的 , 要影響到數(shù)據(jù)庫的全部站點 , 雖然引起冷啟動的故障一般講是本地的 . ? 以前的一致性狀態(tài)是由檢查點來標志的 檢查點和冷啟動 5 不一致性檢測和解決方法 ? 一致的全局狀態(tài) C的兩個特征 – 對于每個事務 T, C包含了 T在任何站點的全部事務所執(zhí)行的更新 , 或者它不包含它們中的任何一個。兩個進程， 一個是主進程，一個是備份，它們同時提供同樣的服務，主進程與備份進程都是基于故障 停止模塊實現(xiàn)。 b 引入不一致性的風險下 , 盡量 提高可用性， 解鎖 x2, 其它事務可以使用它的值。 – 它強調(diào)數(shù)據(jù)庫的正確性，要求數(shù)據(jù)庫正確運行，既符合某種規(guī)格化要求。 ? 兩者關(guān)系 – 通常認為構(gòu)建可用性的系統(tǒng)比可靠性的系統(tǒng)容易 – 兩者是統(tǒng)一的，可靠性高的系統(tǒng)可用性自然是好的 – 兩者又是矛盾的，增加錯誤風險的情況下，可提高可用性 。 ? 錯誤預防 – 保證所實現(xiàn)的系統(tǒng)不包含任何錯誤 – 錯誤回避： 保證系統(tǒng)不會帶入錯誤的技術(shù)（詳細的設(shè)計方法學和質(zhì)量控制） – 錯誤清除： 清查那些在使用了錯誤回避技術(shù)路線后還殘留在系統(tǒng)中的錯誤，并清除它們（需要大量的測試和證實過程） 基本容錯方法和技術(shù) 2 分布式數(shù)據(jù)庫系統(tǒng)的故障原因和容錯技術(shù) ? 故障檢測 – 潛伏的故障： 故障發(fā)生一段時間后才被檢測出來 – 錯誤潛伏期： 從故障發(fā)生到被檢測出來的時間 – 平均檢測時間 (MTTD)：平均錯誤潛伏時間 – 平均修復時間 (MTTR)：修復一個失敗的系統(tǒng)所需要的期望時間 – 平均故障間隔時間 (MTBF)：在可以自我修復的系統(tǒng)中相繼的失敗之間的期望時間 , 由經(jīng)驗或從可靠性函數(shù)計算 基本容錯方法和技術(shù) 2 分布式數(shù)據(jù)庫系統(tǒng)的故障原因和容錯技術(shù) MTBF MTTD MTTR 在這段時間內(nèi)， 可能發(fā)生多起錯誤 故障 發(fā)生 造成 錯誤 檢測到 錯誤 修復 故障 發(fā)生 造成 錯誤 時間 相繼發(fā)生的事件 基本容錯方法和技術(shù) 2 分布式數(shù)據(jù)庫系統(tǒng)的故障原因和容錯技術(shù) ? 冗余 – 所有容錯系統(tǒng)設(shè)計中都采用的基本原則是在系統(tǒng)的組件中提供冗余 ? 模塊化 – 系統(tǒng)的每個組件都設(shè)計為具有定義很好的輸入 /輸出接口的模塊 – 模塊化可以把故障隔離在單一的組件中 ? 系統(tǒng)實現(xiàn) – 故障 停止模塊（ failstop module) – 進程對（ Process pairs) 基本容錯方法和技術(shù) 2 分布式數(shù)據(jù)庫系統(tǒng)的故障原因和容錯技術(shù) time 正常 停止 恢復 正常 易失存儲丟失 穩(wěn)定存儲 ok ? 故障 停止模塊 – 不斷地對自身進行檢測，當檢測到一個故障時，就自動停止。 分布式可靠性協(xié)議 3 分布式數(shù)據(jù)庫的可靠性協(xié)議 ? 終結(jié)協(xié)議與恢復協(xié)議的比較 – 假若一個 Site失效 ? 終結(jié)協(xié)議確定了未失效 Site如何處理該失效事件 ? 恢復協(xié)議確定失效 Site重啟動后，進程（協(xié)調(diào)者，參與者）恢復它的狀態(tài)的過程 – 網(wǎng)絡(luò)分割時 ? 終結(jié)協(xié)議采取必要的措施來終結(jié)在不同網(wǎng)絡(luò)區(qū)間執(zhí)行的活動事務 ? 當網(wǎng)絡(luò)重新連接后，恢復協(xié)議保證使各個冗余 DB相互一致 分布式可靠性協(xié)議 3 分布式數(shù)據(jù)庫的可靠性協(xié)議 ? 兩階段提交協(xié)議的要點 – 允許參與者單方面撤銷事務，直到做出肯定性的建議 – 一旦參與者確定了提交或者撤銷提議，它不能再更改 – 當參與者處于就緒狀態(tài)，它可根據(jù)協(xié)調(diào)者發(fā)出的消息的種類，轉(zhuǎn)換為相應的提交或者撤銷狀態(tài) – 協(xié)調(diào)者依據(jù)全局提交規(guī)則作出全局終結(jié)決定 – 在發(fā)生故障的情況下，協(xié)調(diào)者和參與者可能會進入互相等待的狀態(tài)，一般采用定時器來解決這種問題 兩階段提交協(xié)議的演變 3 分布式數(shù)據(jù)庫的可靠性協(xié)議 協(xié)調(diào)者 參與者 PREPARE PREPARED COMMIT ACK 2PC提交 協(xié) 調(diào) 者 參 與 者 PREPARE NO ABORT ACK 2PC夭折 集中式 2PC 協(xié)調(diào)者 參與者 I W C A I R C A mit申請 申請 prepare* no abort* prepared* mit mit ACK 申請 prepare prepared 申請 prepare no abort ACK F ACK* ACK* 標記 : 輸入消息 輸出消息 * = 每一個 兩階段提交協(xié)議的演變 3 分布式數(shù)據(jù)庫的可靠性協(xié)議 ? 當參與者進入“ R”狀態(tài) : – 它必定已獲得所有資源 – 它只能根據(jù)協(xié)調(diào)者指令提交或夭折 ? 當所有參與者是在“ R”時 , 協(xié)調(diào)者才能進入“ C” 狀態(tài) , 即 , 它一定 最終 能提交 兩階段提交協(xié)議的演變 3 分布式數(shù)據(jù)庫的可靠性協(xié)議 ? 假定撤銷 2PC和假定提交 2PC協(xié)議 – 目的是改善 2PC的性能 – 假定撤銷協(xié)議中，協(xié)調(diào)者不必等待參與者的ACK消息，減少了協(xié)調(diào)者與參與者之間傳遞消息的數(shù)量 –