I checked the test instructions and mentioned there that timing is
important as that was inhibiting me at first.
Furthermore I checked through releases and marked the tasks accordingly
(fixed in Disco already, B/C affected).
** Description changed:
[Impact]
When an operator of Juju attempts to restore a backup, it fails with a
mongorestore related error[0]. Under the hood, Juju uses the supplied
mongo related command line interfaces (mongodump, mongorestore etc),
using these in conjunction with the oplog related flags for the former
CLIs, the mongorestore fails with the following error:
> Failed: restore error: error applying oplog: applyOps: applyOps had
one or more errors applying ops
The only work around for Juju at the moment is to update mongod, so that
it carries the following commit[1]. MongoDB have an identical issue,
under a different name, which fixes this[2], but there is unfortunately
no work around without upgrading mongod so it caries the former commit.
The original investigation around Juju failing to restore a previous
dump can be seen here[3]
I've verified with the 3.6.11 and the same restore, worked fine.
[Test Case]
- The following test case doesn't require Juju, and can be replicated
- quite easily inside a lxc container. It may require 2 or 3 goes,
- depending on timings of the creation of the index and the mongodump, but
- I've been getting this consistently.
+ The following test case doesn't require Juju, and can be replicated quite
easily inside a lxc container. It may require 2 or 3 goes, depending on timings
of the creation of the index and the mongodump, but I've been getting this
consistently.
+ Please do mind that timing is important, so putting the commands in a script
will help a lot to reliably trigger the issue.
You can also find instructions in one pastebin[4]
// Launch a container
lxc launch ubuntu:18.04 mongo
lxc exec mongo bash
// Install a version of mongo that Juju is using.
sudo apt update
sudo apt install -y mongodb
// Edit /etc/mongodb.conf and add the following line:
replSet = "rs0"
// Restart the service
systemctl restart mongodb.service
// not required, but helps diagnose bsondump
snap install jq
// launch the mongo CLI, running each command
mongo --eval "rs.initiate()"
mongo --eval "rs.status()"
mongo --eval "db.foo.insert({'foo':'bar'})"
mongo --eval "db.foo.createIndex({'bar':1})"
// Get the dump
mongodump --oplog
// check if it's going to fail
// if the output contains a createIndex, but doesn't contain an oid then
it'll fail.
bsondump dump/oplog.bson | jq
// Drop the foo collection, so we don't get any duplication errors
mongo --eval "db.foo.drop()"
// Now restore the dump
mongorestore --oplogReplay dump/
// It should fail with
2019-03-22T17:26:28.034+0000 preparing collections to restore from
2019-03-22T17:26:28.035+0000 reading metadata for test.foo from
dump/test/foo.metadata.json
2019-03-22T17:26:28.053+0000 restoring test.foo from dump/test/foo.bson
2019-03-22T17:26:28.056+0000 restoring indexes for collection test.foo from
metadata
2019-03-22T17:26:28.062+0000 finished restoring test.foo (1 document)
2019-03-22T17:26:28.062+0000 replaying oplog
2019-03-22T17:26:28.064+0000 Failed: restore error: error applying oplog:
applyOps: applyOps had one or more errors applying ops
After updating the packages, re-run the drop and try to import again,
this time it should work:
# mongo --eval "db.foo.drop()"
MongoDB shell version v3.6.3
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.6.3
true
r
# mongorestore --oplogReplay dump/
2019-03-22T19:49:43.838+0000 preparing collections to restore from
2019-03-22T19:49:43.840+0000 reading metadata for test.foo from
dump/test/foo.metadata.json
2019-03-22T19:49:43.856+0000 restoring test.foo from dump/test/foo.bson
2019-03-22T19:49:43.858+0000 restoring indexes for collection test.foo from
metadata
2019-03-22T19:49:43.866+0000 finished restoring test.foo (1 document)
2019-03-22T19:49:43.866+0000 replaying oplog
2019-03-22T19:49:43.867+0000 done
-
[Other Info]
0. https://paste.ubuntu.com/p/9r9pYc9g9D/
1.
https://github.com/mongodb/mongo/commit/0d0ba866052fd2b9ceaaa66c2b725a02822b102d
2. https://jira.mongodb.org/browse/SERVER-36951
3. https://bugs.launchpad.net/juju/+bug/1818831
4. https://paste.ubuntu.com/p/HJsDf5yNkS/
** Also affects: mongodb (Ubuntu Cosmic)
Importance: Undecided
Status: New
** Also affects: mongodb (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: mongodb (Ubuntu)
Status: In Progress => Fix Released
** Changed in: mongodb (Ubuntu Bionic)
Status: New => In Progress
** Changed in: mongodb (Ubuntu Cosmic)
Status: New => In Progress
** Changed in: mongodb (Ubuntu Bionic)
Assignee: (unassigned) => Andreas Hasenack (ahasenack)
** Changed in: mongodb (Ubuntu Cosmic)
Assignee: (unassigned) => Andreas Hasenack (ahasenack)
** Changed in: mongodb (Ubuntu)
Assignee: Andreas Hasenack (ahasenack) => (unassigned)
** Changed in: mongodb (Ubuntu Bionic)
Importance: Undecided => Critical
** Changed in: mongodb (Ubuntu Cosmic)
Importance: Undecided => Critical
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1821391
Title:
mongorestore fails with createIndexes command in oplog
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mongodb/+bug/1821391/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
