split brain issue about repmgr

[ibarwick]

Hi Jin

repmgrd does not currently support this kind of functionality. We are currently working on a new version with improved features, including improved metadata which would make it easier to support situations where "STONITH" ("shoot the other node in the head") is required.

Please note that the witness server does not function as a controlling instance for the cluster; it exists to ensure an odd number of nodes are running to provide a "casting vote" when deciding which node to promote in the kind of split brain situation you describe.

Regards

Ian Barwick

[tkrajca]

Hi Jin,

I think I have got a working version of repmgrd for your scenario.

Basically, I added a 'gateway' configuration option. If a gateway is set, then the master (only the master) monitors/pings its gateway, if it detects that gateway is down for a configured period of time (the configured period of time is slightly smaller than the configured period of time for the master being down at the moment) - it cannot ping it any more, the master shuts itself down.

This should be pretty much how pgpool2 handles these types of scenarios.

So in your case, after shutting the network interface of the master down, repmgrd should shut the master down after a little while - just before the new master is promoted from the available slaves.

I'll add a pull request in a second, it would be great if you could review it/test it.

Thanks,
Tomas

[tkrajca]

PR here #46

[martinmarques]

This doesn't seem to be an issue really. repmgr is not where you have to look for STONITH (although it could be done with some scripting and the new events triggering them).

Closing this now