[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