[SR-Users] Interactions of dmq_usrloc and usrloc w/db_mode > 0

[Alex Balashov]

Hi,

No, there is no such replication; one node is the single source of truth for the DB, and the other nodes use db_mode 0. 

But still, some in-memory contacts are missing from the DB. I can’t really say if it’s a lot or a little; there are too many to spot-check.

— Alex

—
Sent from mobile, with due apologies for brevity and errors.

> On Sep 27, 2022, at 5:36 AM, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> 
> Hello,
> 
> if each node is having its own independent database, it should work
> fine. If the database is replicated or a cluster, then conflicts of
> duplicated rows can occur, there is the option to do update if insert
> failed, but probably is better that only one node writes to db if the db
> does replication by itself.
> 
> Cheers,
> Daniel
> 
>> On 27.09.22 01:04, Alex Balashov wrote:
>> Yeah, it worked great in ‘lab’ for me too. It’s in production that there are some struggles… :-) 
>> 
>>>> On Sep 26, 2022, at 2:17 PM, Arsen Semenov <arsperger at gmail.com> wrote:
>>> 
>>> by the chance I was playing exactly with the same setup these days, in a lab everything works just fine. +1 to the initial question. 
>>> 
>>>> On Mon 26 Sep 2022 at 18:33, Joel Serrano <joel at textplus.com> wrote:
>>> +1 in this situation haha, also hoping to get some nice input :D
>>> 
>>>> On Mon, Sep 26, 2022 at 9:20 AM Matteo Brancaleoni <mbrancaleoni at gmail.com> wrote:
>>> Well,
>>> 
>>> I asked a similar question here https://lists.kamailio.org/pipermail/sr-users/2022-July/115160.html but no answer yet :) 
>>> 
>>> What I see on my side is that it indeed works, the only drawback is that the same contact is getting synced to DB, which causes a duplicate error unless you use the "db_insert_update" option.
>>> 
>>> Done that seems that it works ok (did tested in prod yet), and I had the all the contacts live on all nodes and on db. The only downside that maybe can happen is that the periodic sync may skew a bit the expire time and maybe give a contact some more seconds, but it really depends on timings of the clusters.
>>> 
>>> But I'm really interested in the answer, too :) 
>>> 
>>> -- Matteo
>>> 
>>> 
>>>> On Mon, Sep 26, 2022 at 4:07 PM Alex Balashov <abalashov at evaristesys.com> wrote:
>>> Hi,
>>> 
>>> Are there any known contraindications for replicating contacts using dmq/dmq_usrloc, and injecting those contacts into a database on one of the nodes using usrloc with `db_mode` 1 or 2?
>>> 
>>> Predictably, this is being done to support the use-case of getting registration status from database. If you think this should be done with JSONRPC, I am in complete agreement with you, but it’s not up to me. :-)
>>> 
>>> I am doing this with `db_mode` 2 now, and finding that, for a small number of AORs, one can find instances where they are consistently stored in memory but not present in the `location` table. The overall proportion of these AORs, out of thousands, seems to be quite small. It was initially somewhat higher, and it went down once I increased usrloc `timer_processes` and increased the sync interval from 30 to 60 seconds. 
>>> 
>>> Nevertheless, it is still non-zero, and I am getting intermittent reports. I wonder if there are some prior experiences with this and anything to watch out, or if `db_mode` 1 might be a superior choice. I personally cannot see how that would be; it seems to have all the performance downsides of mode 3. But perhaps if something about it is more “problem-free” vis-a-vis DMQ, it’s worth a shot?
>>> 
>>> — Alex
>>> 
>>> -- 
>>> Alex Balashov | Principal | Evariste Systems LLC
>>> 
>>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
>>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>>> 
>>> 
>>> __________________________________________________________
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>  * sr-users at lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>>> Edit mailing list options or unsubscribe:
>>>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>> __________________________________________________________
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>  * sr-users at lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>>> Edit mailing list options or unsubscribe:
>>>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>> __________________________________________________________
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>  * sr-users at lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>>> Edit mailing list options or unsubscribe:
>>>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>> -- 
>>> Sent from Gmail Mobile
>>> __________________________________________________________
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> * sr-users at lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>>> Edit mailing list options or unsubscribe:
>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> -- 
>> Alex Balashov | Principal | Evariste Systems LLC
>> 
>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>> 
>> 
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>  * sr-users at lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>> Edit mailing list options or unsubscribe:
>>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - Online
>  Nov 7-10, 2022 (Europe Timezone)
>  * https://www.asipto.com/sw/kamailio-advanced-training-online/
>