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:
The 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:
https://github.com/edelight/chef-mongodb/issues/347
Is there a better cookbook for mongo?
Doug.