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

[Liviu Chircu]

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
> 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/945eda9a/attachment.html>