Local Recovery Manager and Its Handling of Update and Write Operations
The local recovery manager is a key component in a distributed database system that ensures the database remains consistent and recovers from crashes or failures. When dealing with update and write operations, the recovery manager follows certain steps to maintain the integrity of the database.
- Update Operations: When an update operation is performed, such as changing the value of a record, the local recovery manager ensures that the old value is stored in a log before the update is applied. This helps in recovering the previous state if there is a failure. The update is only finalized when the system successfully logs the change.
- Write Operations: A write operation refers to the insertion of new data into the database. Before writing data to disk, the system ensures that a log record of the write operation is created. This log helps the recovery manager know which data was written and allows it to restore the data in case of system failure.
In both cases, the local recovery manager relies on the write-ahead logging (WAL) protocol, which ensures that changes are logged to a persistent storage (like a disk) before actually being written to the database. This makes sure that in the event of a crash, the database can be recovered to its last consistent state.
Importance of Log Records
Log records are crucial for maintaining the consistency and durability of the database. They serve as a history of all operations (updates, writes, commits, and aborts) performed on the database. Here’s why they are important:
- Crash Recovery: If the system crashes, the log records help the recovery manager figure out which transactions were completed and which ones need to be rolled back. This ensures that the database can be restored to a consistent state, without losing any committed changes or keeping uncommitted changes.
- Durability: Once a transaction commits, its changes are guaranteed to be persistent, even in the case of crashes, because the log records ensure that the changes are safely stored before they are applied to the actual data.
- Undo and Redo Operations: Log records allow the system to undo changes from transactions that didn’t commit (rollback) and redo changes from transactions that did commit, ensuring consistency and correctness.
For example, consider a banking system: if a transfer from Account A to Account B is logged and the system crashes before the transfer completes, the log will help restore the transaction and ensure that the money is correctly transferred (or rolled back if it wasn’t completed).
State Diagram of 2PC (Two-Phase Commit) Protocol
2PC (Two-Phase Commit) is a protocol used in distributed transactions to ensure that all parts of a distributed system either commit or abort the transaction.
- Phase 1: Prepare Phase
- The coordinator sends a “prepare” request to all participants (databases).
- Each participant sends back a “vote” (yes or no) based on whether it can commit the transaction.
- Phase 2: Commit Phase
- If all participants vote “yes,” the coordinator sends a “commit” message, and the participants commit the transaction.
- If any participant votes “no” (due to failure or inability to commit), the coordinator sends a “rollback” message to all participants, and they all roll back the transaction.
State Diagram of 2PC:
+-------------------------+
| |
Start -> Send "Prepare" ---> Wait for Votes
| |
(If any participant votes No) |
v |
Abort <---------------------+
|
(If all votes are Yes) |
v |
Commit ---------------------> End
State Diagram of 3PC (Three-Phase Commit) Protocol
3PC (Three-Phase Commit) is an extension of the 2PC protocol, designed to handle some of the limitations of 2PC (especially in terms of recovery from failures).
- Phase 1: Can Commit Phase
- The coordinator asks if all participants can commit by sending a “can commit” message.
- Participants reply with a “yes” or “no.”
- Phase 2: Prepare Phase
- If all participants respond with “yes,” the coordinator sends a “prepare” message, indicating they can proceed to commit.
- If any participant responds with “no,” the coordinator sends a “rollback” message.
- Phase 3: Commit Phase
- If the prepare phase is successful, the coordinator sends a “commit” message. Participants then commit the transaction.
- If any failure happens, the coordinator can instruct participants to rollback, ensuring consistency.
State Diagram of 3PC:
+----------------------------+
| |
Start --> Send "Can Commit" --> Wait for Votes
| |
(If any participant votes No) |
v |
Abort <------------------------+
|
(If all votes are Yes) |
v |
Send "Prepare" -------------> Wait for "Commit"
| |
(If any failure during Prepare) |
v |
Abort <------------------------+
|
Send "Commit" -------------> End
Comparison: Centralized 2PC vs Distributed 2PC
- Centralized 2PC: In a centralized 2PC system, a single coordinator (central server) is responsible for managing the transaction and coordinating the commit or rollback decisions. This is simpler but has the risk of failure if the coordinator crashes.
- Distributed 2PC: In distributed 2PC, multiple coordinators or distributed systems handle transaction coordination. It is more fault-tolerant and scalable but is more complex to implement due to the need for communication across different systems.
Thus, the local recovery manager ensures consistency by logging update and write operations. Log records are essential for crash recovery, durability, and ensuring consistency across the system. 2PC and 3PC are protocols used to ensure that all participants in a distributed transaction either commit or abort, with 3PC being more resilient to failures. Centralized 2PC is simpler but less fault-tolerant compared to Distributed 2PC, which is more robust but complex.