5 ms·
Looks very interesting! > The switch is made by putting the user on the source database in READ ONLY mode, so that it is not accepting any more writes and wait
by tudorg 3y ago
Looks very interesting!
> The switch is made by putting the user on the source database in READ ONLY mode, so that it is not accepting any more writes and waits for the flush lag to be 0. It is up to user to kick of a rolling restart of your application containers or failover DNS (more on these below in strategies) after the switchover is complete, so that your application isn't sending any read/write requests to the old/source database.
This does mean that there will be a "downtime" during which the DB is in read-only mode, right? I understand this period can be really small, but that depends on how long the app deployment takes.
- shayonj 3y agoThanks for taking a look! Thats right, it was a typo. Mean't zero data loss and minimal downtime. There are some strategies in the readme like using weighted based DNS failover to reduce the downtime even less without requiring application deployment.
- CoolCold 3y agoSimple LB like Haproxy works fine for this and similar cases. In very nutshell, Haproxy executes checks every n seconds (in your case it can be readonly mode checks ) and disables that upstream. We use it over Mysql/Pg+patroni/Redis and works fine - we made tests for low load though, just up to 5k qps fot PG case and up to 80k rps for Redis case.
- nijave 3y agoThis can be done with pgbouncer and you can suspend the database so pgbouncer "holds" connections. If the application has high enough timeouts, it will look like it's just taking longer than normal to connect.
- CoolCold 3y agoThat specific case and if you can afford PgBouncer, I agree with you. On a wider scale, Haproxy adds value - auto tracking on sync/async replicas, replica lag windows, falling back on master if all replicas lagging/down, so on.