Log file Viewer

[11:59:57] <hackeron> Hi there, I have a replica set and one of the servers went offline, I restarted the primary server and it has been an hour and it's still not listening on port 27017 -- the CPU is at 500% and I'm seeing this in the logs: "2020-11-28T11:58:38.957+0000 I REPL [repl writer worker 11] applied op: CRUD { ts: Timestamp(16065..." -- any ideas? - is there anyway to skip those operations to get Mongo back up

[12:00:04] <hackeron> and running and do thee in the background? - I'm on version 4.0.21

[12:06:31] <hackeron> also seeing this occationally in the logs: 2020-11-28T12:05:47.930+0000 I COMMAND [initandlisten] command local.oplog.rs command: getMore { getMore: 27454798672, collection: "oplog.rs", $db: "local" } originatingCommand: { find: "oplog.rs", filter: { ts: { $gte: Timestamp(1606501290, 60) } }, oplogReplay: true, $db: "local" } planSummary: COLLSCAN cursorid:27454798672 keysExamined:0 docsExamined:25407

[12:06:37] <hackeron> numYields:199 nreturned:25407 reslen:16764380 locks:{ Global: { acquireCount: { r: 200 } }, Database: { acquireCount: { r: 200 } }, oplog: { acquireCount: { r: 200 } } } storage:{ data: { bytesRead: 17102721, timeReadingMicros: 418728 } } protocol:op_msg 477ms

[12:08:23] <hackeron> here's the complete beginning of the log: https://pastebin.com/g0YqFsRy

[16:35:37] <d4rkp1r4t3> whats the output of rs.status()? another member of your replset may have became primary when you restarted the primary or the when the other server went offline. those are replication commands so it might be that its trying to sync with the primary but there is too much replication lag to ever catch up.

[16:39:47] <d4rkp1r4t3> and since they are logging replication commands, i would have to imagine it is listening on port 27017 to receive those commands. whats the output of 'netstat -nap | grep LISTEN | grep tcp' ?

[16:42:50] <d4rkp1r4t3> oh nm. i see in the logs it says 'Replaying stored operations from ...' from Fri Nov 27 13:21:30 to Sat Nov 28 06:17:55 . so theres quite a bit it has to catch up on it looks like before it enters into primary/secondary state

[16:43:52] <d4rkp1r4t3> rs.conf() and rs.status() would still be helpful though