2022年分布式数据库中的事务管理和恢复

徐俊刚（xujg@)分布式数据库系统及其应用2007年2月——2007年6月8/6/20261分布式事务概述分布式事务的执行和恢复两阶段提交协议分布式数据库中的数据更新分布式事务增强数据库一致性总结分布式数据库中的事务管理和恢复第4章8/6/20262事务概念事务是访问或更新各种数据项的最小逻辑工作单位。它是一个操作序列它可以使数据库从一个一致状态到另外一个一致状态事务必须保证数据库的一致性事务执行期间数据库可能不一致1.1分布式事务定义和特性1分布式事务概述8/6/20263当事务提交（commit）时数据库必须是一致的事务T开始事务T结束事务T的执行数据库一致数据库一致数据库可能临时不一致1.1分布式事务定义和特性1分布式事务概述事务概念8/6/20264分布式事务集中式事务和操作数据在一个站点上不存在传输费用分布式操作数据分布在不同的站点上事务也在多个站点上执行分布式事务是集中式事务的扩充站点和通信连路故障都可能导致错误发生分布式事务的恢复要比集中式事务复杂的多1.1分布式事务定义和特性1分布式事务概述8/6/20265ACID特性原子性（Atomicity）事务的操作要么全部执行,要么全部不执行,保证数据库一致性状态一致性（Consistency）事务的正确性，串行性，并发执行的多个事务,其操作的结果应与以某种顺序串行执行这几个事务所得的结果相同.

持久性（Durability）当事务提交后,其操作的结果将永久化,而与提交后发生的故障无关1.1分布式事务定义和特性1分布式事务概述分布式事务特性8/6/20267隔离性（Isolation）

虽然可以有多个事务同时执行，但是单个事务的执行不应该感知其他事务的存在，因此事务执行的中间结果应该对其他并发事务隐藏此外，分布式数据库系统中还要考虑数据传送、通信原语和控制报文等。全局事务的主事务和子事务全部成功提交，才能改变数据库状态，有一个失败，其他子事务操作都要撤销。1.1分布式事务定义和特性1分布式事务概述分布式事务特性8/6/20268从账号A向账号B转账$50:

1.read(A)2.A:=A–503. write(A)4. read(B)5. B:=B+506. write(B)1.1分布式事务定义和特性1分布式事务概述分布式事务特性举例8/6/20269

一致性要求:事务执行后A和B账号的总金额不变原子性要求:如果事物在第3步和第6步之间故障,系统应该保证事务对数据库的修改没有产生,否则将导致不一致性1.1分布式事务定义和特性1分布式事务概述分布式事务特性举例8/6/202610持久性要求:一旦用户通知说事务已经完成（即$50转账成功），那么由该事务对数据库的修改就必须保证是永久的，即使是发生故障也如此1.1分布式事务定义和特性1分布式事务概述分布式事务特性举例8/6/202611独立性要求

如果在第3步和第6步之间,允许其他事务访问被修改的数据库的中间结果,那么它将见到一个不一致的数据库

(也就是说，A+B的和少于它的正确值）

当然事务的串行执行将不会出现这种情况，但是数据库中事务并行执行的优点就损失了1.1分布式事务定义和特性1分布式事务概述分布式事务特性举例8/6/202612BeginTransaction原语：开始一个事务T1[]T2[]:子事务或操作序列:Tn[]Commit原语：事务成功完成的结束Rollback或Abort原语：事务失败的结束1.2分布式事务结构和事务状态1分布式事务概述分布式事务的一般结构8/6/202613活动

从事务开始执行的初始状态始，事务执行中保持该状态部分提交

事务的最后一个语句执行后进入该状态.失败

一旦发现事务不能正常执行时进入该状态夭折

当事务被回滚后，数据库恢复到事务开始执行前的状态。

事务夭折后有两种选择重启动仅当没有内部逻辑错误时杀死提交

当事务成功执行后.1.2分布式事务结构和事务状态1分布式事务概述分布式事务的状态8/6/2026141.2分布式事务结构和事务状态1分布式事务概述分布式事务的状态8/6/202615进程：系统中可以并行执行的一段操作序列，分布式事务中的子事务序列是进程方式完成的进程说明：定义进程的行为模式，数据和数据上的操作，功能等进程执行：按模式来启动这个进程，执行其中的操作过程：不可并行执行的操作序列事务代理（Agent）：应用在各个Site上执行的若干进程，称作应用在该Site上的代理。代理可以执行应用程序员写的程序，也可以执行系统的原语函数，不同代理间通过报文实现通讯根代理（RootAgent）应用启动Site上的代理。根代理所在的Site称作原发Site.一般，根代理负责发系统原语，只有根代理可以请求创建新代理。1.2分布式事务结构和事务状态1分布式事务概述进程相关定义8/6/202616为了协调执行分布式应用的全局操作，分驻于不同站点的诸事务代理必须进行协调，有如下规定：每一应用都有一个负责启动整个事务的总代理（或称根代理）只有总代理才能发出全局有效的事务开始、提交和撤消原语只有总代理才能请求建立新的事务代理各站点上的子事务都执行成功，总代理才能决定提交该事务，否则总代理将决定撤销该事务1.2分布式事务结构和事务状态1分布式事务概述进程协作8/6/202617全局级转帐事务FUND_TRANSFER: read(terminal,$AMOUNT,$FROM_ACC,$TO_ACC);

begin_transaction; selectAMOUNTinto$FROM_AMOUNTfromACCOUNT whereACCOUNT_NUMBER=$FROM_ACC; if$FROM_AMOUNT-$AMOUNT<0thenabort elsebegin updateACCOUNT setAMOUNT=AMOUNT-$AMOUNT whereACCOUNT_NUMBER=$FROM_ACC; updateACCOUNT setAMOUNT=AMOUNT-$AMOUNT whereACCOUNT_NUMBER=$TO_ACC;

commit end8/6/202619输入：汇出金额和转入/转出帐号事务开始：检查转出帐号中是否有足够的转出资金？更新转出帐号存款余额创建AGENT1向代理1送消息：转入帐号，金额等待来自AGENT1的消息成功？提交事务：成功结束撤消事务：失败结束ROOT_AGENTAGENT接收来自根代理的信息更新转入帐号存款余额发送执行消息给根代理(成功或失败)是否否转账应用处理流程8/6/202620ROOT_AGENT; read(terminal,$AMOUNT,$FROM_ACC,$TO_ACC); begin_transaction; selectAMOUNTinto$FROM_AMOUNTfromACCOUNT whereACCOUNT_NUMBER=$FROM_ACC; if$FROM_AMOUNT-$AMOUNT<0thenabort elsebegin updateACCOUNT setAMOUNT=AMOUNT-$AMOUNT whereACCOUNT_NUMBER=$FROM_ACC;

createAGENT;

sendtoAGENT($AMOUNT,$TO_ACC); commit/*这里省略了等待消息和判别*/ endAGENT;

receivefromROOT_AGENT($AMOUNT,$TO_ACC); updateACCOUNTsetAMOUNT=AMOUNT+$AMOUNTwhere ACCOUNT=$TO_ACC;

sendtoROOT_AGENT(‘SUCCESS’/’FALL’)转账事务的两个代理8/6/202621分布式事务管理问题处理数据项的多个副本分布式事务处理负责保持同一数据的多个副本之间的一致性。当某个副本所在站点发生故障时，负责生成与该数据其他副本一致的拷贝，以便于及时恢复。单个站点的故障一个站点或多个站点故障时，DDBMS继续与其他正常运行的站点一起继续工作当故障站点恢复时，DDBMS协同故障站点的DBMS，必须使得该站点与系统连接时，局部数据库与其他站点同步通信网络的故障必须能够处理两个或者多个站点间的通信网络故障分布式提交如果提交分布式事务过程中有一个站点发生故障，提交就会产生问题两阶段提交协议用于解决这一问题1.3分布式事务管理的问题和目标1分布式事务概述8/6/202622分布式事务管理目标目的：事务能有效、可靠、并发的执行除了策略之外，效率的几个重要方面CPU和主存的使用控制报文响应时间可用性目标维护事务的ACID性质获得最小的主存和CPU开销，降低报文数目，加快响应时间获得最大限度的可靠性和可用性1.3分布式事务管理的问题和目标1分布式事务概述8/6/202623抽象模型LTM:LocalTransactionManagerDTM:DistributedTransactionManager2.1分布式事务管理的抽象模型2分布式事务的执行与恢复本地事务管理器LTM1本地事务管理器LTM2本地事务管理器LTMn分布式事务管理器DTM1分布式事务管理器DTM2分布式事务管理器DTMn站点n站点2站点18/6/202624事务管理DTM功能保证分布式事务ACID特性，特别是原子性，使每一站点的子事务都成功执行，或者都不执行。通过向各站点发begin-transaction,commit或者abort,create原语来实现的负责协调由该站点发出的所有分布式事务的执行启动分布式事务的执行将分布式事务分解为子事务，并将其分派到恰当的站点上执行决定分布式事务的终止（子事务都提交或者都撤销）支持分布式事务执行位置透明性实现了对网络上各站点的各子事务的监督和管理完成对整个分布式事务执行过程的调度和管理保证分布式数据库系统的高效率Log原语：

LocalBegin-Trans,Local-Commit,Local-Abort2.1分布式事务管理的抽象模型2分布式事务的执行与恢复8/6/202625事务管理LTM功能保证本地事务的ACID特性维护一个用于恢复的日志，代替DTM把分布事务的执行与恢复信息记入日志参与适当的并发控制模式，以协调在该站点上执行的事务的并发执行。接收并遵从本Site上DTM发来的Log原语，记入Log并执行之Log原语：

LocalBegin-Trans,Local-Commit,Local-Abort2.1分布式事务管理的抽象模型2分布式事务的执行与恢复8/6/202626分布式事务执行的控制模型是指协调分布式事务中各成员DBMS执行其子事务的通用方法，有三种:主从模型：主、从控制器，LTM之间无通信三角模型：LTM之间可以传递数据，避免了主从之间不必要的传输层次控制模型：LTM还可再创建Agent，控制其它LTM执行，比前两种复杂2.2分布式事务执行的控制模型2分布式事务的执行与恢复8/6/202627分布式事务管理器局部事务管理器局部事务管理器局部事务管理器数据库数据库数据库命令命令命令回答回答回答主从控制模型8/6/202628分布式事务管理器局部事务管理器局部事务管理器数据库数据库命令命令回答回答临时数据三角控制模型8/6/202629分布式事务管理器局部事务管理器数据库命令命令回答回答局部事务管理器局部事务管理器局部事务管理器局部事务管理器局部事务管理器命令命令命令命令回答回答回答回答数据库数据库数据库数据库数据库…………层次控制模型8/6/202630故障类型事务故障由非预期的、不正常的程序结束所造成的故障，即事务没有执行到Commit或显示Rollback语句的故障，如：计算溢出、完整性破坏、操作员干预、输入输出错误、死循环等）处理方法：内存、磁盘上信息没有损失，使用Log做Rollback系统故障造成系统停止运行的任何事件，要求系统重启动，如CPU出错、缓冲区满、系统崩溃等处理方法：内存、I/OBuffer内容皆丢失，DB没有破坏，恢复时，搜索Log,确定Rollback的事务。2.3分布式数据库系统中的故障2分布式事务的执行与恢复8/6/202631介质故障：辅助存储器介质遭破坏处理方法：如数据丢失,日志无损失，从某个Dump状态开始执行已提交事务；数据与日志都丢失不可能完全恢复以上三种可以统称为站点故障.2.3分布式数据库系统中的故障2分布式事务的执行与恢复8/6/202632通讯故障报文故障报文错报文失序报文丢失报文延迟网络分割故障（网络断连）通讯发生,既有某个报文Message从Sitex发往Sitey,正常情况:(a)在某时间段Dmax之后,x站点收到y发回的应答信息(Ack)(b)y收到的Message是一个合适的次序(c)Message本身的信息是正确的

但是当某个Dmax之后,x还没收到y的Ack,则可能发生:

(a)Message或Ack信息丢失(b)网络分割,即网络不通2.3分布式数据库系统中的故障2分布式事务的执行与恢复8/6/202633问题可以进一步分为:a)是否是所在Site故障,还是系统响应过慢，还是网络流量过大b)若是故障,是通讯故障,还是y站点故障?c)如果是报文故障，是报文丢失还是应答丢失对上述故障,其恢复程序可以有不同级别:一级:仅处理Site故障二级:Site故障及Message故障三级:Site故障及Message故障,还包括网络分割2.3分布式数据库系统中的故障2分布式事务的执行与恢复8/6/202634事务恢复当发生故障时，保证事务原子性的措施称为事务故障恢复，简称事务恢复主要依靠日志来实现事务状态转移跟踪（操作）Begin_transaction：标记事务开始执行Read&write：表示事务对某个数据项进行读写End_transaction：表示读写操作已完成，标记事务执行结束Commit_transaction：表示事务已经成功结束，任何改变已不可更改Rollback(abort)：表示事务没有成功结束，撤销事务对数据库所作的任何改变2.4事务故障恢复的基本概念2分布式事务的执行与恢复8/6/2026352.4事务故障恢复的基本概念2分布式事务的执行与恢复ACTVEPARTIALLYCOMMITTEDCOMMITEDFAILEDTERMINATEDBEGINTRANSACTIONREAD/WRITEENDTRANSACTIONCOMMITABORTABORT8/6/202636事务的提交点当事务T所有的站点数据库存取操作都已成功执行；所有操作对数据库的影响都已记录在日志中。到达提交点提交点后事务就成为已提交的事务，并假定其结果以永久记录在数据库中事务在日志中写入提交记录[commit,T]在系统发生故障时，需要扫描日志，检查日志中写入[start_transaction,T],但没有写入[commit,T]的所有事务T恢复时必须回滚这些事务以取消他们对数据库的影响此外，还必须对日志中记录的已提交子事务的所有写操作进行恢复。2.4事务故障恢复的基本概念2分布式事务的执行与恢复8/6/202637事务的提交点相关操作日志文件保存到磁盘上一般先将文件的相关块，从磁盘拷贝到主存的缓冲区，然后更新，再写回磁盘缓冲区中会经常存在一个或多个日志文件块，写满后一次性写回磁盘系统崩溃时，主存中的信息会丢失，这些信息无法利用因此，事务到达提交点之前，未写到磁盘的日志必须写入，称为事务提交前强制写日志。2.4事务故障恢复的基本概念2分布式事务的执行与恢复8/6/202638日志Log：记录所有对DB的操作事务标识：每个事务给定一个具有惟一性的标识符Log记录项:[start_transaction,T],[write_item,T,x,旧值,新值][read_item,T,x][commit,T][abort,T]写动作：写Log比写数据优先Log存储：一般存在盘上,还会定期备份到磁带上2.4事务故障恢复的基本概念2分布式事务的执行与恢复8/6/202639Log举例LogWriteOutput<start,T0><write,T0,A,1000,950><write,T0,B,2000,2050>

A=950

B=2050<commit,T0><start,T1><write,T1,C,700,600>

C=600

BB,BA<commit,

T1>

BC注:BX

表示含有X的存储块.2.4事务故障恢复的基本概念2分布式事务的执行与恢复8/6/202640数据访问xYABx1y1缓冲区缓冲块A

缓冲块Binput(A)output(B)read(X)write(Y)磁盘T1工作区T2工作区主存x22.4事务故障恢复的基本概念2分布式事务的执行与恢复8/6/202641档案库一天要产生大量的LogLog划分为两部分一部分是当前活动的联机部分，存储在磁盘上另一部分是档案存储部分，存储在磁带上2.4事务故障恢复的基本概念2分布式事务的执行与恢复8/6/202642日志缓冲区……数据库缓冲区(易变数据库)局部恢复管理器数据库缓冲区管理器主存取出读/写读/写日志档案库DB档案库稳定日志稳定DB读/写读/写2.4事务故障恢复的基本概念2分布式事务的执行与恢复数据库、日志和档案库的存储模式8/6/202643<write,T0,A,1000,950>事务在两个账户之间执行“基金汇兑”操作。保证分布式事务ACID特性，各站点上的子事务都执行成功，总代理才能决定提交该事务，否则总代理将决定撤销该事务点A暂时未连通。4事务故障恢复的基本概念检查点（Checkpoint）2分布式事务的执行与恢复2分布式事务的执行与恢复参与者之间可以互相通信。假设账户分布在网络的不同站点上。所有操作对数据库的影响都已记录在日志中。冗余数据绝对保持一致是不可能的,一般允许对冗余数据的修改有暂时的不一致.否则，就决定提交整个事务，发送“全局提交”消息给所有参与者，进入提交状态4分布式数据库中的数据更新检查点（Checkpoint）设置一个周期性（时间/容量）操作点a)LogBuffer内容写入Log数据集b)写检查点Log信息：当前活动事务表,每个事务最近一次Log记录在Log文件中的位置c)DBBuffer内容写入DBd)将本次检查点Log项在Log文件中的地址记入“重启动文件”2.4事务故障恢复的基本概念2分布式事务的执行与恢复8/6/202644事务本身也会发生故障，也是主要通过日志来实现恢复恢复原则孤立和逐步退出事务的原则undo事务已对DB的修改(不影响其他事务的可排除性局部故障，如事务操作的删除、超时、违反完整性原则、资源、限制和死锁等)成功结束事务原则Redo已成功事务的操作夭折事务原则撤销全部事务,恢复到初态，两种做法：利用数据备份和Undo

2.5事务故障的恢复2分布式事务的执行与恢复8/6/202645本地事务恢复(与集中式恢复相同)从“重启动文件”读出最近Checkpoint的地址,并定出Checkpoint在Log文件中的位置创建Redo表（初态为空）,Undo表(即Checkpoint相应内容中的活动事务表)检查得出Undo事务（向前检索，遇到begintransaction的log记录，其对应的事务）与Redo事务（向前检索，遇到commit的log记录，其对应事务）反向检索Log,将Undo表中事务,直到遇到对应的BeginTrans正向检索Redo事务的Log记录,并执行之,直到对应的Commit记录2.5事务故障的恢复2分布式事务的执行与恢复8/6/202646重启动文件UNDOREDO活动事务表故障发生地址c0c1(1)(3)(5)(2)(4)日志数据集利用日志进行事务恢复的过程2.5事务故障的恢复2分布式事务的执行与恢复8/6/202647Checkpoints举例T1可以忽略(因为有检查点，更新已经被写入磁盘)T2和T3redo.T4undoTcTfT1T2T3T4checkpointsystemfailure2.5事务故障的恢复2分布式事务的执行与恢复8/6/202648分布式事务恢复参考模型RootAgentAgentAgentDTM-Agent站点1的LTMDTM-AgentDTM-Agent站点2的LTM站点n的LTM全局事务分布式事务管理器(DTM)局部事务管理器(LTM)2.5事务故障的恢复2分布式事务的执行与恢复8/6/202649分布式事务模型底层：本地事务管理层，LTM之间不需要进行联系，执行上层DTM代理发来的原语，实现接口1Localbegin,localcommit,localabort,localcreate中间层：分布式事务管理层，一组互相交换报文的本地DTM组成，实现接口2Begintransaction,commit,abort,create顶层：全局事务层，由总代理和其他代理组成，只有它与中间层联系2.5事务故障的恢复2分布式事务的执行与恢复8/6/202650..BeginTransaction..CreateAgent1SendtoAgent1.Local-begin.SendCreateReqWriteBegin-transactioninLocalLogRootAgentDTM-AgentLTMReceive...LocalCreateLocal-begin………….WriteBegin-transactioninLocalLogLTMDTM-AgentAgent113245678分布式事务执行和恢复举例8/6/202651基本思想将本地原子性提交行为的效果扩展到分布式事务,保证了分布式事务提交的原子性,并在不损坏Log的情况下,实现快速故障恢复,提高DDB系统的可靠性.第一阶段：表决阶段第二阶段：执行阶段两类代理协调者(Coordinator)：提交和撤销事务的决定权，一般是总代理参与者(Participants)：负责在本地数据库中执行写操作，并且向协调者提出提交和撤销子事务的意向3.1基本思想和内容3两阶段提交协议8/6/2026523.1基本思想和内容3两阶段提交协议协调者参与者日志日志日志日志命令应答......参与者参与者2PC中协调者和参与者的关系8/6/202653表决阶段目的是形成一个共同的决定首先，协调者给所有参与者发送“准备”消息，进入等待状态其次，参与者收到“准备”消息后，检查是否能够提交本地事务如能，给协调者发送“建议提交”消息,进入就绪状态如不能，给协调者发送“建议撤销”消息，可以单方面撤销第三，协调者收到所有参与者的消息后，他就做出是否提交事务的决定，只要有一个参与者投了反对票，就决定撤销整个事务，发送“全局撤销”消息给所有参与者，进入撤销状态否则，就决定提交整个事务，发送“全局提交”消息给所有参与者，进入提交状态执行阶段实现表决阶段的决定，提交或者撤销3.1基本思想和内容3两阶段提交协议8/6/202654初始写begin_commit到日志等待有要求撤消的？写commit到日志提交写end_of_transt到日志初始准备提交？写ready到日志就绪消息类型？写abort到日志写commit到日志提交撤消撤消写abort到日志写abort到日志协调者参与者nonoabortcommit准备撤消提交全局撤消全局提交ACKACK两阶段提交协议的活动8/6/2026552PC协议的重要特点允许参与者单方面撤销事务一旦参与者确定了提交或撤销协议，它就不能再更改它的提议当参与者处于就绪状态时，根据协调者发出的消息种类，它可以转换为提交状态或者撤销状态协调者根据全局提交规则做出全局终止决定协调者和参与者可能进入互相等待对方消息的状态，使用定时器，保证退出消息等待状态3.1基本思想和内容3两阶段提交协议8/6/202656集中式通讯只发生在协调者和参与者之间，参与者之间不交换信息分层式协调者是在树根的DTM代理者，协调者与参与者之间的通讯不用直接广播的方法进行，而是使报文在树中上下传播。每个DTM代理是通信树的一个内部节点，它从下层节点处收集报文或向它们广播报文。线性参与者之间可以互相通信。系统中的站点间要排序，消息串行传递。支持没有广播功能的网络分布式允许所有参与者在第一阶段相互通信，从而可以独立做出事务终止决定。3.2通信结构3两阶段提交协议8/6/20265723451234511协调者参与者协调者协调者参与者第一阶段第二阶段准备建议撤消/提交全局撤消/提交提交/撤消集中式8/6/20265834251511协调者参与者协调者协调者参与者第一阶段第二阶段准备建议撤消/提交全局撤消/提交提交/撤消23422分层式8/6/2026591234n第一阶段第二阶段准备建议提交/撤消建议提交/撤消建议提交/撤消全局提交/撤消全局提交/撤消全局提交/撤消全局提交/撤消线性式8/6/2026601n4324321n……协调者协调者协调者+参与者第一阶段准备建议撤消/提交全局撤消/提交可独立做决定分布式8/6/202661站点故障a>

参与者在将“Ready”记录入Log之前故障此时协调者(C)达到超时，Abort发生。站点（P）恢复时，重启动程序将执行Abort，不必从其他站点获取信息。b>

当将“Ready”写入Log后，站点故障此时所有运行的站点都将正常结束事务（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后故障无任何动作发生3.2两阶段提交协议和故障恢复3两阶段提交协议8/6/2026622.报文丢失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”报文3.2两阶段提交协议和故障恢复3两阶段提交协议8/6/202663网络分割站点假设分成两组：协调者组和参与者组。一组是协调者，一组是参与者。于是从协调者看是参与者组故障，结果同1.a>,1.b>。从参与者组看是协调者站点故障，动作如1.c>,1.d>。3.2两阶段提交协议和故障恢复3两阶段提交协议8/6/202664初始写begin_commit到日志等待有要求撤消的？写commit到日志提交写Complete到日志初始准备提交？写ready到日志就绪消息类型？写abort到日志写commit到日志提交撤消撤消写abort到日志写abort到日志协调者参与者nonoabortcommit2.b>

准备2.a>撤消2.a>

提交2.c>全局撤消全局提交ACKACK1.c>1.d>1.e>1.a>1.b>2.d>8/6/202665多站点数据更新方法：站点A上有事务T对X更新,X在B1,…Bn和C1,…Cm上有副本,则也要对这些副本更新问题多个站点同时更新不现实(每一个站点某一时刻与站点A连通的概率小于1）对未连通站点上的副本更新增多时出错,更新的顺序也不一定是连通顺序4.1多站点数据更新4分布式数据库中的数据更新8/6/2026664.1多站点数据更新4分布式数据库中的数据更新站点A要更新X站点B1站点B2站点Bn站点C1站点C2站点Cm说明：(1)X在B1,B2,…,Bn和C1,C2,…,Cm上都有副本；(2)但只有站点B1,B2,…,Bn与站点A连通而站点C1,C2,…,Cm与站点A暂时未连通。8/6/202667主文本更新思想：指定主副本,修改只对主副本进行,修改辅助副本时,也按在主副本上执行的更新顺序执行问题修改传播必须在短时间内完成,否则将获得“过时”数据主副本不可用,引得其他副本也不可用4.2主文本更新4分布式数据库中的数据更新8/6/2026684.2主文本更新4分布式数据库中的数据更新网络站点AX主文本站点B2X辅文本站点B1X辅文本站点B3X辅文本站点B5X辅文本站点B4X辅文本T1T2未连通T1在T2之前8/6/202669移动主文本法若初次更新在辅文本上进行，然后再把更新引向该数据的主站点如果主站点此时尚未连通，则另选一个辅站点中的辅文本为该数据新的主文本进行更新待原主文本站点连通后，系统将自动把它改为辅文本，并按记录要求执行更新如果初次更新在主文本上进行，但主文本站点与网络未接通，则此次更新操作失败，事务被撤销，因为无法传播更新移动文本法的问题网络分割成很多部分时，更新处理会不一致网络分割成W1,W2，W1中X更新为R,W2中X更新为S,网络连通时，使用R还是S来恢复X呢？4.2主文本更新4分布式数据库中的数据更新8/6/202670快照(Snapshot)与视图相似,是导出的关系快照的数据是实际存放在数据库中的，视图不是周期地更新用于某些需要“冻结”数据的应用

4.3快照方法4分布式数据库中的数据更新8/6/202671例子

DefineSnapshotHP-BookasSELECT*FROMBookWHEREPrice>$100REFRESHEveryday特点快照不考虑数据的辅助副本,只关心主文本和这个主本上定义的多个快照快照与视图一样可以定义为一个或多个主副本的部分或全部快照可以完成复杂的查询,但又不阻止更新查询操作可使用快照，也可使用主文本，对更新操作还是在主文本上进行4.3快照方法4分布式数据库中的数据更新8/6/202672业务规则约束有效性约束:域