ServerDB, Meta: add support for SQLite WAL.

Using SQLite's WAL (write-ahead log) can create less disk I/O while
still providing good consistency and durability.

This change uses SQLite's WAL with synchronous=NORMAL which can
cause loss of transactions on power failure. Only the transactions
which haven't been synced to the disk by the OS are lost. The
database itself will still be in a consistent state, but it might
not have all recent changes.

1 files changed, 20 insertions, 0 deletions

diff --git a/scripts/murmur.ini b/scripts/murmur.ini
index b4b83d225..07f039fb0 100644
--- a/scripts/murmur.ini
+++ b/scripts/murmur.ini
@@ -15,6 +15,26 @@
 ; murmur.sqlite in default locations or create it if not found.
 database=
 
+; Murmur defaults to using SQLite with its default rollback journal.
+; In some situations, using SQLite's write-ahead log (WAL) can be
+; advantageous.
+; If you encounter slowdowns when moving between channels and similar
+; operations, enabling the SQLite write-ahead log might help.
+;
+; To use SQLite's write-ahead log, set sqlite_wal to one of the following
+; values:
+;
+; 0 - Use SQLite's default rollback journal.
+; 1 - Use write-ahead log with synchronous=NORMAL.
+;     If Murmur crashes, the database will be in a consistent state, but
+;     the most recent changes might be lost if the operating system did
+;     not write them to disk yet. This option can improve Murmur's
+;     interactivity on busy servers, or servers with slow storage.
+; 2 - Use write-ahead log with synchronous=FULL.
+;     All database writes are synchronized to disk when they are made.
+;     If Murmur crashes, the database will be include all completed writes.
+;sqlite_wal=0
+
 ; If you wish to use something other than SQLite, you'll need to set the name
 ; of the database above, and also uncomment the below.
 ; Sticking with SQLite is strongly recommended, as it's the most well tested