Documentation > Deployment > Command Logging
The write-ahead logging project is designed to augment the speed of a main-memory system with the stability of disk. Rather than implementing an ARIES-type physical log, since OLTP workloads are characterized by many small transactions, write-ahead logging in the context of H-Store is best implemented as redo-only “command logging.” The command log stores logical information about each committed transaction, such as the transaction ID, procedure name, and procedure parameters. Only committed transactions are sent to disk because aborted transactions can be undone in memory.
The project also implements a number of throughput optimizations, including sharing the log (per site), group commit, and data compression. Using group commit, many transactions are queued and held until the buffer fills, when they are all flushed out to disk in batch (and compressed). This greatly improves average throughput at the slight expense of average latency and some memory overhead.
Usage
The following new site configuration parameters moderate command logging:
- site.commandlog_enable (boolean) – default false – set to true to turn on command logging
- site.commandlog_dir (string) – default global.temp_dir + ‘/wal’ – set to the desired directory path where the log will be stored
- site.commandlog_timeout (integer) – default 500 – the time in milliseconds before the group commit buffer is flushed if it is not filled
To run a TPC-C benchmark with the most basic command logging on (sharing the log but no group commit):
ant hstore-benchmark \ -Dproject=tpcc \ -Dsite.commandlog_enable=true
And to use group commit (+ compression):
ant hstore-benchmark \ -Dproject=tpcc \ -Dsite.commandlog_enable=true \ -Dsite.commandlog_dir="/tmp/hstore/" \ -Dsite.commandlog_timeout=500
Note that group commit is most effective when the database is under high load. If H-Store has time to write to disk between each transaction, group commit should be turned off.
Known Issues
- There is an occasional bug where sending the response after a group commit will trigger a ClosedChannelException. Fixing it should not affect throughput significantly.
- Still need to write recovery and distributed log playback code (in conjunction with snapshot recoveries).