28 Aug
2012
28 Aug
'12
6:34 p.m.
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