<div dir="ltr"><div dir="ltr">On Mon, Jan 31, 2022 at 10:01 AM <<a href="mailto:Veronique.Lefebure@cern.ch">Veronique.Lefebure@cern.ch</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><u></u>

  
   
 
 <div>
  <div>
   Many thanks.
  </div>
  <div>
   And did you have the opportunity to fall back on the standby server, either for maintenance or because the first server went down in an unintended manner ?
  </div>
  <blockquote type="cite">
   <div>
    On 28/01/2022 19:42 Mark Moseley <<a href="mailto:moseleymark@gmail.com" target="_blank">moseleymark@gmail.com</a>> wrote:</div></blockquote></div></blockquote><div><br></div><div>I've only done failovers while testing, both when setting things up initially and once things were in production. What I haven't had happen yet is a non-user-initiated failover due to some real issue, since it's only been deployed to production for a few months now. My testing failover all worked well though. </div><div><br></div><div>I did however learn that if you're using a mysql backend for leases (as I am, replicating an on-board mysql db between both Kea hosts), you should suppress replication for the lease tables, since the hot standby does its own Kea-based replication for leases (I had missed this in the docs). I put the leases into a second database and turned off replication for that database. I could've suppressed it just for the lease4 table but this felt "cleaner". I imagine the same is likely true for other backends like Postgres.</div></div></div>