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

Explore improvements on index build concurrent state handling

    • Type: Icon: Improvement Improvement
    • Resolution: Won't Do
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Storage Execution

      The way index build state is handled is very racy.

      The way active index builds are managed. Active index builds are registered before the 'startIndexBuild' oplog entry is replicated, which leaves open the possibility of a node stepping down, and encountering oplog entry for a DDL operation which assumes no index builds are in-progress (e.g. a collection drop) while the index build is still registered. SERVER-74953 tries to mitigate the issue by making the builder thread interruptible until the oplog entry is replicated, but it won't make the problem disappear.

      The reverse is also true, a committed index build de-registered and cleaned-up can race with step-up checks. And the way index builds are de-registered is all over the place. A search for "activeIndexBuilds.unregisterIndexBuild" turns up 10+ instances.

      ...

            Assignee:
            backlog-server-execution [DO NOT USE] Backlog - Storage Execution Team
            Reporter:
            yujin.kang@mongodb.com Yujin Kang Park
            Votes:
            1 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: