[SERVER-64627] Need general method to handle in-memory state after initial sync Created: 17/Mar/22  Updated: 29/Oct/23  Resolved: 21/Apr/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.0.0-rc4, 5.0.10, 6.1.0-rc0

Type: Improvement Priority: Major - P3
Reporter: Matthew Russotto Assignee: Vesselina Ratcheva (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
is depended on by SERVER-64601 Shard server mongod initialization is... Closed
Duplicate
is duplicated by SERVER-65251 FCBIS doesn't call to the onInitialSy... Closed
Related
is related to SERVER-64433 A new topology time could be gossiped... Closed
is related to SERVER-64601 Shard server mongod initialization is... Closed
is related to SERVER-66082 Ensure that cluster parameters are ap... Closed
is related to SERVER-69017 Clarify interface for initializing in... Backlog
is related to SERVER-64628 More testing of adding nodes to shard... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v6.0, v5.3, v5.0
Sprint: Repl 2022-04-18, Repl 2022-05-02
Participants:

 Description   

We have several classes which use opObservers to keep in-memory state in sync with storage state. These include sharding state, authorization, tenant migration mtabs, maybe others. These will be run during logical initial sync when the system isn't necessarily consistent, and will not be run during file copy based initial sync. Both initial syncs have special code to fix some of these after the system is consistent. We should create a mechanism (either another opObserver, or expanding/renaming the onReplicationRollback opObserver) to handle fixing these cases after initial sync generally.

We might also consider not running the ordinary op observers during initial sync; this may require special treatment of FCV.



 Comments   
Comment by Githook User [ 23/May/22 ]

Author:

{'name': 'Vesselina Ratcheva', 'email': '31660559+vessy-mongodb@users.noreply.github.com', 'username': 'vessy-mongodb'}

Message: SERVER-64627 Refactor onInitialSyncComplete and onStartupRecoveryComplete into new sharding hook

(cherry picked from commit 14e04b0acc27f7d7092eb93bf1b2666c50226d06)
Branch: v5.0
https://github.com/mongodb/mongo/commit/b1754d1d65dd31d4d1210b0d074bbb0c813d86ea

Comment by Githook User [ 29/Apr/22 ]

Author:

{'name': 'Vesselina Ratcheva', 'email': '31660559+vessy-mongodb@users.noreply.github.com', 'username': 'vessy-mongodb'}

Message: SERVER-64627 Refactor onInitialSyncComplete and onStartupRecoveryComplete into new sharding hook that also works with FCBIS

(cherry picked from commit 14e04b0acc27f7d7092eb93bf1b2666c50226d06)
Branch: v6.0
https://github.com/mongodb/mongo/commit/064111fc4e116d43825c1e207e5b77b2064f016a

Comment by Githook User [ 21/Apr/22 ]

Author:

{'name': 'Vesselina Ratcheva', 'email': 'vesselina.ratcheva@10gen.com', 'username': 'vessy-mongodb'}

Message: SERVER-64627 Test that FCBIS calls sharding on-completion hook
Branch: master
https://github.com/10gen/mongo-enterprise-modules/commit/818e40f4efe008bbc00110f77618b49dd60e47d3

Comment by Githook User [ 21/Apr/22 ]

Author:

{'name': 'Vesselina Ratcheva', 'email': '31660559+vessy-mongodb@users.noreply.github.com', 'username': 'vessy-mongodb'}

Message: SERVER-64627 Refactor onInitialSyncComplete and onStartupRecoveryComplete into new sharding hook that also works with FCBIS
Branch: master
https://github.com/mongodb/mongo/commit/14e04b0acc27f7d7092eb93bf1b2666c50226d06

Comment by Vesselina Ratcheva (Inactive) [ 11/Apr/22 ]

This ticket includes the work for SERVER-65251.

Comment by Kaloian Manassiev [ 18/Mar/22 ]

Can we please add this to the ReplicaSetAwareService instead of the OpObserver and to include a better documentation of what exactly guarantees there are under each of the events?

Generated at Thu Feb 08 06:00:46 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.