Write Ahead Logging

Write Ahead Logging

Accomplished Goals

• Multi-thread logging and recovery for concurrent txns
• Single-thread checkpoint creation and recovery
• Lightweight logging during transaction execution, only log committing txns
• Cooperate log recovery and checkpoint recovery
• Truncate/minimize log files by checkpoint

Logging Module Design

Logging manager controls all backend loggers and frontend loggers. It provides interfaces to query and manage these loggers. During Peloton startup, logging manager reads configuration file for log settings. Such as which logging protocol should be used.

The backend loggers are thread-local instances. It is responsible of collecting all logs generated in the work thread.

The frontend logger is a global singleton instance. Logging manager ensures all newly created backend loggers are linked to the frontend loggers. Then the frontend logger continuously collects logs from all registered backend loggers and flush log records to log file or other persistent store.

Logging Module Workflow and Important Interfaces

Recovery Protocol

1. Recover Checkpoint
2. Find min PCID of logs
3. Recover transactions in log between Checkpoint id and persistent commit id
4. Rebuild Indexes

Logging State Diagram

0. invalid
1. Standby -- Bootstrap
2. Recovery -- Optional recovery
3. Logging -- Collect data and flush when commit
4. Terminate -- Collect any remaining data and flush
5. Sleep -- Disconnect backend loggers and frontend logger from manager

Write Behind Logging

No tuple data in the log file

Only tuple header information is recorded in logs. We use database ID, table ID and tuple offset to refer tuple data in tuple data storage.

Write Behind Log

All modifications are directly applied to NVRAM without waiting for logs to be flushed.

We rely on MVCC to ensure consistency. So although the updated data is written to persistent storage immediately, they are not visible before all log items are flushed. When all logs get persisted, DBMS sets the version of the database to make all pending updates visible.

We control tuple update visibility by using commit bits (insert bit and delete bit). Only after logs flushed, logging thread starts to change commit bits in the tuples.

5 steps transaction workflow when doing WBL:

Extended logging workflow

A typical Peloton logging log file structure:

Recovery

Ensure previous run is not interrupt during changing commit bits. Otherwise, redo changing commit bits.

last_record = final log item in the log file;

If (last_record != flush_done_log) {

`return; // recover done`

} else {

`Scan file backward;`

`Set the file cursor after previous commit marked log.`

`Start read all logs from the cursor to the end of file.`

`Re-mark all tuples in these log records.`

}

Configuration Options

In postgresql.conf:

peloton_logging_mode       
       invalid             :  disable logging
       aries               :  enable logging
peloton_checkpoint_mode    
       invalid             :  disable checkpointing
       normal              :  enable checkpointing

Unit tests

Test commands

cd build/tests

./logging_test

./checkpoint_test

Test cases

writing_logfile: execute transaction and write logs.

recovery: turn off logging and write more dummy records. Then reset database and recovery.

Test options

-h --help : Print help message

-t --tuple-count : Tuple count.

-b --backend-count : Backend count. Only work for execute transaction.

-c --check-tuple-count : Check tuple count. Turn off when test performance.

-r --redo-all-logs : Force redo all logs. Execute transaction will fail because commit is not done

-d --dir : log file dir.