Top posting: I have spoken to Cristi and George who both think that they are pretty sure that a Mongo slave instance only can do reads and not write to ANY dataset within the slave MongoDB instance. This changes the entire ballgame and probably some hours of work on registration DB I did since this morning. Let's discuss the alternative during scrum.
On Thursday, 24 February, 2011 11:17 AM, Douglas Hubler wrote: > 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/
