I’ve written a backend for an application for a local business that doesn’t need multi regions and doesn’t do much writes to the DB but mostly reads from it, I’m actually using postgres but sqlite would most likely be enough in this situation.
The problem is that the volumes’ docs says : The first rule of Fly Volumes is: Always run at least two of them per application. If you don’t, at some point you’ll have downtime.
But as I understand having 2 apps (since 1to1 relationship between app and volume) + each one with a volume where the sqlite db would sit wouldn’t work since there would be a problem when writing and things would get out of sync (I guess that’s what LiteFS fixes) .
Is that correct ?
I would also like to know why this warning, why would there be downtime with 1app/volume and which kind of downtime ?
Hi @Heroe. I think you understand the basic gist of it. Only one VM can attach to a volume at a time so when you deploy an application, we have to stop the VM and then restart it with the new code. That short period of time is where you’ll typically see downtime. It’s typically a very short window but it’s downtime for your app nonetheless.
Another possible but rare source of downtime is if the volume failed. We take regular snapshots of volumes so you would need to restore from the last snapshot in that case. You can also check out tools like Litestream which will continuously stream your database changes to S3 for disaster recovery.
If you can tolerate these risks for your app then you can run vanilla SQLite just fine with volumes.
The main benefits of LiteFS are being able to change the primary node dynamically and geographically distributing replicas of your data.
Ok thanks it makes sense, so it’s more a “run at least 2 apps to avoid downtime and thus 2 volumes” rather than a volume only thing right ? I think I can tolerate the little downtime during new deployments for now, I was fearing there were some technical reasons which would cause regular unexpected downtime with a single volume.
For the backup to S3 it’s mandatory with any database anyway so it doesn’t change much for me, I’ll check LiteStream (heard of it but naively thought liteFS was its replacement) but I guess I can also just have a cronjob that runs a script that upload the db file to S3 right ?
Yes, specifically it’s 2 VMs and each one has a volume. “Apps” on Fly.io can have multiple VMs. I hope I didn’t confuse you more.
Litestream still works great for disaster recovery for single-node applications. LiteFS is more of a distributed database although it’ll have some disaster recovery features coming in the near future.
There are some docs on the Litestream web site for running a simpler cron-based backup if Litestream is overkill for what you need:
Yes, specifically it’s 2 VMs and each one has a volume. “Apps” on Fly.io can have multiple VMs. I hope I didn’t confuse you more.
Yes sorry, miswording, if I get it an app represents your given code represented by a Dockerfile (the Linux VM being created from it) and you can have multiple VMs of a given app in different regions via fly machine clone
Litestream still works great for disaster recovery for single-node applications. LiteFS is more of a distributed database although it’ll have some disaster recovery features coming in the near future.
There are some docs on the Litestream web site for running a simpler cron-based backup if Litestream is overkill for what you need
