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

[Øyvind Kolbu]

On 2012-08-24 at 10:48, Øyvind Kolbu wrote:
> First impression is that everything is working now, thanks! At least
> registrations are getting populated in both databases from both servers. As
> I'm out traveling I havn't yet tested calling and whether or not the
> failover works as expected. I assume setting usrloc's db_mode to 3 is
> recommended in this kind of setup?
> 
> For now I'm using:
>     modparam("db_cluster", "cluster","data2=>voip1_data2=9s9p;voip2_data2=8s9p")
> on my voip1 machine, and the line below on the voip2 machine:
>     modparam("db_cluster", "cluster","data2=>voip2_data2=9s9p;voip1_data2=8s9p")
> 
> The same configuration created coredumps on both machines previously.

Have played with usrloc and db_cluster a bit in the lab and think I found
two bugs. I have not inspected the actual sql-commands, but this is based
in my observations. Both sql-servers are running postgresql 9.1.4.

1) If the second server lacks an entry in the location table it will never
   be populated, while the primary is updated. This is a major flaw if
   the second server has been unavailable and then is back again it will
   never contain the same information as the primary.

   I think this is because usrloc issues an UPDATE for the row it read,
   but the second server can not UPDATE an non existent row.

   Deleting the entry from the primary server will issue an INSERT to both
   databases and then they are identical again, for that row at least.

2) If the primary lacks an entry and the second already has it, it will
   get an extra entry for that user. After a while though the stale entry
   will be pruned.

   Probably similar reason as above. usrloc finds no entries in the table
   when reading, thus issuing INSERT.

Tried setting

    modparam("usrloc", "db_check_update", 1)

but to no avail.

Even enabling

   modparam("usrloc", "db_update_as_insert", 1)

will not fix issue #1.

-- 
Øyvind Kolbu