-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
Minor Change
-
ALL
-
v4.2, v4.0
-
Repl 2019-07-29
-
47
Issue 1)
The issue:
The node complains that the namespace "oplog.rs" doesn’t exist, and the test fails on the assert that tries to drop “oplog.rs”, here. This failure happens on an ephemeral storage engine, the ephemeralForTest storage engine. The node is restarted at some point, to take it from being a part of a replSet to being a standalone. However, in the process of restarting (i.e. shutting down and starting back up), the ephemeral storage engine is wiped and loses its “oplog.rs” collection (which it had when it was a part of a replSet), thus leading to the failure saying the namespace doesn’t exist when we attempt to drop it.
Other points: The InMemory WiredTiger storage engine does not fail this way, despite the reasoning given above. On requesting the database to drop the “oplog.rs” namespace, the database first performs a check to make sure dropping “oplog.rs” (or any other oplog namespace) is allowed and then proceeds to actually try and drop it. The InMemory WiredTiger storage engine therefore doesn’t actually try and drop this namespace, because it doesn’t get that far. This check isn't triggered when using the ephemeralForTest storage engine.
Proposed fixes:
*Currently the node is started as a part of a replset and then restarted as a standalone. It might be better to just start up as a standalone directly and manually insert the oplog. This will guarantee that an oplog is present, and will also remove the test's reliance on methods like ReplicaSetTest's initiate() that aren't relevant. I think this is the best solution. See here *
Another solution is to surround the entire dropping portion of the test (lines 29 to 35) with a check to make sure “oplog.rs” exists first. This is a decent solution, because it accounts for any other storage engines that may have similar behaviors. Also, the purpose of the entire test is to see if forbidding the oplog works.
A third solution is to alter the ephemeralForTest storage engine to make it resemble the WiredTiger InMemory storage engine, but I don’t think this is a good approach. The InMemory WiredTiger storage engine has a bug (in supportsRecoveryTimestamp) which is why it behaves differently from the ephemeralForTest storage engine (mentioned above), and the ephemeralForTest shouldn’t adopt that bug as well.
Issue 2)
The issue:
Not all storage engines support the replSetResizeOplog command (see SERVER-38356). In an attempt to maintain the same starting state for each iteration of the test (by maintaining the same oplog size), the replSetResizeOplog command is used but fails on the ephemeralForTest storage engine, which does not support the command.
Proposed fixes:
A solution is to remove the line that tries to maintain uniformity at the start of each test. Since this is a part of the auth suite, it is unlikely that the particular size of the oplog even matters.
Another solution is to introduce the isWiredTigerOrInMemory() check - only when it is true, then issue the replSetResizeOplog command. Otherwise, just drop and create a new oplog. I think this is the best solution.
- is duplicated by
-
SERVER-42131 Modify test to account for storage engines that do not support the replSetResizeOplog command
- Closed
- is related to
-
SERVER-38356 Forbid dropping oplog in standalone mode on storage engines that support replSetResizeOplog
- Closed