default ctdb configuration file locations

[Martin Schwenke]

On Fri, 21 Oct 2016 10:48:30 -0500, Steve French <smfrench at gmail.com>
wrote:

> [...] Part of the reason I was worrying
> about this is seeing some strange behavior I (at first) thought was
> configuration related but presumably is not.  I had configured a two
> node ctdb cluster with the node below's ctdbd.conf configured as:
> 
> "CTDB_CAPABILITY_RECMASTER=no"
> 
> 
> $ ctdb status
> 
> Number of nodes:2
> pnn:0 172.29.161.26    OK
> pnn:1 172.29.161.45    OK (THIS NODE)
> Generation:1678151314
> Size:2
> 
> hash:0 lmaster:0
> hash:1 lmaster:1
> Recovery mode:NORMAL (0)
> Recovery master:1
> 
> I am certain that CTDB_CAPABILITY_RECMASTER is set to no on that node
> (and not set to anything on the other node) but it is still becoming
> recovery master which I found confusing.

What does "ctdb getcapabilities" say on that node?

If it says "YES":

* Have you restarted CTDB since setting "CTDB_CAPABILITY_RECMASTER=no"?  

  Although changes to some variables take relatively immediate effect
  (e.g. on next monitor cycle), the ones that translate to daemon
  options only take effect at startup.

  For this particular option, we could make (for example) 00.ctdb
  notice a change and have it run "ctdb setrecmasterrole on|off".
  However, this is probably needless overhead for most users, who just
  retain the default of allowing all nodes to be recovery master.

  If you need to change the value while running then you can just run
  "ctdb setrecmasterrole on|off".

* CTDB_CAPABILITY_RECMASTER is case-sensitive

  Only an exact value of "no" will switch it off.  Perhaps we need to
  loosen the matching?

If it says "NO" and the node is recovery master (for more than about
a second) then we have a bug in the recovery daemon's recovery master
checking logic. I have touched that code several times in the last
couple of years so there is obviously a chance that I have broken it.
However, it does work for me...  :-)

peace & happiness,
martin