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 <[email protected]
<mailto:[email protected]>> 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:[email protected]/opensips
<http://user:[email protected]/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
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
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
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
