<div dir="auto">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. <div dir="auto"><br></div><div dir="auto">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!) :)<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 6 Nov 2019, 17:40 Liviu Chircu, <<a href="mailto:liviu@opensips.org" target="_blank" rel="noreferrer">liviu@opensips.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p><tt>The answer is: it depends. If each of your servers has its
own, local "location" table for<br>
persistency reasons, then you must remove
"skip_replicated_db_ops". This is our<br>
recommended way of ensuring persistency: no more shared DB
shenanigans, keep the tables private.</tt></p>
<p><tt>However, if your architecture forces each of your servers to
share the same "location"<br>
table, then "skip_replicated_db_ops" may help, hopefully if it's
still 100% functional.</tt></p>
<p><tt>Cheers,</tt><br>
</p>
<pre cols="72">Liviu Chircu
OpenSIPS Developer
<a href="http://www.opensips-solutions.com" rel="noreferrer noreferrer" target="_blank">http://www.opensips-solutions.com</a></pre>
<div>On 06.11.2019 18:52, Callum Guy wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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.
<div>
<div><br>
</div>
<div>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! </div>
<div><br>
</div>
<div>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 :)</div>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, 6 Nov 2019 at 16:01,
Liviu Chircu <<a href="mailto:liviu@opensips.org" rel="noreferrer noreferrer" target="_blank">liviu@opensips.org</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p><tt>Hi Callum,</tt></p>
<p><tt>In short:<br>
</tt></p>
<p><tt>* "sync-from-cluster" will deny all DB writes. It is
useful in case you don't<br>
mind the risk of losing all registrations in case the
active node is offline<br>
and you restart the backup for some reason. On the
positive side, you will<br>
push a lot less queries to the disk.<br>
</tt></p>
<p><tt>* "load-from-sql" will enable all DB writes. By
using it, you gain better<br>
durability for the registrations, just like in the
vanilla OpenSIPS usrloc.<br>
This is just a restart persistency related setting --
the cluster nodes will<br>
still continue to replicate data at runtime and you
will still be able to<br>
invoke the "ul_cluster_sync" MI command.<br>
</tt></p>
<p><tt>* "skip_replicated_db_ops" is some hack from version
2.2, and we haven't taken<br>
the time to remove it from the code. It seems to be
still functional, so as<br>
long as you enable it, the DB writes will be denied.<br>
</tt></p>
<p><tt>Regards,<br>
</tt></p>
<pre cols="72">Liviu Chircu
OpenSIPS Developer
<a href="http://www.opensips-solutions.com" rel="noreferrer noreferrer" target="_blank">http://www.opensips-solutions.com</a></pre>
<div>On 06.11.2019 17:10, Callum Guy wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi All,<br>
<div><br>
</div>
<div>I've been testing a new cluster based registrar
config and noticed that the location records weren't
being written back to the database. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>modparam("usrloc", "location_cluster", 25)<br>
modparam("usrloc", "cluster_mode", "full-sharing")<br>
modparam("usrloc", "pinging_mode", "ownership")<br>
modparam("usrloc", "restart_persistency", "<b>sync-from-cluster</b>")<br>
modparam("usrloc", "sql_write_mode", "write-back")<br>
modparam("usrloc", "timer_interval", 60)<br>
modparam("usrloc", "skip_replicated_db_ops", 1)<br>
modparam("usrloc", "max_contact_delete", 25)<br>
modparam("usrloc", "hash_size", 16)<br>
modparam("usrloc", "nat_bflag", "NATTED_CONTACT")<br>
modparam("usrloc", "use_domain", 1)</div>
<div>modparam("usrloc", "db_url", "mysql://<a href="http://user:abc@192.168.151.20/opensips" rel="noreferrer noreferrer" target="_blank">user:abc@192.168.151.20/opensips</a>")<br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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!</div>
<div><br>
</div>
<div>Many thanks,</div>
<div><br>
</div>
<div>Callum</div>
</div>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;text-align:justify"><font size="3" face="Verdana"><span style="font-size:8px;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span></font></p>
<div><img src="https://www.x-on.co.uk/email/footer/General-Practice-Awards-shortlisted.jpg"></div>
<div><br>
</div>
<div>
<div>
<div><font size="4"><b><sup><font face="Verdana">0333
332 0000 | <a href="http://www.x-on.co.uk" rel="noreferrer noreferrer" target="_blank">www.x-on.co.uk</a>
| <sub> </sub></font></sup></b></font><font size="4"><b><sub><sup><font face="Verdana"><a href="https://www.linkedin.com/company/x-on" rel="noreferrer noreferrer" target="_blank"><img src="http://www.x-on.co.uk//images/icon/linkedin.png" width="24" height="24"></a> <a href="https://www.facebook.com/XonTel" rel="noreferrer noreferrer" target="_blank"><img src="http://www.x-on.co.uk//images/icon/facebook.png" width="24" height="24"></a> <a href="https://twitter.com/xonuk" rel="noreferrer noreferrer" target="_blank"><img src="http://www.x-on.co.uk//images/icon/twitter.png" width="24" height="24"></a></font></sup></sub> </b></font><br>
<p><span style="font-size:6pt;font-family:Verdana;color:black">X-on
is a trading name of Storacall Technology Ltd a
limited company registered in England and Wales.<br>
Registered Office : Avaland House, 110 London
Road, Apsley, Hemel Hempstead, Herts, HP3 9SD.
Company Registration No. 2578478.<br>
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 <span>+44(0)333 332 0000</span>
and delete the<br>
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. </span><span style="font-size:6pt;font-family:Verdana;color:black">Views
or opinions expressed by an individual<br>
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<br>
for viruses. X-on makes no representation or
warranty as to the absence of viruses in this
email or any attachments.</span></p>
<p><span style="font-size:6pt;font-family:Verdana;color:black"></span><font size="2"><span style="font-size:6pt;font-family:Verdana;color:black"></span></font></p>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Users mailing list
<a href="mailto:Users@lists.opensips.org" rel="noreferrer noreferrer" target="_blank">Users@lists.opensips.org</a>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" rel="noreferrer noreferrer" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote>
</div>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;text-align:justify"><font size="3" face="Verdana"><span style="font-size:8px;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span></font></p>
<div><img src="https://www.x-on.co.uk/email/footer/General-Practice-Awards-shortlisted.jpg"></div>
<div><br>
</div>
<div>
<div>
<div><font size="4"><b><sup><font face="Verdana">0333 332
0000 | <a href="http://www.x-on.co.uk" rel="noreferrer noreferrer" target="_blank">www.x-on.co.uk</a>
| <sub> </sub></font></sup></b></font><font size="4"><b><sub><sup><font face="Verdana"><a href="https://www.linkedin.com/company/x-on" rel="noreferrer noreferrer" target="_blank"><img src="http://www.x-on.co.uk//images/icon/linkedin.png" width="24" height="24"></a>
<a href="https://www.facebook.com/XonTel" rel="noreferrer noreferrer" target="_blank"><img src="http://www.x-on.co.uk//images/icon/facebook.png" width="24" height="24"></a>
<a href="https://twitter.com/xonuk" rel="noreferrer noreferrer" target="_blank"><img src="http://www.x-on.co.uk//images/icon/twitter.png" width="24" height="24"></a></font></sup></sub> </b></font><br>
<p><span style="font-size:6.0pt;font-family:Verdana;color:black">X-on
is a trading name of Storacall Technology Ltd a limited
company registered in
England and Wales.<br>
Registered Office : Avaland House, 110 London Road,
Apsley, Hemel Hempstead,
Herts, HP3 9SD. Company Registration No. 2578478.<br>
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 <span>+44(0)333 332 0000</span>
and delete the<br>
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. </span><span style="font-size:6.0pt;font-family:Verdana;color:black">Views
or opinions expressed by an individual<br>
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<br>
for
viruses. X-on makes no representation or warranty as to
the absence of viruses
in this email or any attachments.</span></p>
<p><span style="font-size:6.0pt;font-family:Verdana;color:black"></span><font size="2"><span style="font-size:6.0pt;font-family:Verdana;color:black"></span></font></p>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Users mailing list
<a href="mailto:Users@lists.opensips.org" rel="noreferrer noreferrer" target="_blank">Users@lists.opensips.org</a>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" rel="noreferrer noreferrer" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;text-align:justify"><font size="3" face="Verdana"><span style="font-size:8px;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span></font></p><div><img src="https://www.x-on.co.uk/email/footer/General-Practice-Awards-shortlisted.jpg"></div><div><br></div><div><div><div><font size="4"><b><sup><font face="Verdana">0333 332 0000 | <a href="http://www.x-on.co.uk" target="_blank">www.x-on.co.uk</a> | <sub> </sub></font></sup></b></font><font size="4"><b><sub><sup><font face="Verdana"><a href="https://www.linkedin.com/company/x-on" target="_blank"><img src="http://www.x-on.co.uk//images/icon/linkedin.png" width="24" height="24"></a> <a href="https://www.facebook.com/XonTel" target="_blank"><img src="http://www.x-on.co.uk//images/icon/facebook.png" width="24" height="24"></a> <a href="https://twitter.com/xonuk" target="_blank"><img src="http://www.x-on.co.uk//images/icon/twitter.png" width="24" height="24"></a></font></sup></sub> </b></font><br><p><span style="font-size:6.0pt;font-family:Verdana;color:black">X-on
is a trading name of Storacall Technology Ltd a limited company registered in
England and Wales.<br>
Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead,
Herts, HP3 9SD. Company Registration No. 2578478.<br>
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 <span>+44(0)333 332 0000</span> and delete the<br>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. </span><span style="font-size:6.0pt;font-family:Verdana;color:black">Views
or opinions expressed by an individual<br>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<br>for
viruses. X-on makes no representation or warranty as to the absence of viruses
in this email or any attachments.</span></p>
<p><span style="font-size:6.0pt;font-family:Verdana;color:black"></span><font size="2"><span style="font-size:6.0pt;font-family:Verdana;color:black"></span></font></p></div></div></div>