[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 addUser succeeded, but cannot wait for replication since we no longer have so the user did not replicate to secondaries as we did not authenticate 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.
|