On Wed, Feb 23, 2011 at 9:40 PM, Joegen Baclor <[email protected]> wrote: > On Thursday, 24 February, 2011 09:46 AM, Douglas Hubler wrote: >> >> On Wed, Feb 23, 2011 at 6:44 PM, Joegen Baclor<[email protected]> wrote: >>> >>> What if we simply invert 1 and 2 and forget about 2-3 all together if 1 >>> succeeds? >> >> I see where you're going, but we cannot guarantee the REGISTRATION >> makes is back thru normal mongo replication. If you can solve that >> w/o blocking the SIP transaction then sure. What I think you'll find >> is that you'd just be creating a FIFO queue in memory that >> accomplished kinda the same thing only less resilient to server >> restarts because it wouldn't be using mongo to store the pending >> REGISTRATION that have yet to make a round trip. >> > > > > I concede. However, how does the master DB compute delta when syncing write > operations with the slave registration db? is this transactional or > computed against the entire BSON document?
transactional. i.e. slave contacts master and says : "any new records since t=X" > I suggest that we have two > sets of DB's. imdb.local.registrar -> imdb.shared.registrar the guaranty > the integrity of the master slave setup instead of allowing slaves to write > the the replicated (which they should not do IMHO). whatever you think is easiest to implement. i thought a simple attribute "local=t" made things simple. keep in mind there are a few utility scripts that peek at registration info i'd hate to complicate their job by having to query 2 tables. > 1. Slave writes to imdb.local.registrar > 2. Slave replicates to master > > Redirect process. > > 1. INVITE goes in. > 2. Registrar queries imdb.local.registrar > 3. If not found, fallback to imdb.shared.registrar > 4. If not found on both, allow fallback rules to take precedence. > > > > > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
