Understanding Write Ahead Logging: 4 Comprehensive Aspects

The technique of Write Ahead Logging (WAL) is hugely popular among database systems and database professionals. This approach has an edge over the traditional Rollbacking method as it ensures that no record of the transaction will be lost. It stalls Data Flushing and first transfers the associated transaction logs to the database. Then only it sends the required data records to the disk. Why do we do this? The simple answer is to maintain the ACID properties of a transaction. Therefore, WAL plays a major role in preserving the ACID properties of transactions.

This article introduced Write Ahead Logging and lists its key features. It also explains the important concepts of WAL and elaborates on its work. Moreover, the article provides 3 easy steps to use WAL for your database. Read along to learn more about WAL and understand its limitations.

What is Write-Ahead Logging?

The Write Ahead Logging (WAL) technique is a popular method among database users to preserve the atomicity and durability of their data writes. This technique operates on the concept of logging your data writes in secure storage prior to making any permanent changes in your database. This way you can ensure the durability of your writes in case of a server crash.

This will allow you to just copy the required log entry and use it again as a data write if there is any sudden loss in your database. Moreover, since your log entries will be in sequential order, you can maintain the atomicity of your data operations by referring to the logs in the event of a server crash.

Write Ahead Logging maintains individual logs for every server process stored in a sequential manner. Every single log entry has a unique identifier to avoid any confusion. Moreover, these identifiers facilitate certain operations on the log, such as Log Segmentation, Log Cleaning with Low-Water Mark etc. Furthermore, a general log entry looks like the following:

class WALEntry…

  private final Long entryIndex;
  private final byte[] data;
  private final EntryType entryType;
  private final long timeStamp;

Key Features of Write Ahead Logging

The following features are responsible for the popularity of Write Ahead Logging:

• Reduced Disk Writes: WAL reduces the amount of disk writes significantly as you only need to flush the log file to the disk when committing a transaction. This is an optimal method rather than writing every transaction directly on the disk. 
• Decreased Syncing Cost: Since log files accept data sequentially, the syncing cost of log data is much less as compared to that of flushing data pages. This is beneficial, especially for servers managing numerous small transactions using different parts of your data store.
• Fast Redo Operation: WAL supports high-speed roll-forward recovery (REDO). This implies any modifications that were aborted in between can be recovered from the log records. 
• Accessible Data Backup: WAL caters to your data backup needs and also provides you with backup and point-in-time recovery. You can simply archive the WAL data and revert to any time instant that occurred prior to the latest data write.

To learn more about Write Ahead Logging, visit here.

Key Factors in Write Ahead Logging

The Write Ahead Logging technique works to provide a safety net for your daily transactions. To understand its working, you need to first understand its following key concepts:

• Checkpoints
• Performance

Checkpoints

A “Checkpoint” operation transfers the Write Ahead Logging file transactions into your database. The normal rollback contains only 2 operations namely, Reading & Writing. However, WAL takes it a step further and adds a third operation called Checkpointing. You can even perform a Checkpoint and Read operation concurrently which will in turn boost your database’s performance. 

A Checkpoint operation must stop only when it reaches a WAL page that succeeds the end mark of any of the current read operations. This is to prevent overwriting in the database file. Furthermore, a Checkpoint stores the WAL index to memorize how far it got. This allows it to resume the transfer of WAL data to your database from the point where it left off in the last transfer. A long-running Read operation can prevent a new Checkpoint from moving forward, but since every Read operation eventually ends, the Checkpoint can continue.

Performance

Using Write Ahead Logging provides you with faster Write transactions as they only require you to write the data once. This is an improvement over the Rollback method which involves writing the journal transactions 2 times. Read operations, on the other hand, show a deterioration in performance with an increase in the WAL file size. This is due to the direct proportionality between the time required to read a WAL file and its size. Therefore, to have a high Read performance, you need to keep the WAL file size low by performing Checkpoints periodically. 

Understanding the Write-Ahead Logging Process

The Write Ahead Logging approach preserves your original data in the database and appends the modifications in a distinct WAL file. Moreover, a COMMIT operation occurs only when you add a record to WAL, indicating a commit operation. This implies, that your data can COMMIT without even writing to the actual database. This way, your clients can continue to read data even when changes in WAL are going on.

The Write Ahead Logging facility surely ensures that your data writes are secure at all times. However, you must consider certain technicalities while performing the “Flushing” operation. The file handling libraries in most programming languages today contain a method which forces the operating system into ‘flushing’ the file changes to the disk. To maintain a smooth data flushing, you must ensure the following:

• If you will be flushing every log write to the disk, it will provide you with high durability but these constraints hamper your disk performance. Moreover, if your data flushing operation suffers from delay, you will get better performance but at the risk of losing log entries in case of a server crash. Therefore, flushing data in batches is the most sought after method while implementing Write After Logging. This way, you will get maximum performance at minimum risk.
• WAL entries can often have corrupted log files. You must detect such files to avoid disruptions in the data writes. To overcome such bottlenecks, save log entries via CRC (Cyclic Redundancy Check) records, which allows validation at the time of data read.
• Utilize Segmented Log and Low-Water Mark Single to simplify your log file management tasks. Moreover, these techniques will allow you to prevent the fast consumption of your storage. 

Steps to Configure Write-Ahead Logging for Databases

• Step 1: Convert the Default Setting to the WAL Mode
• Step 2: Set Up Automatic and Forced Checkpoint Settings
• Step 3: Use Checkpoints Initiated by Applications

Step 1: Convert the Default Setting to the WAL Mode

As default, any SQLite database connection has the setting, journal_mode=DELETE. To convert this setting to WAL mode, use the  below code:

PRAGMA journal_mode=WAL;

The above code will return a “wal” string that will represent the new journal mode. However, if the WAL conversion will fail, then the journaling mode will remain unchanged and the returned string will be the prior journaling mode.

Step 2: Set Up Automatic and Forced Checkpoint Settings

An SQLite database automatically checkpoints whenever a COMMIT operation occurs and causes an increase in the size of your WAL file (1000 pages or more). Another situation for an automatic Checkpoint is when you close the last database connection on a file. This default configuration works well for most applications. However, if a program requires a higher level of control, then it may force a Checkpoint operation using the wal_checkpoint pragma. Alternatively, such a program can also call the sqlite3_wal_checkpoint() C interface to enforce a Checkpoint.

You can also change the threshold for automatic Checkpoint call by disabling the wal_autocheckpoint pragma or by using the function from the C interface, sqlite3_wal_autocheckpoint(). 

Step 3: Use Checkpoints Initiated by Applications

Any application can launch a Checkpoint operation in WAL using a writable database connection by invoking the sqlite3_wal_checkpoint() or sqlite3_wal_checkpoint_v2() function. Moreover, Checkpoints, based on their aggressiveness are of 3 types PASSIVE, FULL, and RESTART. The PASSIVE Checkpoint is used as the default option and performs its work without interfering with any other database connections. This implies, the PASSIVE option may not run to completion concurrent readers or writers are present. 

The FULL and RESTART Checkpoints work harder than the PASSIVE option to run the Checkpointing to completion. They need to be called using the sqlite3_wal_checkpoint_v2() function.

Limitations of Write-Ahead Logging

Write Ahead Logging comes along with the following limitations:

• WAL requires that your VFS must work with shared-memory primitives. Unix and Windows VFSes are compatible with shared memory but if you wish to use third-party extensions, then WAL will not function. Moreover, Since WAL does not operate over a file system shared across a network, all of your applications using various databases must reside on the same host computer.
• You can not change the page_size once you have entered the WAL mode. Moreover, this resection is valid for both, an empty database and a backup API. You can only change a page size if you are present in a rollback journal mode.
• WAL is slightly slower (approximately 1% or 2%)  as compared to the traditional rollback-journal technique. This is especially the case for applications that focus on Read operation and use the Write operation rarely.

Conclusion

The article introduced you to Write Ahead Logging and discussed its key features. It then explained the key concepts and working of WAL and discussed how it performs better than the rollback technique. Moreover, the article discussed the steps required to configure WALs for your system and mentioned its limitations.

Visit our Website to Explore Hevo

Now, to perform Data Analytics on your log data, you first need to export this data to a Data Warehouse. This will require you to custom code complex scripts to develop the ETL processes. Hevo Data can automate your data transfer process, hence allowing you to focus on other aspects of your business like Analytics, Customer Management, etc. This platform allows you to transfer data from 100+ multiple sources to Cloud-based Data Warehouses like Amazon Redshift, Snowflake, Google BigQuery, etc. It will provide you with a hassle-free experience and make your work life much easier.

Want to take Hevo for a spin? Sign Up for a 14-day free trial and experience the feature-rich Hevo suite first hand.

Share your understanding of Write Ahead Logging in the comments below!