[SERVER-8096] --fastsync should be prohibited on a replica set Created: 07/Jan/13  Updated: 11/Jul/16  Resolved: 24/Jan/13

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 2.3.2
Fix Version/s: 2.4.0-rc0

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

Attachments: File fastsync_tyler.js     File fastsync_tyler.js    
Operating System: ALL
Participants:

 Description   

If Replica set members are un-initiated and have fastsync enabled, then calling rs.initiate() causes nodes to enter "RECOVERING" state from which they never recover and print the following message continously:

Mon Jan  7 11:21:17.119 [rsSync] replSet initial sync pending
Mon Jan  7 11:21:17.119 [rsSync] replSet syncing to: localhost:27017
Mon Jan  7 11:21:17.120 [rsSync] fastsync: skipping database clone
Mon Jan  7 11:21:17.121 [rsSync] replSet error possible failover clock skew issue? 50eaf54f:1 

This was not the behavior in 2.3.1 or 2.2.X



 Comments   
Comment by Kristina Chodorow (Inactive) [ 24/Jan/13 ]

Fixed by the minvalid change Eric committed.

Comment by Kristina Chodorow (Inactive) [ 22/Jan/13 ]

This fixes the test:

@@ -378,10 +378,11 @@ namespace mongo {
         if (replSettings.fastsync) {
             log() << "fastsync: skipping database clone" << rsLog;
 
             // prime oplog
             init.oplogApplication(lastOp, lastOp);
+            theReplSet->setMinValid(lastOp);
             return;
         }
         else {
             sethbmsg("initial sync drop all databases", 0);
             dropAllDatabasesExceptLocal();

Comment by Kristina Chodorow (Inactive) [ 22/Jan/13 ]

This is a side-effect of SERVER-7652, I think. It should be fixed by SERVER-8139.

Comment by Tyler Brock [ 07/Jan/13 ]

removed unnecessary code from repro.

Comment by Tyler Brock [ 07/Jan/13 ]

This reproduces it.

Comment by Scott Hernandez (Inactive) [ 07/Jan/13 ]

Tyler, please provide a full repro. In a quick test I couldn't reproduce this from master.

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