search for: recmaster

Hi, I came across the 'CTDB_CAPABILITY_LMASTER=no' and 'CTDB_CAPABILITY_RECMASTER=no' options in my quest to salvage a rather poorly performing CTDB cluster over Ceph(fs). Unfortunately, the docs provide not enough information for a clustering noop like myself. Would there be any benefit to disabling those options for a branch office node on a high-latency WAN connection? T...

...> > > We use a Golang-based lock tool that we wrote for CTDB. That tool interacts > > with our 3.4 etcd cluster, and follows the requirements specified in the > > project. > > > > Question, does the external command line tool get called when LMASTER and > > RECMASTER are false? Given a scenario where we have a set of processes that > > have it set to false, then others that have it set to true, does the > > locking tool get called when they're set to false? > > Indeed it does. There are 2 current things conspiring against you: > &g...

Folks, We use a Golang-based lock tool that we wrote for CTDB. That tool interacts with our 3.4 etcd cluster, and follows the requirements specified in the project. Question, does the external command line tool get called when LMASTER and RECMASTER are false? Given a scenario where we have a set of processes that have it set to false, then others that have it set to true, does the locking tool get called when they're set to false? IF you say the lock tool still gets called in both cases, then the docs need to be updated, and we on our en...

...and running, I can transfer each ip address toward on node or the other, seamlessly. They can fence each other. But I still have one big issue : though they have been setup as clones, they don't behave identically : when shutting down node 1, node 0 takes over every part of ctdb setup (ip, recmaster, services). But when I stop ctdb daemon on node 1, though ctdb node 0 correctly stops its children daemons (nmbd, smbd and winbind) and kills itself, node 1 claims : ctdb_recovery_lock: Failed to get recovery lock on '/ctdb/.ctdb.lock' (This directory is clvm + gfs2 shared, writable and...

...it out (though untested). Here is my > Ansible fragment. Is this correct for the property names? > > ... > [legacy] > realtime scheduling = false > {% if ctdb_lmaster_capability is defined %} > lmaster capability = {{ ctdb_lmaster_capability }} > {% endif %} > {% if ctdb_recmaster_capability is defined %} > recmaster capability = {{ ctdb_recmaster_capability }} > {% endif %} > ... Yep. That looks good. These options are documented in the ctdb.conf(5) manual page. Sorry I didn't see the original message. The samba mailing list has always been far too busy for...

...t;robert.buck at som.com> wrote: > We use a Golang-based lock tool that we wrote for CTDB. That tool interacts > with our 3.4 etcd cluster, and follows the requirements specified in the > project. > > Question, does the external command line tool get called when LMASTER and > RECMASTER are false? Given a scenario where we have a set of processes that > have it set to false, then others that have it set to true, does the > locking tool get called when they're set to false? Indeed it does. There are 2 current things conspiring against you: * At the start of each recove...

On Thu, Oct 15, 2020 at 09:01:01AM -0400, Robert Buck via samba wrote: > Can someone please respond to this question? We're unsure how to > persistently set these flags, which are VERY useful for performance from > what we see. We want to ensure that after reboot, particular nodes are > always set on (or others off). From the ctdb/doc/ctdb.1.xml man page file:

...those log messages, they were occurring once per second (precisely). Then after several hours they stopped after these messages in the log: ctdbd[1220]: 10.206.2.124:4379: node 10.200.1.230:4379 is dead: 0 connected ctdbd[1220]: Tearing down connection to dead node :0 ctdb-recoverd[1236]: Current recmaster node 0 does not have CAP_RECMASTER, but we (node 1) have - force an election ctdbd[1220]: Recovery mode set to ACTIVE ctdbd[1220]: This node (1) is now the recovery master ctdb-recoverd[1236]: Election period ended ctdb-recoverd[1236]: Node:1 was in recovery mode. Start recovery process ctdb-recove...

Hi Max, On Wed, 2 Oct 2019 15:08:43 +0000, Max DiOrio <Max.DiOrio at ieeeglobalspec.com> wrote: > As soon as I made the configuration change and restarted CTDB, it crashes. > > Oct 2 11:05:14 hq-6pgluster01 systemd: Started CTDB. > Oct 2 11:05:21 hq-6pgluster01 systemd: ctdb.service: main process exited, code=exited, status=1/FAILURE > Oct 2 11:05:21 hq-6pgluster01

...ore details. Existing setups are not affected, as the default port is 53. CTDB changes ------------ * The "recovery master" role has been renamed "leader" ? Documentation and logs now refer to "leader". ? The following ctdb tool command names have changed: ??? recmaster -> leader ??? setrecmasterrole -> setleaderrole ? Command output has changed for the following commands: ??? status ??? getcapabilities ? The "[legacy] -> recmaster capability" configuration option has been ? renamed and moved to the cluster section, so this is now: ??...

...ore details. Existing setups are not affected, as the default port is 53. CTDB changes ------------ * The "recovery master" role has been renamed "leader" ? Documentation and logs now refer to "leader". ? The following ctdb tool command names have changed: ??? recmaster -> leader ??? setrecmasterrole -> setleaderrole ? Command output has changed for the following commands: ??? status ??? getcapabilities ? The "[legacy] -> recmaster capability" configuration option has been ? renamed and moved to the cluster section, so this is now: ??...

...gt; > 2019/10/04 09:51:29.174870 ctdbd[17244]: Recovery has started > 2019/10/04 09:51:29.174982 ctdbd[17244]: ../ctdb/server/ctdb_server.c:188 ctdb request 2147483554 of type 8 length 48 from node 1 to 0 > 2019/10/04 09:51:29.175021 ctdbd[17244]: Recovery lock configuration inconsistent: recmaster has NULL, this node has /run/gluster/shared_storage/.CTDB-lockfile, shutting down > 2019/10/04 09:51:29.175045 ctdbd[17244]: Shutdown sequence commencing. > 2019/10/04 09:51:29.175056 ctdbd[17244]: Set runstate to SHUTDOWN (6) Yep. CTDB refuses to work if the recovery lock is configured to...

...ore details. Existing setups are not affected, as the default port is 53. CTDB changes ------------ * The "recovery master" role has been renamed "leader" ? Documentation and logs now refer to "leader". ? The following ctdb tool command names have changed: ??? recmaster -> leader ??? setrecmasterrole -> setleaderrole ? Command output has changed for the following commands: ??? status ??? getcapabilities ? The "[legacy] -> recmaster capability" configuration option has been ? renamed and moved to the cluster section, so this is now: ??...

...ore details. Existing setups are not affected, as the default port is 53. CTDB changes ------------ * The "recovery master" role has been renamed "leader" ? Documentation and logs now refer to "leader". ? The following ctdb tool command names have changed: ??? recmaster -> leader ??? setrecmasterrole -> setleaderrole ? Command output has changed for the following commands: ??? status ??? getcapabilities ? The "[legacy] -> recmaster capability" configuration option has been ? renamed and moved to the cluster section, so this is now: ??...

...29 11:12:45.452636 [3932342]: pnn 1 Invalid reqid 220668 in ctdb_reply_control 2014/10/29 11:12:48.462334 [recoverd:6488266]: server/ctdb_recoverd.c:3990 Remote node:0 has different flags for node 1. It has 0x02 vs our 0x00 2014/10/29 11:12:48.462448 [recoverd:6488266]: Use flags 0x00 from local recmaster node for cluster update of node 1 flags 2014/10/29 11:12:48.483362 [3932342]: Freeze priority 1 2014/10/29 11:12:58.574548 [3932342]: /usr/smb_cluster/etc/ctdb/debug_locks.sh[23]: flock: not found 2014/10/29 11:13:08.569593 [3932342]: /usr/smb_cluster/etc/ctdb/debug_locks.sh[23]: flock: not fou...

...ore details. Existing setups are not affected, as the default port is 53. CTDB changes ------------ * The "recovery master" role has been renamed "leader" ? Documentation and logs now refer to "leader". ? The following ctdb tool command names have changed: ??? recmaster -> leader ??? setrecmasterrole -> setleaderrole ? Command output has changed for the following commands: ??? status ??? getcapabilities ? The "[legacy] -> recmaster capability" configuration option has been ? renamed and moved to the cluster section, so this is now: ??...

...ore details. Existing setups are not affected, as the default port is 53. CTDB changes ------------ * The "recovery master" role has been renamed "leader" ? Documentation and logs now refer to "leader". ? The following ctdb tool command names have changed: ??? recmaster -> leader ??? setrecmasterrole -> setleaderrole ? Command output has changed for the following commands: ??? status ??? getcapabilities ? The "[legacy] -> recmaster capability" configuration option has been ? renamed and moved to the cluster section, so this is now: ??...

...ore details. Existing setups are not affected, as the default port is 53. CTDB changes ------------ * The "recovery master" role has been renamed "leader" ? Documentation and logs now refer to "leader". ? The following ctdb tool command names have changed: ??? recmaster -> leader ??? setrecmasterrole -> setleaderrole ? Command output has changed for the following commands: ??? status ??? getcapabilities ? The "[legacy] -> recmaster capability" configuration option has been ? renamed and moved to the cluster section, so this is now: ??...

...ore details. Existing setups are not affected, as the default port is 53. CTDB changes ------------ * The "recovery master" role has been renamed "leader" ? Documentation and logs now refer to "leader". ? The following ctdb tool command names have changed: ??? recmaster -> leader ??? setrecmasterrole -> setleaderrole ? Command output has changed for the following commands: ??? status ??? getcapabilities ? The "[legacy] -> recmaster capability" configuration option has been ? renamed and moved to the cluster section, so this is now: ??...

...the actual error: 2019/10/04 09:51:29.174870 ctdbd[17244]: Recovery has started 2019/10/04 09:51:29.174982 ctdbd[17244]: ../ctdb/server/ctdb_server.c:188 ctdb request 2147483554 of type 8 length 48 from node 1 to 0 2019/10/04 09:51:29.175021 ctdbd[17244]: Recovery lock configuration inconsistent: recmaster has NULL, this node has /run/gluster/shared_storage/.CTDB-lockfile, shutting down 2019/10/04 09:51:29.175045 ctdbd[17244]: Shutdown sequence commencing. 2019/10/04 09:51:29.175056 ctdbd[17244]: Set runstate to SHUTDOWN (6) I'm attaching the full log from this startup. The other thing that b...