[OpenSIPS-Users] 3.0.1 Full sharing registrar - mysql write back not working

Wed Nov 6 18:13:15 EST 2019

Ok, in this case we are running a central database per geographic location
with two local instances per site, each site serves a unique domain. The
goal is to have it setup such that clients will have registrations in two
sites and are served by a single server per site, a VIP owner. The second
instance serves as a hot standby and would ideally be primed with dialog
and location awareness in the event that the first instance fails. When the
failed node is restored we'd like it to fall back cleanly with as little
impact on the users as possible.

skip_replicated_db_ops sounds like it should prevent both servers writing
back to the shared table which could be problematic and a waste of
electricity. If that is the expected behaviour then it sounds helpful so
I'll use it until I know better. I'll update you if I find anything
worrying in the source (or production!) :)

On Wed, 6 Nov 2019, 17:40 Liviu Chircu, <liviu at opensips.org> wrote:

> The answer is: it depends.  If each of your servers has its own, local
> "location" table for
> persistency reasons, then you must remove "skip_replicated_db_ops".  This
> is our
> recommended way of ensuring persistency:  no more shared DB shenanigans,
> keep the tables private.
>
> However, if your architecture forces each of your servers to share the
> same "location"
> table, then "skip_replicated_db_ops" may help, hopefully if it's still
> 100% functional.
>
> Cheers,
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 06.11.2019 18:52, Callum Guy wrote:
>
> Thanks Liviu, that helps a lot. My expectation was that
> the sync-from-cluster option would favour a sync operation from a local
> active peer via the binary interface on first boot, that sounded like the
> ideal behaviour as it should be fully up to date; especially in db write
> back mode. For our production operations it isn't common for the server to
> be taken down unexpectedly so in reality it won't make too much difference
> to use the database as the primary data source on boot.
>
> I can confirm that the load-from-sql behaviour is replicating the contacts
> via clusterer and provides us with the resilience we need, in addition the
> ownership pinging_mode is working exactly as it should - thanks for these
> neat features!
>
> Should I remove skip_replicated_db_ops from our configuration, we're about
> to go live and if it is not a useful setting we would want to take this
> opportunity to purge it! To clarify, my interpretation of the docs for this
> option is that it would prevent duplication of the DB writes for
> new/updated registrations which we would not want. In our two node clusters
> we'd ideally just have the second as a hot backup which captures all the
> dialog and user data but doesn't do anything with it until it gains the
> sharing tag - including DB ops. If we can remove the skip_replicated_db_ops
> option and keep this behaviour please let me know, otherwise we'll leave it
> in place :)
>
>
> On Wed, 6 Nov 2019 at 16:01, Liviu Chircu <liviu at opensips.org> wrote:
>
>> Hi Callum,
>>
>> In short:
>>
>> * "sync-from-cluster" will deny all DB writes.  It is useful in case you
>> don't
>>   mind the risk of losing all registrations in case the active node is
>> offline
>>   and you restart the backup for some reason.  On the positive side, you
>> will
>>   push a lot less queries to the disk.
>>
>> * "load-from-sql" will enable all DB writes.  By using it, you gain better
>>   durability for the registrations, just like in the vanilla OpenSIPS
>> usrloc.
>>   This is just a restart persistency related setting -- the cluster nodes
>> will
>>   still continue to replicate data at runtime and you will still be able
>> to
>>   invoke the "ul_cluster_sync" MI command.
>>
>> * "skip_replicated_db_ops" is some hack from version 2.2, and we haven't
>> taken
>>   the time to remove it from the code.  It seems to be still functional,
>> so as
>>   long as you enable it, the DB writes will be denied.
>>
>> Regards,
>>
>> Liviu Chircu
>> OpenSIPS Developerhttp://www.opensips-solutions.com
>>
>> On 06.11.2019 17:10, Callum Guy wrote:
>>
>> Hi All,
>>
>> I've been testing a new cluster based registrar config and noticed that
>> the location records weren't being written back to the database.
>>
>> The issue appears resolved when I switch usrloc.restart_persistency from
>> "sync-from-cluster" to "load-from-sql". This is acceptable however it seems
>> more correct to allow clusterer to sync the data for me.
>>
>> modparam("usrloc", "location_cluster", 25)
>> modparam("usrloc", "cluster_mode", "full-sharing")
>> modparam("usrloc", "pinging_mode", "ownership")
>> modparam("usrloc", "restart_persistency", "*sync-from-cluster*")
>> modparam("usrloc", "sql_write_mode", "write-back")
>> modparam("usrloc", "timer_interval", 60)
>> modparam("usrloc", "skip_replicated_db_ops", 1)
>> modparam("usrloc", "max_contact_delete", 25)
>> modparam("usrloc", "hash_size", 16)
>> modparam("usrloc", "nat_bflag", "NATTED_CONTACT")
>> modparam("usrloc", "use_domain", 1)
>> modparam("usrloc", "db_url", "mysql://user:abc@192.168.151.20/opensips")
>>
>> I have attempted several variations including
>> removing skip_replicated_db_ops and changing sql_write_mode however nothing
>> resolved the issue. The contacts were visible within the cluster (mi
>> ul_dump) but I couldn't get them to sync back to the database at all.
>>
>> My target implementation is to have a pair of instances, sharing a VIP
>> (keepalived), such that when a node is terminated the clusterer module has
>> preshared all the data and registrations and dialogs do not drop. I have
>> configuration for the dialog and clusterer module which I would be happy to
>> share if required. I would be very interested to hear if I am doing
>> something wrong or misunderstanding how it should work!
>>
>> Many thanks,
>>
>> Callum
>>
>>
>> *0333 332 0000  |  www.x-on.co.uk <http://www.x-on.co.uk>  |   **
>> <https://www.linkedin.com/company/x-on>   <https://www.facebook.com/XonTel>
>>   <https://twitter.com/xonuk> *
>>
>> X-on is a trading name of Storacall Technology Ltd a limited company
>> registered in England and Wales.
>> Registered Office : Avaland House, 110 London Road, Apsley, Hemel
>> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478.
>> The information in this e-mail is confidential and for use by the
>> addressee(s) only. If you are not the intended recipient, please notify
>> X-on immediately on +44(0)333 332 0000 and delete the
>> message from your computer. If you are not a named addressee you must not
>> use, disclose, disseminate, distribute, copy, print or reply to this email. Views
>> or opinions expressed by an individual
>> within this email may not necessarily reflect the views of X-on or its
>> associated companies. Although X-on routinely screens for viruses,
>> addressees should scan this email and any attachments
>> for viruses. X-on makes no representation or warranty as to the absence
>> of viruses in this email or any attachments.
>>
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> *0333 332 0000  |  www.x-on.co.uk <http://www.x-on.co.uk>  |   **
> <https://www.linkedin.com/company/x-on>   <https://www.facebook.com/XonTel>
>   <https://twitter.com/xonuk> *
>
> X-on is a trading name of Storacall Technology Ltd a limited company
> registered in England and Wales.
> Registered Office : Avaland House, 110 London Road, Apsley, Hemel
> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478.
> The information in this e-mail is confidential and for use by the
> addressee(s) only. If you are not the intended recipient, please notify
> X-on immediately on +44(0)333 332 0000 and delete the
> message from your computer. If you are not a named addressee you must not
> use, disclose, disseminate, distribute, copy, print or reply to this email. Views
> or opinions expressed by an individual
> within this email may not necessarily reflect the views of X-on or its
> associated companies. Although X-on routinely screens for viruses,
> addressees should scan this email and any attachments
> for viruses. X-on makes no representation or warranty as to the absence of
> viruses in this email or any attachments.
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

-- 

*0333 332 0000  |  www.x-on.co.uk <http://www.x-on.co.uk>  |   ** 
<https://www.linkedin.com/company/x-on>   <https://www.facebook.com/XonTel> 
  <https://twitter.com/xonuk> *

X-on
is a trading name of Storacall 
Technology Ltd a limited company registered in
England and Wales.

Registered Office : Avaland House, 110 London Road, Apsley, Hemel 
Hempstead,
Herts, HP3 9SD. Company Registration No. 2578478.

The 
information in this e-mail is confidential and for use by the addressee(s)

only. If you are not the intended recipient, please notify X-on immediately 
on +44(0)333 332 0000 and delete the
message from your computer. If you are 
not a named addressee you must not use,
disclose, disseminate, distribute, 
copy, print or reply to this email. Views
or opinions expressed by an 
individual
within this email may not necessarily
reflect the views of X-on 
or its associated companies. Although X-on routinely
screens for viruses, 
addressees should scan this email and any attachments
for
viruses. X-on 
makes no representation or warranty as to the absence of viruses
in this 
email or any attachments.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20191106/ae326849/attachment-0001.html>