[SERVER-3183] Make initial sync more tolerant of sync source changing Created: 02/Jun/11  Updated: 12/Jul/16  Resolved: 21/Sep/11

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

Type: Improvement Priority: Major - P3
Reporter: Kristina Chodorow (Inactive) Assignee: Kristina Chodorow (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Participants:

 Description   

e.g., /* apply relevant portion of the oplog
*/
{
isyncassert( "initial sync source must remain readable throughout our initial sync [2]", source->state().readable() );
if( ! initialSyncOplogApplication(source, /applyGTE/startingTS, /minValid/mvoptime) ) { // note we assume here that this call does not throw

There are a couple of places in initialSyncOplogApplication that this could be improved, too.



 Comments   
Comment by Kristina Chodorow (Inactive) [ 21/Sep/11 ]

Retrying the clone part is going to be very complicated. This should cover most cases.

Comment by auto [ 21/Sep/11 ]

Author:

{u'login': u'kchodorow', u'name': u'Kristina', u'email': u'kristina@10gen.com'}

Message: retry initial syncing oplog until we run out of targets SERVER-3183
Branch: master
https://github.com/mongodb/mongo/commit/e9c2884d3560ff746b80db07cad73209d3a81f7d

Comment by Dwight Merriman [ 21/Sep/11 ]

ok. main thing is if we do this we have good tests that simulate.

also wonder if the clone is 90% of the time anyway in which case yield would be low.

if multiple db's i guess one could just reclone the last one that was in progress.

Comment by auto [ 21/Sep/11 ]

Author:

{u'login': u'kchodorow', u'name': u'Kristina', u'email': u'kristina@10gen.com'}

Message: more flexibility on source choice for initial sync SERVER-3183
Branch: master
https://github.com/mongodb/mongo/commit/a398ef5dcdd33d1576469cd0797ec963bfb35e93

Comment by Kristina Chodorow (Inactive) [ 02/Jun/11 ]

I think this would just be for oplog application. If it fails mid-clone, we have to drop the dbs and start over because otherwise we'd have half of the databases with one minvalid and half with another (although this would work if the second minvalid is before the first, I guess).

Comment by Dwight Merriman [ 02/Jun/11 ]

how is that going to work if we get half way through a clone() and it changes? does clone db code have retry logic?

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