1、分布式事務管理與恢復詳細課件分布式事務管理與恢復事務概念事務是訪問或更新各種數據項的程序執行單元.事務必須保證數據庫的一致性事務執行期間數據庫可能不一致事務概念-續 當事務提交（commit）時數據庫必須是一致的DatabaseConsistentConsistent事務概念-續 兩個問題:故障 各種軟硬件故障并發執行 多個事務同時執行事務性質ACID原子性（Atomicity） 事務的操作要么全部執行, 要么全部不執行 一致性（Consistency） 并發執行的多個事務,其操作的結果應與以某種順序串行執行這幾個事務所得的結果相同. 持久性（Durability） 當事務提交后, 其操作的結

2、果將永久化, 而與提交后發生的故障無關 事務性質-續獨立性（ Isolation） 雖然可以有多個事務同時執行，但是單個事務的執行不應該感知其他事務的存在，因此事務執行的中間結果應該對其他并發事務隱藏 一對事務 Ti 和 Tj的執行, 看起來好像是或者 Ti 在Ti 執行結束之后才開始執行，或者Tj,是在 Ti執行結束之后才開始執行舉例從賬號A向賬號B轉賬 $50: 1. read(A) 2. A := A 50 3. write(A) 4. read(B) 5. B := B + 50 6. write(B)舉例-續 一致性要求 事務執行后A 和 B賬號的總金額不變原子性要求 如果事務在第3

3、步和第6步之間故障, 系統應該保證事務對數據庫的修改沒有產生,否則將導致不一致性舉例-續持久性要求 一旦用戶通知說事務已經完成（即$50 轉賬成功），那么由該事務對數據庫的修改就必須保證是永久的，即使是發生故障也如此舉例-續獨立性要求 如果在第 3步和第6步之間, 允許其他事務訪問被修改的數據庫的中間結果, 那么它將見到一個不一致的數據庫 (也就是說， A + B 的和少于它的正確值） 當然事務的串行執行將不會出現這種情況，但是數據庫中事務并行執行的優點就損失了事務狀態活動 從事務開始執行的初始狀態始， 事務執行中保持該狀態部分提交 事務的最后一個語句執行后進入該狀態失敗 一旦發現事務不能正常

4、執行時進入該狀態夭折 當事務被回滾后，數據庫恢復到事務開始執行前的狀態。 事務夭折后有兩種選擇重啟動 僅當沒有內部邏輯錯誤時KILL提交 當事務成功執行后.事務狀態-續abortedcommittedfailedPartiallycommittedactive分布式事務分布式事務是由若干個不同Site上的子事務組成的事務事務的ACID性質此時事務的原子性、一致性、持久性、獨立性等都要將每個Site上的子事務考慮在內分布式事務結構Begin Trans . . . .Abort/CommitBegin Trans T1 T2 . . . Tn Abort/Commit進程協作進程 系統中可以并行

5、執行的一段操作序列，分布式事務中的子事務序列是進程方式完成過程 不可并行執行的操作序列事務代理（Agent） 應用在各個Site上執行的若干進程，稱作應用在該Site上的代理。代理可以執行應用程序員寫的程序，也可以執行系統的原語函數，不同代理間通過報文實現通訊，根代理（Root Agent） 應用啟動Site上的代理。根代理所在的Site稱作原發Site。 一般，根代理負責發系統原語，只有根代理可以請求創建新代理。事務代理轉賬應用事務在兩個賬戶之間執行“基金匯兌”操作。全局關系 Account (Account-number, Amount)假設賬戶分布在網絡的不同站點上。全局級轉帳事務FUN

6、D_TRANSFER:read (terminal,$AMOUNT,$FROM_ACC,$TO_ACC);begin_transaction;select AMOUNT into $FROM_AMOUNT from ACCOUNT where ACCOUNT_NUMBER=$FROM_ACC;if $FROM_AMOUNT-$AMOUNT0 then abortelse begin update ACCOUNT set AMOUNT = AMOUNT-$AMOUNT where ACCOUNT_NUMBER = $FROM_ACC; update ACCOUNT set AMOUNT = AM

7、OUNT+$AMOUNT where ACCOUNT_NUMBER = $TO_ACC; commitend輸入：匯出金額和轉入/轉出帳號事務開始：檢查轉出帳號中是否 有足夠的轉出資金？更新轉出帳號存款余額創建AGENT1向代理1送消息：轉入帳號，金額等待來自AGENT1的消息成功？提交事務：成功結束撤消事務：失敗結束ROOT_AGENTAGENT接收來自根代理的信息更新轉入帳號存款余額發送執行消息給根代理(成功或失敗)是否否轉賬應用處理流程ROOT_AGENT;read(terminal,$AMOUNT,$FROM_ACC,$TO_ACC);begin_transaction;select

8、AMOUNT into $FROM_AMOUNT from ACCOUNT where ACCOUNT_NUMBER=$FROM_ACC;if $FROM_AMOUNT-$AMOUNT0 then abortelse begin update ACCOUNT set AMOUNT = AMOUNT-$AMOUNT where ACCOUNT_NUMBER = $FROM_ACC;create AGENT;send to AGENT($AMOUNT,$TO_ACC);commit/*這里省略了等待消息和判別*/endAGENT;receive from ROOT_AGENT($AMOUNT,$T

9、O_ACC);update ACCOUNT set AMOUNT=AMOUNT+$AMOUNT where ACCOUNT=$TO_ACC;send to ROOT_AGENT(SUCCESS/FALL) 轉賬事務的兩個代理事務管理目標效率的幾個重要方面CPU和主存的使用控制報文響應時間可用性目標維護事務的ACID性質獲得最小的主存和CPU開銷，降低報文數目，加快響應時間獲得最大限度的可靠性和可用性事務管理DTM功能 保證分布式Trans的特征，特別是原子性支持分布式Trans執行的位置傳遞LTM功能保證本地Trans的特征代替DTM把分布Trans的執行與恢復信息記入Log接收并遵從本Sit

10、e上DTM發來的Log原語，記入Log并執行之DTMLTMSiteLog原語： Local Begin-Trans, Local-Commit, Local-Abort分布式Trans執行的控制模型主從模型 LTM之間無通信三角模型 LTM之間有通信層次控制模型 LTM之間有通信，并且LTM還可再創建Agent，控制其它LTM執行分布式事務管理器局部事務管理器局部事務管理器局部事務管理器數據庫數據庫數據庫命令命令命令回答回答回答主從控制分布式事務管理器局部事務管理器局部事務管理器數據庫數據庫命令命令回答回答臨時數據三角控制分布式事務管理器局部事務管理器數據庫命令命令回答回答局部事務管理器局部事

11、務管理器局部事務管理器局部事務管理器局部事務管理器命令命令命令命令回答回答回答回答數據庫數據庫數據庫數據庫數據庫層次控制故障類型事務故障由非預期的、不正常的程序結束所造成的故障，即事務沒有執行到Commit或顯示Rollback語句的故障，如：溢出、死循環等內存、磁盤上信息沒有損失，使用Log做Rollback系統故障造成系統停止運行的任何事件，要求系統重啟動內存、I/O Buffer內容皆丟失，DB沒有破壞，恢復時，搜索Log, 確定Rollback的Trans。設置檢查點故障類型-續介質故障輔助存儲器介質遭破壞數據丟失, 日志無損失 從某個Dump狀態開始執行已提交事務數據與日志都丟失 不

12、可能完全恢復通訊故障前三種統稱為站點故障. 通訊故障通訊發生, 既有某個報文Message從Site x 發往Site y, 正常情況:(a) 在Dmax 之后, x 站點收到y發回的應答信息(Ack)(b) y收到的Message是一個合適的次序(c ) Message本身的信息是正確的 但是當某個Dmax之后, x還沒收到y的Ack, 則可能發生: (a) Message 或 Ack 信息丟失 (b) 網絡分割, 及網絡不通Site xSite ymessageAck通訊故障-續 問題可以進一步分為:a) 是否是所在Site故障, 還是系統慢下來了?b) 若是故障, 是通訊故障, 還是 y

13、 站點故障?c) Message 是否已到達 y 站點? 對上述故障, 其恢復程序可以有不同級別:一級: 僅處理Site故障二級: Site故障及Message故障三級: Site故障及Message故障, 還包括網絡分割SiteSiteSite Site Site Site Site 恢復算法恢復算法是保證系統故障后數據庫仍保持一致性，以及保證事務原子性和持久性的技術恢復算法有兩部分組成在事務正常執行時，記錄下足夠的能使系統恢復的信息在故障發生時，恢復數據庫到一致性、原子性和持久性狀態事務日志日志Log 記錄所有對DB的操作事務標識 每個事務給定一個具有惟一性的標識符Log記錄項 : 開始,

14、 T, 提交, T, 夭折, T, 讀, T, x, 寫, T, x, 舊值, 新值DB寫動作 Log優先 Log存儲 一般存在盤上, 事務提交時, Log Buffer強迫寫Log舉例Log Write Output A = 950 B = 2050 BB, BA C = 600 BC 注: BX 表示含有X的存儲塊.數據訪問xYABx1y1 緩沖區緩沖塊 A 緩沖塊 Binput(A)output(B) read(X)write(Y)磁盤 T1工作區T2 工作區主存x2基于日志的恢復當系統故障時:如果 log 含有記錄, 但沒有記錄 ，事務 Ti 必須執行 undone 如果 log 即含

15、有 又有 記錄，事務 Ti 必須 redone Undo 操作先執行, redo 操作后執行.舉例 已知事務 T0 和 T1 (T0 在 T1前執行):T0: read (A)T1 : read (C)A: = A - 50C:=C- 100Write (A) write (C)read (B)B:= B + 50write (B)舉例-續如下是系統在三個不同時刻的Log記錄.舉例-續 三個不同時刻的系統恢復動作:(a) undo (T0): B 恢復到 2000 ，A恢復到 1000.(b) undo (T1) 并且 redo (T0): C恢復到 700, 然后 A和 B 分別寫入950

16、和 2050 .(c) redo (T0)和 (T1): A 和 B分別寫入950 和 2050 .C 寫入600檢查點檢查點設置一個周期性操作點a) Log Buffer寫入Log數據集b) 寫檢查點Log項, 當前活動事務表, 每個事務最近一次Log記錄在Log文件中的位置c) DB Buffer寫入DBd) 將檢查點Log項在Log文件中的位置記入“重啟動文件”檢查點恢復T1 可以忽略 (因為有檢查點，更新已經被寫入磁盤)T2 和 T3 redone.T4 undoneTcTfT1T2T3T4checkpointsystem failure事務故障恢復恢復原則孤立和逐步退出事務的原則 u

17、ndo 事務已對DB的修改 ( 不影響其他事務的可排除性局部故障)成功結束事務原則 Redo 已成功事務的操作夭折事務原則 撤銷全部事務, 恢復到初態 (Undo)事務故障恢復-續本地事務恢復 (與集中式恢復相同)從“重啟動文件” 讀出最近Checkpoint的地址, 并定出Checkpoint在Log文件中的位置創建Redo表, Undo表(即Checkpoint相應內容中的活動事務表)檢查得出Redo事務與Undo事務反向檢索Log, 將Undo表中事務撤銷, 直到遇到對應的Begin Trans正向檢索Redo事務的Log記錄, 并執行之, 直到對應的Commit記錄2PC協議 (2-P

18、hase Commit )基本思想 將本地原子性提交行為的效果擴展到分布式事務, 保證了分布式事務提交的原子性, 并在不損壞Log的情況下, 實現快速故障恢復, 提高DDB系統的可靠性.第一階段 表決階段第二階段 執行階段兩類代理協調者(Coordinator)參與者(Participants)初始寫begin_commit到日志等待有要求撤消的？寫commit到日志提交寫end_of_transt到日志初始準備提交？寫ready到日志就緒消息類型？寫abort到日志寫commit到日志提交撤消撤消寫abort到日志寫abort到日志協調者參與者nonoabortcommit準備撤消提交全局撤

19、消全局提交ACKACK2PC的通訊結構集中式通訊只發生在協調者和參與者之間，參與者之間不交換信息分層式協調者是在樹根的DTM代理者，協調者與參與者之間的通訊不用直接廣播的方法進行，而是使報文在樹中上下傳播。每個DTM代理這是通信樹的一個內部節點，它從下層節點除收集報文或向他們廣播報文。線性 參與者之間可以互相通信。系統中的站點間要排序分布式允許所有參與者在第一階段相互通信，從而可以獨立做出事務終止決定。23451234511協調者參與者協調者協調者參與者第一階段第二階段準備建議撤消/提交全局撤消/提交提交/撤消集中式34251511協調者參 與 者協調者協調者參 與 者第一階段第二階段準備建議

20、撤消/提交全局撤消/提交提交/撤消23422分層式1234n第一階段第二階段準備建議提交/撤消建議提交/撤消建議提交/撤消全局提交/撤消全局提交/撤消全局提交/撤消全局提交/撤消線性式1n4324321n協調者協調者協調者+參與者第一階段準備建議撤消/提交全局撤消/提交可獨立做決定分布式2PC與故障恢復站點故障a 參與者在將“Ready”記錄入Log之前故障此時協調者達到超時，Abort發生。站點（P）恢復時，重啟動程序將執行Abort，不必從其他站點獲取信息。b 當將“Ready”寫入Log后，P故障此時所有運行的站點都將正常結束事務（Commit/Abort)。P恢復時，因為P已Ready

21、，所以不可判定C的最終決定。因此恢復時，重啟動程序要詢問C或其他站點。c 當C將“Prepare”寫入Log，但“G-commit”/”G-abort”還沒有寫入是故障所有回答“Ready”的P等待C恢復。C重啟動時，將重開提交協議，重發“Prepare”，于是P要識別重發。d C在將“G-commit”/”G-abort”寫入Log后，“Complete”沒有寫入前故障收到命令的P正常執行，C重啟動程序必須再次向所有P重發命令。以前沒有收到命令的P也必須等待C恢復，P要識別兩次命令。e “Complete”寫入Log后故障無任何動作發生2PC與故障恢復-續2. 報文丟失a 從P發出的“Rea

22、dy”/“Abort”報文丟失C達到超時，整個事務執行“G-abort”。該故障僅能被C識別，此時C認為P故障，但P并無故障，不需執行重啟動程序。b “Prepare”報文丟失P等待，C得不到回答，結果同2.ac “G-commit”/”G-abort”報文丟失P處于不確定狀態。回答“Abort”的可以確定其工作，回答“Ready”的不行。此時可以修改加入計時器，超時則申請重發命令。d “Ack”報文丟失C超時，可重發“G-commit”/”G-abort”命令，P無論是否有活動，都重發“Ack”報文2PC與故障恢復-續網絡分割假設分成兩組。一組是協調者，一組是參與者。于是從協調者看是參與者組故障，結果同1.a, 1.b。 從參與者組看是協調者站點故障，動作如1.c, 1.d。初始寫begin_commit到日志等待有要求撤消的？寫commit到日志提交寫Complete到日志初始準備提交？寫ready到日志就緒消息類型？寫abort到日志寫commit到日志提交撤消撤消寫abort到日志寫abort到日志協調者參與者nonoabortcommit 2. b 準備2.a撤消2.a 提交2.c全局撤消全局提交ACKACK1.c1.d1.e1.a1.b2.d業務規則的一致性有效性約束 域約束數據依賴約束 實體完整性和引用完整性例子取現金時