It's a great article, but I've always felt these are missing critical real-world application from the perspective of a full stack dev who also wants to manage their own databases.
- How do I check how many seconds the replica is lagging behind master?
- How would I monitor the replica? A simple cron task that pings a health check if everything is OK (lag is < x) would be a nice start.
And then things get complicated quickly:
- How do I failover to the replica if the primary goes down? There's pgBouncer, repmgr, patroni...
- Should I have it automatically or manually?
- Do I need 2 replicas to avoid the split brain scenario? my brain hurts already.
- After a failover occurs (either automatically or manually), how in the world am I going to configure the primary to be the primary again, and the replica to act as the replica again, going back to the original scenario?
I'd pay to learn this with confidence.
- How do I check how many seconds the replica is lagging behind master?
- How would I monitor the replica? A simple cron task that pings a health check if everything is OK (lag is < x) would be a nice start.
And then things get complicated quickly:
- How do I failover to the replica if the primary goes down? There's pgBouncer, repmgr, patroni...
- Should I have it automatically or manually?
- Do I need 2 replicas to avoid the split brain scenario? my brain hurts already.
- After a failover occurs (either automatically or manually), how in the world am I going to configure the primary to be the primary again, and the replica to act as the replica again, going back to the original scenario?
I'd pay to learn this with confidence.