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

Improve robustness of backup_restore.js around dropping test database

    • Fully Compatible
    • ALL
    • v4.0, v3.6
    • Repl 2018-07-30, Repl 2018-08-13, Repl 2018-08-27, Repl 2018-09-10, Repl 2018-09-24, Repl 2018-10-08
    • 16

      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.

            vesselina.ratcheva@mongodb.com Vesselina Ratcheva (Inactive)
            vesselina.ratcheva@mongodb.com Vesselina Ratcheva (Inactive)
            0 Vote for this issue
            3 Start watching this issue