[SERVER-8922] Log in as read write user on secondary database Created: 09/Mar/13  Updated: 10/Dec/14  Resolved: 25/Mar/13

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 2.2.3
Fix Version/s: None

Type: Question Priority: Major - P3
Reporter: Sumathy Panicker Assignee: J Rassi
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CentOS release 6.3 (Final)


Participants:

 Description   

We have created a read-write user on our primary database but we cannot log on with this user to our secondary databases. Is this default behaviour?



 Comments   
Comment by J Rassi [ 25/Mar/13 ]

I'm going to close out this ticket – please feel free to reopen if you have any further related questions.

Comment by J Rassi [ 16/Mar/13 ]

The warning "cannot wait for replication since we no longer have auth" is unrelated: it indicates that the shell cannot confirm that the user entry has been replicated; it doesn't indicate that replication can't occur. Typically, the addUser function blocks until replication of the call has finished to a majority of members; however, if you're authenticating via a localhost connection and adding the first admin user, then the addUser function returns immediately (since the connection becomes marked as unauthenticated); but, the user is still replicated (since the connections between replica set members, which are authenticated as the __system user, are unaffected). Thus, assuming the secondary is up to date, you should in fact be able to log into the secondary immediately after running addUser on the primary.

Was the user added when the mongod instance was running in standalone mode (not running with the --replSet option)? Changes made while in standalone mode are not written to the oplog, and thus won't get replicated.

Was the user added to the local database? Changes to the local database also do not get written to the oplog.

Comment by Sumathy Panicker [ 14/Mar/13 ]

Yes I do see it in the primary. I don't see it on the secondary. However I figured out the issue.

While setting up replications sets for another env I understood what might have
happened to the admin user. When I created the admin user on primary I got
this error - I remember getting this error in prod also.

addUser succeeded, but cannot wait for replication since we no longer have
auth

so the user did not replicate to secondaries as we did not authenticate
against the admin database.( as we turned auth on in mongo.conf and
restarted mongo)

Once you authenticate and create the user - it gets replicated ...

Comment by J Rassi [ 09/Mar/13 ]

Do you see the user in question when you run db.system.users.find() on the primary? Do you see the same user when you run rs.slaveOk() + db.system.users.find() on the secondary?

Comment by Sumathy Panicker [ 09/Mar/13 ]

Hi Jason

Thanks for the reply. The secondary is up to date and I was logging against the correct database. I created another read-write user from the primary and it was replicated successfully to the 2 secondaries. So I think we are ok now . The mystery of why the first read user did not get replicated remains?

-Sumathy

Comment by J Rassi [ 09/Mar/13 ]

No, you are supposed to be able to do this; user information is replicated to secondaries.

  • Is the secondary up to date?
  • Are you sure you are logging in against the correct database?
Generated at Thu Feb 08 03:18:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.