18372006. RECOVERY FROM LOSS OF LEADER DURING ASYNCHRONOUS DATABASE TRANSACTION REPLICATION simplified abstract (Oracle International Corporation)
Contents
- 1 RECOVERY FROM LOSS OF LEADER DURING ASYNCHRONOUS DATABASE TRANSACTION REPLICATION
- 1.1 Organization Name
- 1.2 Inventor(s)
- 1.3 RECOVERY FROM LOSS OF LEADER DURING ASYNCHRONOUS DATABASE TRANSACTION REPLICATION - A simplified explanation of the abstract
- 1.4 Simplified Explanation
- 1.5 Potential Applications
- 1.6 Problems Solved
- 1.7 Benefits
- 1.8 Potential Commercial Applications
- 1.9 Possible Prior Art
- 1.10 Unanswered Questions
- 1.11 Original Abstract Submitted
RECOVERY FROM LOSS OF LEADER DURING ASYNCHRONOUS DATABASE TRANSACTION REPLICATION
Organization Name
Oracle International Corporation
Inventor(s)
Leonid Novak of Castro Valley CA (US)
Sampanna Salunke of San Carlos CA (US)
Mark Dilman of Sunnyvale CA (US)
Wei-Ming Hu of Palo Alto CA (US)
RECOVERY FROM LOSS OF LEADER DURING ASYNCHRONOUS DATABASE TRANSACTION REPLICATION - A simplified explanation of the abstract
This abstract first appeared for US patent application 18372006 titled 'RECOVERY FROM LOSS OF LEADER DURING ASYNCHRONOUS DATABASE TRANSACTION REPLICATION
Simplified Explanation
A lead-sync log record is used to synchronize the replication logs of follower shards to the leader shard in a database system. When a shard server becomes a new leader and fails to determine a consensus for a transaction commit operation, the new leader shard performs a sync operation using the lead-sync log record to synchronize the replication logs of the follower shards to its own replication log. This process involves identifying transactions to be recovered, defining a recovery window in the replication log, and performing recovery actions on the identified transactions.
- Synchronization of replication logs between leader and follower shards
- Recovery of transactions in case of failure to determine consensus
- Use of lead-sync log record for synchronization
Potential Applications
- Database management systems
- Distributed systems
- Data replication technologies
Problems Solved
- Ensuring consistency in replicated data
- Handling failures in distributed systems
- Efficient recovery of transactions
Benefits
- Improved fault tolerance
- Enhanced data reliability
- Streamlined recovery processes
Potential Commercial Applications
- Cloud computing services
- Enterprise database solutions
- Data replication software
Possible Prior Art
One possible prior art could be the use of distributed consensus algorithms like Paxos or Raft to ensure consistency in replicated data in distributed systems.
Unanswered Questions
How does the lead-sync log record handle conflicts in replicated data?
The article does not provide information on how conflicts in replicated data are resolved during the synchronization process.
What are the performance implications of the recovery actions on a large set of transactions?
The article does not discuss the potential performance impact of performing recovery actions on a significant number of transactions in the system.
Original Abstract Submitted
A lead-sync log record is used to synchronize the replication logs of follower shards to the leader shard. In response to a failure to determine that there is a consensus for a database transaction commit operation after a shard server becomes a new leader, the new leader shard performs a sync operation using the lead-sync log record to synchronize replication logs of the follower shards to the replication log of the new leader. A shard server identifies a first transaction having a first log record but not a post-commit log record in the replication log, defines a recovery window in the replication log starting at the first log record of the identified first transaction and ending at the lead-sync log record, identifies a set of transactions to be recovered, and performs a recovery action on the set of transactions to be recovered.