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

tolerate bad collection metadata produced on version 2.4 or earlier

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Closed
    • Priority: Critical - P2
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.4.0-rc2
    • Component/s: Storage
    • Labels:
      None
    • Backwards Compatibility:
      Minor Change
    • Sprint:
      Query 2016-11-21

      Description

      The collection creation path in versions 2.4.x and earlier persisted any unknown collection options in the catalog. Due to the changes SERVER-25459, recent versions of master will reject these unknown options. This causes mongod to fail during startup with fatal assertion 18523, as in the following:

      2016-10-11T11:30:13.901-0400 I -        [initandlisten] Fatal assertion 18523 InvalidOptions: The field 'badOption' is not a valid collection option. Options: { badOption: "foo" } at src/mongo/db/storage/mmap_v1/mmap_v1_database_catalog_entry.cpp 876
      

      It could also cause 3.4 secondaries replicating this metadata to shut down with a fatal assertion.

      In order to make it possible for affected deployments to smoothly upgrade to 3.4, the 3.4 node must be able to tolerate extant bad metadata while also rejecting any new collection creation requests which include a bad option. Luckily, collections created on 2.4 or earlier can be identified by the fact that 2.4 also materialized the create field as the first BSONElement in the catalog metadata. Versions 2.6.x and later neither materialized the create field nor wrote unknown collection options to disk. (2.6 through 3.2 ignored unknown options but did not write them into the catalog, whereas 3.4 will reject unknown options entirely.) Therefore, only collection metadata documents which begin with the create field can include unknown options. A 3.4 node can simply ignore unknown fields during collection parsing only if the create field is present.

      Going forward, we could eliminate bad collection metadata entirely by creating a command or startup flag that traverses the catalog and strips out any unknown fields. This work is out of scope for this ticket.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              david.storch David Storch
              Reporter:
              david.storch David Storch
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: