fencing ... relates to a master/slave cluster as in how?
Because when you promote a slave, you also need to fence writes to the old master, otherwise you can end up in a "split-brain" scenario, where the old and new masters are both accepting writes, and nobody's replicating.
Have fun cleaning that up.
(them not being relational is irrelevant to replication)
I disagree. Their being relational imposes extra constraints upon replication. ACID?
Look, I'm rapidly losing interest in going back and forth like this. You don't seem very interested in the validity of another perspective, but rather just keep finding fault in things that don't do it your preferred way. If you want to have a discussion, I'll play. If not, let's just walk away.
Because when you promote a slave, you also need to fence writes to the master, otherwise you can end up in a "split-brain" scenario.
There is only one master, hence there can not be a "split brain". You seem to be confusing master/slave and multi-master configuration (which pg doesn't support).
I disagree. Their being relational imposes extra constraints upon replication. ACID?
Well, it doesn't.
Look, I'm rapidly losing interest in going back and forth like this.
You claim things are "easy" that you clearly haven't done before. I was merely calling you out on that, but agree the discussion is unlikely to go anywhere from here.
Edit: Oh and you retouching your comments all the time doesn't help either (the split-brain paragraph just changed...). I'm out.
> There is only one master, hence there can not be a "split brain".
That's very naive. There are situations -- very real ones -- where the failing master doesn't know it is failing, where clients can still connect and the new master can't safely tell the old one to stop being a master. This is where fencing comes in, and other concepts like heartbeats and STONITH and backup interconnects and so on, all of which makes automatic failover complicated and error-prone.
There are good reasons that 35+ years after the invention of the relational database, only the top commercial ones implement this really cleanly (but they still require expensive dedicated DBAs, for the most part).
You claim things are "easy" that you clearly haven't done before.
I've been a PostgreSQL DBA for a decade, and built HA setups for my last three employers. Care to reevaluate your claims of what I have or haven't done?
Because when you promote a slave, you also need to fence writes to the old master, otherwise you can end up in a "split-brain" scenario, where the old and new masters are both accepting writes, and nobody's replicating.
Have fun cleaning that up.
(them not being relational is irrelevant to replication)
I disagree. Their being relational imposes extra constraints upon replication. ACID?
So how do you monitor e.g. the replication lag?
Icinga invokes this: https://bucardo.org/check_postgres/check_postgres.pl.html#re...
Look, I'm rapidly losing interest in going back and forth like this. You don't seem very interested in the validity of another perspective, but rather just keep finding fault in things that don't do it your preferred way. If you want to have a discussion, I'll play. If not, let's just walk away.