Feature request: replica set support about em-mongo

[krobertson]

Any plans for this?

[tobsch]

interested too!

[rcreasey]

+1

[alebsack]

+1

[cypriss]

I'd love tihs

[fl00r]

Just implemented this feature in my fork, going to check it out in production

[ivobenedito]

Hi @fl00r,
Have you tested this out in a prod environment?
When do you think it will be ready for a PR?

[fl00r]

@ivobenedito, a week in prod. While mongodb master get down, client successfully reconnected

[ivobenedito]

@fl00r Cool ;)!! I'm mounting a ReplicaSet on my localhost to also make some failover tests.

[fl00r]

It will be good to get some feedback :)
Ehmm.. By the way, replica set connection should be established by new_replicas method

EM::Mongo::Connection.new_replicas([host:port, host:port, ...], timeout, reconnect_in: 1000)

[ivobenedito]

@fl00r Thanks for showing the syntax usage. Did some tests with it yesterday.
Meanwhile, what do you think on having a more solid API, for example:

EM::Mongo::Connection.new # simple connector
EM::Mongo::ReplicaSetConnection.new # replset connector

# currently, the original mongo driver updated to this
Mongo::MongoClient.new # simple connector
Mongo::MongoReplicaSetClient.new # replset connector

[ivobenedito]

@fl00r Also, think I might have found a bug.

I'm using a ReplicaSet with 3 members, everytime I shutdown the primary and a secondary from the remaining 2 gets elected to master, the client works fine.

Meanwhile, if I shutdown another member (primary) and only leave 1 active (secondary), mongo doesn't elect the secondary to primary without an arbiter, which means the ReplSet stops working.
This is how mongo works, and the app isn't able to fetch anything from Mongo because there is no primary node. (makes sense)

Then, If I bring another member in again, a primary is elected but the app/driver can't find it anymore.

Have you covered/tested this use case?

[fl00r]

Right now driver tries to reconnect few times with timeout delay and then calls on_unbind callback (which is do nothing by default).

In production you should raise an error and stop your application in case if after some retries client can't reconnect. Then you will get some alerts from production and then somehow solve your problem and start your application again (we use runitd for supervising our applications).

So you should pass on_unbind: proc{ fail "Can't reconnect blah blah blah" } option. Or I can add support of infinite reconnects, which looks like a bad option.

About naming. In my first iteration I've created ReplicaSetConnection class for connection :) so, now I think it is good idea to return back

[fl00r]

Hi. As far as em-mongo isn't supported enough I've begun to write new MongoDB Client on EventMachine.
Protocol and some common stuf is already implemented. ReplicaSets support will be added till Monday.

https://github.com/fl00r/monga

If somebody interested - welcome!

[bcg]

@fl00r if you have any interest in taking over em-mongo, or just taking the name once you have feature parity, I would be more than happy to hand over the keys (to the gem as well). At the very least let me know when you think monga its stable for production use and I will make mention of it in the README.

I haven't used MongoDB in a long, long time and probably never will.

cc: @ivobenedito

[fl00r]

Hello! Somehow github removed all my notifications :/
It is a good idea to not produce many clients and to maintain only one.

[fl00r]

I've rewritten my client to support all kind of interfaces: blocking (over TCPSocket), synchronous (over Fibers on EventMachine) and asynchronous (over EventMachine). But API has changed because I've used callbacks instead of Deferrable. Going to rewrite Wiki and Readme soon

[dCSeven]

@fl00r I've seen that you've implemented replica set support on your repo (some time ago, I know).

If you like to, it would be a great thing to merge your commits into this here.