Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-28044

Improve / Refactor ConfigDiffTracker chunk reload logic



    • Type: Improvement
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Sharding
    • Labels:


      There is no reason to have the error check found here in the ConfigDiffTracker during chunk reload. Whatever 'inconsistent' state that may have previously existed no longer exists.


      {ns, lastmod}

      index on config.chunks, together with querying by ascending 'lastmod' value and writes to config.chunks always having higher 'lastmod' values than any existing document, assures that any writes that pause reads midway will not cause any documents to be missed. The only thing that can happen is that a read pauses partway through, an update happens to a document already read, and we then read the updated document. This will return two documents with the same _id field. This will actually cause our current reload logic to fail, but there is no reason it should fail. Rather than a loop to remove all overlaps, and then a second loop to insert all new documents and check again for overlap, which errors, we should have a single loop that removes overlaps and inserts in a rolling fashion. Then there is no issue.

      Doing this would make the reload logic cleaner and easier to follow – right now there are more comments, some mysterious, to explain the more complicated logic --, and prevent possible failures that should be entirely unnecessary.


          Issue Links



              • Votes:
                0 Vote for this issue
                3 Start watching this issue


                • Created: