(Reposting from sr-dev because, in retrospect, it makes more sense here.)
Does anyone know of any issues running usrloc with DB backing ('location') in a multi-master DB-replicated environment? I am referring to plain usrloc, not p_usrloc.
I have such an environment set up with db_mode = 1 (immediate write-through) and have run into a problem where Kamailio occasionally stops writing to the location table for no apparent reason. I am wondering if this is because another Kamailio instance bound to the secondary replica is performing a DB sync as well, and at some point they collide in some sort of race condition. Would db_mode 2 fix? Would anything fix? Is this even the problem?
-- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
I asked also on devel list, but no follow up there, so here again for the sake of going on with the conversation on this forum:
Is this like blocking or just not writing to db, but in memory everything is ok? iirc, all db failed operations should be reported as error to syslog, do you get any?
Cheers, Daniel
On 7/9/12 1:52 PM, Alex Balashov wrote:
(Reposting from sr-dev because, in retrospect, it makes more sense here.)
Does anyone know of any issues running usrloc with DB backing ('location') in a multi-master DB-replicated environment? I am referring to plain usrloc, not p_usrloc.
I have such an environment set up with db_mode = 1 (immediate write-through) and have run into a problem where Kamailio occasionally stops writing to the location table for no apparent reason. I am wondering if this is because another Kamailio instance bound to the secondary replica is performing a DB sync as well, and at some point they collide in some sort of race condition. Would db_mode 2 fix? Would anything fix? Is this even the problem?
-- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 07/10/2012 06:21 AM, Daniel-Constantin Mierla wrote:
I asked also on devel list, but no follow up there, so here again for the sake of going on with the conversation on this forum:
Is this like blocking or just not writing to db, but in memory everything is ok? iirc, all db failed operations should be reported as error to syslog, do you get any?
Sorry Daniel, I must have missed your reply on the devel list! My apologies.
To answer your questions:
1) Yes, this is just not writing to the DB; there is no evidence of blocking, nor evidence of database impact outside of usrloc. All other DB-backed modules write fine.
2) Yes, the contact bindings are stored in memory, so everything "works". However, certain internal needs rely on being able to see the bindings in the DB.
3) No DB or other complaints from Kamailio internally in syslog.
The next logical step would be to turn up debug logs, but the problem is that this issue is extremely difficult to consistently reproduce, which makes me think there is some sort of exotic race condition afoot.
-- Alex
Hello,
On 7/10/12 1:19 PM, Alex Balashov wrote:
On 07/10/2012 06:21 AM, Daniel-Constantin Mierla wrote:
I asked also on devel list, but no follow up there, so here again for the sake of going on with the conversation on this forum:
Is this like blocking or just not writing to db, but in memory everything is ok? iirc, all db failed operations should be reported as error to syslog, do you get any?
Sorry Daniel, I must have missed your reply on the devel list! My apologies.
To answer your questions:
- Yes, this is just not writing to the DB; there is no evidence of
blocking, nor evidence of database impact outside of usrloc. All other DB-backed modules write fine.
- Yes, the contact bindings are stored in memory, so everything
"works". However, certain internal needs rely on being able to see the bindings in the DB.
- No DB or other complaints from Kamailio internally in syslog.
The next logical step would be to turn up debug logs, but the problem is that this issue is extremely difficult to consistently reproduce, which makes me think there is some sort of exotic race condition afoot.
is it sporadically, only for few records, or once it started is for all records? Do you have small max registration interval?
Anything particular in database server logs?
You can eventually enable logging of sql queries in the database server and see if they get to the server or not. Alternative is to capture the traffic to the database if it is over the net.
Cheers, Daniel