Re: simple failover cluster (windows 2008)

[Stephen Steneker]

Our current production environment has 2 database SQL Server nodes in a failover cluster configuration, with the data stored on a redundant SAN.  I am starting to use MongoDB for a small application (small user set, small data set, light load) and would like to install it on the same cluster, with a simple failover if the primary DB server fails.  I was thinking the same setup, with the MongoDB data folder being on the SAN.   Is this possible, or do I need to do master/slave replication and have two data folders.  If this is the case, I couldn't put the data on the SAN because it is only accessible by the active node.  I'd have to store it on the C drive of each node, which is not ideal, but doable.

Hi Brian,

The recommended (and supported) configuration for failover and redundancy would be to use MongoDB's replica sets.  There are some extra administrative benefits in having a secondary copy of the data online .. for example, you can do maintenance on one member of your replica set without unnecessary downtime.

Rather than master/slave replication (which is deprecated), you should be using replica sets.  The minimal configuration would be two data nodes and an "arbiter" process running on a third server (so it can determine which of the two data nodes is up and help elect a new primary).

If you want to rely on your SAN for data redundancy and have some sort of heartbeat failover spin up a new server process when the primary dies, it would be possible but less than ideal (and potentially problematic).  In particular, mongod will look for lock files and journal entries on startup in order to work out what changes need to be applied on unclean shutdown.  You could cause some grief by accidentally having two primaries live and trying to use the same data directory, or have issues with stale file locks depending on how your SAN manages the failover.

Cheers,

Stephen

[Brian Donahue]

Stephen,

Sorry for the delayed reply (summer vacation), but thank you very much for this info.  In my case, where I have just 2 load balanced web servers, and 2 clustered database servers (one active, one failover/passive), where do you think the arbiter process should live?  I see that having two members in a set is not a preferred set up.  I guess the good news is that currently this MongoDB set is not critical data and can be destroyed/rebuilt arbitrarily, so it's not app-critical (though it's been very useful!).   But, I just was wondering what you thought the best way to go would be, given this infrastructure?

Thanks again!

Brian

--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com
To unsubscribe from this group, send email to
mongodb-user...@googlegroups.com
See also the IRC channel -- freenode.net#mongodb

[Stephen Steneker]

Sorry for the delayed reply (summer vacation), but thank you very much for this info.  In my case, where I have just 2 load balanced web servers, and 2 clustered database servers (one active, one failover/passive), where do you think the arbiter process should live?  I see that having two members in a set is not a preferred set up.  I guess the good news is that currently this MongoDB set is not critical data and can be destroyed/rebuilt arbitrarily, so it's not app-critical (though it's been very useful!).   But, I just was wondering what you thought the best way to go would be, given this infrastructure?

Hi Brian,

The arbiter process should ideally should run on a third server.  This will allow the arbiter's vote to help elect either of your database servers as a primary.

Replication is intended for use in an active/active configuration where secondaries are online at the same time as the primary, and an election to select a new primary can happen based on the current availability of replica set members.

If you instead plan to use active/passive configuration and failover independent of MongoDB, then presumably you will be relying on the redundancy/integrity of your SAN and be pointing the passive mongod to the same data directory as the primary upon failover.  The caveats with this approach are that you need to ensure both mongod processes are not active at the same time, and that your SAN will release appropriate file locks on failover.

Cheers,

Stephen