ctdb listvars

[ronnie sahlberg]

Hi,

These should all be described in the master branch of ctdb.
Older branches unfortunately are a bit behind and probably missing
some/most of these in the description.


This is from the master branch:




PUBLIC TUNABLES

These are the public tuneables that can be used to control how ctdb behaves.
MaxRedirectCount

Default: 3

If we are not the DMASTER and need to fetch a record across the
network we first send the request to the LMASTER after which the
record is passed onto the current DMASTER. If the DMASTER changes
before the request has reached that node, the request will be passed
onto the "next" DMASTER. For very hot records that migrate rapidly
across the cluster this can cause a request to "chase" the record for
many hops before it catches up with the record. this is how many hops
we allow trying to chase the DMASTER before we switch back to the
LMASTER again to ask for new directions.

When chasing a record, this is how many hops we will chase the record
for before going back to the LMASTER to ask for new guidance.
SeqnumInterval

Default: 1000

Some databases have seqnum tracking enabled, so that samba will be
able to detect asynchronously when there has been updates to the
database. Everytime a database is updated its sequence number is
increased.

This tunable is used to specify in 'ms' how frequently ctdb will send
out updates to remote nodes to inform them that the sequence number is
increased.
ControlTimeout

Default: 60

This is the default setting for timeout for when sending a control
message to either the local or a remote ctdb daemon.
TraverseTimeout

Default: 20

This setting controls how long we allow a traverse process to run.
After this timeout triggers, the main ctdb daemon will abort the
traverse if it has not yet finished.
KeepaliveInterval

Default: 5

How often in seconds should the nodes send keepalives to eachother.
KeepaliveLimit

Default: 5

After how many keepalive intervals without any traffic should a node
wait until marking the peer as DISCONNECTED.

If a node has hung, it can thus take
KeepaliveInterval*(KeepaliveLimit+1) seconds before we determine that
the node is DISCONNECTED and that we require a recovery. This
limitshould not be set too high since we want a hung node to be
detectec, and expunged from the cluster well before common CIFS
timeouts (45-90 seconds) kick in.
RecoverTimeout

Default: 20

This is the default setting for timeouts for controls when sent from
the recovery daemon. We allow longer control timeouts from the
recovery daemon than from normal use since the recovery dameon often
use controls that can take a lot longer than normal controls.
RecoverInterval

Default: 1

How frequently in seconds should the recovery daemon perform the
consistency checks that determine if we need to perform a recovery or
not.
ElectionTimeout

Default: 3

When electing a new recovery master, this is how many seconds we allow
the election to take before we either deem the election finished or we
fail the election and start a new one.
TakeoverTimeout

Default: 9

This is how many seconds we allow controls to take for IP failover events.
MonitorInterval

Default: 15

How often should ctdb run the event scripts to check for a nodes health.
TickleUpdateInterval

Default: 20

How often will ctdb record and store the "tickle" information used to
kickstart stalled tcp connections after a recovery.
EventScriptTimeout

Default: 20

How long should ctdb let an event script run before aborting it and
marking the node unhealthy.
EventScriptTimeoutCount

Default: 1

How many events in a row needs to timeout before we flag the node
UNHEALTHY. This setting is useful if your scripts can not be written
so that they do not hang for benign reasons.
EventScriptUnhealthyOnTimeout

Default: 0

This setting can be be used to make ctdb never become UNHEALTHY if
your eventscripts keep hanging/timing out.
RecoveryGracePeriod

Default: 120

During recoveries, if a node has not caused recovery failures during
the last grace period, any records of transgressions that the node has
caused recovery failures will be forgiven. This resets the ban-counter
back to zero for that node.
RecoveryBanPeriod

Default: 300

If a node becomes banned causing repetitive recovery failures. The
node will eventually become banned from the cluster. This controls how
long the culprit node will be banned from the cluster before it is
allowed to try to join the cluster again. Don't set to small. A node
gets banned for a reason and it is usually due to real problems with
the node.
DatabaseHashSize

Default: 100001

Size of the hash chains for the local store of the tdbs that ctdb manages.
DatabaseMaxDead

Default: 5

How many dead records per hashchain in the TDB database do we allow
before the freelist needs to be processed.
RerecoveryTimeout

Default: 10

Once a recovery has completed, no additional recoveries are permitted
until this timeout has expired.
EnableBans

Default: 1

When set to 0, this disables BANNING completely in the cluster and
thus nodes can not get banned, even it they break. Don't set to 0
unless you know what you are doing.
DeterministicIPs

Default: 0

When enabled, this tunable makes ctdb try to keep public IP addresses
locked to specific nodes as far as possible. This makes it easier for
debugging since you can know that as long as all nodes are healthy
public IP X will always be hosted by node Y.

The cost of using deterministic IP address assignment is that it
disables part of the logic where ctdb tries to reduce the number of
public IP assignment changes in the cluster. This tunable may increase
the number of IP failover/failbacks that are performed on the cluster
by a small margin.
LCP2PublicIPs

Default: 1

When enabled this switches ctdb to use the LCP2 ip allocation algorithm.
ReclockPingPeriod

Default: x

Obsolete
NoIPFailback

Default: 0

When set to 1, ctdb will not perform failback of IP addresses when a
node becomes healthy. Ctdb WILL perform failover of public IP
addresses when a node becomes UNHEALTHY, but when the node becomes
HEALTHY again, ctdb will not fail the addresses back.

Use with caution! Normally when a node becomes available to the
cluster ctdb will try to reassign public IP addresses onto the new
node as a way to distribute the workload evenly across the
clusternode. Ctdb tries to make sure that all running nodes have
approximately the same number of public addresses it hosts.

When you enable this tunable, CTDB will no longer attempt to rebalance
the cluster by failing IP addresses back to the new nodes. An
unbalanced cluster will therefore remain unbalanced until there is
manual intervention from the administrator. When this parameter is
set, you can manually fail public IP addresses over to the new node(s)
using the 'ctdb moveip' command.
DisableIPFailover

Default: 0

When enabled, ctdb weill not perform failover or failback. Even if a
node fails while holding public IPs, ctdb will not recover the IPs or
assign them to another node.

When you enable this tunable, CTDB will no longer attempt to recover
the cluster by failing IP addresses over to other nodes. This leads to
a service outage until the administrator has manually performed
failover to replacement nodes using the 'ctdb moveip' command.
VerboseMemoryNames

Default: 0

This feature consumes additional memory. when used the talloc library
will create more verbose names for all talloc allocated objects.
RecdPingTimeout

Default: 60

If the main dameon has not heard a "ping" from the recovery dameon for
this many seconds, the main dameon will log a message that the
recovery daemon is potentially hung.
RecdFailCount

Default: 10

If the recovery daemon has failed to ping the main dameon for this
many consecutive intervals, the main daemon will consider the recovery
daemon as hung and will try to restart it to recover.
LogLatencyMs

Default: 0

When set to non-zero, this will make the main daemon log any operation
that took longer than this value, in 'ms', to complete. These include
"how long time a lockwait child process needed", "how long time to
write to a persistent database" but also "how long did it take to get
a response to a CALL from a remote node".
RecLockLatencyMs

Default: 1000

When using a reclock file for split brain prevention, if set to
non-zero this tunable will make the recovery dameon log a message if
the fcntl() call to lock/testlock the recovery file takes longer than
this number of ms.
RecoveryDropAllIPs

Default: 120

If we have been stuck in recovery, or stopped, or banned, mode for
this many seconds we will force drop all held public addresses.
verifyRecoveryLock

Default: 1

Should we take a fcntl() lock on the reclock file to verify that we
are the sole recovery master node on the cluster or not.
DeferredAttachTO

Default: 120

When databases are frozen we do not allow clients to attach to the
databases. Instead of returning an error immediately to the
application the attach request from the client is deferred until the
database becomes available again at which stage we respond to the
client.

This timeout controls how long we will defer the request from the
client before timing it out and returning an error to the client.
StatHistoryInterval

Default: 1

Granularity of the statistics collected in the statistics history.
AllowClientDBAttach

Default: 1

When set to 0, clients are not allowed to attach to any databases.
This can be used to temporarily block any new processes from attaching
to and accessing the databases.
RecoverPDBBySeqNum

Default: 0

When set to non-zero, this will change how the recovery process for
persistent databases ar performed. By default, when performing a
database recovery, for normal as for persistent databases, recovery is
record-by-record and recovery process simply collects the most recent
version of every individual record.

When set to non-zero, persistent databases will instead be recovered
as a whole db and not by individual records. The node that contains
the highest value stored in the record "__db_sequence_number__" is
selected and the copy of that nodes database is used as the recovered
database.


regards
ronnie sahlberg

On Fri, Feb 3, 2012 at 1:14 AM, Martin Gombac <martin at isg.si> wrote:
> Hi all.
>
> Is there any documentation or description on what do the values actually
> set/regulate? I didn't find anything via google. I can guess by name, but
> anyway:
>
> MaxRedirectCount    = 3
> SeqnumInterval      = 1000
> ControlTimeout      = 60
> TraverseTimeout     = 20
> KeepaliveInterval   = 5
> KeepaliveLimit      = 5
> RecoverTimeout      = 20
> RecoverInterval     = 1
> ElectionTimeout     = 3
> TakeoverTimeout     = 5
> MonitorInterval     = 15
> TickleUpdateInterval = 20
> EventScriptTimeout  = 30
> EventScriptTimeoutCount = 44
> EventScriptUnhealthyOnTimeout = 0
> RecoveryGracePeriod = 120
> RecoveryBanPeriod   = 300
> DatabaseHashSize    = 10000
> DatabaseMaxDead     = 5
> RerecoveryTimeout   = 10
> EnableBans          = 1
> DeterministicIPs    = 1
> ReclockPingPeriod   = 60
> NoIPFailback        = 0
> VerboseMemoryNames  = 0
> RecdPingTimeout     = 60
> RecdFailCount       = 10
> LogLatencyMs        = 0
> RecLockLatencyMs    = 1000
> RecoveryDropAllIPs  = 60
> VerifyRecoveryLock  = 1
> VacuumDefaultInterval = 10
> VacuumMaxRunTime    = 30
> RepackLimit         = 10000
> VacuumLimit         = 5000
> VacuumMinInterval   = 10
> VacuumMaxInterval   = 10
> VacuumFastPathCount = 60
> MaxQueueDropMsg     = 1000000
> UseStatusEvents     = 0
> AllowUnhealthyDBRead = 0
>
> Regards,
> --
> Martin Gombač
> ISG d.o.o.
> 00386 (0)1 620 75 03