I'm wondering if anyone has actually gotten the Edelight MongoDB cookbook to work, with multiple shards and multiple replicas per shard? I've been playing with it for months now and I'm frustrated beyond belief. We had the folks from mongodb come out and meet us a few months ago and they anecdotally told us they had heard of people who were actually using it.
Since I'm so frustrated, and can't be bothered detailing all the issues from scratch, here's part of an email I sent internally within our organisation today about it...
"Last night, I was able to get the community cookbook to deploy two replica sets, but I had to remove authentication to do so. I had issues getting the sharding to work on the router, so, since the sharding is going to be handled by mongos on the DBC rightscsale instances anyway, and Eugene has said we _might_ not need sharding, I decided to go back to getting replica sets with authentication to work.
When auth is enabled in the cookbook, it automatically tries to authenticate every operation as the admin user when configuring replication, which, if not previously configured will fail. This means the admin user has to be created first. Since the cookbook puts the replset option in the config file automatically on every node, the node knows it's part of a replica set. This means the admin user can't be create on an arbitrary node, but instead has to be created only the primary node. However, there is no primary node until replication has been set up, which it hasn't been yet because there is no admin user.
Someone suggested I work around this by spinning up a data node manually (without the options configured by the cookbook to make it look like it's part of a replica set) and then using the appropriate commands to create the admin user. Not sure how I'd copy the database over to the instances. In any case, that's hardly automated.
I asked why the admin user can't be added to the router. After all, that's what it's for, right? Apparently db local users are propagated from the router to the data nodes, but system level users (like the admin user) are not. When I attempted to use the cookbook yesterday to create the admin user on the router, mongo failed because the auth option isn't recognized on the router. I don't know why. Maybe because system level users aren't propagated. Even if I get the admin user created on the data nodes, this will stop the admin user (presumably with the same credentials) from being created on the router, and then sharding can't be configured on top of the replica sets.
Once the keyfile option is supplied to the cookbook, then for reasons I don't understand, the cookbook automatically adds the auth option to the config file, which as we know, breaks the router. From what I've been told, they are two different things. One is for internal authentication, and the other is for external user authentication."
All very frustrating stuff. On top of that there's other issues, like the fact that the shard name is passed to the addshard() command instead of the replica set name:
https://github.com/edelight/chef-mongodb/issues/348The replica set name used in the chef search has a hard coded "rs_" at the front, and this isn't documented anywhere which initially caused a lot of time to be wasted: