On Thu, May 17, 2012 at 3:14 AM, Todd Hodgen <thod...@frontier.com> wrote: > I now understand the Arbiter, and the reason why there are three servers > rather than two. On[e] thought, if you had only two servers, and one failed, > as an automated workaround, the remaining server could be reconfigured to be > a Single server deployment through a script. Or at least we discussed that > scenario tonight.
that's exactly what I was thinking. It would have to be script that is run manually because without an arbiter, you cannot automate it. Having said that, someone could setup a poor man's arbiter. A cron script that had some test unique to their network that could safely decide to force a database to become primary. For example, ping company mail server and if you can reach that and not reach other mongo server, than chances are good other mongo server is dead and you can take over. Also, by installing arbiter on one of the two nodes, then you can have *that* particular machine take over if other machine is down. This trick only works for one machine. So this is really about addressed the situation when the primary is down and secondary cannot decide what to do. Example: Machine A will survive is Machine B is down. Machine B will *not* survive automatically is Machine A is down. Machine A mongodb arbiter Machine B mongodb (including sipx-users list) _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
