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

Liviu Chircu liviu at opensips.org
Wed Nov 6 12:39:03 EST 2019


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 Developer
http://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 
> <mailto: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 Developer
>     http://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
>>     <http://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 list
>>     Users at lists.opensips.org  <mailto:Users at lists.opensips.org>
>>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto: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 list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20191106/a1411e29/attachment.html>


More information about the Users mailing list