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

Øyvind Kolbu oyvind.kolbu at usit.uio.no
Thu Aug 30 12:50:54 CEST 2012


On 2012-08-30 at 11:32, Daniel-Constantin Mierla wrote:
> On 8/30/12 10:29 AM, Øyvind Kolbu wrote:
> > Yes, I actually want both, HA + replication, by using db_cluster as the
> > replicator. And as I've demonstrated the location-table on non-primary
> > servers will lack entries after downtime, which is bad.
> Replication is done with parallel writing as long as all nodes are 
> available, but, better said, you look for re-synchronization after 
> downtime, which is another story, not easy to code, because it is db 
> specific.

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.

> > If this indeed is impossible I've have to continue our current scheme with
> > SIP level replication.
> If you use db mode 3, then you can do database level replication, is the 
> same.

-------    -------
| 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



More information about the sr-users mailing list