Logical Timestamp Database Recovery
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional point-in-time recovery (PITR) processes in distributed databases are inefficient due to the reliance on log sequence numbers (LSNs), which leads to contention and inhibits parallel application of log records, particularly because they require a coordinator node to manage LSNs across different nodes, hindering logical consistency and efficiency.
Innovation Solution
The approach shifts from using LSNs to globally consistent logical timestamps (LTs) for PITR, allowing each database node to apply log records with timestamps preceding a specified LT, thereby eliminating the need for a coordinator node to manage LSNs and enabling parallel processing across nodes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If LSN-based PITR is used in distributed databases, then coordinator node can manage transaction ordering, but parallel application of log records is inhibited and efficiency decreases
Solution Approach 1:
The patent extracts the coordinator node from the PITR process by allowing each database node to independently determine its own recovery LSN based on the target timestamp and its local transaction commit timeline. This eliminates the coordinator node as a contention point while maintaining logical consistency through timestamp-based ordering.
Solution Approach 2:
The patent segments the centralized LSN management into distributed autonomous LSN determination at each node. Each node independently identifies log records to apply by comparing its local transaction commit timestamps with the target recovery timestamp, enabling parallel processing across all nodes without coordination overhead.
2Measurement precision
If coordinator node manages LSN for each worker node, then consistent recovery point is achieved, but contention point is created and parallel processing is hindered
Solution Approach 1:
Each database node performs self-service by independently determining its recovery LSN based on the target timestamp and its own local transaction commit timeline. Nodes autonomously identify which log records to apply without requiring the coordinator node to calculate or communicate node-specific LSNs, eliminating coordination overhead while maintaining accurate recovery points.
3Ease of operation
If LSN translation is performed for each worker node, then proper log record application is enabled, but coordinator node becomes bottleneck
Solution Approach 1:
The system performs preliminary action by pre-recording transaction commit timestamps in log records during normal database operations. During PITR, each node can immediately use these pre-recorded timestamps to determine the recovery LSN by simple comparison with the target timestamp, eliminating the need for time-consuming LSN translation calculations at the coordinator node.
Data Source
AI summary
A system includes reception of a request for recovery of a database to a recovery time, determination of a recovery logical timestamp corresponding to the recovery time, identification of database log records associated with a logical timestamp preceding the recovery logical timestamp, application of the identified database log records to the database sequentially according to log sequence number, identification, after applying the identified database log records, of one or more open transactions on the database, identification of a first one or more of the one or more open transactions which are associated with a commit log record associated with a logical timestamp preceding the recovery logical timestamp, and, in response to identification of the first one or more of the one or more open transactions, committing of the first one or more of the one or more open transactions.