[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