-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: 2.6.11, 3.0.5, 3.1.4
-
Component/s: Replication
-
None
-
Replication
Now that SERVER-18280 is fixed, it is possible to see mongos messages such as:
2015-08-03T06:06:55.726+0000 I NETWORK [conn24] node HOSTNAME:PORT believes it is primary, but its election id of 55bf04a0c0f569a0268e3ab5 is older than the most recent election id for this set, 55bf04aacc82c473f5fa767f
However, when attempting to diagnose the source of this message, these election ids are not present anywhere in the shard logs (at default level).
When a member is elected, it should log the election id it that it will be reporting. eg:
Unable to find source-code formatter for language: diff. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml
-2015-08-03T06:05:20.523+0000 I REPL [ReplicationExecutor] replSet election succeeded, assuming primary role +2015-08-03T06:05:20.523+0000 I REPL [ReplicationExecutor] replSet election succeeded, assuming primary role, election id 55bf04a0c0f569a0268e3ab5 2015-08-03T06:05:20.523+0000 I REPL [ReplicationExecutor] transition to PRIMARY 2015-08-03T06:05:21.478+0000 I REPL [rsSync] transition to primary complete; database writes are now permitted
The workaround is to use the timestamp of the election id ObjectId as a heuristic, ie. noticing that
> ObjectId("55bf04a0c0f569a0268e3ab5").getTimestamp()
ISODate("2015-08-03T06:05:20Z")
and then going looking for an election around 06:05:20.
- related to
-
-
- Closed
-