[SERVER-13909] Update Command Spec to include setVersion, electionId, lastOp, lastWriteDate Created: 12/May/14  Updated: 06/Dec/22  Resolved: 05/Oct/18

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: David Golden Assignee: Backlog - Replication Team
Resolution: Won't Fix Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to DRIVERS-298 Update Command Spec to include setVer... Closed
related to SERVER-18717 compose electionId in OID format from... Closed
related to SERVER-19554 Return last visible optime in repldat... Closed
related to SERVER-13542 Expose electionId on primary in isMaster Closed
Assigned Teams:
Replication
Sprint: Repl 17 (07/15/16), Repl 18 (08/05/16), Repl 2016-08-29, Repl 2016-10-10
Participants:

 Description   

Returning the current setVersion, electionId, lastOp, lastWriteDate would allow drivers to avoid pinging the server using ismaster continuously to establish the topology of the replicaset as well as provide monotonic read operations.

In case of a primary election a new electionId would be returned and in the case of a new secondary being added or removed a new setVersion would be returned.

If adding a new secondary that caused an election the server might return both a new setVersion and a new electionId.

the lastOp field would allow for simpler monotonic read operations.
lastWriteDate could be used for staleness calculations. It will become necessary to have it separate from lastOp once we remove the embedded timestamp from the lastOp field.



 Comments   
Comment by Gregory McKeon (Inactive) [ 05/Oct/18 ]

Closing this, since the corresponding drivers ticket is closed.

Comment by Eric Milkie [ 24/Aug/16 ]

This is something I'd still like to do.

Comment by Eric Milkie [ 30/Apr/15 ]

Note: in 3.2, the electionId will be composed from the node's current term. It will still be in OID format and thus be comparable in the same way as in 3.0.

Comment by Christian Amor Kvalheim [ 03/Jun/14 ]

Would it make sense to bump the wire protocol version for this ?

Comment by Christian Amor Kvalheim [ 14/May/14 ]

this touched upon the election Id as well to be able to detect when a new primary has been elected.

Comment by David Golden [ 13/May/14 ]

I have mixed feelings about limiting to writes or (alternatively) limiting to any commands but on PRIMARY only.

The goal for the driver is to detect that its view of the replica set config is stale. Seeing a set version higher than the last set version it received from a primary is an indication that something has changed and it would still need to query the primary for the correct config.

So if a secondary has a lower set version, that gets ignored. If a secondary has a higher set version, that means the primary needs to be checked. So it wouldn't ever flap unless primary was flapping.

However, in a separate, but related conversation, Matthias and Jesse discussed a race condition wherein a primary (A) is reconfigured and then is partitioned before it can propagate the config change to secondaries (B) and (C). Assume we can still see all three, though. In such a race, assume (B) and (C) elect (B) as the new primary, then we could see the set version reported by (B) be lower than the set version reported by (A) after it steps down. That might cause extra requests to the (B) to see why (A) is reporting a higher version.

Given that, I think it would be reasonable to limit set version reporting to the primary host only. Any change in what the primary is reporting would be either a reconfig or a config-rollback. Either way, it signals the driver to call ismaster and get a new view of the replica set config.

Comment by Eric Milkie [ 13/May/14 ]

When you say "any command (e.g. writes)", this is incongruous since not all commands do writes. I think if we amend the description to say "commands that do writes" return the replica set config version, this could work. Since writing-commands can only successfully complete on a PRIMARY, using the replica set config version from such a command's response will be authoritative.
I think it could be problematic to include the config version for all commands, since secondaries may be unaware of a config change, and thus a driver might flap between two different configs if it were issuing commands to more than one node.

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