Enable WAL for SQLite

[asymmetric]

As discussed in #2917 (comment), it makes sense to use the WAL for SQLite installs.

Further optimizations are possible (e.g. synchronous = NORMAL), but since they require tradeoffs (e.g. for the DB's durability), they have not been implemented in this PR, and could be implemented in a follow-up PR.

Pull Request Checklist

• Pull request is based on the develop branch
• Pull request includes a changelog file. The entry should:
  • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
  • Use markdown where necessary, mostly for code blocks.
  • End with either a period (.) or an exclamation mark (!).
  • Start with a capital letter.
  • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
• Pull request includes a sign off
• Code style is correct
  (run the linters)

[richvdh]

is it correct that we do this on every new connection? According to https://www.sqlite.org/wal.html#persistence_of_wal_mode it seems like it is persisted in the database, so shouldn't it just go in a database schema migration file?

[asymmetric]

Indeed, it's sufficient to do this once (although doing it every time won't cause issues). Any pointers on how to implement this as a migration?

[richvdh]

Have a look at https://matrix-org.github.io/synapse/develop/development/database_schema.html#delta-files.

[DMRobertson]

It doesn't look like the pragma will be dumped when we do a full schema dump :

$ sqlite3 test.db
-- Loading resources from /home/dmr/.sqliterc
SQLite version 3.36.0 2021-06-18 18:36:39
Enter ".help" for usage hints.
sqlite> PRAGMA journal_mode;
journal_mode
delete
sqlite> PRAGMA journal_mode = WAL;
journal_mode
wal
sqlite> .schema
sqlite> .dump --data-only --nosys
sqlite> .dump 
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
COMMIT;
sqlite> 

So: if we effect this change via a migration, new installations won't benefit from this the next time we take a schema dump.

[richvdh]

Can you share any metrics about any performance improvement this brings?

[asymmetric]

@richvdh I don't have my own metrics to share, no, but from a purely theoretical POV, this allows multiple concurrent readers, so it's the first step towards improving read performance (once multiple connections are allowed).

It also allows for backup solutions like litestream, which rely on the WAL file existing.

On SQLite's WAL page it says that

WAL might be very slightly slower (perhaps 1% or 2% slower) than the traditional rollback-journal approach in applications that do mostly reads and seldom write.

but this is not the case for a chat servre, I reckon.

So in my opinion this strictly improves the SQLite situation, with no negative consequences I can think of.

[richvdh]

@asymmetric ok; can I at least confirm that you have tried it out on a real server?

[asymmetric]

Indeed, we have been using this PRAGMA on our homeserver without issues. Note that I just ran the query manually instead of running a modified version of synapse, but that shouldn't malke any difference.

I'll look into adding a migration.

[reivilibre]

The WAL also means that readers and a writer can co-exist and access the database at the same time. I think it's very sensible to try this with Synapse