GBase 8c Transaction State Persistence Technology Analysis and Practice - 02 Technical Implementation

In a distributed database, transaction state persistence is a critical feature for ensuring data consistency and system reliability, relying on the following key technologies:

Distributed Transaction Protocol: GBase 8c employs an advanced distributed transaction protocol to ensure ACID compliance for operations spanning multiple nodes, guaranteeing Atomicity, Consistency, Isolation, and Durability.

Multi-Copy Data Strategy: To enhance data availability and fault tolerance, GBase 8c supports a multi-copy data strategy. Data can be stored on multiple nodes, ensuring continued service availability through replicas even if some nodes fail.

Failure Recovery Mechanism: When a node failure occurs within the system, GBase 8c leverages data replicas on other nodes to execute failure recovery, ensuring transaction completion.

Two-Phase Commitment Protocol (2PC): The two-phase commitment protocol is the cornerstone for implementing distributed transactions.

In traditional 2PC transactions, a failure during the global commit phase, such as a coordinator crash, can lead to inconsistent commit states across cluster nodes, breaking transaction atomicity. Furthermore, 2PC transactions persistently hold acquired locks, potentially preventing other transactions from acquiring locks and proceeding, which can severely stall the entire cluster. Therefore, checking for such transactions and expeditiously advancing the 2PC outcome (commit or rollback) is necessary.

To address these issues, GBase 8c optimizes the 2PC execution flow and designs a 2PC transaction state persistence feature to ensure the cluster continues providing services without interruption.

When a coordinator crashes, the system immediately detects the issue and automatically elects a healthy coordinator to take over all incomplete 2PC transactions from the failed one. The new coordinator gathers all outstanding 2PC transactions, checks the phase of each one, determines whether each should be committed or rolled back, and then sends corresponding commands to all participants to complete the entire 2PC process, ensuring the system is not blocked.

The two-phase commit transaction process is as follows:

a. The CN2 node dispatches the transaction Prepare status as normal.

b. The three DN nodes return the transaction Prepare OK status as normal.

c. The CN2 node dispatches the transaction Commit status as normal.

d. While DN1 node returns Commit OK status and DN2 and DN3 have not yet completed their Commit OK submission, the CN2 node crashes.

e. At this point, the CN3 node detects the CN2 node crash and automatically takes over the incomplete transactions and states from CN2.

f. The DN2 and DN3 nodes resubmit their Commit OK status to the CN3 node, completing the two-phase commit process.

After taking over, the CN3 node does not need to repeat the previously successful transaction states; it can directly continue the unfinished states from the crashed CN2 node to complete the current transaction. The entire process is transparent to the upper-layer business applications, ensuring that any node crash within the database cluster does not cause deadlocks or abnormal waiting.