分布式事務管理與恢復PPT課件

1、事務概念 事務是訪問或更新各種數(shù)據(jù)項的程序執(zhí)行單元. 事務必須保證數(shù)據(jù)庫的一致性 事務執(zhí)行期間數(shù)據(jù)庫可能不一致第1頁/共70頁事務概念-續(xù) 當事務提交（commit）時數(shù)據(jù)庫必須是一致的DataBaseConsistentConsistentT第2頁/共70頁事務概念-續(xù) 兩個問題: 故障 各種軟硬件故障 并發(fā)執(zhí)行 多個事務同時執(zhí)行第3頁/共70頁事務性質 ACID 原子性（Atomicity） 事務的操作要么全部執(zhí)行, 要么全部不執(zhí)行 一致性（Consistency） 并發(fā)執(zhí)行的多個事務,其操作的結果應與以某種順序串行執(zhí)行這幾個事務所得的結果相同. 持久性（Durability） 當事務提交

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

3、要求 事務執(zhí)行后A 和 B賬號的總金額不變 原子性要求 如果事物在第3步和第6步之間故障, 系統(tǒng)應該保證事務對數(shù)據(jù)庫的修改沒有產生,否則將導致不一致性第7頁/共70頁舉例-續(xù) 持久性要求 一旦用戶通知說事務已經完成（即$50 轉賬成功），那么由該事務對數(shù)據(jù)庫的修改就必須保證是永久的，即使是發(fā)生故障也如此第8頁/共70頁舉例-續(xù) 獨立性要求 如果在第 3步和第6步之間, 允許其他事務訪問被修改的數(shù)據(jù)庫的中間結果, 那么它將見到一個不一致的數(shù)據(jù)庫 (也就是說， A + B 的和少于它的正確值） 當然事務的串行執(zhí)行將不會出現(xiàn)這種情況，但是數(shù)據(jù)庫中事務并行執(zhí)行的優(yōu)點就損失了第9頁/共70頁事務狀態(tài) 活

4、動 從事務開始執(zhí)行的初始狀態(tài)始， 事務執(zhí)行中保持該狀態(tài) 部分提交 事務的最后一個語句執(zhí)行后進入該狀態(tài). 失敗 一旦發(fā)現(xiàn)事務不能正常執(zhí)行時進入該狀態(tài) 夭折 當事務被回滾后，數(shù)據(jù)庫恢復到事務開始執(zhí)行前的狀態(tài)。 事務夭折后有兩種選擇 重啟動 僅當沒有內部邏輯錯誤時 殺死 提交 當事務成功執(zhí)行后.第10頁/共70頁事務狀態(tài)-續(xù)第11頁/共70頁SQL中的事務定義 數(shù)據(jù)操作語言中包含說明一組操作組成一個事務的結構. SQL中, 事務隱含的開始. SQL中,如下語句結束事務: Commit work 提交當前的事務, 開始一個新的事務. Rollback work 是當前的事務夭折.第12頁/共70頁SQ

5、L中事務定義 - 續(xù) SQL-92中事務一致性級別: Serializable 缺省 Repeatable read Read committed Read uncommitted第13頁/共70頁分布式事務 分布式事務是由若干個不同Site上的子事務組成的事務 事務的ACID性質此時事務的原子性、一致性、持久性、獨立性等都要將每個Site上的子事務考慮在內第14頁/共70頁分布式事務結構Begin Trans . . . .Abort/CommitBegin Trans T1 T2 . . . Tn Abort/Commit第15頁/共70頁進程協(xié)作 進程 系統(tǒng)中可以并行執(zhí)行的一段操作序列，

6、分布式事務中的子事務序列是進程方式完成 過程 不可并行執(zhí)行的操作序列 事務代理（Agent） 應用在各個Site上執(zhí)行的若干進程，稱作應用在該Site上的代理。代理可以執(zhí)行應用程序員寫的程序，也可以執(zhí)行系統(tǒng)的原語函數(shù)，不同代理間通過報文實現(xiàn)通訊第16頁/共70頁 根代理（Root Agent） 應用啟動Site上的代理。根代理所在的Site稱作原發(fā)Site. 一般，根代理負責發(fā)系統(tǒng)原語，只有根代理可以請求創(chuàng)建新代理。第17頁/共70頁轉賬應用事務在兩個賬戶之間執(zhí)行“基金匯兌”操作。全局關系 Account (Account-number, Amount)假設賬戶分布在網絡的不同站點上。第18頁

7、/共70頁全局級轉帳事務FUND_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 s

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

9、_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;create AGENT;send to AGENT($AMOUNT,$TO_ACC);commit/*這里省略了等待消息和判別*/endAGENT;rec

10、eive from ROOT_AGENT($AMOUNT,$TO_ACC);update ACCOUNT set AMOUNT=AMOUNT+$AMOUNT where ACCOUNT=$TO_ACC;send to ROOT_AGENT(SUCCESS/FALL) 轉賬事務的兩個代理第21頁/共70頁事務管理目標 目的 事務能有效、可靠、并發(fā)的執(zhí)行 效率的幾個重要方面 CPU和主存的使用 控制報文 響應時間 可用性 目標 維護事務的ACID性質 獲得最小的主存和CPU開銷，降低報文數(shù)目，加快響應時間 獲得最大限度的可靠性和可用性第22頁/共70頁事務管理 DTM功能 保證分布式Trans的特

11、征，特別是原子性 支持分布式Trans執(zhí)行的位置傳遞 LTM功能 保證本地Trans的特征 代替DTM把分布Trans的執(zhí)行與恢復信息記入Log 接收并遵從本Site上DTM發(fā)來的Log原語，記入Log并執(zhí)行之DTMLTMSiteLog原語： Local Begin-Trans, Local-Commit, Local-Abort第23頁/共70頁分布式Trans執(zhí)行的控制模型 主從模型 LTM之間無通信 三角模型 LTM之間有通信 層次控制模型 LTM之間有通信，并且LTM還可再創(chuàng)建Agent，控制其它LTM執(zhí)行第24頁/共70頁分布式事務管理器局部事務管理器局部事務管理器局部事務管理器數(shù)據(jù)

12、庫數(shù)據(jù)庫數(shù)據(jù)庫命令命令命令回答回答回答主從控制第25頁/共70頁分布式事務管理器局部事務管理器局部事務管理器數(shù)據(jù)庫數(shù)據(jù)庫命令命令回答回答臨時數(shù)據(jù)三角控制第26頁/共70頁分布式事務管理器局部事務管理器數(shù)據(jù)庫命令命令回答回答局部事務管理器局部事務管理器局部事務管理器局部事務管理器局部事務管理器命令命令命令命令回答回答回答回答數(shù)據(jù)庫數(shù)據(jù)庫數(shù)據(jù)庫數(shù)據(jù)庫數(shù)據(jù)庫層次控制第27頁/共70頁故障類型 事務故障由非預期的、不正常的程序結束所造成的故障，即事務沒有執(zhí)行到Commit或顯示Rollback語句的故障，如：溢出、死循環(huán)等內存、磁盤上信息沒有損失，使用Log做Rollback 系統(tǒng)故障造成系統(tǒng)停止運行

13、的任何事件，要求系統(tǒng)重啟動內存、I/O Buffer內容皆丟失，DB沒有破壞，恢復時，搜索Log, 確定Rollback的Trans。設置檢查點第28頁/共70頁故障類型-續(xù) 介質故障輔助存儲器介質遭破壞 數(shù)據(jù)丟失, 日志無損失 從某個Dump狀態(tài)開始執(zhí)行已提交事務 數(shù)據(jù)與日志都丟失 不可能完全恢復 通訊故障前三種統(tǒng)稱為站點故障. 第29頁/共70頁通訊故障 通訊發(fā)生, 既有某個報文Message從Site x 發(fā)往Site y, 正常情況:(a) 在Dmax 之后, x 站點收到y(tǒng)發(fā)回的應答信息(Ack)(b) y收到的Message是一個合適的次序(c ) Message本身的信息是正確的

14、 但是當某個Dmax之后, x還沒收到y(tǒng)的Ack, 則可能發(fā)生: (a) Message 或 Ack 信息丟失 (b) 網絡分割, 及網絡不通第30頁/共70頁通訊故障-續(xù) 問題可以進一步分為:a) 是否是所在Site故障, 還是系統(tǒng)慢下來了?b) 若是故障, 是通訊故障, 還是 y 站點故障?c) Message 是否已到達 y 站點? 對上述故障, 其恢復程序可以有不同級別:一級: 僅處理Site故障二級: Site故障及Message故障三級: Site故障及Message故障, 還包括網絡分割第31頁/共70頁日志 Log 記錄所有對DB的操作 事務標識 每個事務給定一個具有唯一性 的

15、標識符 Log記錄項 : 開始, T, 提交, T, 夭折, T, 讀, T, x, 寫, T, x, 舊值, 新值 DB寫動作 Log優(yōu)先 Log存儲 一般存在盤上, 事務提交時, Log Buffer強迫寫第32頁/共70頁Log舉例Log Write Output A = 950 B = 2050 C = 600 BB, BA BC注: BX 表示含有X的存儲塊.第33頁/共70頁數(shù)據(jù)訪問xYABx1y1 緩沖區(qū)緩沖塊 A 緩沖塊 Binput(A)output(B) read(X)write(Y)磁盤 T1工作區(qū)T2 工作區(qū)主存x2第34頁/共70頁日志緩沖區(qū)數(shù)據(jù)庫緩沖區(qū)(易變數(shù)據(jù)庫)

16、局部恢復管理器數(shù)據(jù)庫緩沖區(qū)管理器主存取出讀/寫讀/寫日志檔案庫DB檔案庫穩(wěn)定日志穩(wěn)定DB讀/寫讀/寫第35頁/共70頁日志恢復舉例 兩個事務 T0 和 T1 (T0 在 T1前執(zhí)行):T0: read (A)T1 : read (C)A: = A - 50C:=C- 100Write (A) write (C)read (B)B:= B + 50write (B)第36頁/共70頁日志恢復舉例-續(xù) 事務執(zhí)行在不同時刻的日志. 第37頁/共70頁日志恢復舉例-續(xù) 故障發(fā)生時刻不同，處理不同:(a) 無動作(b) 由于有 ，必須 redo(T0) (c) 由于 和 都出現(xiàn)， 必須依次執(zhí)行 redo

17、(T1)和 redo(T0) 第38頁/共70頁檢查點日志恢復問題 :搜索整個日志非常耗時某些已經寫入數(shù)據(jù)庫的更新還要重復執(zhí)行.第39頁/共70頁檢查點-續(xù) 檢查點 設置一個周期性操作點a) Log Buffer寫入Log數(shù)據(jù)集b) 寫檢查點Log項, 當前活動事務表, 每個事務最近一次Log記錄在Log文件中的位置c) DB Buffer寫入DBd) 將檢查點Log項在Log文件中的位置記入“重啟動文件”第40頁/共70頁檢查點-續(xù)T1 可以忽略 (因為有檢查點，更新已經被寫入磁盤)T2 和 T3 redone.T4 undoneTcTfT1T2T3T4checkpointsystem fa

18、ilure第41頁/共70頁事務故障恢復 恢復原則 孤立和逐步退出事務的原則 undo 事務已對DB的修改 ( 不影響其他事務的可排除性局部故障) 成功結束事務原則 Redo 已成功事務的操作 夭折事務原則 撤銷全部事務, 恢復到初態(tài) (Undo)第42頁/共70頁事務故障恢復-續(xù) 本地事務恢復 (與集中式恢復相同) 從“重啟動文件” 讀出最近Checkpoint的地址, 并定出Checkpoint在Log文件中的位置 創(chuàng)建Redo表, Undo表(即Checkpoint相應內容中的活動事務表) 檢查得出Redo事務與Undo事務 反向檢索Log, 將Undo表中事務, 直到遇到對應的Begi

19、n Trans 正向檢索Redo事務的Log記錄, 并執(zhí)行之, 直到對應的Commit記錄第43頁/共70頁重啟動文件UNDOREDO活動事務表故障發(fā)生地址c0c1(1)(3)(5)(2)(4)Log data set利用日志進行事務恢復過程第44頁/共70頁 分布式事務恢復參考模型RootAgentAgentAgentDTM-Agent站點1的LTMDTM-AgentDTM-Agent站點2的LTM站點n的LTM全局事務分布式事務管理器(DTM)局部事務 管理器 (LTM)第45頁/共70頁.Begin Transaction.Create Agent1Send to Agent1.Loca

20、l-begin .Send Create ReqWriteBegin -transactionin Local LogRoot AgentDTM-AgentLTMReceive.Local CreateLocal-begin.WriteBegin -transactionin Local LogLTMDTM-Agent Agent113245678第46頁/共70頁2PC協(xié)議 基本思想 將本地原子性提交行為的效果擴展到分布式事務, 保證了分布式事務提交的原子性, 并在不損壞Log的情況下, 實現(xiàn)快速故障恢復, 提高DDB系統(tǒng)的可靠性. 第一階段 表決階段 第二階段 執(zhí)行階段 兩類代理 協(xié)調者(

21、Coordinator) 參與者(Participants)第47頁/共70頁初始寫begin_commit到日志等待有要求撤消的？寫commit到日志提交寫end_of_transt到日志初始準備提交？寫ready到日志就緒消息類型？寫abort到日志寫commit到日志提交撤消撤消寫abort到日志寫abort到日志協(xié)調者參與者nonoabortcommit準備撤消提交全局撤消全局提交ACKACK第48頁/共70頁2PC的通訊結構 集中式通訊只發(fā)生在協(xié)調者和參與者之間，參與者之間不交換信息 分層式協(xié)調者是在樹根的DTM代理者，協(xié)調者與參與者之間的通訊不用直接廣播的方法進行，而是使報文在樹中

22、上下傳播。每個DTM代理這是通信樹的一個內部節(jié)點，它從下層節(jié)點除收集報文或向他們廣播報文。 線性 參與者之間可以互相通信。系統(tǒng)中的站點間要排序 分布式允許所有參與者在第一階段相互通信，從而可以獨立做出事務終止決定。第49頁/共70頁23451234511協(xié)調者參與者協(xié)調者協(xié)調者參與者第一階段第二階段準備建議撤消/提交全局撤消/提交提交/撤消集中式第50頁/共70頁34251511協(xié)調者參 與 者協(xié)調者協(xié)調者參 與 者第一階段第二階段準備建議撤消/提交全局撤消/提交提交/撤消23422分層式第51頁/共70頁1234n第一階段第二階段準備建議提交/撤消建議提交/撤消建議提交/撤消全局提交/撤消全

23、局提交/撤消全局提交/撤消全局提交/撤消線性式第52頁/共70頁1n4324321n協(xié)調者協(xié)調者協(xié)調者+參與者第一階段準備建議撤消/提交全局撤消/提交可獨立做決定分布式第53頁/共70頁 信息協(xié)議程序 第54頁/共70頁2PC與故障恢復站點故障a 參與者在將“Ready”記錄入Log之前故障此時協(xié)調者達到超時，Abort發(fā)生。站點（P）恢復時，重啟動程序將執(zhí)行Abort，不必從其他站點獲取信息。b 當將“Ready”寫入Log后，P故障此時所有運行的站點都將正常結束事務（Commit/Abort)。P恢復時，因為P已Ready，所以不可判定C的最終決定。因此恢復時，重啟動程序要詢問C或其他站點

24、。c 當C將“Prepare”寫入Log，但“G-commit”/”G-abort”還沒有寫入是故障所有回答“Ready”的P等待C恢復。C重啟動時，將重開提交協(xié)議，重發(fā)“Prepare”，于是P要識別重發(fā)。d C在將“G-commit”/”G-abort”寫入Log后，“Complete”沒有寫入前故障收到命令的P正常執(zhí)行，C重啟動程序必須再次向所有P重發(fā)命令。以前沒有收到命令的P也必須等待C恢復，P要識別兩次命令。e “Complete”寫入Log后故障無任何動作發(fā)生第55頁/共70頁2PC與故障恢復-續(xù)2. 報文丟失a 從P發(fā)出的“Ready”/“Abort”報文丟失C達到超時，整個事務

25、執(zhí)行“G-abort”。該故障僅能被C識別，此時C認為P故障，但P并無故障，不需執(zhí)行重啟動程序。b “Prepare”報文丟失P等待，C得不到回答，結果同2.ac “G-commit”/”G-abort”報文丟失P處于不確定狀態(tài)?；卮稹癆bort”的可以確定其工作，回答“Ready”的不行。此時可以修改加入計時器，超時則申請重發(fā)命令。d “Ack”報文丟失C超時，可重發(fā)“G-commit”/”G-abort”命令，P無論是否有活動，都重發(fā)“Ack”報文第56頁/共70頁2PC與故障恢復-續(xù)網絡分割假設分成兩組。一組是協(xié)調者，一組是參與者。于是從協(xié)調者看是參與者組故障，結果同1.a, 1.b。

26、從參與者組看是協(xié)調者站點故障，動作如1.c, 1.d。第57頁/共70頁初始寫begin_commit到日志等待有要求撤消的？寫commit到日志提交寫Complete到日志初始準備提交？寫ready到日志就緒消息類型？寫abort到日志寫commit到日志提交撤消撤消寫abort到日志寫abort到日志協(xié)調者參與者nonoabortcommit 2. b 準備2.a撤消2.a 提交2.c全局撤消全局提交ACKACK1.c1.d1.e1.a1.b2.d第58頁/共70頁業(yè)務規(guī)則的一致性 有效性約束 域約束 數(shù)據(jù)依賴約束 實體完整性和引用完整性 例子 取現(xiàn)金時 一個賬戶的存款余額必須等于或大于零

27、 轉賬時一個賬戶的存款余額必須等于或大于零. 事務結束時,兩賬戶中存款總和, 必須與事務開始時兩賬戶存款之和相同 定期利息計算事務執(zhí)行后, 所有賬戶存款之和比事務開始前各賬戶存款總和大于10%第59頁/共70頁冗余數(shù)據(jù)的一致性 冗余數(shù)據(jù)必須保持一致 例子site1 site2T1: Read(x) write(x) T2: Read(x) x=x-20 write (x)設數(shù)據(jù)x在兩個站點都有副本. 兩個事務分別執(zhí)行, 這樣兩個事務的執(zhí)行會產生不同的結果.處置x=50, T2T1的執(zhí)行順序得到 T1T2的執(zhí)行順序得到 x=35 (x*1.1)-20=50*1,1)第60頁/共70頁冗余數(shù)據(jù)的一致性-續(xù) 異步復制器 冗余數(shù)據(jù)絕對保持一致是不可能的, 一般允許對冗余數(shù)據(jù)的修改有暫時的不一致. 復制數(shù)據(jù)庫的應用 向分站點發(fā)送只讀數(shù)據(jù) 在一個周期結束時從分站點對中心站點復制這個周期內改變過的數(shù)據(jù) 復制數(shù)據(jù)并建立決策支持系統(tǒng) 建立關鍵數(shù)據(jù)的備份副本第61頁/共70頁冗余數(shù)據(jù)的一致性-續(xù) 不同復制器的差別a 何時在主copy上獲取數(shù)據(jù)b 何時把主副本上的數(shù)據(jù)用到輔助副本上 對a有方法 1. 數(shù)據(jù)驅動: 當事務修改主副本時, 獲取有關數(shù)據(jù)修改信息, 并將其寫到一個獲取文件或隊列中. 2. 計時器驅動: 由系統(tǒng)在用戶定義的時間間隔自動獲取相關數(shù)據(jù)修改信息 3. 應