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

strengthen journal checks to detect unexpected errors in last journal file as well

    XMLWordPrintableJSON

Details

    • Icon: Improvement Improvement
    • Resolution: Won't Fix
    • Icon: Major - P3 Major - P3
    • None
    • None
    • MMAPv1, Storage
    • None
    • Storage Execution

    Description

      In the case of a crash or filesystem snapshot, the last journal section may be incomplete and therefore appear damaged during recovery on subsequent startup, and that condition is tolerated (assuming a fix for SERVER-15111). Damage to any other journal section is unexpected and indicates a malfunction (such as a storage error). Currently damage to any section in any but the last journal file results in a refusal to finish recovery and a shutdown, as the consequence of such damage may be a large number of errors and inconsistencies in the database.

      However any damage to the last journal file is assumed to be in the last section of that file, and therefore is tolerated - recovery is halted at that point and mongod continues normal startup. This ticket tracks strengthening that test to treat damage in the last journal file to any section but the last as also fatal.

      Unfortunately when journal files are being reused it is not possible to detect with absolute certainty whether any given section is the last section, because the old data following the last section may masquerade as a valid section of the current use of this journal file. However it is possible to detect the last section with high probability:

      • Every time a journal file is reused it is assigned a new randomly chosen 64-bit file id, and that file id is recorded in the header of every section. By comparing the fileid of the section following the current one with the expected fileid, it is possible to determine whether the current section is the last with a probability of 1 in 2^64 (~10^19) of incorrectly concluding that the current section is not the last.
      • In addition the 128-bit hash of the following section can be checked, giving a probability of incorrectly concluding that the current section is not the last of 1 in 2^(64+128) (~10^57) (assuming for the sake of convenience a perfect hash.)

      The net result is a choice between the following imperfect outcomes:

      • With the current implementation, there is a small probability p of a malfunction (such as a storage error) damaging a section of the last journal file other than the last section; mongod would terminate recovery and continue with startup at that point with some number of journal sections remaining unprocessed. The consequence is a potentially large number of errors and inconsistencies in the database due to the unprocessed journal sections.
      • If one of the imperfect checks for last journal section given above is implemented, there is a probability of 1 in ~10^19 or ~10^57 (depending on which test is used) of incorrectly concluding that the damaged section is not the last section. The consequence is failure to recover a recoverable journal.

      Attachments

        Activity

          People

            backlog-server-execution Backlog - Storage Execution Team
            bruce.lucas@mongodb.com Bruce Lucas (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: