OceanBase Database adopts the two-phase commit protocol to implement distributed transactions. Take distributed transfer as an example. Assume that Account UA on Node A transfers funds to Account UB on Node B. The following procedure applies to two-phase transaction commit:
The first phase is the preparation phase, in which Node A and Node B check whether the status of UA and UB is normal. In other words, Node A and Node B check whether the balance of UA is sufficient and transferable (below the threshold), and whether UB can receive the transfer (not frozen). If both yes, UA and UB are locked.
The second phase is the commit phase. If both UA and UB pass the preparation phase, OceanBase notifies Node A to deduct the balance of UA and notifies Node B to add transferred funds to UB. Hence, the transfer is completed. Otherwise, OceanBase notifies Node A and Node B to roll back their accounts and cancels the transfer.
However, if one node, for example, Node A, fails during the execution of two-phase transactions, OceanBase does not know the situation of operation performed by Node A on UA. The preparation process of Node A may be uncompleted, completed and succeeded, or completed but failed. Node A may recover soon, does not recover for a long time, or be permanently damaged. It is even impossible to tell whether Node A fails or is recovered after the failure. The monitoring node cannot always determine the status of the monitored node, because the monitoring node itself or its communication with the monitored node may be abnormal. Therefore, the execution result of the distributed transaction is uncertain.
Paxos + two-phase commit protocol:
OceanBase Database introduces the Paxos distributed consistency protocol to the two-phase commit process, which provides automatic fault tolerance for distributed transactions. As shown in the preceding figure, each participant of the two-phase commit process contains multiple replicas. OceanBase achieves high availability among replicas through the Paxos protocol. When a participant node fails, OceanBase Database elects another replica as the new participant in seconds through the Paxos protocol. This new replica replaces the original participant to provide the services with the status of the original participant. This mechanism enables OceanBase Database to determine the execution result of distributed transactions and facilitate the completion of the two-phase commit.
OceanBase Database improves the conventional two-phase commit protocol to improve the distributed transaction processing capability and reduce the latency. The idea of "participant as coordinator" shows that the first participant of each distributed transaction undertakes the work of the coordinator in the two-phase commit protocol. As shown in the preceding figure, the conventional two-phase commit protocol has an independent coordinator. The coordinator maintains the status of the distributed transaction and responds to the client after the preparation and commit operations are performed. It also generates logs before performing each operation, which can be used to recover the distributed transaction status after the coordinator fails. The latency of one time of two-phase commit is equal to two times of RPC and four times of log writing operations. The coordinator in OceanBase Database is stateless. It no longer maintains the status of distributed transactions. Instead, it dynamically constructs the global status of distributed transactions during downtime recovery, based on the local status of all participants. The coordinator does not need to write logs, and the latency is equal to one time of RPC and log writing operation.