We've seen a few customer cases where dbCheck is executed on the set, resulting in asymmetric lag. In these cases, a common recommendation is to set batchWriteConcern: n = # of nodes, since the expectation is that dbCheck will block each batch on all nodes responding (effectively throttling dbCheck until the lagged secondary recovers). We should add a test to ensure that this behavior is correct and is a valid recovery strategy.