【正文】 在執(zhí)行這兩個事務的所有站點中都以同樣的次序記錄 檢查點和冷啟動 5 不一致性檢測和解決方法 總 結 ?分布式數據庫可靠性的概念 ?分布式數據庫系統(tǒng)故障原因和容錯技術 ?分布式數據庫的可靠性協(xié)議 ?網絡分割與提交協(xié)議 ?不一致性的檢測和解決方法 。在執(zhí)行一個分布式事務時，若一個 Site故障，希望其它 Site也停止該事務。T 5ESS數字交換機 %硬件 , %軟件 , %操作 ? 軟件故障 – 通信或 DB的原因是產生軟件故障的主要原因 . – 代碼中的 Bug, 曾有報告指出 , 1000條指令中 , 個 BUG 系統(tǒng)失敗的原因 2 分布式數據庫系統(tǒng)的故障原因和容錯技術 永久性 故障 錯誤的 設計 不穩(wěn)定 或者 臨界的 組件 不穩(wěn)定的 外部環(huán)境 操作者 的過失 系 統(tǒng) 失 敗 永久性 錯誤 間歇性 錯誤 瞬變的 錯誤 系統(tǒng)失敗的原因 ? 容錯 – 設計一種使系統(tǒng)識別出可能會發(fā)生的錯誤的方法。 – 指在給定的時間點系統(tǒng)可以正常運行的概率。 ? 可用性 – 強調的是當需要訪問數據庫時，它是可用的。 ponent1 ponent2 ponent3 環(huán)境 系統(tǒng) 刺激 響應 ? 系統(tǒng)規(guī)范說明 （ Specification） 系統(tǒng)提供的對所有可能的刺激將產生的響應行為必須遵循的說明 系統(tǒng)失敗的原因 2 分布式數據庫系統(tǒng)的故障原因和容錯技術 ? 故障 – 任何偏離規(guī)范說明的行為 ? 軟故障和硬故障 – 軟故障包括間歇性（ intermittent）和瞬變性（ transient）故障，通過重啟動來修復 – 硬故障指永久性故障 , 錯誤設計等 ? 軟件和硬件故障 系統(tǒng)失敗的原因 2 分布式數據庫系統(tǒng)的故障原因和容錯技術 ? 軟故障 占 90%以上并且該比例穩(wěn)定 – 67年， 美空軍指出計算機中電子故障 80%是間歇性的 – 67年， IBM 指出 90%故障是間歇性的 – 80年，研究指出軟故障明顯高于硬故障 – 87年， Gray指出 大部分軟件故障是瞬變性故障 系統(tǒng)失敗的原因 2 分布式數據庫系統(tǒng)的故障原因和容錯技術 ? 審查不同計算機系統(tǒng)中出錯的統(tǒng)計數據 – IBM/XA 的 OS 可靠性報告 57%是硬件 , 12% 軟件 , 14%操作 , 7% 環(huán)境（斯坦福 線性加速器 SLAC） – Tandem計算機 18%硬件 25% 軟件 25%維護 17%操作 , 14%環(huán)境 – ATamp。 – 協(xié)議描述了原語的執(zhí)行過程 ? 命令執(zhí)行過程 – BeginTransaction： 登錄 – Read： LRM先在 Trans的緩沖區(qū)中讀，若不在，則向緩沖區(qū)管理器發(fā) Fetch命令，讀出數據后， LRM將它交給調度程序 – Write： 若在 Buffer中得到，則在那更新，否則對 Buffer Manager發(fā) Fetch命令，讀出數據并修改，同時數據的前像和修改后的后像寫入 Log – Abort： 通過 Log做 Undo – Commit： 將事務結束記錄入 Log項 局部可靠性協(xié)議 3 分布式數據庫的可靠性協(xié)議 ? 目的 – 維持在多個數據庫上執(zhí)行的事務的原子性和持久性 ? 原語 – Begin_Transaction – read, write, – Abort, mit ? 命令執(zhí)行與局部協(xié)議類似 分布式可靠性協(xié)議 3 分布式數據庫的可靠性協(xié)議 ? 可靠性協(xié)議組成 – 包括提交、終結、恢復協(xié)議 – 提交和恢復協(xié)議詳細說明提交命令和恢復命令是如何執(zhí)行的 – 終結協(xié)議是分布式系統(tǒng)特有的協(xié)議。 C C2和 C3 是本地檢查點 (從站點 1開始 ) 寫檢查點報文 兩階段提交的報文 (R=READY,C=COMMIT) 全局檢查點的同步問題 ? 避免上述問題的簡單辦法是 , 要求在每個站點記錄其本地檢查點之前 , 使所有站點變成不活躍的 . ? 全部站點必須同時停留在不活躍狀態(tài) , 需要進行協(xié)調 , 使用與 2PC類似的協(xié)議 – 由一協(xié)調者把“預備檢查點”廣播給所有站點 – 每個站點就終結了的事務的執(zhí)行然后回答 Ready – 于是該協(xié)調者再廣播“執(zhí)行檢查點” 檢查點和冷啟動 5 不一致性檢測和解決方法 ? 更高效的方法有： – 松散同步檢查點：由一個協(xié)調者來要求所有站點記錄一全局檢查點 , 但是它們可在一較大的時間間隔內自由地執(zhí)行之 , 保證同一事務的全部子事務都包含在相應于同一全局檢查點的本地檢查點的責任交事務管理器承擔 – 為了完全避免建立全局檢查點，讓恢復過程在冷啟動時承擔重構一致的全局狀態(tài)的任務。因此，協(xié)調者不需要做專門的處理 三階段提交協(xié)議的超時處理 3 分布式數據庫的可靠性協(xié)議 ? 參與者超時 – 在 Initial狀態(tài)超時：與 2PC中的情況相同 – 在 Ready狀態(tài)超時：參與者準備 Commit. 由于與協(xié)調者的通信丟失 , 終結協(xié)議將選舉一個新的協(xié)調者，新協(xié)調者根據下面所述終結協(xié)議終結事務 – 在 PC狀態(tài)超時：參與者已收到“ Preparetomit”, 正在等待來自協(xié)調者的“全局提交”消息 , 處理同第二條。 – 優(yōu)點是縮短了故障檢測的潛伏期。采用太謹慎的策略會降低可用性 分布式數據庫可靠性概念 1 分布式數據庫可靠性概念及其度量 例 : Site1 Site2 x1 x2 Lock x1 Lock x2 2PC Ready 故障出現(xiàn) Site1也 Ready 故 Commit Site 2 等待 此時 Site 2有兩種可能 : a 以正確性為標準， x2則等待 , 并 Lock 2, 直到故障恢復。1. 分布式數據庫的可靠性的概念及其度量 2. 分布式數據庫系統(tǒng)的故障原因和容錯技術 3. 分布式數據庫的可靠性協(xié)議 4. 網絡分割和提交協(xié)議 5. 不一致性監(jiān)測和解決方法 分布式數據庫中的可靠性 第 6章 ? 可靠性 – 指數據庫在一給定時間間隔內不產生任何失敗的概率。提高了可靠性，但犧牲了可用性。 基本容錯方法和技術 2 分布式數據庫系統(tǒng)的故障原因和容錯技術 ? 進程對（ Process pairs) – 通過 軟件模塊的雙工來實現(xiàn)容錯。 三階段提交協(xié)議的超時處理 3 分布式數據庫的可靠性協(xié)議 協(xié)調者 參與者 PREPARE PREPARED COMMIT PRECOMMIT ACK 1. 超時 : Abort 3. 超時 : 忽略 1. 超時 : abort 2. 超時 :終結協(xié)議 :終結協(xié)議 2. 超時 : 把參與者 移入 PC ? 競選新的協(xié)調者 – 使用競選協(xié)議 ? 新協(xié)調者送出 REQUEST狀態(tài)給參與者 ? 使用終結規(guī)則做出決定 ? 與參與者通信 三階段提交協(xié)議的終結協(xié)議 3 分布式數據庫的可靠性協(xié)議 競選協(xié)議 ? 進程全序 – 協(xié)調者 = 0, 參與者 1,…,n ? 任何時候 , 選擇 “最小的” 工作進程為協(xié)調者 三階段提交協(xié)議的終結協(xié)議 3 分布式數據庫的可靠性協(xié)議 ? 終結規(guī)則 – 新協(xié)調者在 Wait狀態(tài)：將全局 Abort. 此時參與者可以在任何狀態(tài) , 若參與者是在 PC狀態(tài) , 即它是期望有“ GCommit” , 但是得到了“ GAbort”. 3PC中缺少從 PC到 Abort的轉換 , 這對終結協(xié)議很有用 . – 新