[Info-vax] Quorum strategy
Stephen Hoffman
seaohveh at hoffmanlabs.invalid
Wed May 22 17:34:53 EDT 2019
On 2019-05-22 20:18:44 +0000, Hans Bachner said:
> I believe Marc also mentioned somewhere (can't find that right now...)
> that the secondary node could/should be used for some
> analysis/troubleshooting tasks before it is rebooted.
What I'm referring to as the secondary can do that.
If the secondary is wedged while the primary is down, the secondary can
be manually selected to continue its processing using the IPLC handler.
Or rebooting the secondary as primary, or rebooting in a degraded or
restricted configuration pending promotion to primary.
That IPLC processing could conceivably be automated using outboard
keep-alive processing, and a whole lot of testing.
> This would not work if only the primary node had a vote.
Sure it would.
> It even could not be cleany shut down before rebooting it as the "new primary".
I stated that the reboot would require parameter changes to adjust the votes.
Would I want to design apps and a cluster configuration to work this way? No.
App changes would provide better results.
But the no-changes requirements precludes other approaches.
There is no good way to solve this within the constraints.
I'd like to believe we can still have isolated systems running static
configurations and forever and with no changes. A very few folks
actually do manage that, too. Most of us are increasingly running with
less-than-fully-isolated and increasingly connected servers, and many
of these configurations with little or no control over peer servers and
even less over clients. In recent years, software is no more "done"
than lawns are "mowed". We've done remote software upgrades on Mars,
after all. https://www.nasa.gov/jpl/msl/mars-rover-curiosity-20131220/
--
Pure Personal Opinion | HoffmanLabs LLC
More information about the Info-vax
mailing list