Minimize downtime on self hosted for a password emergency

Dear friends,
I have no idea how I got into this but the credentials for the admin user and the read/only user for a specific database are not recognized anymore :frowning: Thankfully the readwrite to the production DB is working well.

Self hosted on an EC2 instance with Ubuntu.

It this wasn’t in production use I could systemctl stop mongod, then relaunch it with no authentication, fix my users, then again restart with auth.

How could I aproach this with the very least noticeable downtime? Thanks a lot.

Yes, that is how we do it. Having a replicaSet allows you to do this with minimal downtime.

EDIT: solved … see below … almost had an heart attack :slight_smile:

Oh my god :frowning: I disabled the authentication, ran a javascript to create the same user with a new password and restarted with auth enabled but now I seem to only see an old version of the data … really worried. Help please.

I did the password changes without thinking enough on my Ubunto native host mongodb and restarted it with the new credentials. Then checked the data and started panicking as it was old stale data from mid September.

Point is that since then I am not using the host MongoDB but rather a docker container mongodb which exports its 27017 port on the host.

Then the host MongoDB started it “highjacked” that port without flinching so I connected to the host instance with stale data.

One I understood I killed the host instance and reconnected with Compass to 27017 and this time to the container 27017 and all was good.

Now will have to repeat the password reset on the containerized mongo.

Thanks for the patience

1 Like