如何保证transaction commit的完整性
来源:互联网 发布:java zip文件加密 编辑:程序博客网 时间:2024/05/16 15:58
欢迎和我探讨数据库技术,可以给我发信:tieyingz@cs.cmu.edu
当commit涉及到多行的时候,并且提供的是行锁,那么就涉及到如何保证多行commit的完整性,不至于1行提交了,另外一行没有提交,那么concurrent txn会读到不同的结果。无论是单机事务还是分布式事务都涉及到这个问题。
如何解决上述问题?需要一个全局锁(确切的说应该叫公共flag),至于这个锁如何实现,不同数据库不同方法。例如Oracle对表进行加锁,这样多行commit完再对表锁进行释放。而对于分布式事务,则需要一个全局锁,因为涉及到多个节点。Oracle把全局锁放在了commit site上。我们可以想象成一个中心server上有一个meta表,一个txn访问数据的时候如果该数据已经写入了,但是version还是没有被置上,就去meta表里查看对应数据是否已经被标记成commit了。
因此要保证commit的原子性需要性能上的代价,特别是分布式事务中,会引来额外的RPC开销。如果上面提到的flag放在本地则会大大减少RPC带来的影响。草案如下:
有一个GlobalMetaTable,同时每个节点有LocalMetaTable。GlobalMeta针对GlobalTxn,LocalMeta针对LocalTxn和GlobalTxn。对于GlobalTxn,其commit开始时,首先获得GlobalCommitId,更新GlobalMetaTable对应的那条Tuple,然后同步其涉及到的所有节点的LocalMetaTable。
下面转了一个两阶段提交的过程,其特点是阻塞,来保证提交过程的原子性!
前提条件
系统节点分为:其中一个节点被设置为协调者(co-ordinator),其他节点设置为参与者(cohort)。
算法
分两个阶段成功
两阶段提交中的故障处理:超时和重发机制
由两阶段提交协议的工作原理可见,之所以能够在不丢失运行记录信息的情况下.从所有故障中迅速恢复,就是因为在执行过程中维护了事务日志,记录了执行恢复所需要的信息。
现在来分析当发生不同类型故障时,2Pc的行为 。
站点故障
(1)一参与者在把就绪记录写入运行记录以前出现故障。在这种情况下,协调者超时机制满期,它将采取撤消的决定。所有的参与者都撤销它们的子事务。当发生该故障的参与者恢复时,重启动过程简单地撤销该事务即可.不需要过问其他站点的情况(2)一参与者在把就绪记录写入运行记录以后发生故障。在这种情况下,其他参与者的站点终止该事务(提交或撤消)。当故障站点恢复时,重启动过程不得不询问协调者或别的某个参与者关于该事务的结果(提交或撤消),然后执行相应的动作(提交或撤消)。这种情况下需要访问远程的恢复信息.
(3)协调者在把预备记录写入运行记录以后,而在写入global-commit或global-abort记录以前发生故障。这种情况下所有已经回答READY的参与者必须等待协调者恢复。协调者的重启动过程从头开始恢复提交协议,从预备记录(在运行记录中)读取参与者的标识,再次把PREPARE(预备)报发送给它们。每个就绪的参与者必须要识别出该新的PREPARE报文是前一个的重复报文。
(4)协调者在远行记录中写入global-commit或global-abort记录以后而在写入完成记录以前发生故障。这种情况下,协调者在重启动时必须再次给所有参与者发送其决定,未曾收到此命令的所有参与者不得不等待到协调者恢复为止。和以前一样,参与者不应因收到该命令报文两次而受到影响。
(5)协调者在运行记录中写入完成以后发生故障。这种情况下,该事物已经结束,在重启动时不需任何动作。
丢失报文
(1)来自一个参与者的回答报文(READY或ABORT)被丢失。在这种情况下,协调者的超时满期,整个事务被撤销。要注意,只由协调者来发现这种故障,而从协调者的观点来看,它完全好像是一参与者的故障。但是.从参与者的观点来看情况就不同了,该参与者并不认为自己有故障,因而不会执行重启动过程。(2)丢失一个PREPARE报文。这种情况下该参与者仍停在等待状态。因为协调者并没有收到回答,所以其全局结果和前一种情况相同。
(3)丢失一命令报文(commit或abort)。采用图4.15的协议时,该参与者对此命令处于不肯定状态。在参与者中引入超时机制就可简单地消除这个问题;从回答起在超时后仍末收到任何报文的话,就发送—请求再发送该命令。
(4)丢失一个AcK报文。协调者对参与者有无收到该报文处于不肯定状态。可以在协调者中引入超时机制就可简单地消除这个问题;如果从发出命令起到超时后仍未受到任何AcK报文,协调者就再次发送该命令。在参与者站点处理这种情况的最好办法是再次发送AcK报文,即使该子事务在那期间已经完成并不再活动也要重发。
网络分割
这里假设发生了简单的网络分割情况,即把站点分成为两个组;包含协调者的组叫做协调者组,而另一组叫参与者组。从协调者的观点来看,这种分割等效于一组参与者的故障情况,与上述第1(1)和1(2)点相似:协调者作出决定然后把命令发送给协调者一组中的所有参与者,因而这些站点能够正确地结束事务。如从参与者组的成员观点来看,这种分割等效于协调者故障,情况与上述第1(3)和1(4)点相似。要注意,对于涉及处理分布式事务的站点来说,其恢复过程要比集中式数据库复杂。在集中式数据库中,只合两种可能;事务要么提交,要么不提交,所以恢复机构执行相应的重做或撤销动作。在分布式数据库中,还可能有其他情况
(1)一个参与者就绪(情况1(2))。
(2)协调者已启动第1阶段(情况1(3))。
(3)协调者已启动第2阶段(情况1(4))。
这些情况分布式数据库管理系统中的恢复机制都能识别,并根据识别的情况作相应的处理。
其他:
个人总结:
感兴趣的同学可以参考一下oracle的实现:简单说就是对表加锁,而不仅仅对行加锁。
https://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_txns003.htm:
Places a distributed lock on modified tables, which prevents reads
Queries that start after a node has prepared cannot access the associated locked data until all phases complete. The time is insignificant unless a failure occurs (see"Deciding How to Handle In-Doubt Transactions").
Two-Phase Commit Mechanism
Unlike a transaction on a local database, a distributed transaction involves altering data on multiple databases. Consequently, distributed transaction processing is more complicated, because the database must coordinate the committing or rolling back of the changes in a transaction as a self-contained unit. In other words, the entire transaction commits, or the entire transaction rolls back.
The database ensures the integrity of data in a distributed transaction using thetwo-phase commit mechanism. In theprepare phase, the initiating node in the transaction asks the other participating nodes to promise to commit or roll back the transaction. During thecommit phase, the initiating node asks all participating nodes to commit the transaction. If this outcome is not possible, then all nodes are asked to roll back.
All participating nodes in a distributed transaction should perform the same action: they should either all commit or all perform a rollback of the transaction. The database automatically controls and monitors the commit or rollback of a distributed transaction and maintains the integrity of the global database (the collection of databases participating in the transaction) using the two-phase commit mechanism. This mechanism is completely transparent, requiring no programming on the part of the user or application developer.
The commit mechanism has the following distinct phases, which the database performs automatically whenever a user commits a distributed transaction:
This section contains the following topics:
Prepare Phase
Commit Phase
Forget Phase
Prepare Phase
The first phase in committing a distributed transaction is the prepare phase. In this phase, the database does not actually commit or roll back the transaction. Instead, all nodes referenced in a distributed transaction (except the commit point site, described in the "Commit Point Site") are told to prepare to commit. By preparing, a node:
Records information in the redo logs so that it can subsequently either commit or roll back the transaction, regardless of intervening failures
Places a distributed lock on modified tables, which prevents reads
When a node responds to the global coordinator that it is prepared to commit, the prepared nodepromises to either commit or roll back the transaction later, but does not make a unilateral decision on whether to commit or roll back the transaction. The promise means that if an instance failure occurs at this point, the node can use the redo records in the online log to recover the database back to the prepare phase.
Note:
Queries that start after a node has prepared cannot access the associated locked data until all phases complete. The time is insignificant unless a failure occurs (see"Deciding How to Handle In-Doubt Transactions").Types of Responses in the Prepare Phase
When a node is told to prepare, it can respond in the following ways:
Prepared Response
When a node has successfully prepared, it issues a prepared message. The message indicates that the node has records of the changes in the online log, so it is prepared either to commit or perform a rollback. The message also guarantees that locks held for the transaction can survive a failure.
Read-Only Response
When a node is asked to prepare, and the SQL statements affecting the database do not change any data on the node, the node responds with aread-only message. The message indicates that the node will not participate in the commit phase.
There are three cases in which all or part of a distributed transaction is read-only:
Only queries are issued at one or more nodes.
No data is changed.
Changes rolled back due to triggers firing or constraint violations.
No data changes.
Transaction is not started with
SET TRANSACTION READ ONLY
statement.
No data changes.
Transaction is started with
SET TRANSACTION READ ONLY
statement.
Note that if a distributed transaction is set to read-only, then it does not use undo segments. If many users connect to the database and their transactions arenot set toREAD ONLY
, then they allocate undo space even if they are only performing queries.
Abort Response
When a node cannot successfully prepare, it performs the following actions:
Releases resources currently held by the transaction and rolls back the local portion of the transaction.
Responds to the node that referenced it in the distributed transaction with an abort message.
These actions then propagate to the other nodes involved in the distributed transaction so that they can roll back the transaction and guarantee the integrity of the data in the global database. This response enforces the primary rule of a distributed transaction:all nodes involved in the transaction either all commit or all roll back the transaction at the same logical time.
Steps in the Prepare Phase
To complete the prepare phase, each node excluding the commit point site performs the following steps:
The node requests that its descendants, that is, the nodes subsequently referenced, prepare to commit.
The node checks to see whether the transaction changes data on itself or its descendants. If there is no change to the data, then the node skips the remaining steps and returns a read-only response (see"Read-Only Response").
The node allocates the resources it needs to commit the transaction if data is changed.
The node saves redo records corresponding to changes made by the transaction to its redo log.
The node guarantees that locks held for the transaction are able to survive a failure.
The node responds to the initiating node with a prepared response (see "Prepared Response") or, if its attempt or the attempt of one of its descendents to prepare was unsuccessful, with an abort response (see"Abort Response").
These actions guarantee that the node can subsequently commit or roll back the transaction on the node. The prepared nodes then wait until aCOMMIT
orROLLBACK
request is received from the global coordinator.
After the nodes are prepared, the distributed transaction is said to be in-doubt (see "In-Doubt Transactions").It retains in-doubt status until all changes are either committed or rolled back.
Commit Phase
The second phase in committing a distributed transaction is the commit phase. Before this phase occurs,all nodes other than the commit point site referenced in the distributed transaction have guaranteed that they are prepared, that is, they have the necessary resources to commit the transaction.
Steps in the Commit Phase
The commit phase consists of the following steps:
The global coordinator instructs the commit point site to commit.
The commit point site commits.
The commit point site informs the global coordinator that it has committed.
The global and local coordinators send a message to all nodes instructing them to commit the transaction.
At each node, the database commits the local portion of the distributed transaction and releases locks.
At each node, the database records an additional redo entry in the local redo log, indicating that the transaction has committed.
The participating nodes notify the global coordinator that they have committed.
When the commit phase is complete, the data on all nodes of the distributed system is consistent.
Guaranteeing Global Database Consistency
Each committed transaction has an associated system change number (SCN) to uniquely identify the changes made by the SQL statements within that transaction. The SCN functions as an internal timestamp that uniquely identifies a committed version of the database.
In a distributed system, the SCNs of communicating nodes are coordinated when all of the following actions occur:
A connection occurs using the path described by one or more database links
A distributed SQL statement executes
A distributed transaction commits
Among other benefits, the coordination of SCNs among the nodes of a distributed system ensures global read-consistency at both the statement and transaction level. If necessary, global time-based recovery can also be completed.
During the prepare phase, the database determines the highest SCN at all nodes involved in the transaction. The transaction then commits with the high SCN at the commit point site. The commit SCN is then sent to all prepared nodes with the commit decision.
See Also:
"Managing Read Consistency" for information about managing time lag issues in read consistencyForget Phase
After the participating nodes notify the commit point site that they have committed, the commit point site can forget about the transaction. The following steps occur:
After receiving notice from the global coordinator that all nodes have committed, the commit point site erases status information about this transaction.
The commit point site informs the global coordinator that it has erased the status information.
The global coordinator erases its own information about the transaction.
- 如何保证transaction commit的完整性
- 如何保证数据库完整性
- transaction除了保证完整性还能加速
- 保证数据的完整性
- 保证数据的完整性
- 保证数据的完整性
- 应用层如何保证一个包的完整性?
- 怎么样保证数据的完整性
- Java 保证数据的完整性
- mysql 如何保证数据完整性 -- 笔记
- Java安全之保证消息的完整性
- Java安全之保证消息的完整性
- md5算法 保证下载文件的完整性
- 数据库之表、保证数据的完整性
- 蓝牙通信之保证数据的完整性
- 3.保证数据完整性
- 约束-保证数据完整性
- MySql_保证数据完整性
- 用Mathematica对足球赛进行简单模拟
- 任我行在线安装方式
- HDU 3507 斜率优化
- Linux Ubuntu系统下Java开发环境搭建
- Leetcode-28.Implement strStr()
- 如何保证transaction commit的完整性
- 如何在linux下安装eclipse
- tomcat无法访问8080解决方法
- javase学习大纲
- php环境搭建
- 核心动画
- 向量、因子学习
- 为初学者答效率的问题
- [leetcode] 290. Word Pattern 解题报告