Mongo db server is designed to start in one mode: master or slave. We originally thought we could segregate dbs one as master/master(e.g. registrations) and another as master/slave (e.g. config). We could start two mongo db server, one in each mode, but that adds complexity on top of master/master which is not entirely sanctioned by mongo community to begin with.
So the one thought would be to figure out how to use master/slave for registrations and still achieve HA and branch survivability. I have a proposal, we redesign registration workflow as the following: 1.) Registration is saved to local mongodb and tagged as local copy 2.) attempt to send a copy all local registrations to master mongodb 3.) remove all local registrations with registrations that were successfully replicated from master Notes: if step 2 fails because link w/master is dead, then it will try next time including and new registrations that came in If step 3 clears 1 local registration or 10 local registrations, it doesn't care. This same mechanism can be used for subscriptions This relies on high enough registration rate to double as syncing mechanism. We may want to run steps 2-3 in separate thread so we can controlled rate, faster or slower If we generalize this "sync" strategy, it could be used for things from voicemail to end user PIN updates from TUI. Why doesn't mongo handle this situation? Good question, I'm glad you asked. I think its because mongo is not meant to work on branch survivability mode. Mongo would have you setup bunch of dedicated mongo servers that if one went down, another could be quickly elected to take it's place. This is what you want in a web farm, but we want "cord is cut to master, keep going" mode. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
