I’ve set up a simple fly postgres server and I’ve been trying to wrap my head around the “replication” topic, to deploy the database on multiple machines and in multiple regions.
Does replication automatically work? Do I just have to add machines/region and that’s it?
Do I need at least 3 machines in each region so that replication works/is enabled?
Does replication mean that it automatically keeps all machines in sync, so that I still have a “single” database from outside I can access (like a Grafana dashboard)?
Finally, I fear that replication doesn’t even work in my use case. I’m only using to store log messages and user mails in my database, so it’s a write heavy scenario. As I understand it, replicas are primarily for read-only scenarios?
The documentation links to nats.io for that case, but this is completely overwhelming for me. I have absolutely no idea whatsoever what to do with that. The website’s description is really confusing. Is it a separate data storage? Or a way to write asynchronously to my postgres database? Do I need to set yet another fly app running nats.io, just to write to my database?
Hi… No, you typically have only one machine in each of the non-primary regions.
The three machines are for failover during deploys and migrations—or even hardware crashes, .
Replicas are strictly read-only, and if your nodes in all regions mainly just want to write, then this style of distributed database won’t help you much.
NATS was mentioned in the logging case exactly because it is a distributed messaging system. (Indeed, it’s the one that the Fly.io platform itself uses for logs, last I checked.) Your nodes in other regions send messages to the one that actually owns the database.
(You can do that in other ways, too, e.g., with HTTP calls on the .internal network or with Elixir’s native RPC.)
Hope this clears things up a little!
Aside: This part of Fly’s documentation assumes that you already know the basics of distributed systems, which is maybe why there is a “missing stair” feeling suddenly.
(Fly is one of those organizations where “Advanced” in the index title really does mean what it says…)
Thanks for the reply, that does make things a bit clearer Yeah, the documentation definitely assumes a lot of experience and knowledge in some areas, which is unfortunate.
So, I feel like I have two choices, since I have to keep it basic because one, I have no idea what I’m doing, and two, I’m using a Swift Vapor backend, so support for all the cool stuff that other backend systems have is rather limited, I’m afraid.
Setting up NATS
This would make the server infrastructure even more complicated for a noob like me. I already have my backend + postgres servers, one set for a staging environment and one set for a production environment. Adding a NATS app (and then probably another app that actually writes the messages from NATS to the database, if I understand that part correctly) will make my head explode. How do people do these things, especially on even lower level platforms like AWS ?
Using HTTP calls and .internal urls
I guess this would be simple but could add a lot of latency to the calls, unless I make the call asynchronously from my backend and don’t wait for it to return. Though I have no idea what side effects that would have (like fly shutting down idle machines; I don’t know if it were able to detect such asynchronous calls and wait)
There are other options, but I think you do have the right drift overall, …
Fly likes NATS a lot, but it’s definitely not the only messaging system. And a person could also consider non-Postgres databases that are designed around eventually consistent, multi-master writes (as the documentation mentions in passing).
I go the Elixir/Erlang route myself (+ LiteFS primary-swapping hijinks, maybe, for “pickle jar” cases), but @poundifdef is promoting SQS on Fly.io lately, if I understand correctly.
He might be able to give some quick intuitions about whether that messaging subsystem would be easier in this particular context…
.
?
…