Re: [SR-Users] db_cluster together with the registrar module = signal 11

On 2012-08-30 at 11:32, Daniel-Constantin Mierla wrote: I don't want Kamailio to synchronise my data, but I think it is reasonable to expect it to treat the write targets individual and independent of the result from the initial reading. Perhaps enabling db_update_as_insert is the only current option. ------- ------- | DB1 | | DB2 | ------- ------- | | | | | | ------- -------- | LOC1| | LOC2 | ------- -------- \ / ---------- | Phones | ---------- The above setup is my scenario. When everything is up LOC1 will use DB1 for reading and write to both DB1 and DB2. Similarly LOC2 will use DB2 for reading and write to both DB1 and DB2. Both uses the "other" DB as failover for reading. LOC1 and LOC2 are setup with even load in an SRV record. - While DB2 is down, say reboot for a new kernel, a phone A boots and registers at LOC1 and is populated in the DB1 database. Reading works fine from LOC2 to DB1. - DB2 is back again. - Phone A re-registers at LOC1. The previous entry is found in the location table and an UPDATE is issued for both DB1 and DB2, but DB2 will still lack the entry. DB2 will _never_ get an entry for until phone A boots and gets a new Call-ID or for some reason phone A chooses to register with LOC2 instead. Then a duplicate entry will end up in DB1, as LOC2 will blindly issue an INSERT to both DB1 and DB2. As the location servers are evenly used, ~every second call to phone A will fail with 404. -- Øyvind Kolbu