kocolosk commented on issue #602: Security objects cannot be synced if nodes are in maintenance mode URL: https://github.com/apache/couchdb/issues/602#issuecomment-333706653 @janl no, that wasn't what I was suggesting; I was only explaining why this sort of thing tends to not crop up in production. I'd agree that a user should not voluntarily put a majority of cluster nodes into maintenance, but if that user is unlucky enough to lose 2/3 of a cluster and she still wants predictable responses to view queries then she may well end up in this position. I was suggesting setting a flag somewhere in the codepath of `mem3_sync_security` that would allow it to retrieve security objects from nodes in maintenance mode. One (slightly hacky) way to do that would be to set a custom IO priority for the request. This is not without its own issues, though ... in the case I described above where 2/3 of the cluster was destroyed a sync process patched in this way could actually remove the security settings from the remaining healthy nodes, since the shards on the rebuilding nodes would constitute a simple majority of all database shards and "outvote" the healthy ones. The proper fix here is to introduce versioning into security objects. I recall some attempts at doing so over the years but also recall those attempts running into unexpectedly gnarly corner cases. @davisp and @chewbranca may remember more. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
With regards, Apache Git Services
