Mongorestore dropping admin.tempusers Unauthorized

Hi Team,

Use mongorestore to restore the backup data of replica set cluster A to replica set cluster B.the user configuration information of the two clusters is the same.

When using mongorestore for the first time to restore in cluster B, after the user/role information is restored, subsequent operations will prompt that there is no permission, but there is no current problem when mongorestore is executed repeatedly.

first recovery(failed)

09:51:24.051+0800	restoring users from archive './mongo.data.role_root'
09:51:24.061+0800	restoring users to temporary collection
09:51:24.072+0800	using 1 insertion workers
09:51:24.170+0800	restoring roles from archive './mongo.data.role_root'
09:51:24.171+0800	restoring roles to temporary collection
09:51:24.171+0800	using 1 insertion workers
09:51:24.194+0800	merging users/roles from temp collections
09:51:24.323+0800	dropping temporary collection admin.temproles
09:51:24.379+0800	error dropping temporary collection admin.temproles: (Unauthorized) Command drop requires authentication
09:51:24.379+0800	dropping temporary collection admin.tempusers
09:51:24.380+0800	error dropping temporary collection admin.tempusers: (Unauthorized) Command drop requires authentication
09:51:24.380+0800	replaying oplog
09:51:24.422+0800	demux End
09:51:24.422+0800	Failed: restore error: error applying oplog: applyOps: (Unauthorized) Command applyOps requires authentication

retry recovery(no error)

10:16:20.797+0800	restoring users from archive './mongo.data.role_root'
10:16:20.808+0800	dropping preexisting temporary collection admin.tempusers
10:16:20.820+0800	restoring users to temporary collection
10:16:20.820+0800	using 1 insertion workers
10:16:20.844+0800	restoring roles from archive './mongo.data.role_root'
10:16:20.845+0800	dropping preexisting temporary collection admin.temproles
10:16:20.848+0800	restoring roles to temporary collection
10:16:20.848+0800	using 1 insertion workers
10:16:20.869+0800	merging users/roles from temp collections
10:16:20.873+0800	dropping temporary collection admin.temproles
10:16:20.876+0800	dropping temporary collection admin.tempusers
10:16:20.878+0800	replaying oplog
10:16:20.883+0800	demux namespaceHeader: { oplog true 6610091830139547777}
10:16:20.883+0800	applied 2 oplog entries
10:16:20.883+0800	building indexes up to 4 collections in parallel
10:16:20.883+0800	starting index build routine with id=3
10:16:20.883+0800	no indexes to restore for collection test2.infos
10:16:20.883+0800	no indexes to restore for collection tests.messages
10:16:20.883+0800	no indexes to restore for collection admin.message
10:16:20.883+0800	no indexes to restore for collection t.message
10:16:20.883+0800	no indexes to restore for collection test1.messages
10:16:20.883+0800	ending index build routine with id=3, no more work to do
10:16:20.883+0800	demux checksum for namespace .oplog is correct (6610091830139547777), 771 bytes
10:16:20.883+0800	demux End
10:16:20.883+0800	demux finishing (err:<nil>)
10:16:20.883+0800	starting index build routine with id=0
10:16:20.883+0800	ending index build routine with id=0, no more work to do
10:16:20.883+0800	starting index build routine with id=1
10:16:20.883+0800	ending index build routine with id=1, no more work to do
10:16:20.883+0800	starting index build routine with id=2
10:16:20.883+0800	ending index build routine with id=2, no more work to do
10:16:20.883+0800	14155037 document(s) restored successfully. 0 document(s) failed to restore.

mongod --version

db version v7.0.4
Build Info: {
    "version": "7.0.4",
    "gitVersion": "38f3e37057a43d2e9f41a39142681a76062d582e",
    "openSSLVersion": "OpenSSL 3.0.2 15 Mar 2022",
    "modules": [],
    "allocator": "tcmalloc",
    "environment": {
        "distmod": "ubuntu2204",
        "distarch": "x86_64",
        "target_arch": "x86_64"
    }
}

mongodump --version

mongodump version: 100.9.4
git version: ce6af0fefca324ad5d9cb689d335130f48c99699
Go version: go1.20.12
   os: linux
   arch: amd64
   compiler: gc

mongorestore --version

mongorestore version: 100.9.4
git version: ce6af0fefca324ad5d9cb689d335130f48c99699
Go version: go1.20.12
   os: linux
   arch: amd64
   compiler: gc

dump: mongodump --host=xxx --port=xxx -u xxx -p xxx --archive=xxx --oplog
restore: mongorestore --host=xxx --port=xxx -u xxx -p xxx --archive=xxx --drop --oplogReplay --authenticationDatabase=admin

Perhaps: When mongorestore restores users/roles, the userId will be changed, and the server will force the connection to be logged in using the previous userId to expire(Unauthorized).

Does mongorestore have an optimized way to restore users?

1 Like