31–40 of 63 posts
I know I am going to get fairly polarized responses on this one... Too bad it is written in Ruby.
What if it's written in Assembly (which is hard to read, maintained....) ?
I know I am going to get fairly polarized responses on this one... Too bad it is written in Ruby.
https://pgedge.github.io/spock/
which can also be used for online upgrades.
It however only supports Postgres 15 and (not yet released) 16
The fastest way to switchover is probably adding a iptables rule on the old server to DNAT to the new server. Unless you have a load-balancer or another network middleware like Kubernetes' clusterIP services (which uses iptables or IPVS internally). Waiting for a rolling restart or DNS cache expiration could take a while, during which the app is talking to a read-only database, if I understand correctly.
I guess this is pretty similar to what heroku does for pg updates? If using this tool for upgrades with minimal downtime, if I understand right, you need to orchestrate your db callers to switch over to the new primary at the right point, when it's ready? Tips for getting that to happen at just the right point to minimize downtime?
Great question: so you can watch the stats command. The command returns a JSON every second which has a switchover_completed_at field. It is updated the as soon as the switchover is complete. UPDATE: Some more reading material here: https://github.com/shayonj/pg_easy_replicate#switchover-stra...
I did this the "hard way" a year ago. This blog post came in handy: https://jstaf.github.io/posts/pglogical/ pglogical is magic. Keeping an eye on this project for the future, looks great.
> Binary replication only works with DBs of the same major version. If you want to replicate to a different version, well… you can’t. Is this true? I thought they fixed that at some point after PG11.
WAL streaming is still only supported between the same major versions and AFAIA that isn't going to change anytime soon.
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…
Thanks 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.
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.
If not, what would better approaches be