Write-Behind Logging - WBL

One of my most popular blogs to date is also my first blog on Write-Ahead Logs. If you remember, WAL allows databases to store transaction records in a sequential manner, thus preventing the need for the database to perform random writes to persist records on disk, hence helping improve the performance of the database while still ensuring durability. However, with the availability of NVM technologies, is the optimization to ensure sequential access really needed?

WBL — Write-Behind Log

Write-behind logging (WBL) is a logging technique used in database management systems (DBMS) to improve performance. It differs from write-ahead logging (WAL) in that it does not write the log records to persistent storage immediately after they are generated. Instead, the log records are buffered in memory and written to persistent storage in the background. This allows the DBMS to continue processing transactions without waiting for the log records to be written.

But wait, if log records are buffered in memory, wouldn’t that be an issue? That was the entire problem statement for using WAL!

WBL is made possible by advancements in hardware, such as non-volatile memory (NVM). NVM is a type of memory that retains its data even when power is lost. This means that the log records can be buffered in NVM and written to persistent storage later, without the risk of losing data.

How does Write-Behind Logging?work

1. A user updates record/s in a database.
2. The changes are buffered in memory. The changes are not written to the log until the transaction commits.
3. The transaction commits. On commit, the database writes the changes to a log in the NVM.
4. The database continues processing other requests.
5. At a later time, when the system is less busy, the database flushes the log to disk.?
6. The changes to the database are now durable and will not be lost if the system crashes.

Write-behind logging is a trade-off between performance and durability. By delaying the writing of changes to disk, write-behind logging can improve performance. However, it also increases the chances of data loss. Yes!

The potential risk of data loss in write-behind logging arises when the changes have not been flushed from the log buffer in NVM to a more persistent storage medium, such as a disk, before a system failure occurs. If a failure happens before the changes are persisted from NVM to disk, the logged modifications that have not been flushed could be lost.

To mitigate this risk, proper recovery mechanisms should be in place. Upon system restart, the write-behind logging system needs to ensure that any logged changes still residing in NVM are replayed and persisted to disk to restore the database to a consistent state. This recovery process involves correctly handling the logged modifications and ensuring that no data loss or inconsistencies occur during the recovery phase.

Another approach is to make use of deferred write. With deferred write, the database flushes the log to disk at regular intervals. This helps to reduce the chances of data loss in case of failures but still needs the recovery mechanisms to be in place.

Advantages of Write-Behind Logging?

• Improved performance: Write-behind logging can improve the performance of database systems by allowing them to continue processing requests even if the disk is busy.
• Reduced disk I/O: Write-behind logging can reduce disk I/O by delaying the writing of changes to the disk until they are needed.
• Increased scalability: Write-behind logging can help to improve the scalability of database systems by allowing them to handle more requests without slowing down.

Disadvantages of Write-Behind Logging?

• Increased risk of data loss: Since write-behind logging defers the actual disk write operation, there is a potential risk of data loss in the event of a system failure or crash before the changes are flushed to disk. You need to have proper recovery mechanisms as suggested above to prevent data loss.
• Increased Recovery Time: In the event of a system failure, recovering the database using the logged changes can introduce additional recovery time. The system needs to replay the logged modifications and bring the database to a consistent state, which may take longer compared to systems that employ immediate disk writes.
• Increased Complexity: Write-behind logging adds an additional layer of complexity to the system architecture. The need to manage and synchronize the in-memory modifications, the log buffer, and the disk writes requires careful design and implementation. This complexity can make the system more prone to bugs, performance issues, and potential data corruption if not handled correctly.

This brings us to the end of this article. We talked about write-behind logging, how it differs from WAL, its advantages, disadvantages and some caveats to take care of while implementing write-behind logging. Please post comments on any doubts you might have and will be happy to discuss them!

Thank you for reading! I’ll be posting weekly content on distributed systems & patterns, so please like, share and subscribe to this?newsletter ?for notifications of new posts.

Please comment on the post with your feedback, will help me improve!?:)

Until next time, Keep asking questions & Keep learning!