两阶段提交 [英] Two phase commit

问题描述

我相信大多数人都知道什么2PC（两阶段提交协议）是如何使用它在Java或大多数现代语言。

假设我有两个数据库（A和B）使用2PC在两个或更多的数据库两个不同的位置。在A和B准备好提交事务之前，两个DB都将向事务管理器报告它们已准备好提交。因此，当事务管理器被确认时，它将发送一个信号给A和B告诉他们继续。

这是我的问题：让我们说A收到信号并提交交易。一旦一切完成，B即将做同样的，但有人拔掉电源线，导致整个服务器关机。当B恢复在线时，B会做什么？

请记住，A是承诺，但B不是，我们使用2PC（所以，2PC的设计停止工作，不是它？）

解决方案

两阶段提交

两阶段提交不能保证分布式事务不会失败，但它确保它不会在TM不知道的情况下默默失败。

为了使B将事务报告为准备提交，B必须在永久存储器中存在事务（即B必须能够保证事务可以在所有情况下提交）。在这种情况下，B已经持续了事务，但是事务管理器尚未从B接收到确认B已经完成提交的消息。

事务管理器将轮询B再次当B回到在线并要求它提交事务。如果B已经提交了事务，它会将事务报告为已提交。如果B尚未提交事务，那么它将提交，因为它已经持久化它并且因此仍然能够提交事务。

为了B在这种情况下，它将不得不经历灾难性的故障，丢失数据或日志条目。事务管理器仍会知道B没有报告成功提交。 ¹

在实践中，如果B不能再提交事务，这将意味着B出现的灾难已经导致数据丢失，并且当TM要求它提交一个它不知道或者没有认为处于可提交状态的TxID时，B会报告一个错误。 / p>

因此，两阶段提交并不能防止灾难性故障的发生，但它可以防止故障被忽视。在这种情况下，如果B无法提交，事务管理器将向应用程序报告错误。

应用程序仍然必须能够从错误中恢复，但事务不能默默失败，而不会使应用程序意识到不一致的状态。

语义

• 如果资源管理员或网络在阶段1中，
  事务管理器将检测到致命错误（无法连接到
  资源管理器），并将子事务标记为失败。当
  网络恢复时，它将中止所有参与资源管理器的所有
  的事务。




• 如果资源管理器网络在阶段2中下降，
  交易经理将继续轮询资源管理器，直到
  它恢复。当它重新连接回资源管理器
  时，它将告诉RM提交事务。如果RM返回一个
  错误，沿着'未知TxID'的行，TM将知道
  在RM中有数据丢失问题。




• 如果TM在阶段1中下降，则客户端将阻塞，直到
  TM恢复，除非超时或由于
  断开的网络连接而接收到错误。在这种情况下，客户端意识到
  的错误，可以重试或发起中止本身。




• 在阶段2，它将阻塞客户端，直到
  TM恢复。它已经将事务报告为
  committable，没有致命错误应该提交给客户端
  ，虽然它可能会阻塞，直到TM恢复。 TM将仍然
  具有处于未提交状态的交易，并且将在其返回时轮询RM
  以提交。

资源管理器中的提交后数据丢失事件不由事务管理器处理，并且是RM弹性的函数。

两阶段提交不保证容错能力 - 请参阅 Paxos 的一个协议的例子，它解决容错 - 但它确保分布式事务的部分失败不能被注意到。

1. 请注意，这种故障也会丢失先前提交的事务中的数据。两阶段提交不能保证资源管理器不会丢失或损坏数据，也不保证DR过程不会崩溃。

I believe most of people know what 2PC (two-phase commit protocol) is and how to use it in Java or most of modern languages. Basically, it is used to make sure the transactions are in sync when you have 2 or more DBs.

Assume I've two DBs (A and B) using 2PC in two different locations. Before A and B are ready to commit a transaction, both DBs will report back to the transaction manager saying they are ready to commit. So, when the transaction manager is acknowledged, it will send a signal back to A and B telling them to go ahead.

Here is my question: let's say A received the signal and commited the transaction. Once everything is completed, B is about to do the same but someone unplugs the power cable, causing the whole server shutdown. When B is back online, what will B do? And how does B do it?

Remember, A is committed but B is not, and we are using 2PC (so, the design of 2PC stops working, does not it?)

解决方案

On Two-Phase Commit

Two phase commit does not guarantee that a distributed transaction can't fail, but it does guarantee that it can't fail silently without the TM being aware of it.

In order for B to report the transaction as being ready to commit, B must have the transaction in persistent storage (i.e. B must be able to guarantee that the transaction can commit in all circumstances). In this situation, B has persisted the transaction but the transaction manager has not yet received a message from B confirming that B has completed the commit.

The transaction manager will poll B again when B comes back online and ask it to commit the transaction. If B has already committed the transaction it will report the transaction as committed. If B has not yet committed the transaction it will then commit as it has already persisted it and is thus still in a position to commit the transaction.

In order for B to fail in this situation, it would have to undergo a catastrophic failure that lost data or log entries. The transaction manager would still be aware that B had not reported a successful commit.¹

In practice, if B can no longer commit the transaction, it would imply that the disaster that took B out had caused data loss, and B would report an error when the TM asked it to commit a TxID that it wasn't aware of or didn't think was in a commitable state.

Thus, two phase commit does not prevent a catastrophic failure from occuring, but it does prevent the failure from going unnoticed. In this scenario the transaction manager will report an error back to the application if B cannot commit.

The application still has to be able to recover from the error, but the transaction cannot fail silently without the application being made aware of the inconsistent state.

Semantics

• If a resource manager or network goes down in phase 1, the transaction manager will detect a fatal error (can't connect to resource manager) and mark the sub-transaction as failed. When the network comes back up it will abort the transaction on all of the participating resource managers.

• If a resource manager or network goes down in phase 2, the transaction manager will continue to poll the resource manager until it comes back up. When it re-connects back to the resource manager it will tell the RM to commit the transaction. If the RM returns an error along the lines of 'Unknown TxID' the TM will be aware that there is a data loss issue in the RM.

• If the TM goes down in phase 1 then the client will block until the TM comes back up, unless it times out or receives an error due to the broken network connection. In this case the client is made aware of the error and can either re-try or initiate the abort itself.

• If the TM goes down in phase 2 then it will block the client until the TM comes back up. It has already reported the transaction as committable and no fatal error should be presented to the client, although it may block until the TM comes back up. The TM will still have the transaction in an uncommitted state and will poll the RMs to commit when it comes back up.

Post-commit data loss events in the resource managers are not handled by the transaction manager and are a function of the resilience of the RMs.

Two-phase commit does not guarantee fault tolerance - see Paxos for an example of a protocol that does address fault tolerance - but it does guarantee that partial failure of a distributed transaction cannot go un-noticed.

1. Note that this sort of failure could also lose data from previously committed transactions. Two phase commit does not guarantee that the resource managers can't lose or corrupt data or that DR procedures don't screw up.

这篇关于两阶段提交的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！