[SERVER-19978] Log electionid Created: 17/Aug/15  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Replication
Affects Version/s: 2.6.11, 3.0.5, 3.1.4
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Kevin Pulo Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-18280 ReplicaSetMonitor should use election... Closed
Assigned Teams:
Replication
Participants:

 Description   

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:

-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.



 Comments   
Comment by Eric Milkie [ 21/Dec/15 ]

Going forward, the electionId's will no longer have times in them, but only the election term (appearing as a 't' field in every oplog entry). Thus, this work may no longer be required after upgrade to 3.2.

Generated at Thu Feb 08 03:52:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.