|
Even though the fix adds a potential mutex acquisition into canAcceptWritesFor and checkCanServerReadsFor, I don't believe it comes with a real performance cost. The mutex acquisition can only possibly happen if those methods are called on the oplog namespace. Normal writes on the primary and secondary do not ever call into canAcceptWritesFor() for the oplog write, so the only cost from acquiring the mutex on oplog writes in canAcceptWritesFor() is for user-initiated writes to the oplog. Reads done for replication will call checkCanServerReadsFor against the oplog namespace, but usually against a node that is in PRIMARY or SECONDARY states, and the fix does not lock the mutex if the node is primary or secondary. The only time I think this change results in a mutex acquisition that wasn't there previously is for oplog reads from a node that is in RECOVERING, which shouldn't pose a practical performance problem.
|
|
Unfortunately, I don't believe that we can fix this by simply locking mutexes, as the perf impact will be too great. However, for canAcceptWritesFor(), we might be able to check ns.isOplog() first, and then lock the mutex and check _memberState if true.
Similarly for checkCanServeReadsFor().
|