db.auth() keeps failing for STARTUP2

[Scarlett Zuo]

Dear All,

I've set up a 3-node-Mongo, two data hosting and 1 arbiter. Currently, the second node is syncing with the primary as STARTUP2. However, I'm not able to use db.auth("user","pwd") to log in and do anything. Is this normal? I remember I was able to do so yesterday before linking the two, and maybe even after - but I can't remember for sure.

Any help would be greatly appreciated!

Thanks!

Scarlett

[Scarlett Zuo]

Dear All, 

I want to update the post with some more information and hopefully someone may be able to help.

My mongo replica set is on AWS, using Amazon Linus AMI. I definitely should be able to log in to the STARTUP2 with admin user because I've tried a few days now and sometimes it works just fine. But when I cannot, the log message says: 

SCRAM-SHA-1 authentication failed for admin on admin from client 127.0.0.1 ; UserNotFound: Could not find user admin@admin

Does anyone have a similar issue before? 

Also, after a crash of the mongod on the STARTUP2, I noticed that the "du -ah /mongodata" returns a much smaller size than when I previously checked. Could someone please explain what's going on here?

Many thanks!

Scarlett

[Attila Tozser]

That is just an assumption, but i think, your mongod is doing an initial sync (based on the STARTUP2 phase and the authentication failure):

https://docs.mongodb.com/manual/core/replica-set-sync/#initial-sync

https://docs.mongodb.com/manual/reference/replica-states/#replstate.STARTUP2

 After losing the content for some reason, the replicaset member is recreating it's data from another replica. As long as the admin database is not created (copied over) during the initial sync, it cannot authenticate the users (as they are not there). Is there some automation recreating the node from scratch? During the data synchronization, the node is in state STARTUP2. Other than this it should not stay in STARTUP2 state for a long period, and it should be able to authenticate the user connections.

Attila

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
 
For other MongoDB technical support options, see: https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+unsubscribe@googlegroups.com.
To post to this group, send email to mongod...@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/e866bc7c-3e8d-4cbf-90fc-a22b7bb2e86b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Scarlett Zuo]

Hi Attila,

Many thanks for your answer!

This is indeed the initial sync - I just converted the standalone node to a replica set, that's why. Also, the database is quite big 1.3 T, hence it takes a long time. 

Your explanation makes sense. My only confusion is that during the initial set up, before I added the 2nd node to the replica, I also created the same users on this node, but somehow, during the syncing, I cannot log in. And this behaviour is not consistent, though most of the time, I cannot log in.

Thanks again for your help!

Scarlett

To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user...@googlegroups.com.

To post to this group, send email to mongod...@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-user.

[Kevin Adistambha]

Hi Scarlett

My only confusion is that during the initial set up, before I added the 2nd node to the replica, I also created the same users on this node, but somehow, during the syncing, I cannot log in. And this behaviour is not consistent, though most of the time, I cannot log in.

User logins are stored in the admin database. If you subsequently designate this node as a member of a replica set and add it to an existing replica set, this node will then perform an initial sync.

The initial sync process starts by dropping all databases (except local), which includes that admin database that contains your user login data.

However, once that node reached the SECONDARY state, it would have replicated the admin database from the PRIMARY, which subsequently allows you to login.

I believe cases where you cannot login into the new node is during the moments where the admin database hasn't yet transferred to the node.

You can verify this behaviour by:

1. Create a single replica set node with auth, with user “x” as admin
2. Create a standalone node with auth, with user “y” as admin
3. Verify that you can login as “x” into node (1) and as “y” into node (2)
4. Restart node (2) using the --replSet parameter
5. Add node (2) to the replica set by running rs.add(<node_2 address>) in node (1)
6. You will not be able to login as “y” anymore into node (2), but now you can login as “x” into node (1) and node (2)

Best regards,
Kevin

​

[Scarlett Zuo]

Hi Kevin,

Thank you very much! Your explanation is very helpful!

When the database was syncing, and when I had problem log in, I did once stop the mongod, commented out the replica setting etc, and created a new user, and then restarted mongod as replica again. I did notice that the syncing started from almost ground zero. Now I'm almost sure that when the syncing is finished, I won't find that user. 

Thanks again for your help!

Scarlett