<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">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" 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" 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" 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: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" target="_blank">Users@lists.opensips.org</a>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" 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" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="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>