Closed magicprinc closed 8 months ago
Hi @magicprinc, thanks for the feedback. Yes, I agree much of the functionality is already there. I think this is a duplicate of #8 though and it's functionality planned for v0.4.0
. I'm not sure if switching from standby to primary is something Litestream itself will handle as it seems like the application would need knowledge of that as well and Litestream currently runs separately from it. I'm still thinking through how that cut over could work automatically.
I think #8 is more complicated: In active/standby scenario a standby database is inaccessible for other clients.
I'm not sure if switching from standby to primary is something Litestream itself will handle
It shouldn’t handle it itself: it should simply check "flag" file (or something more complicated) to switch from replicate to restore mode and back
@magicprinc Ok, I'll keep this ticket open to track it. 👍
This has dropped out of scope due to live replication being moved to the LiteFS project.
As you know, in active/standby configuration, there is one active server and one or more standby servers. The active server works hard and its "binary log" aka "changes" are replicated to the standby servers and applied there. Thus, the standby server is always ready to become a new active server.
Litestream already has more than 70-80% of this scheme implemented!
• It runs as a service/daemon and constantly replicates changes to safe destinations (including file paths, which can be network paths to other “standby” server). • It can be used to restore these changes as a new database. • Litestream even has an option to periodically validate replicas by restoring them and comparing their checksum to the primary database’s checksum.
The idea is:
Litestream could work as a service on standby side too - by restoring changes constantly. (It can be expensive for S3, but great for two servers with high-speed connection.) For a configured database with path: /var/lib/db, Litestream could check flag "/var/lib/db.standby" (a empty file is enough). If this file doesn't exist, then run as usual (= in replicate mode). If this file exists, then run in restore mode.
Then downtime will be minimized to almost 0. Currently, it is quite big because one need to restore the latest version first, and it can last long... In the active/standby case, admin must only delete "standby status flag". Other apps on the standby server could monitor this flag too and access the database and do work only in its absence.
PS: Thank You very much for amazing product! It really extends the sphere of SQLite's applications a lot!