Distributed Database Transaction Recovery via AGEs
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In distributed databases, achieving transactional consistency can be challenging when the transaction coordination manager's outcome store is unavailable, particularly during unclean detach and attach scenarios, master database restores, or when the outcome store is corrupt, leading to potential data inconsistencies and losses.
Innovation Solution
The use of monotonically increasing AGEs (commitment sequence numbers) across database segments to ensure transactional consistency, where each segment hosts multiple logical databases and provides services like storage and operating system services, allowing for the calculation of GPAs and designation of a controller to manage transaction outcomes and resolve in-doubt transactions without relying on the transaction coordination manager.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a single authoritative outcome store is used to resolve in-doubt transactions, then transactional consistency can be recovered, but the system becomes vulnerable when the outcome store is unavailable or corrupt
Solution Approach 1:
The patent divides the centralized outcome store into distributed segment-level storage across multiple database software instances. Each instance maintains its own segment transaction log and persisted transactions table, eliminating the single point of failure. This segmentation allows recovery to proceed using locally available information even when other instances or a centralized store are unavailable.
Solution Approach 2:
The patent enables each database segment to independently determine transaction outcomes using its own local transaction logs and persisted transactions tables. The controller segment coordinates recovery by gathering information from other segments and making final decisions, but each segment has the capability and authority to resolve its own in-doubt transactions locally without requiring a centralized outcome store.
2Reliability
If the transaction coordination manager's outcome store is unavailable during recovery, then centralized transaction resolution fails, but segments still need to achieve consistency
Solution Approach 1:
The patent implements self-service recovery where each database segment independently determines the outcome of its in-doubt transactions using its own transaction logs and persisted transactions tables. The controller segment facilitates this by gathering information from other segments and coordinating the recovery process, but each segment performs its own resolution without requiring external assistance from a transaction coordination manager or centralized outcome store.
3Adaptability or versatility
If AGEs are persisted in persistent memory for each segment, then transactional consistency can be achieved without centralized coordination, but storage requirements and complexity increase
Solution Approach 1:
The patent implements a progressive recovery approach where segments first attempt to determine transaction outcomes using only their own local information (partial action). If this is insufficient, the controller segment coordinates with other segments to gather additional information. This partial action approach allows many segments to recover independently without requiring full distributed coordination, reducing overall system complexity while maintaining autonomous recovery capability.
Data Source
AI summary
A distributed database transaction coordination manager's outcome store may be unavailable to resolve in-doubt transactions locally, e.g., after an unclean detach, during an outcomes store restore, or during a logical database restore. To facilitate transactional consistency, AGEs and values based on them are used. Some code avoids reformatting any closed physical portion for reuse based on the segment's most recently received minimum of persisted AGEs. Some code commits any in-doubt transactions that appear on an aggregate list and aborts any not on the aggregate list. Some code writes each segment's transaction commit records to persistent storage until the segment's persisted-AGE is not less than a common-restore-AGE, and some code resolves any in-doubt transactions based on a harvested outcomes list. Outcomes may reside in a log or a persisted transactions table. A restore checkpoint may include harvested outcomes. Segments may reside on cloud nodes and/or in a shared nothing database system.