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

Improve format of documents returned by $backupCursor aggregation command

    XMLWordPrintableJSON

Details

    • Icon: Improvement Improvement
    • Resolution: Won't Do
    • Icon: Major - P3 Major - P3
    • None
    • None
    • None
    • None
    • Storage Execution

    Description

      When we open a backup cursor and return documents via the $backupCursor aggregation command, documents currently have the following formats depending on the type of backup.

      • Non-incremental (i.e. full) backups return one document per file with the format:

        {
            filename: String,
            fileSize: Number
        }

      • The first full backup used as the basis for future incremental backups returns one document per file with the format:

        {
            filename: String,
            fileSize: Number,
            offset: Number (=0),
            length: Number (=fileSize)
        }

        Note: In this case, offset=0 and length=fileSize always holds.

      • Incremental backups return one document per unchanged file with the format:

        {
            filename: String,
            fileSize: Number
        }

      • Incremental backups return multiple documents (one document per block, where each block has a default size of 16MB) per changed file with the format:

        {
            filename: String,
            fileSize: Number,
            offset: Number,
            length: Number

      We should make this format more consistent by returning document with the following format regardless of the type of backup.

      {
          filename: String,
          fileSize: Number,
          offset: Number,
          length: Number
      }

      In the case of non-incremental backups and the first full backup used as the basis for future incremental backupsoffset=0 and length=0 would clearly indicate the type of backup. Since this involves additive changes to the backup API, it should require few changes from downstream teams like Cloud Backup.

      Attachments

        Activity

          People

            backlog-server-execution Backlog - Storage Execution Team
            james.heppenstall@mongodb.com James Heppenstall
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: