分布式事务管理与恢复.ppt

第九章 分布式事务管理与恢复,事务概念,事务是访问或更新各种数据项的程序执行单元. 事务必须保证数据库的一致性 事务执行期间数据库可能不一致,事务概念-续,当事务提交（commit）时数据库必须是一致的,T,事务概念-续,两个问题: 故障 各种软硬件故障 并发执行 多个事务同时执行,事务性质,ACID 原子性（Atomicity） 事务的操作要么全部执行, 要么全部不执行 一致性（Consistency） 并发执行的多个事务,其操作的结果应与以某种顺序串行执行这几个事务所得的结果相同. 持久性（Durability） 当事务提交后, 其操作的结果将永久化, 而与提交后发生的故障无关,事务性质-续,独立性（ 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步和第6步之间故障, 系统应该保证事务对数据库的修改没有产生,否则将导致不一致性,举例-续,持久性要求 一旦用户通知说事务已经完成（即$50 转账成功），那么由该事务对数据库的修改就必须保证是永久的，即使是发生故障也如此,举例-续,独立性要求 如果在第 3步和第6步之间, 允许其他事务访问被修改的数据库的中间结果, 那么它将见到一个不一致的数据库 (也就是说， A + B 的和少于它的正确值） 当然事务的串行执行将不会出现这种情况，但是数据库中事务并行执行的优点就损失了,事务状态,活动 从事务开始执行的初始状态始， 事务执行中保持该状态 部分提交 事务的最后一个语句执行后进入该状态. 失败 一旦发现事务不能正常执行时进入该状态 夭折 当事务被回滚后，数据库恢复到事务开始执行前的状态。 事务夭折后有两种选择 重启动 仅当没有内部逻辑错误时 杀死 提交 当事务成功执行后.,事务状态-续,SQL中的事务定义,数据操作语言中包含说明一组操作组成一个事务的结构. SQL中, 事务隐含的开始. SQL中,如下语句结束事务: Commit work 提交当前的事务, 开始一个新的事务. Rollback work 是当前的事务夭折.,SQL中事务定义 - 续,SQL-92中事务一致性级别: Serializable 缺省 Repeatable read Read committed Read uncommitted,分布式事务,分布式事务是由若干个不同Site上的子事务组成的事务 事务的ACID性质 此时事务的原子性、一致性、持久性、独立性等都要将每个Site上的子事务考虑在内,分布式事务结构,Begin Trans . . . . Abort/Commit,Begin Trans T1 T2 . . . Tn Abort/Commit,进程协作,进程 系统中可以并行执行的一段操作序列，分布式事务中的子事务序列是进程方式完成 过程 不可并行执行的操作序列 事务代理（Agent） 应用在各个Site上执行的若干进程，称作应用在该Site上的代理。代理可以执行应用程序员写的程序，也可以执行系统的原语函数，不同代理间通过报文实现通讯,根代理（Root Agent） 应用启动Site上的代理。根代理所在的Site称作原发Site. 一般，根代理负责发系统原语，只有根代理可以请求创建新代理。,转账应用,事务在两个账户之间执行“基金汇兑”操作。 全局关系 Account (Account-number, Amount) 假设账户分布在网络的不同站点上。,全局级转帐事务 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 abort else begin update ACCOUNT set AMOUNT = AMOUNT$AMOUNT where ACCOUNT_NUMBER = $FROM_ACC; update ACCOUNT set AMOUNT = AMOUNT$AMOUNT where ACCOUNT_NUMBER = $TO_ACC; commit end,输入：汇出金额和转入/转出帐号,事务开始：检查转出帐号中是否 有足够的转出资金？,更新转出帐号存款余额 创建AGENT1 向代理1送消息：转入帐号，金额,等待来自AGENT1的消息,成功？,提交事务：成功结束,撤消事务：失败结束,ROOT_AGENT,AGENT,接收来自根代理的信息,更新转入帐号存款余额,发送执行消息给根代理 (成功或失败),是,否,否,转账应用处理流程,ROOT_AGENT; 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 abort else begin update ACCOUNT set AMOUNT = AMOUNT-$AMOUNT where ACCOUNT_NUMBER = $FROM_ACC; create AGENT; send to AGENT($AMOUNT,$TO_ACC); commit/*这里省略了等待消息和判别*/ end AGENT; receive from ROOT_AGENT($AMOUNT,$TO_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 接收并遵从本Site上DTM发来的Log原语，记入Log并执行之,DTM,LTM,Site,Log原语： Local Begin-Trans, Local-Commit, Local-Abort,分布式Trans执行的控制模型,主从模型 LTM之间无通信 三角模型 LTM之间有通信 层次控制模型 LTM之间有通信，并且LTM还可再创建Agent，控制其它LTM执行,分布式事务 管理器,局部事务 管理器,局部事务 管理器,局部事务 管理器,数据库,数据库,数据库,命令,命令,命令,回答,回答,回答,主从控制,分布式事务 管理器,局部事务 管理器,局部事务 管理器,数据库,数据库,命令,命令,回答,回答,临时数据,三角控制,分布式事务 管理器,局部事务 管理器,数据库,命令,命令,回答,回答,局部事务 管理器,局部事务 管理器,局部事务 管理器,局部事务 管理器,局部事务 管理器,命令,命令,命令,命令,回答,回答,回答,回答,数据库,数据库,数据库,数据库,数据库,层次控制,故障类型,事务故障 由非预期的、不正常的程序结束所造成的故障，即事务没有执行到Commit或显示Rollback语句的故障，如：溢出、死循环等 内存、磁盘上信息没有损失，使用Log做Rollback 系统故障 造成系统停止运行的任何事件，要求系统重启动 内存、I/O Buffer内容皆丢失，DB没有破坏，恢复时，搜索Log, 确定Rollback的Trans。 设置检查点,故障类型-续,介质故障 辅助存储器介质遭破坏 数据丢失, 日志无损失 从某个Dump状态开始执行已提交事务 数据与日志都丢失 不可能完全恢复 通讯故障 前三种统称为站点故障.,通讯故障,通讯发生, 既有某个报文Message从Site x 发往Site y, 正常情况: (a) 在Dmax 之后, x 站点收到y发回的应答信息(Ack) (b) y收到的Message是一个合适的次序 (c ) Message本身的信息是正确的 但是当某个Dmax之后, x还没收到y的Ack, 则可能发生: (a) Message 或 Ack 信息丢失 (b) 网络分割, 及网络不通,通讯故障-续,问题可以进一步分为: a) 是否是所在Site故障, 还是系统慢下来了? b) 若是故障, 是通讯故障, 还是 y 站点故障? c) Message 是否已到达 y 站点? 对上述故障, 其恢复程序可以有不同级别: 一级: 仅处理Site故障 二级: Site故障及Message故障 三级: Site故障及Message故障, 还包括网络分割,日志,Log 记录所有对DB的操作 事务标识 每个事务给定一个具有唯一性 的标识符 Log记录项 : 开始, T, 提交, T, 夭折, T, 读, T, x, 写, T, x, 旧值, 新值 DB写动作 Log优先 Log存储 一般存在盘上, 事务提交时, Log Buffer强迫写,Log举例,Log Write Output A = 950 B = 2050 C = 600 BB, BA BC 注: BX 表示含有X的存储块.,数据访问,x,Y,A,B,x1,y1,缓冲区,缓冲块 A,缓冲块 B,input(A),output(B),read(X),write(Y),磁盘,T1工作区,T2 工作区,主存,x2,日志 缓冲区,数据库 缓冲区 (易变数据库),局部恢复 管理器,数据库缓冲区 管理器,主存,取出,读/写,读/写,日志 档案库,DB 档案库,稳定 日志,稳定 DB,读/写,读/写,日志恢复举例,两个事务 T0 和 T1 (T0 在 T1前执行): T0: read (A) T1 : read (C) A: = A - 50 C:=C- 100 Write (A) write (C) read (B) B:= B + 50 write (B),日志恢复举例-续,事务执行在不同时刻的日志.,日志恢复举例-续,故障发生时刻不同，处理不同: (a) 无动作 (b) 由于有 ，必须 redo(T0) (c) 由于 和 都出现， 必须依次执行 redo(T1)和 redo(T0),检查点,日志恢复问题 : 搜索整个日志非常耗时 某些已经写入数据库的更新还要重复执行.,检查点-续,检查点 设置一个周期性操作点 a) Log Buffer写入Log数据集 b) 写检查点Log项, 当前活动事务表, 每个事务最近一次Log记录在Log文件中的位置 c) DB Buffer写入DB d) 将检查点Log项在Log文件中的位置记入“重启动文件”,检查点-续,T1 可以忽略 (因为有检查点，更新已经被写入磁盘) T2 和 T3 redone. T4 undone,事务故障恢复,恢复原则 孤立和逐步退出事务的原则 undo 事务已对DB的修改 ( 不影响其他事务的可排除性局部故障) 成功结束事务原则 Redo 已成功事务的操作 夭折事务原则 撤销全部事务, 恢复到初态 (Undo),事务故障恢复-续,本地事务恢复 (与集中式恢复相同) 从“重启动文件” 读出最近Checkpoint的地址, 并定出Checkpoint在Log文件中的位置 创建Redo表, Undo表(即Checkpoint相应内容中的活动事务表) 检查得出Redo事务与Undo事务 反向检索Log, 将Undo表中事务, 直到遇到对应的Begin Trans 正向检索Redo事务的Log记录, 并执行之, 直到对应的Commit记录,重启动文件,UNDO,REDO,活动事务表,故障 发生,地址,c0,c1,(1),(3),(5),(2),(4),Log data set,利用日志进行事务恢复过程,分布式事务恢复参考模型,Root Agent,Agent,Agent,DTM- Agent,站点1的 LTM,DTM- Agent,DTM- Agent,站点2的 LTM,站点n的 LTM,全局事务,分布式事务管理器(DTM),局部事务 管理器 (LTM),. . Begin Transaction . . Create Agent1 Send to Agent1,. Local-begin . Send Create Req,Write Begin -transaction in Local Log,Root Agent,DTM-Agent,LTM,Receive.,Local Create Local-begin,. Write Begin -transaction in Local Log,LTM,DTM-Agent,Agent1,1,3,2,4,5,6,7,8,2PC协议,基本思想 将本地原子性提交行为的效果扩展到分布式事务, 保证了分布式事务提交的原子性, 并在不损坏Log的情况下, 实现快速故障恢复, 提高DDB系统的可靠性. 第一阶段 表决阶段 第二阶段 执行阶段 两类代理 协调者(Coordinator) 参与者(Participants),初始,写begin_commit到日志,等待,有要求撤消的？,写commit到日志,提交,写end_of_transt到日志,初始,准备提交？,写ready到日志,就绪,消息类型？,写abort到日志,写commit到日志,提交,撤消,撤消,写abort到日志,写abort到日志,协调者,参与者,no,no,abort,commit,准备,撤消,提交,全局撤消,全局提交,ACK,ACK,2PC的通讯结构,集中式 通讯只发生在协调者和参与者之间，参与者之间不交换信息 分层式 协调者是在树根的DTM代理者，协调者与参与者之间的通讯不用直接广播的方法进行，而是使报文在树中上下传播。每个DTM代理这是通信树的一个内部节点，它从下层节点除收集报文或向他们广播报文。 线性 参与者之间可以互相通信。系统中的站点间要排序 分布式 允许所有参与者在第一阶段相互通信，从而可以独立做出事务终止决定。,2,3,4,5,1,2,3,4,5,1,1,协调者,参与者,协调者,协调者,参与者,第一阶段,第二阶段,准备,建议撤消/提交,全局撤消/提交,提交/撤消,集中式,3,4,2,5,1,5,1,1,协调者,参 与 者,协调者,协调者,参 与 者,第一阶段,第二阶段,准备,建议撤消/提交,全局撤消/提交,提交/撤消,2,3,4,2,2,分层式,1,2,3,4,n,第一阶段,第二阶段,准备,建议提交/撤消,建议提交/撤消,建议提交/撤消,全局提交/撤消,全局提交/撤消,全局提交/撤消,全局提交/撤消,线性式,1,n,4,3,2,4,3,2,1,n,协调者,协调者,协调者+参与者,第一阶段,准备,建议撤消/提交,全局撤消/提交 可独立做决定,分布式,信息协议程序 p.96-98,2PC与故障恢复,站点故障 a 参与者在将“Ready”记录入Log之前故障 此时协调者达到超时，Abort发生。站点（P）恢复时，重启动程序将执行Abort，不必从其他站点获取信息。 b 当将“Ready”写入Log后，P故障 此时所有运行的站点都将正常结束事务（Commit/Abort)。P恢复时，因为P已Ready，所以不可判定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发出的“Ready”/“Abort”报文丢失 C达到超时，整个事务执行“G-abort”。该故障仅能被C识别，此时C认为P故障，但P并无故障，不需执行重启动程序。 b “Prepare”报文丢失 P等待，C得不到回答，结果同2.a c “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到日志,协调者,参与者,no,no,abort,commit,2. b 准备,2.a撤消,2.a 提交,2.c全局撤消,全局提交,ACK,ACK,1.c,1.d,1.e,1.a,1.b,2.d,业务规则的一致性,有效性约束 域约束 数据依赖约束 实体完整性和引用完整性 例子 取现金时 一个账户的存款余额必须等于或大于零 转账时 一个账户的存款余额必须等于或大于零. 事务结束时,两账户中存款总和, 必须与事务开始时两账户存款之和相同 定期利息计算 事务执行后, 所有账户存款之和比事务开始前各账户存款总和大于10%,冗余数据的一致性,冗余数据必须保持一致 例子,site1,site2,T1: Read(x) x=x*1.1 write(x),T2: Read(x) x=x-20 write (x),设数据x在两个站点都有副本. 两个事务分别执行, 这样两个事务的执行会产生不同的结果. 处置x=50, T2T1的执行顺序得到 x=33 (x-20)*1.1=(50-20)*1.1 T1T2的执行顺序得到 x=35 (x*1.1)-20=50*1,1),冗余数据的一致性-续,异步复制器 冗余数据绝对保持一致是不可能的, 一般允许对冗余数据的修改有暂时的不一致. 复制数据库的应用 向分站点发送只读数据 在一个周期结束时从分站点对中心站点复制这个周期内改变过的数据 复制数据并建立决策支持系统 建立关键数据的备份副本,冗余数据的一致性-续,不同复制器的差别 a 何时在主copy上获取数据 b 何时把主副本上的数据用到辅助副本上 对a有方法 1. 数据驱动: 当事务修改主副本时,