What if we simply invert 1 and 2 and forget about 2-3 all together if 1 succeeds?
On Wednesday, 23 February, 2011 11:57 PM, Douglas Hubler wrote: > 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/ > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
