Hello,
usrloc has already "server_id_filter" for filtering by server id deletions
and loading of db records. And also ka_* has a filter for that, so why not
add a filter also for saving records?
This will enable to:
- share a db between servers, everyone managing own records
- be compatible with dmq for usrloc replication, you may have replicated
contacts and db persistence at same time.
what do you think?
br,
matteo
On Tue, Sep 27, 2022 at 11:39 AM Daniel-Constantin Mierla <miconda(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only
to the
sender!
--
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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the
sender!
--
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(a)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