Todd Lipcon created KUDU-2370: --------------------------------- Summary: Allow accessing consensus metadata during flush/sync Key: KUDU-2370 URL: https://issues.apache.org/jira/browse/KUDU-2370 Project: Kudu Issue Type: Improvement Components: consensus, perf Affects Versions: 1.8.0 Reporter: Todd Lipcon
In some cases when disks are overloaded or starting to go bad, flushing consensus metadata can take a significant amount of time. Currently, we hold the RaftConsensus::lock_ for the duration of things like voting or changing term, which blocks other requests such as writes or UpdateConsensus calls. There are certainly some cases where exposing "dirty" (non-durable) cmeta is illegal from a Raft perspectives, but there are other cases where it is safe. For example: - assume we receive a Write request, and we see that cmeta is currently busy flushing a change that marks the local replica as a FOLLOWER. In that case, if we wait on the lock, when we eventually acquire it, we'll just reject the request anyway. We might as well reject it immediately. - Assume we receive a Write request, and we see that cmeta is currently flushing a change that will mark the local replica as a LEADER in the next term. CheckLeadershipAndBindTerm can safely bind to the upcoming term rather than blocking until the flush completes. - Assume we recieve an UpdateConsensus or Vote request for term N, and we see that we're currently flushing a change to term M > N. I think it's safe to reject the request even though the new term isn't yet durable. Probably a few other cases here where it's safe to act on not-yet-durable info. -- This message was sent by Atlassian JIRA (v7.6.3#76005)