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@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@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@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@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@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@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@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@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@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/
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users@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