We’ve got an app with a Region Pool set to syd. Over the past few deploys we’ve seen the app running in hkg, sin, mia(! long way from syd) and maa. Is there an issue with the syd at the moment?
Our db is located in syd, and whenever the app deploy is not syd performance is significantly degraded, I’m assuming from the app <-> db communication. Are there docs explaining how to get a clustered db working across 2 or more regions?
Just to check, when you run fly regions list, do you see any backup regions listed? They are a legacy pool but if e.g hkg is listed, that would explain why that sometimes gets picked. You can remove them using (I think) fly regions backup set (ie setting none). Which should just leave syd.
You can also “pin” an app to a region by attaching a volume. If an app has a mounted volume in a region, that takes precedence: fly volumes · Fly Docs So that may help keep your app in one place too (you could add a small 1GB one to minimise cost).
As for making a clustered database, there is indeed. You would have a primary (in syd) and then add read replicas in other regions. Take a look at:
We have a volume attached in syd and no backup regions. Our latest deploy went to Brazil, so it seems that the volume is not having any effect on where our deployment ends up.
Instances
ID PROCESS VERSION REGION DESIRED STATUS HEALTH CHECKS RESTARTS CREATED
bf8bfea1 app 13 gru run running 1 total, 1 passing 0 51m39s ago
❯ fly volumes list -a vex-staging
ID STATE NAME SIZE REGION ZONE ATTACHED VM CREATED AT
vol_k0o6d42lj67r87gy created vex_staging_data 3GB syd 2958 4 days ago
Of course I worked out the issue 2 mins after posting here.
I hadn’t attached the volume to the application as detailed at Volumes.
Once that was done the deploy is working as expected.