Creating a MongoDB oplog user

This is a guide to set up an oplog user that can read from the local.oplog.rs collection. You can only use this guide if you have admin privileges on the cluster. If you are using a DBaaS they will usually have tools in their UI that you can use to create the user.

It is recommended to create a special user (say, oplogger) that is used only for this purpose. Note that the oplog is shared between all databases served by your replica set of mongod processes; if you are sharing your cluster with unrelated apps, the oplogger user will be able to see all changes to all databases in your cluster. You will need Mongo administrator credentials to create this user.

Log in to the admin database with the Mongo shell using your administrator credentials. (You must connect to the current primary in your replica set; if the prompt says SECONDARY instead of PRIMARY, type db.isMaster() in the mongo shell and try again connecting to the server listed under primary.)

$ mongo -u YourExistingAdminUserName -p YourExistingAdminPassword mongo-server-1.example.com/admin

Now run the following command to make an oplogger user with the ability to read collections in the local database.

If you are using Mongo 2.6:

cluster:PRIMARY> db.createUser({user: "oplogger", pwd: "PasswordForOplogger", roles: [{role: "read", db: "local"}]})

If you are using Mongo 2.4:

cluster:PRIMARY> db.addUser({user: "oplogger", pwd: "PasswordForOplogger", roles: [], otherDBRoles: {local: ["read"]}})

(You may be used to running db.createUser (or db.addUser) inside the actual database that you want the new user to be able to access (in this case, local), instead of running it in admin and using the authSource flag to specify that you want to authenticate against admin. However, this doesn't work with the special case of the local database. Mongo 2.6 specifically prevents you from creating users in the local database, and while Mongo 2.4 would let you do it, you would find that you need to run db.addUser separately against each database replica (and risking ending up with different passwords on each), because the local database is not itself replicated across servers.)