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

Improve robustness of backup_restore.js around dropping test database

    XMLWordPrintable

    Details

    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.0, v3.6
    • Sprint:
      Repl 2018-07-30, Repl 2018-08-13, Repl 2018-08-27, Repl 2018-09-10, Repl 2018-09-24, Repl 2018-10-08
    • Linked BF Score:
      16

      Description

      The backup-restore fixture may kill its FSM client while the latter is in the process of dropping the test database as part of its per-workload cleanup. In that case, that fixture could later fail to write to that database, as it may be in a drop-pending state. The following improvements can be made to avoid this scenario:
      1. Use an assert.soon to poll for the test database to no longer exist right after killing the FSM and CRUD clients. (We currently all ReplSetTest.awaitReplication(), which is not sufficient in this case, since the drop database oplog entry may not exist yet).
      2. The backup-restore fixture attempts to ensure replication between workloads by doing a w:3 insert on the test.fsm_teardown collection and then immediately dropping it. It would be more useful to change the write concern to w:majority so that we can be sure it gets committed.

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: