Hi Henning,
Yes, the db_check_update approach provides an adequate solution. I already explored that
before making this post.
My interest in that issue is insofar as:
1) How do registrants come to go missing from the DB sync, if assured to be starting from
0?
2) If this is a quality that is innate to how db_mode 2 works, shouldn’t db_check_update
be on by default, and/or shouldn’t the documentation reflect that db_check_update is a
necessary or best practice alongside db_mode 2?
— Alex
—
Sent from my iPad
On Mar 7, 2020, at 3:19 PM, Henning Westerholt
<hw(a)skalatan.de> wrote:
Hi Alex,
the db_timer_clean is just an additional mechanism to clean-up expired records. Like if
you get some errors from time to time in the DB connection, and some deletes are not
correctly processed on the DB. Then some stale records should be left in the DB, and you
can use this one to clean up.
Normally it should be not necessary, as Kamailio will synchronize it just by the normal
timer. From the source:
/*!
* \brief Write-back timer, used for WRITE_BACK db_mode
*
* Write-back timer, used for WRITE_BACK db_mode. Process
* all contacts from the record, delete expired ones from the DB.
* Furthermore it updates changed contacts, and also insert new
* ones in the DB.
* \param _r processed record
*/
static inline void wb_timer(urecord_t* _r) {..}
About the first question, why some registrations are missing in the DB - this needs to be
investigated more closely. As a workaround you could try (as already suggested) to use the
INSERT instead of UPDATE module parameter, e.g. with db_check_update.
Cheers,
Henning
--
Henning Westerholt –
https://skalatan.de/blog/
Kamailio services –
https://gilawa.com
-----Original Message-----
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Alex Balashov
Sent: Friday, March 6, 2020 7:31 PM
To: sr-users(a)lists.kamailio.org
Subject: Re: [SR-Users] usrloc db_mode 2 and dropped contacts
And another question that goes along with this:
Do I need `db_timer_clean` to make db_mode 2 work as expected?
A reasonable person would conclude from the documentation for `timer_interval` and
`db_mode 2` ...
"2 - Write-Back scheme. This is a combination of previous two
schemes. All changes are made to memory and database synchronization
is done in the timer. The timer deletes all expired contacts and
flushes all modified or new contacts to database."
"The module uses a timer to delete expired contacts, synchronize with
database and other tasks, that need to be run periodically."
... that deletion of expired contacts is propagated to underlying DB storage (passed
through the logic of whichever db_mode) in the form of periodic deletions of expired
contacts.
It appears not to be enabled by default. DELETE statements appear to be issued
periodically from usrloc even though it's not enabled.
So, what's that setting for? When and why do I need it?
-- Alex
On Fri, Mar 06, 2020 at 12:58:16PM -0500, Alex
Balashov wrote:
Hi,
On 4.4.7, since switching to db_mode 2 for usrloc with the following settings:
modparam("usrloc", "db_mode", 2)
modparam("usrloc", "timer_procs", 2)
modparam("usrloc", "skip_remote_socket", 1)
modparam("usrloc", "timer_interval", 30)
modparam("usrloc", "matching_mode", 0)
I seem to run into a situation where, despite starting from zero local
registrations and an empty DB `location` table, out of ~1700
registrations visible in the runtime usrloc table, about 60-80 never
make it into the database.
This is because they're being continuously UPDATE'd rather than
INSERT'd, so there is some presumption that they should already be in
the Postgres database. But they're not.
This gap seems to very slowly grow over time.
I understand that this option is intended to deal with a scenario like
that:
https://kamailio.org/docs/modules/5.3.x/modules/usrloc.html#usrloc.p.d
b_check_update
but the documentation doesn't say it needs to be on for db_mode 2 to
work correctly, and it's off by default.
I'm wondering what causes certain registrants to get into this state
in the first place, where the registrar presumes that they've already
been synced to the DB and only need to be update'd on renewal, where
in fact they have not been synced.
Causes I've ruled out:
1) The contacts being ignored due to non-local socket or other
invalidation;
2) Contacts being explicitly deleted by an outside process.
Any ideas appreciated!
-- 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 (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
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 (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users