[DOCS-10654] Docs for SERVER-30249: Mongos does not attach operationTime to the results if the keys are not available Created: 08/Aug/17  Updated: 29/Oct/23  Resolved: 17/Oct/17

Status: Closed
Project: Documentation
Component/s: None
Affects Version/s: None
Fix Version/s: 3.5.11

Type: Task Priority: Major - P3
Reporter: Emily Hall Assignee: Kay Kim (Inactive)
Resolution: Fixed Votes: 0
Labels: PM-221
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-30249 Mongos does not attach operationTime... Closed
Related
Participants:
Days since reply: 6 years, 17 weeks, 1 day ago
Epic Link: DOCS: 3.6 Server

 Description   

Documentation Request Summary:

Upgrade downgrade docs need to mention that after changing the featureCompatibilityVersion mongos needs to be bounced to pick up the changes in the causal consistency behavior. It appears that normal procedure will do just that but its better to stress in the case users decide to run the command.

Engineering Ticket Description:

Currently mongos does not return operationTime until the signing keys become available. This prevents sessions to be causally consistent as the keys are not available instantaneously.

Note:
returning just operationTime even if there are no keys as it does not require keys introduces issues related to a multi-shard execution without gossiping logical time. Its ok for a single RS as it does not need to gossip the clusterTime as its always matches the oplog time

Suggested implementation will block in mongos initialization until keys are available if its accessing a sharded cluster

1.
in initializeSharding: https://github.com/mongodb/mongo/blob/r3.5.10/src/mongo/s/server.cpp#L190
add a blocking call until keys are available:

status = waitForSigningKeys(opCtx);
    if (!status.isOK()) {
        return status;
    }

2.
implement waitForSigningKeys as (very similar to waitForShardRegistryReload)

Status waitForSigningKeys(OperationContext* opCtx) {
    while (true) {
        auto stopStatus = opCtx->checkForInterruptNoAssert();
        if (!stopStatus.isOK()) {
            return stopStatus;
        }
 
        try {
           auto logicalTimeValidator = LogicalTimeValidator::get(opCtx)
           
            if (logicalTimeValidator->shouldGossipLogicalTime()) {
                return Status::OK();
            }
            sleepFor(kRetryInterval);
            continue;
        } catch (const DBException& ex) {
            Status status = ex.toStatus();
            warning()
                << "Error waiting for signing keys, sleeping for 2 seconds and trying again"
                << causedBy(status);
            sleepFor(kRetryInterval);
            continue;
        }
    }
}



 Comments   
Comment by Kay Kim (Inactive) [ 17/Oct/17 ]

thanks much.

Comment by Misha Tyulenev [ 17/Oct/17 ]

kay.kim there is no need to bounce mongos on the downgrade, but the docs you mentioned already suggest to restart.
I think its a good idea even if we are not requiring it.

Comment by Kay Kim (Inactive) [ 05/Oct/17 ]

See DOCSP-966 for code review

Generated at Thu Feb 08 08:01:05 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.