Replication Failure Scenerios

[voldyman]

Is there a scenario where the data written to SQLite by the application won't be durable?

I don't know enough of SQLite functioning to be sure but my mental model is:

Process 1 (Application): Write to SQLite -> SQLite appends entry in WAL
Process 2 (Litestream): hits monitor interval -> Reads txns from SQLite WAL -> Updates in S3

If host died between the monitor interval and there were pending writes, the changes would be lost. Is this accurate?

Thanks for the great project!

[voldyman]

Read more of the code and found that the WAL is continuously uploaded to S3, faster than the monitor interval. So the interval of missing out on WAL is shorter.
observation based on code

[benbjohnson]

Yes, that's an accurate mental model. Litestream performs asynchronous replication similar to PostgreSQL's streaming replication so there is a small window for data loss in the event of a catastrophic failure. I plan to add synchronous replication in the future as well but that can incur a performance and availability penalty so it would need to be enabled explicitly.

As for intervals, there are two main ones in Litestream. There's a monitor interval that moves WAL pages from the primary DB's WAL file to a shadow WAL file that can be read by replicas. This interval defaults to 1s and is mainly to limit resource usage on the machine. Then there's also an interval for the S3 replica that specifies how frequently WAL files should be uploaded to S3. This interval defaults to 10s and is mainly to limit costs as there is a per-request charge on S3. This default interval value costs about $1.30/month if you have constant writes against the database. You can adjust the interval up or down depending on your cost requirements and your tolerance for data loss in the event of a catastrophic failure.

[voldyman]

thanks for the detailed answer!