-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: 3.2.17, 3.4.9
-
Component/s: Replication
-
None
-
ALL
-
v4.0, v3.6, v3.4
-
-
Repl 2018-10-08
The mongod instance in my production environtment suffers very big IO pressure, and I see a lot of oplog scan in the log like belows.
2017-10-23T17:48:01.845+0800 I COMMAND [conn8766752] query local.oplog.rs query: { ts: { $gte: Timestamp 1505624058000|95, $lte: Timestamp 1505624058000|95 } } planSummary: COLLSCAN cursorid:20808023597 ntoreturn:0 ntoskip:0 keysExamined:0 docsExamined:44669401 keyUpdates:0 writeConflicts:0 numYields:353599 nreturned:0 reslen:20 locks:{ Global: { acquireCount: { r: 707200 } }, Database: { acquireount: { r: 353600 }, acquireWaitCount: { r: 15 }, timeAcquiringMicros: { r: 3667 } }, oplog: { acquireCount: { r: 353600 } } } 935646ms
I found one of the secondary( a hidden node) is in RECORING state, I dive into the code and find the root cause.
The hidden node has following warning log
We cannot use xxx as a sync source because it does not contain the necessary operations for us to reach a consistent state ...
When secondary choose a sync source ,it will make sure the oplog in minvalid exist in the sync source,it will send a
- duplicates
-
SERVER-29843 Make oplog queries with point equality on ts field use getOplogStartHack
- Closed