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

Update shard_aware_init to flush its shard identity before shutdown

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.2.0-rc3, 4.3.1
    • Component/s: None
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.2
    • Sprint:
      Service Arch 2019-07-01
    • Linked BF Score:
      16

      Description

      We currently spin up sharding in advance of replication (see SERVER-41005). Because of that, it is possible for sharding to miss out on certain writes on startup (writes to admin.system.version that are still in the oplog and haven't yet been recovered).

      It's going to be quite difficult to untangle all the dependencies between sharding and replication, and in the mean while shard_aware_init has more failures than we'd like. See BF-12759. That particular test specifically checks that corrupting our version (via a manual update to admin.system.version) causes mongod to crash on startup. The problem is that because we start sharding before replication (and also do a complicated dance of restarting in standalone mode to corrupt the document), we can perform an update when the document we want to modify isn't present (because it's still in the oplog and we're in standalone mode), and then fail to crash on startup.

      So let's fix up that test by waiting to flush the oplog before shutting down the node (when in replica set mode).

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: