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 <[email protected]> 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 <[email protected]> On Behalf Of Alex > Balashov > Sent: Friday, March 6, 2020 7:31 PM > To: [email protected] > 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 >> [email protected] >> 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 > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
