--- /dev/null
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb-statistics</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdb-statistics.7"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb-statistics — CTDB statistics output</p></div><div class="refsect1"><a name="idm139938143499680"></a><h2>OVERALL STATISTICS</h2><p>
+ CTDB maintains information about various messages communicated
+ and some of the important operations per node. See the
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span> commands
+ <span class="command"><strong>statistics</strong></span> and <span class="command"><strong>statisticsreset</strong></span>
+ for displaying statistics.
+ </p><div class="refsect2"><a name="idm139938144880704"></a><h3>Example: ctdb statistics</h3><pre class="screen">
+CTDB version 1
+Current time of statistics : Fri Sep 12 13:32:32 2014
+Statistics collected since : (000 01:49:20) Fri Sep 12 11:43:12 2014
+ num_clients 6
+ frozen 0
+ recovering 0
+ num_recoveries 2
+ client_packets_sent 281293
+ client_packets_recv 296317
+ node_packets_sent 452387
+ node_packets_recv 182394
+ keepalive_packets_sent 3927
+ keepalive_packets_recv 3928
+ node
+ req_call 48605
+ reply_call 1
+ req_dmaster 23404
+ reply_dmaster 24917
+ reply_error 0
+ req_message 958
+ req_control 197513
+ reply_control 153705
+ client
+ req_call 130866
+ req_message 770
+ req_control 168921
+ timeouts
+ call 0
+ control 0
+ traverse 0
+ locks
+ num_calls 220
+ num_current 0
+ num_pending 0
+ num_failed 0
+ total_calls 130866
+ pending_calls 0
+ childwrite_calls 1
+ pending_childwrite_calls 0
+ memory_used 334490
+ max_hop_count 18
+ total_ro_delegations 2
+ total_ro_revokes 2
+ hop_count_buckets: 42816 5464 26 1 0 0 0 0 0 0 0 0 0 0 0 0
+ lock_buckets: 9 165 14 15 7 2 2 0 0 0 0 0 0 0 0 0
+ locks_latency MIN/AVG/MAX 0.000685/0.160302/6.369342 sec out of 214
+ reclock_ctdbd MIN/AVG/MAX 0.004940/0.004969/0.004998 sec out of 2
+ reclock_recd MIN/AVG/MAX 0.000000/0.000000/0.000000 sec out of 0
+ call_latency MIN/AVG/MAX 0.000006/0.000719/4.562991 sec out of 126626
+ childwrite_latency MIN/AVG/MAX 0.014527/0.014527/0.014527 sec out of 1
+ </pre></div><div class="refsect2"><a name="idm139938144074928"></a><h3>CTDB version</h3><p>
+ Version of the ctdb protocol used by the node.
+ </p></div><div class="refsect2"><a name="idm139938141891920"></a><h3>Current time of statistics</h3><p>
+ Time when the statistics are generated.
+ </p><p>
+ This is useful when collecting statistics output periodically
+ for post-processing.
+ </p></div><div class="refsect2"><a name="idm139938144102064"></a><h3>Statistics collected since</h3><p>
+ Time when ctdb was started or the last time statistics was reset.
+ The output shows the duration and the timestamp.
+ </p></div><div class="refsect2"><a name="idm139938141729504"></a><h3>num_clients</h3><p>
+ Number of processes currently connected to CTDB's unix socket.
+ This includes recovery daemon, ctdb tool and samba processes
+ (smbd, winbindd).
+ </p></div><div class="refsect2"><a name="idm139938142880032"></a><h3>frozen</h3><p>
+ 1 if the the databases are currently frozen, 0 otherwise.
+ </p></div><div class="refsect2"><a name="idm139938142575152"></a><h3>recovering</h3><p>
+ 1 if recovery is active, 0 otherwise.
+ </p></div><div class="refsect2"><a name="idm139938141022688"></a><h3>num_recoveries</h3><p>
+ Number of recoveries since the start of ctdb or since the last
+ statistics reset.
+ </p></div><div class="refsect2"><a name="idm139938142040320"></a><h3>client_packets_sent</h3><p>
+ Number of packets sent to client processes via unix domain socket.
+ </p></div><div class="refsect2"><a name="idm139938141224144"></a><h3>client_packets_recv</h3><p>
+ Number of packets received from client processes via unix domain socket.
+ </p></div><div class="refsect2"><a name="idm139938144042032"></a><h3>node_packets_sent</h3><p>
+ Number of packets sent to the other nodes in the cluster via TCP.
+ </p></div><div class="refsect2"><a name="idm139938141988928"></a><h3>node_packets_recv</h3><p>
+ Number of packets received from the other nodes in the cluster via TCP.
+ </p></div><div class="refsect2"><a name="idm139938143080240"></a><h3>keepalive_packets_sent</h3><p>
+ Number of keepalive messages sent to other nodes.
+ </p><p>
+ CTDB periodically sends keepalive messages to other nodes.
+ See <em class="citetitle">KeepaliveInterval</em> tunable in
+ <span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span> for more details.
+ </p></div><div class="refsect2"><a name="idm139938142460160"></a><h3>keepalive_packets_recv</h3><p>
+ Number of keepalive messages received from other nodes.
+ </p></div><div class="refsect2"><a name="idm139938142634128"></a><h3>node</h3><p>
+ This section lists various types of messages processed which
+ originated from other nodes via TCP.
+ </p><div class="refsect3"><a name="idm139938142037088"></a><h4>req_call</h4><p>
+ Number of REQ_CALL messages from the other nodes.
+ </p></div><div class="refsect3"><a name="idm139938144753248"></a><h4>reply_call</h4><p>
+ Number of REPLY_CALL messages from the other nodes.
+ </p></div><div class="refsect3"><a name="idm139938142887920"></a><h4>req_dmaster</h4><p>
+ Number of REQ_DMASTER messages from the other nodes.
+ </p></div><div class="refsect3"><a name="idm139938145081184"></a><h4>reply_dmaster</h4><p>
+ Number of REPLY_DMASTER messages from the other nodes.
+ </p></div><div class="refsect3"><a name="idm139938142797792"></a><h4>reply_error</h4><p>
+ Number of REPLY_ERROR messages from the other nodes.
+ </p></div><div class="refsect3"><a name="idm139938141620704"></a><h4>req_message</h4><p>
+ Number of REQ_MESSAGE messages from the other nodes.
+ </p></div><div class="refsect3"><a name="idm139938144156784"></a><h4>req_control</h4><p>
+ Number of REQ_CONTROL messages from the other nodes.
+ </p></div><div class="refsect3"><a name="idm139938140997424"></a><h4>reply_control</h4><p>
+ Number of REPLY_CONTROL messages from the other nodes.
+ </p></div></div><div class="refsect2"><a name="idm139938143466848"></a><h3>client</h3><p>
+ This section lists various types of messages processed which
+ originated from clients via unix domain socket.
+ </p><div class="refsect3"><a name="idm139938141519088"></a><h4>req_call</h4><p>
+ Number of REQ_CALL messages from the clients.
+ </p></div><div class="refsect3"><a name="idm139938142138032"></a><h4>req_message</h4><p>
+ Number of REQ_MESSAGE messages from the clients.
+ </p></div><div class="refsect3"><a name="idm139938143399744"></a><h4>req_control</h4><p>
+ Number of REQ_CONTROL messages from the clients.
+ </p></div></div><div class="refsect2"><a name="idm139938142804592"></a><h3>timeouts</h3><p>
+ This section lists timeouts occurred when sending various messages.
+ </p><div class="refsect3"><a name="idm139938143685040"></a><h4>call</h4><p>
+ Number of timeouts for REQ_CALL messages.
+ </p></div><div class="refsect3"><a name="idm139938141590784"></a><h4>control</h4><p>
+ Number of timeouts for REQ_CONTROL messages.
+ </p></div><div class="refsect3"><a name="idm139938142988736"></a><h4>traverse</h4><p>
+ Number of timeouts for database traverse operations.
+ </p></div></div><div class="refsect2"><a name="idm139938140879008"></a><h3>locks</h3><p>
+ This section lists locking statistics.
+ </p><div class="refsect3"><a name="idm139938142459456"></a><h4>num_calls</h4><p>
+ Number of completed lock calls. This includes database locks
+ and record locks.
+ </p></div><div class="refsect3"><a name="idm139938141728352"></a><h4>num_current</h4><p>
+ Number of scheduled lock calls. This includes database locks
+ and record locks.
+ </p></div><div class="refsect3"><a name="idm139938141930096"></a><h4>num_pending</h4><p>
+ Number of queued lock calls. This includes database locks and
+ record locks.
+ </p></div><div class="refsect3"><a name="idm139938142666848"></a><h4>num_failed</h4><p>
+ Number of failed lock calls. This includes database locks and
+ record locks.
+ </p></div></div><div class="refsect2"><a name="idm139938143981744"></a><h3>total_calls</h3><p>
+ Number of req_call messages processed from clients. This number
+ should be same as client --> req_call.
+ </p></div><div class="refsect2"><a name="idm139938141503504"></a><h3>pending_calls</h3><p>
+ Number of req_call messages which are currenly being processed.
+ This number indicates the number of record migrations in flight.
+ </p></div><div class="refsect2"><a name="idm139938141551456"></a><h3>childwrite_calls</h3><p>
+ Number of record update calls. Record update calls are used to
+ update a record under a transaction.
+ </p></div><div class="refsect2"><a name="idm139938142822896"></a><h3>pending_childwrite_calls</h3><p>
+ Number of record update calls currently active.
+ </p></div><div class="refsect2"><a name="idm139938144013152"></a><h3>memory_used</h3><p>
+ The amount of memory in bytes currently used by CTDB using
+ talloc. This includes all the memory used for CTDB's internal
+ data structures. This does not include the memory mapped TDB
+ databases.
+ </p></div><div class="refsect2"><a name="idm139938142962048"></a><h3>max_hop_count</h3><p>
+ The maximum number of hops required for a record migration request
+ to obtain the record. High numbers indicate record contention.
+ </p></div><div class="refsect2"><a name="idm139938143508848"></a><h3>total_ro_delegations</h3><p>
+ Number of readonly delegations created.
+ </p></div><div class="refsect2"><a name="idm139938142708592"></a><h3>total_ro_revokes</h3><p>
+ Number of readonly delegations that were revoked. The difference
+ between total_ro_revokes and total_ro_delegations gives the
+ number of currently active readonly delegations.
+ </p></div><div class="refsect2"><a name="idm139938141590240"></a><h3>hop_count_buckets</h3><p>
+ Distribution of migration requests based on hop counts values.
+ Buckets are 1, < 4, < 8, < 16, < 32, < 64, <
+ 128, < 256, < 512, ≥ 512.
+ </p></div><div class="refsect2"><a name="idm139938143414000"></a><h3>lock_buckets</h3><p>
+ Distribution of record lock requests based on time required to
+ obtain locks. Buckets are < 1ms, < 10ms, < 100ms,
+ < 1s, < 2s, < 4s, < 8s, < 16s, < 32s, <
+ 64s, ≥ 64s.
+ </p></div><div class="refsect2"><a name="idm139938141409200"></a><h3>locks_latency</h3><p>
+ The minimum, the average and the maximum time (in seconds)
+ required to obtain record locks.
+ </p></div><div class="refsect2"><a name="idm139938142745920"></a><h3>reclock_ctdbd</h3><p>
+ The minimum, the average and the maximum time (in seconds)
+ required to check if recovery lock is still held by recovery
+ daemon when recovery mode is changed. This check is done in ctdb daemon.
+ </p></div><div class="refsect2"><a name="idm139938143025616"></a><h3>reclock_recd</h3><p>
+ The minimum, the average and the maximum time (in seconds)
+ required to check if recovery lock is still held by recovery
+ daemon during recovery. This check is done in recovery daemon.
+ </p></div><div class="refsect2"><a name="idm139938142519424"></a><h3>call_latency</h3><p>
+ The minimum, the average and the maximum time (in seconds) required
+ to process a REQ_CALL message from client. This includes the time
+ required to migrate a record from remote node, if the record is
+ not available on the local node.
+ </p></div><div class="refsect2"><a name="idm139938141604624"></a><h3>childwrite_latency</h3><p>Default: 0</p><p>
+ The minimum, the average and the maximum time (in seconds)
+ required to update records under a transaction.
+ </p></div></div><div class="refsect1"><a name="idm139938143655776"></a><h2>DATABASE STATISTICS</h2><p>
+ CTDB maintains per database statistics about important operations.
+ See the <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span> command
+ <span class="command"><strong>dbstatistics</strong></span> for displaying database statistics.
+ </p><div class="refsect2"><a name="idm139938143465056"></a><h3>Example: ctdb dbstatistics notify_index.tdb</h3><pre class="screen">
+DB Statistics: notify_index.tdb
+ ro_delegations 0
+ ro_revokes 0
+ locks
+ total 131
+ failed 0
+ current 0
+ pending 0
+ hop_count_buckets: 9890 5454 26 1 0 0 0 0 0 0 0 0 0 0 0 0
+ lock_buckets: 4 117 10 0 0 0 0 0 0 0 0 0 0 0 0 0
+ locks_latency MIN/AVG/MAX 0.000683/0.004198/0.014730 sec out of 131
+ Num Hot Keys: 3
+ Count:7 Key:2f636c75737465726673
+ Count:18 Key:2f636c757374657266732f64617461
+ Count:7 Key:2f636c757374657266732f646174612f636c69656e7473
+ </pre></div><div class="refsect2"><a name="idm139938142129200"></a><h3>DB Statistics</h3><p>
+ Name of the database.
+ </p></div><div class="refsect2"><a name="idm139938142084448"></a><h3>ro_delegations</h3><p>
+ Number of readonly delegations created in the database.
+ </p></div><div class="refsect2"><a name="idm139938142116336"></a><h3>ro_revokes</h3><p>
+ Number of readonly delegations revoked. The difference in
+ ro_delegations and ro_revokes indicates the currently active
+ readonly delegations.
+ </p></div><div class="refsect2"><a name="idm139938144070224"></a><h3>locks</h3><p>
+ This section lists locking statistics.
+ </p><div class="refsect3"><a name="idm139938143763344"></a><h4>total</h4><p>
+ Number of completed lock calls. This includes database locks
+ and record locks.
+ </p></div><div class="refsect3"><a name="idm139938143591696"></a><h4>failed</h4><p>
+ Number of failed lock calls. This includes database locks and
+ record locks.
+ </p></div><div class="refsect3"><a name="idm139938141660528"></a><h4>current</h4><p>
+ Number of scheduled lock calls. This includes database locks
+ and record locks.
+ </p></div><div class="refsect3"><a name="idm139938141103264"></a><h4>pending</h4><p>
+ Number of queued lock calls. This includes database locks and
+ record locks.
+ </p></div></div><div class="refsect2"><a name="idm139938141836608"></a><h3>hop_count_buckets</h3><p>
+ Distribution of migration requests based on hop counts values.
+ Buckets are 1, < 4, < 8, < 16, < 32, < 64, <
+ 128, < 256, < 512, ≥ 512.
+ </p></div><div class="refsect2"><a name="idm139938144268496"></a><h3>lock_buckets</h3><p>
+ Distribution of record lock requests based on time required to
+ obtain locks. Buckets are < 1ms, < 10ms, < 100ms,
+ < 1s, < 2s, < 4s, < 8s, < 16s, < 32s, <
+ 64s, ≥ 64s.
+ </p></div><div class="refsect2"><a name="idm139938141023712"></a><h3>locks_latency</h3><p>
+ The minimum, the average and the maximum time (in seconds)
+ required to obtain record locks.
+ </p></div><div class="refsect2"><a name="idm139938142295568"></a><h3>Num Hot Keys</h3><p>
+ Number of contended records determined by hop count. CTDB keeps
+ track of top 10 hot records and the output shows hex encoded
+ keys for the hot records.
+ </p></div></div><div class="refsect1"><a name="idm139938143557184"></a><h2>SEE ALSO</h2><p>
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span>,
+
+ <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
+ </p></div></div></body></html>
--- /dev/null
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb-tunables</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdb-tunables.7"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb-tunables — CTDB tunable configuration variables</p></div><div class="refsect1"><a name="idm140250114160032"></a><h2>DESCRIPTION</h2><p>
+ CTDB's behaviour can be configured by setting run-time tunable
+ variables. This lists and describes all tunables. See the
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>
+ <span class="command"><strong>listvars</strong></span>, <span class="command"><strong>setvar</strong></span> and
+ <span class="command"><strong>getvar</strong></span> commands for more details.
+ </p><div class="refsect2"><a name="idm140250113977776"></a><h3>MaxRedirectCount</h3><p>Default: 3</p><p>
+ 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.
+ </p><p>
+ 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.
+ </p></div><div class="refsect2"><a name="idm140250112552272"></a><h3>SeqnumInterval</h3><p>Default: 1000</p><p>
+ 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.
+ </p><p>
+ 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.
+ </p></div><div class="refsect2"><a name="idm140250112801136"></a><h3>ControlTimeout</h3><p>Default: 60</p><p>
+ This is the default
+ setting for timeout for when sending a control message to either the
+ local or a remote ctdb daemon.
+ </p></div><div class="refsect2"><a name="idm140250112625904"></a><h3>TraverseTimeout</h3><p>Default: 20</p><p>
+ 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.
+ </p></div><div class="refsect2"><a name="idm140250112994768"></a><h3>KeepaliveInterval</h3><p>Default: 5</p><p>
+ How often in seconds should the nodes send keepalives to eachother.
+ </p></div><div class="refsect2"><a name="idm140250113999488"></a><h3>KeepaliveLimit</h3><p>Default: 5</p><p>
+ After how many keepalive intervals without any traffic should a node
+ wait until marking the peer as DISCONNECTED.
+ </p><p>
+ 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.
+ </p></div><div class="refsect2"><a name="idm140250113832160"></a><h3>RecoverTimeout</h3><p>Default: 20</p><p>
+ 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.
+ </p></div><div class="refsect2"><a name="idm140250113438992"></a><h3>RecoverInterval</h3><p>Default: 1</p><p>
+ How frequently in seconds should the recovery daemon perform the
+ consistency checks that determine if we need to perform a recovery or not.
+ </p></div><div class="refsect2"><a name="idm140250113236784"></a><h3>ElectionTimeout</h3><p>Default: 3</p><p>
+ 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.
+ </p></div><div class="refsect2"><a name="idm140250113440720"></a><h3>TakeoverTimeout</h3><p>Default: 9</p><p>
+ This is how many seconds we allow controls to take for IP failover events.
+ </p></div><div class="refsect2"><a name="idm140250111963200"></a><h3>MonitorInterval</h3><p>Default: 15</p><p>
+ How often should ctdb run the event scripts to check for a nodes health.
+ </p></div><div class="refsect2"><a name="idm140250112163600"></a><h3>TickleUpdateInterval</h3><p>Default: 20</p><p>
+ How often will ctdb record and store the "tickle" information used to
+ kickstart stalled tcp connections after a recovery.
+ </p></div><div class="refsect2"><a name="idm140250115209376"></a><h3>EventScriptTimeout</h3><p>Default: 30</p><p>
+ Maximum time in seconds to allow an event to run before timing
+ out. This is the total time for all enabled scripts that are
+ run for an event, not just a single event script.
+ </p><p>
+ Note that timeouts are ignored for some events ("takeip",
+ "releaseip", "startrecovery", "recovered") and converted to
+ success. The logic here is that the callers of these events
+ implement their own additional timeout.
+ </p></div><div class="refsect2"><a name="idm140250113300784"></a><h3>MonitorTimeoutCount</h3><p>Default: 20</p><p>
+ How many monitor events in a row need to timeout before a node
+ is flagged as UNHEALTHY. This setting is useful if scripts
+ can not be written so that they do not hang for benign
+ reasons.
+ </p></div><div class="refsect2"><a name="idm140250113467376"></a><h3>RecoveryGracePeriod</h3><p>Default: 120</p><p>
+ 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.
+ </p></div><div class="refsect2"><a name="idm140250112493824"></a><h3>RecoveryBanPeriod</h3><p>Default: 300</p><p>
+ 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.
+ </p></div><div class="refsect2"><a name="idm140250111569040"></a><h3>DatabaseHashSize</h3><p>Default: 100001</p><p>
+ Size of the hash chains for the local store of the tdbs that ctdb manages.
+ </p></div><div class="refsect2"><a name="idm140250112323888"></a><h3>DatabaseMaxDead</h3><p>Default: 5</p><p>
+ How many dead records per hashchain in the TDB database do we allow before
+ the freelist needs to be processed.
+ </p></div><div class="refsect2"><a name="idm140250114315872"></a><h3>RerecoveryTimeout</h3><p>Default: 10</p><p>
+ Once a recovery has completed, no additional recoveries are permitted
+ until this timeout has expired.
+ </p></div><div class="refsect2"><a name="idm140250113887312"></a><h3>EnableBans</h3><p>Default: 1</p><p>
+ 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. You should set this to the same value on
+ all nodes to avoid unexpected behaviour.
+ </p></div><div class="refsect2"><a name="idm140250111531200"></a><h3>DeterministicIPs</h3><p>Default: 0</p><p>
+ 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.
+ </p><p>
+ 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.
+ </p></div><div class="refsect2"><a name="idm140250112209184"></a><h3>LCP2PublicIPs</h3><p>Default: 1</p><p>
+ When enabled this switches ctdb to use the LCP2 ip allocation
+ algorithm.
+ </p></div><div class="refsect2"><a name="idm140250114324944"></a><h3>ReclockPingPeriod</h3><p>Default: x</p><p>
+ Obsolete
+ </p></div><div class="refsect2"><a name="idm140250113649088"></a><h3>NoIPFailback</h3><p>Default: 0</p><p>
+ 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.
+ </p><p>
+ 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.
+ </p><p>
+ 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.
+ </p></div><div class="refsect2"><a name="idm140250112149232"></a><h3>DisableIPFailover</h3><p>Default: 0</p><p>
+ When enabled, ctdb will 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.
+ </p><p>
+ 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.
+ </p></div><div class="refsect2"><a name="idm140250112776944"></a><h3>NoIPTakeover</h3><p>Default: 0</p><p>
+ When set to 1, ctdb will not allow IP addresses to be failed over
+ onto this node. Any IP addresses that the node currently hosts
+ will remain on the node but no new IP addresses can be failed over
+ to the node.
+ </p></div><div class="refsect2"><a name="idm140250114993088"></a><h3>NoIPHostOnAllDisabled</h3><p>Default: 0</p><p>
+ If no nodes are healthy then by default ctdb will happily host
+ public IPs on disabled (unhealthy or administratively disabled)
+ nodes. This can cause problems, for example if the underlying
+ cluster filesystem is not mounted. When set to 1 on a node and
+ that node is disabled it, any IPs hosted by this node will be
+ released and the node will not takeover any IPs until it is no
+ longer disabled.
+ </p></div><div class="refsect2"><a name="idm140250113809520"></a><h3>DBRecordCountWarn</h3><p>Default: 100000</p><p>
+ When set to non-zero, ctdb will log a warning when we try to recover a
+ database with more than this many records. This will produce a warning
+ if a database grows uncontrollably with orphaned records.
+ </p></div><div class="refsect2"><a name="idm140250113368688"></a><h3>DBRecordSizeWarn</h3><p>Default: 10000000</p><p>
+ When set to non-zero, ctdb will log a warning when we try to recover a
+ database where a single record is bigger than this. This will produce
+ a warning if a database record grows uncontrollably with orphaned
+ sub-records.
+ </p></div><div class="refsect2"><a name="idm140250112645408"></a><h3>DBSizeWarn</h3><p>Default: 1000000000</p><p>
+ When set to non-zero, ctdb will log a warning when we try to recover a
+ database bigger than this. This will produce
+ a warning if a database grows uncontrollably.
+ </p></div><div class="refsect2"><a name="idm140250114616832"></a><h3>VerboseMemoryNames</h3><p>Default: 0</p><p>
+ This feature consumes additional memory. when used the talloc library
+ will create more verbose names for all talloc allocated objects.
+ </p></div><div class="refsect2"><a name="idm140250113342448"></a><h3>RecdPingTimeout</h3><p>Default: 60</p><p>
+ 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.
+ </p></div><div class="refsect2"><a name="idm140250113524352"></a><h3>RecdFailCount</h3><p>Default: 10</p><p>
+ 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.
+ </p></div><div class="refsect2"><a name="idm140250114731216"></a><h3>LogLatencyMs</h3><p>Default: 0</p><p>
+ 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".
+ </p></div><div class="refsect2"><a name="idm140250111628960"></a><h3>RecLockLatencyMs</h3><p>Default: 1000</p><p>
+ 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.
+ </p></div><div class="refsect2"><a name="idm140250112069552"></a><h3>RecoveryDropAllIPs</h3><p>Default: 120</p><p>
+ If we have been stuck in recovery, or stopped, or banned, mode for
+ this many seconds we will force drop all held public addresses.
+ </p></div><div class="refsect2"><a name="idm140250112936832"></a><h3>VacuumInterval</h3><p>Default: 10</p><p>
+ Periodic interval in seconds when vacuuming is triggered for
+ volatile databases.
+ </p></div><div class="refsect2"><a name="idm140250112117984"></a><h3>VacuumMaxRunTime</h3><p>Default: 120</p><p>
+ The maximum time in seconds for which the vacuuming process is
+ allowed to run. If vacuuming process takes longer than this
+ value, then the vacuuming process is terminated.
+ </p></div><div class="refsect2"><a name="idm140250111996192"></a><h3>RepackLimit</h3><p>Default: 10000</p><p>
+ During vacuuming, if the number of freelist records are more
+ than <code class="varname">RepackLimit</code>, then databases are
+ repacked to get rid of the freelist records to avoid
+ fragmentation.
+ </p><p>
+ Databases are repacked only if both
+ <code class="varname">RepackLimit</code> and
+ <code class="varname">VacuumLimit</code> are exceeded.
+ </p></div><div class="refsect2"><a name="idm140250114794416"></a><h3>VacuumLimit</h3><p>Default: 5000</p><p>
+ During vacuuming, if the number of deleted records are more
+ than <code class="varname">VacuumLimit</code>, then databases are
+ repacked to avoid fragmentation.
+ </p><p>
+ Databases are repacked only if both
+ <code class="varname">RepackLimit</code> and
+ <code class="varname">VacuumLimit</code> are exceeded.
+ </p></div><div class="refsect2"><a name="idm140250113734000"></a><h3>VacuumFastPathCount</h3><p>Default: 60</p><p>
+ When a record is deleted, it is marked for deletion during
+ vacuuming. Vacuuming process usually processes this list to purge
+ the records from the database. If the number of records marked
+ for deletion are more than VacuumFastPathCount, then vacuuming
+ process will scan the complete database for empty records instead
+ of using the list of records marked for deletion.
+ </p></div><div class="refsect2"><a name="idm140250114795824"></a><h3>DeferredAttachTO</h3><p>Default: 120</p><p>
+ 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.
+ </p><p>
+ This timeout controls how long we will defer the request from the client
+ before timing it out and returning an error to the client.
+ </p></div><div class="refsect2"><a name="idm140250112807120"></a><h3>HopcountMakeSticky</h3><p>Default: 50</p><p>
+ If the database is set to 'STICKY' mode, using the 'ctdb setdbsticky'
+ command, any record that is seen as very hot and migrating so fast that
+ hopcount surpasses 50 is set to become a STICKY record for StickyDuration
+ seconds. This means that after each migration the record will be kept on
+ the node and prevented from being migrated off the node.
+ </p><p>
+ This setting allows one to try to identify such records and stop them from
+ migrating across the cluster so fast. This will improve performance for
+ certain workloads, such as locking.tdb if many clients are opening/closing
+ the same file concurrently.
+ </p></div><div class="refsect2"><a name="idm140250113465456"></a><h3>StickyDuration</h3><p>Default: 600</p><p>
+ Once a record has been found to be fetch-lock hot and has been flagged to
+ become STICKY, this is for how long, in seconds, the record will be
+ flagged as a STICKY record.
+ </p></div><div class="refsect2"><a name="idm140250111515504"></a><h3>StickyPindown</h3><p>Default: 200</p><p>
+ Once a STICKY record has been migrated onto a node, it will be pinned down
+ on that node for this number of ms. Any request from other nodes to migrate
+ the record off the node will be deferred until the pindown timer expires.
+ </p></div><div class="refsect2"><a name="idm140250111919552"></a><h3>StatHistoryInterval</h3><p>Default: 1</p><p>
+ Granularity of the statistics collected in the statistics history.
+ </p></div><div class="refsect2"><a name="idm140250113801408"></a><h3>AllowClientDBAttach</h3><p>Default: 1</p><p>
+ 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.
+ </p></div><div class="refsect2"><a name="idm140250111550352"></a><h3>RecoverPDBBySeqNum</h3><p>Default: 1</p><p>
+ When set to zero, database recovery for persistent databases
+ is record-by-record and recovery process simply collects the
+ most recent version of every individual record.
+ </p><p>
+ 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.
+ </p><p>
+ By default, recovery of persistent databses is done using
+ __db_sequence_number__ record.
+ </p></div><div class="refsect2"><a name="idm140250112196048"></a><h3>FetchCollapse</h3><p>Default: 1</p><p>
+ When many clients across many nodes try to access the same record at the
+ same time this can lead to a fetch storm where the record becomes very
+ active and bounces between nodes very fast. This leads to high CPU
+ utilization of the ctdbd daemon, trying to bounce that record around
+ very fast, and poor performance.
+ </p><p>
+ This parameter is used to activate a fetch-collapse. A fetch-collapse
+ is when we track which records we have requests in flight so that we only
+ keep one request in flight from a certain node, even if multiple smbd
+ processes are attemtping to fetch the record at the same time. This
+ can improve performance and reduce CPU utilization for certain
+ workloads.
+ </p><p>
+ This timeout controls if we should collapse multiple fetch operations
+ of the same record into a single request and defer all duplicates or not.
+ </p></div><div class="refsect2"><a name="idm140250113381232"></a><h3>Samba3AvoidDeadlocks</h3><p>Default: 0</p><p>
+ Enable code that prevents deadlocks with Samba (only for Samba 3.x).
+ </p><p>
+ This should be set to 1 when using Samba version 3.x to enable special
+ code in CTDB to avoid deadlock with Samba version 3.x. This code
+ is not required for Samba version 4.x and must not be enabled for
+ Samba 4.x.
+ </p></div></div><div class="refsect1"><a name="idm140250113309648"></a><h2>SEE ALSO</h2><p>
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+
+ <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
+ </p></div></div></body></html>
--- /dev/null
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdb.1"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb — CTDB management utility</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ctdb</code> [<em class="replaceable"><code>OPTION</code></em>...] {<em class="replaceable"><code>COMMAND</code></em>} [<em class="replaceable"><code>COMMAND-ARGS</code></em>]</p></div></div><div class="refsect1"><a name="idm140001401982336"></a><h2>DESCRIPTION</h2><p>
+ ctdb is a utility to view and manage a CTDB cluster.
+ </p><p>
+ The following terms are used when referring to nodes in a
+ cluster:
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">PNN</span></dt><dd><p>
+ Physical Node Number. The physical node number is an
+ integer that describes the node in the cluster. The
+ first node has physical node number 0. in a cluster.
+ </p></dd><dt><span class="term">PNN-LIST</span></dt><dd><p>
+ This is either a single PNN, a comma-separate list of PNNs
+ or "all".
+ </p></dd></dl></div><p>
+ </p><p>
+ Commands that reference a database use the following terms:
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">DB</span></dt><dd><p>
+ This is either a database name, such as
+ <code class="filename">locking.tdb</code> or a database ID such
+ as "0x42fe72c5".
+ </p></dd><dt><span class="term">DB-LIST</span></dt><dd><p>
+ A space separated list of at least one
+ <em class="parameter"><code>DB</code></em>.
+ </p></dd></dl></div><p>
+ </p></div><div class="refsect1"><a name="idm140001402008576"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-n <em class="parameter"><code>PNN-LIST</code></em></span></dt><dd><p>
+ The nodes specified by PNN-LIST should be queried for the
+ requested information. Default is to query the daemon
+ running on the local host.
+ </p></dd><dt><span class="term">-Y</span></dt><dd><p>
+ Produce output in machine readable form for easier parsing
+ by scripts. This uses a field delimiter of ':'. Not all
+ commands support this option.
+ </p></dd><dt><span class="term">-x <em class="parameter"><code>SEPARATOR</code></em></span></dt><dd><p>
+ Use SEPARATOR to delimit fields in machine readable output.
+ This implies -Y.
+ </p></dd><dt><span class="term">-X</span></dt><dd><p>
+ Produce output in machine readable form for easier parsing
+ by scripts. This uses a field delimiter of '|'. Not all
+ commands support this option.
+ </p><p>
+ This is equivalent to "-x|" and avoids some shell quoting
+ issues.
+ </p></dd><dt><span class="term">-t <em class="parameter"><code>TIMEOUT</code></em></span></dt><dd><p>
+ Indicates that ctdb should wait up to TIMEOUT seconds for
+ a response to most commands sent to the CTDB daemon. The
+ default is 10 seconds.
+ </p></dd><dt><span class="term">-T <em class="parameter"><code>TIMELIMIT</code></em></span></dt><dd><p>
+ Indicates that TIMELIMIT is the maximum run time (in
+ seconds) for the ctdb command. When TIMELIMIT is exceeded
+ the ctdb command will terminate with an error. The default
+ is 120 seconds.
+ </p></dd><dt><span class="term">-? --help</span></dt><dd><p>
+ Print some help text to the screen.
+ </p></dd><dt><span class="term">--usage</span></dt><dd><p>
+ Print useage information to the screen.
+ </p></dd><dt><span class="term">-d --debug=<em class="parameter"><code>DEBUGLEVEL</code></em></span></dt><dd><p>
+ Change the debug level for the command. Default is NOTICE (2).
+ </p></dd><dt><span class="term">--socket=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ Specify that FILENAME is the name of the Unix domain
+ socket to use when connecting to the local CTDB
+ daemon. The default is
+ <code class="filename">/usr/local/var/run/ctdb/ctdbd.socket</code>.
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm140001397612864"></a><h2>ADMINISTRATIVE COMMANDS</h2><p>
+ These are commands used to monitor and administer a CTDB cluster.
+ </p><div class="refsect2"><a name="idm140001397611712"></a><h3>pnn</h3><p>
+ This command displays the PNN of the current node.
+ </p></div><div class="refsect2"><a name="idm140001397610560"></a><h3>xpnn</h3><p>
+ This command displays the PNN of the current node without
+ contacting the CTDB daemon. It parses the nodes file
+ directly, so can produce unexpected output if the nodes file
+ has been edited but has not been reloaded.
+ </p></div><div class="refsect2"><a name="idm140001397609136"></a><h3>status</h3><p>
+ This command shows the current status of all CTDB nodes based
+ on information from the queried node.
+ </p><p>
+ Note: If the the queried node is INACTIVE then the status
+ might not be current.
+ </p><div class="refsect3"><a name="idm140001402039168"></a><h4>Node status</h4><p>
+ This includes the number of physical nodes and the status of
+ each node. See <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for information
+ about node states.
+ </p></div><div class="refsect3"><a name="idm140001402036912"></a><h4>Generation</h4><p>
+ The generation id is a number that indicates the current generation
+ of a cluster instance. Each time a cluster goes through a
+ reconfiguration or a recovery its generation id will be changed.
+ </p><p>
+ This number does not have any particular meaning other than
+ to keep track of when a cluster has gone through a
+ recovery. It is a random number that represents the current
+ instance of a ctdb cluster and its databases. The CTDB
+ daemon uses this number internally to be able to tell when
+ commands to operate on the cluster and the databases was
+ issued in a different generation of the cluster, to ensure
+ that commands that operate on the databases will not survive
+ across a cluster database recovery. After a recovery, all
+ old outstanding commands will automatically become invalid.
+ </p><p>
+ Sometimes this number will be shown as "INVALID". This only means that
+ the ctdbd daemon has started but it has not yet merged with the cluster through a recovery.
+ All nodes start with generation "INVALID" and are not assigned a real
+ generation id until they have successfully been merged with a cluster
+ through a recovery.
+ </p></div><div class="refsect3"><a name="idm140001402033136"></a><h4>Virtual Node Number (VNN) map</h4><p>
+ Consists of the number of virtual nodes and mapping from
+ virtual node numbers to physical node numbers. Virtual
+ nodes host CTDB databases. Only nodes that are
+ participating in the VNN map can become lmaster or dmaster
+ for database records.
+ </p></div><div class="refsect3"><a name="idm140001402031664"></a><h4>Recovery mode</h4><p>
+ This is the current recovery mode of the cluster. There are two possible modes:
+ </p><p>
+ NORMAL - The cluster is fully operational.
+ </p><p>
+ RECOVERY - The cluster databases have all been frozen, pausing all services while the cluster awaits a recovery process to complete. A recovery process should finish within seconds. If a cluster is stuck in the RECOVERY state this would indicate a cluster malfunction which needs to be investigated.
+ </p><p>
+ Once the recovery master detects an inconsistency, for example a node
+ becomes disconnected/connected, the recovery daemon will trigger a
+ cluster recovery process, where all databases are remerged across the
+ cluster. When this process starts, the recovery master will first
+ "freeze" all databases to prevent applications such as samba from
+ accessing the databases and it will also mark the recovery mode as
+ RECOVERY.
+ </p><p>
+ When the CTDB daemon starts up, it will start in RECOVERY
+ mode. Once the node has been merged into a cluster and all
+ databases have been recovered, the node mode will change into
+ NORMAL mode and the databases will be "thawed", allowing samba
+ to access the databases again.
+ </p></div><div class="refsect3"><a name="idm140001402027760"></a><h4>Recovery master</h4><p>
+ This is the cluster node that is currently designated as the recovery master. This node is responsible of monitoring the consistency of the cluster and to perform the actual recovery process when reqired.
+ </p><p>
+ Only one node at a time can be the designated recovery master. Which
+ node is designated the recovery master is decided by an election
+ process in the recovery daemons running on each node.
+ </p></div><div class="refsect3"><a name="idm140001402025760"></a><h4>Example</h4><pre class="screen">
+# ctdb status
+Number of nodes:4
+pnn:0 192.168.2.200 OK (THIS NODE)
+pnn:1 192.168.2.201 OK
+pnn:2 192.168.2.202 OK
+pnn:3 192.168.2.203 OK
+Generation:1362079228
+Size:4
+hash:0 lmaster:0
+hash:1 lmaster:1
+hash:2 lmaster:2
+hash:3 lmaster:3
+Recovery mode:NORMAL (0)
+Recovery master:0
+ </pre></div></div><div class="refsect2"><a name="idm140001402023856"></a><h3>nodestatus [<span class="optional"><em class="parameter"><code>PNN-LIST</code></em></span>]</h3><p>
+ This command is similar to the <span class="command"><strong>status</strong></span>
+ command. It displays the "node status" subset of output. The
+ main differences are:
+ </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
+ The exit code is the bitwise-OR of the flags for each
+ specified node, while <span class="command"><strong>ctdb status</strong></span> exits
+ with 0 if it was able to retrieve status for all nodes.
+ </p></li><li class="listitem"><p>
+ <span class="command"><strong>ctdb status</strong></span> provides status information
+ for all nodes. <span class="command"><strong>ctdb nodestatus</strong></span>
+ defaults to providing status for only the current node.
+ If PNN-LIST is provided then status is given for
+ the indicated node(s).
+ </p></li></ul></div><p>
+ A common invocation in scripts is <span class="command"><strong>ctdb nodestatus
+ all</strong></span> to check whether all nodes in a cluster are
+ healthy.
+ </p><div class="refsect3"><a name="idm140001396491728"></a><h4>Example</h4><pre class="screen">
+# ctdb nodestatus
+pnn:0 10.0.0.30 OK (THIS NODE)
+
+# ctdb nodestatus all
+Number of nodes:2
+pnn:0 10.0.0.30 OK (THIS NODE)
+pnn:1 10.0.0.31 OK
+ </pre></div></div><div class="refsect2"><a name="idm140001396490032"></a><h3>recmaster</h3><p>
+ This command shows the pnn of the node which is currently the recmaster.
+ </p><p>
+ Note: If the the queried node is INACTIVE then the status
+ might not be current.
+ </p></div><div class="refsect2"><a name="idm140001396488288"></a><h3>uptime</h3><p>
+ This command shows the uptime for the ctdb daemon. When the last recovery or ip-failover completed and how long it took. If the "duration" is shown as a negative number, this indicates that there is a recovery/failover in progress and it started that many seconds ago.
+ </p><div class="refsect3"><a name="idm140001396486976"></a><h4>Example</h4><pre class="screen">
+# ctdb uptime
+Current time of node : Thu Oct 29 10:38:54 2009
+Ctdbd start time : (000 16:54:28) Wed Oct 28 17:44:26 2009
+Time of last recovery/failover: (000 16:53:31) Wed Oct 28 17:45:23 2009
+Duration of last recovery/failover: 2.248552 seconds
+ </pre></div></div><div class="refsect2"><a name="idm140001396485152"></a><h3>listnodes</h3><p>
+ This command shows lists the ip addresses of all the nodes in the cluster.
+ </p><div class="refsect3"><a name="idm140001396484032"></a><h4>Example</h4><pre class="screen">
+# ctdb listnodes
+192.168.2.200
+192.168.2.201
+192.168.2.202
+192.168.2.203
+ </pre></div></div><div class="refsect2"><a name="idm140001396482416"></a><h3>natgwlist</h3><p>
+ Show the current NAT gateway master and the status of all
+ nodes in the current NAT gateway group. See the
+ <em class="citetitle">NAT GATEWAY</em> section in
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more details.
+ </p><div class="refsect3"><a name="idm140001396479984"></a><h4>Example</h4><pre class="screen">
+# ctdb natgwlist
+0 192.168.2.200
+Number of nodes:4
+pnn:0 192.168.2.200 OK (THIS NODE)
+pnn:1 192.168.2.201 OK
+pnn:2 192.168.2.202 OK
+pnn:3 192.168.2.203 OK
+ </pre></div></div><div class="refsect2"><a name="idm140001396478272"></a><h3>ping</h3><p>
+ This command will "ping" specified CTDB nodes in the cluster
+ to verify that they are running.
+ </p><div class="refsect3"><a name="idm140001396477136"></a><h4>Example</h4><pre class="screen">
+# ctdb ping
+response from 0 time=0.000054 sec (3 clients)
+ </pre></div></div><div class="refsect2"><a name="idm140001396475616"></a><h3>ifaces</h3><p>
+ This command will display the list of network interfaces, which could
+ host public addresses, along with their status.
+ </p><div class="refsect3"><a name="idm140001396474448"></a><h4>Example</h4><pre class="screen">
+# ctdb ifaces
+Interfaces on node 0
+name:eth5 link:up references:2
+name:eth4 link:down references:0
+name:eth3 link:up references:1
+name:eth2 link:up references:1
+
+# ctdb -X ifaces
+|Name|LinkStatus|References|
+|eth5|1|2|
+|eth4|0|0|
+|eth3|1|1|
+|eth2|1|1|
+ </pre></div></div><div class="refsect2"><a name="idm140001396472656"></a><h3>ip</h3><p>
+ This command will display the list of public addresses that are provided by the cluster and which physical node is currently serving this ip. By default this command will ONLY show those public addresses that are known to the node itself. To see the full list of all public ips across the cluster you must use "ctdb ip all".
+ </p><div class="refsect3"><a name="idm140001396471280"></a><h4>Example</h4><pre class="screen">
+# ctdb ip -v
+Public IPs on node 0
+172.31.91.82 node[1] active[] available[eth2,eth3] configured[eth2,eth3]
+172.31.91.83 node[0] active[eth3] available[eth2,eth3] configured[eth2,eth3]
+172.31.91.84 node[1] active[] available[eth2,eth3] configured[eth2,eth3]
+172.31.91.85 node[0] active[eth2] available[eth2,eth3] configured[eth2,eth3]
+172.31.92.82 node[1] active[] available[eth5] configured[eth4,eth5]
+172.31.92.83 node[0] active[eth5] available[eth5] configured[eth4,eth5]
+172.31.92.84 node[1] active[] available[eth5] configured[eth4,eth5]
+172.31.92.85 node[0] active[eth5] available[eth5] configured[eth4,eth5]
+
+# ctdb -X ip -v
+|Public IP|Node|ActiveInterface|AvailableInterfaces|ConfiguredInterfaces|
+|172.31.91.82|1||eth2,eth3|eth2,eth3|
+|172.31.91.83|0|eth3|eth2,eth3|eth2,eth3|
+|172.31.91.84|1||eth2,eth3|eth2,eth3|
+|172.31.91.85|0|eth2|eth2,eth3|eth2,eth3|
+|172.31.92.82|1||eth5|eth4,eth5|
+|172.31.92.83|0|eth5|eth5|eth4,eth5|
+|172.31.92.84|1||eth5|eth4,eth5|
+|172.31.92.85|0|eth5|eth5|eth4,eth5|
+ </pre></div></div><div class="refsect2"><a name="idm140001396467728"></a><h3>ipinfo <em class="parameter"><code>IP</code></em></h3><p>
+ This command will display details about the specified public addresses.
+ </p><div class="refsect3"><a name="idm140001396466112"></a><h4>Example</h4><pre class="screen">
+# ctdb ipinfo 172.31.92.85
+Public IP[172.31.92.85] info on node 0
+IP:172.31.92.85
+CurrentNode:0
+NumInterfaces:2
+Interface[1]: Name:eth4 Link:down References:0
+Interface[2]: Name:eth5 Link:up References:2 (active)
+ </pre></div></div><div class="refsect2"><a name="idm140001396464368"></a><h3>scriptstatus</h3><p>
+ This command displays which scripts where run in the previous monitoring cycle and the result of each script. If a script failed with an error, causing the node to become unhealthy, the output from that script is also shown.
+ </p><div class="refsect3"><a name="idm140001396463088"></a><h4>Example</h4><pre class="screen">
+# ctdb scriptstatus
+7 scripts were executed last monitoring cycle
+00.ctdb Status:OK Duration:0.056 Tue Mar 24 18:56:57 2009
+10.interface Status:OK Duration:0.077 Tue Mar 24 18:56:57 2009
+11.natgw Status:OK Duration:0.039 Tue Mar 24 18:56:57 2009
+20.multipathd Status:OK Duration:0.038 Tue Mar 24 18:56:57 2009
+31.clamd Status:DISABLED
+40.vsftpd Status:OK Duration:0.045 Tue Mar 24 18:56:57 2009
+41.httpd Status:OK Duration:0.039 Tue Mar 24 18:56:57 2009
+50.samba Status:ERROR Duration:0.082 Tue Mar 24 18:56:57 2009
+OUTPUT:ERROR: Samba tcp port 445 is not responding
+ </pre></div></div><div class="refsect2"><a name="idm140001396460864"></a><h3>disablescript <em class="parameter"><code>SCRIPT</code></em></h3><p>
+ This command is used to disable an eventscript.
+ </p><p>
+ This will take effect the next time the eventscripts are being executed so it can take a short while until this is reflected in 'scriptstatus'.
+ </p></div><div class="refsect2"><a name="idm140001396458656"></a><h3>enablescript <em class="parameter"><code>SCRIPT</code></em></h3><p>
+ This command is used to enable an eventscript.
+ </p><p>
+ This will take effect the next time the eventscripts are being executed so it can take a short while until this is reflected in 'scriptstatus'.
+ </p></div><div class="refsect2"><a name="idm140001396456448"></a><h3>listvars</h3><p>
+ List all tuneable variables, except the values of the obsolete tunables
+ like VacuumMinInterval. The obsolete tunables can be retrieved only
+ explicitly with the "ctdb getvar" command.
+ </p><div class="refsect3"><a name="idm140001396455216"></a><h4>Example</h4><pre class="screen">
+# ctdb listvars
+MaxRedirectCount = 3
+SeqnumInterval = 1000
+ControlTimeout = 60
+TraverseTimeout = 20
+KeepaliveInterval = 5
+KeepaliveLimit = 5
+RecoverTimeout = 20
+RecoverInterval = 1
+ElectionTimeout = 3
+TakeoverTimeout = 9
+MonitorInterval = 15
+TickleUpdateInterval = 20
+EventScriptTimeout = 30
+MonitorTimeoutCount = 1
+RecoveryGracePeriod = 120
+RecoveryBanPeriod = 300
+DatabaseHashSize = 100001
+DatabaseMaxDead = 5
+RerecoveryTimeout = 10
+EnableBans = 1
+DeterministicIPs = 0
+LCP2PublicIPs = 1
+ReclockPingPeriod = 60
+NoIPFailback = 0
+DisableIPFailover = 0
+VerboseMemoryNames = 0
+RecdPingTimeout = 60
+RecdFailCount = 10
+LogLatencyMs = 0
+RecLockLatencyMs = 1000
+RecoveryDropAllIPs = 120
+VacuumInterval = 10
+VacuumMaxRunTime = 30
+RepackLimit = 10000
+VacuumLimit = 5000
+VacuumFastPathCount = 60
+MaxQueueDropMsg = 1000000
+UseStatusEvents = 0
+AllowUnhealthyDBRead = 0
+StatHistoryInterval = 1
+DeferredAttachTO = 120
+AllowClientDBAttach = 1
+RecoverPDBBySeqNum = 0
+ </pre></div></div><div class="refsect2"><a name="idm140001396451152"></a><h3>getvar <em class="parameter"><code>NAME</code></em></h3><p>
+ Get the runtime value of a tuneable variable.
+ </p><div class="refsect3"><a name="idm140001396449632"></a><h4>Example</h4><pre class="screen">
+# ctdb getvar MaxRedirectCount
+MaxRedirectCount = 3
+ </pre></div></div><div class="refsect2"><a name="idm140001396448112"></a><h3>setvar <em class="parameter"><code>NAME</code></em> <em class="parameter"><code>VALUE</code></em></h3><p>
+ Set the runtime value of a tuneable variable.
+ </p><p>
+ Example: ctdb setvar MaxRedirectCount 5
+ </p></div><div class="refsect2"><a name="idm140001396445456"></a><h3>lvsmaster</h3><p>
+ This command shows which node is currently the LVSMASTER. The
+ LVSMASTER is the node in the cluster which drives the LVS system and
+ which receives all incoming traffic from clients.
+ </p><p>
+ LVS is the mode where the entire CTDB/Samba cluster uses a single
+ ip address for the entire cluster. In this mode all clients connect to
+ one specific node which will then multiplex/loadbalance the clients
+ evenly onto the other nodes in the cluster. This is an alternative to using
+ public ip addresses. See the manpage for ctdbd for more information
+ about LVS.
+ </p></div><div class="refsect2"><a name="idm140001396443328"></a><h3>lvs</h3><p>
+ This command shows which nodes in the cluster are currently active in the
+ LVS configuration. I.e. which nodes we are currently loadbalancing
+ the single ip address across.
+ </p><p>
+ LVS will by default only loadbalance across those nodes that are both
+ LVS capable and also HEALTHY. Except if all nodes are UNHEALTHY in which
+ case LVS will loadbalance across all UNHEALTHY nodes as well.
+ LVS will never use nodes that are DISCONNECTED, STOPPED, BANNED or
+ DISABLED.
+ </p><p>
+ Example output:
+ </p><pre class="screen">
+2:10.0.0.13
+3:10.0.0.14
+ </pre></div><div class="refsect2"><a name="idm140001396440288"></a><h3>getcapabilities</h3><p>
+ This command shows the capabilities of the current node. See
+ the <em class="citetitle">CAPABILITIES</em> section in
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more details.
+ </p><p>
+ Example output:
+ </p><pre class="screen">
+RECMASTER: YES
+LMASTER: YES
+LVS: NO
+ </pre></div><div class="refsect2"><a name="idm140001396436848"></a><h3>statistics</h3><p>
+ Collect statistics from the CTDB daemon about
+ how many calls it has served. Information about
+ various fields in statistics can be found in
+ <span class="citerefentry"><span class="refentrytitle">ctdb-statistics</span>(7)</span>.
+ </p><div class="refsect3"><a name="idm140001396434752"></a><h4>Example</h4><pre class="screen">
+# ctdb statistics
+CTDB version 1
+num_clients 3
+frozen 0
+recovering 0
+client_packets_sent 360489
+client_packets_recv 360466
+node_packets_sent 480931
+node_packets_recv 240120
+keepalive_packets_sent 4
+keepalive_packets_recv 3
+node
+req_call 2
+reply_call 2
+req_dmaster 0
+reply_dmaster 0
+reply_error 0
+req_message 42
+req_control 120408
+reply_control 360439
+client
+req_call 2
+req_message 24
+req_control 360440
+timeouts
+call 0
+control 0
+traverse 0
+total_calls 2
+pending_calls 0
+lockwait_calls 0
+pending_lockwait_calls 0
+memory_used 5040
+max_hop_count 0
+max_call_latency 4.948321 sec
+max_lockwait_latency 0.000000 sec
+ </pre></div></div><div class="refsect2"><a name="idm140001396430880"></a><h3>statisticsreset</h3><p>
+ This command is used to clear all statistics counters in a node.
+ </p><p>
+ Example: ctdb statisticsreset
+ </p></div><div class="refsect2"><a name="idm140001396429248"></a><h3>dbstatistics <em class="parameter"><code>DB</code></em></h3><p>
+ Display statistics about the database DB. Information
+ about various fields in dbstatistics can be found in
+ <span class="citerefentry"><span class="refentrytitle">ctdb-statistics</span>(7)</span>.
+ </p><div class="refsect3"><a name="idm140001396426704"></a><h4>Example</h4><pre class="screen">
+# ctdb dbstatistics locking.tdb
+DB Statistics: locking.tdb
+ ro_delegations 0
+ ro_revokes 0
+ locks
+ total 14356
+ failed 0
+ current 0
+ pending 0
+ hop_count_buckets: 28087 2 1 0 0 0 0 0 0 0 0 0 0 0 0 0
+ lock_buckets: 0 14188 38 76 32 19 3 0 0 0 0 0 0 0 0 0
+ locks_latency MIN/AVG/MAX 0.001066/0.012686/4.202292 sec out of 14356
+ Num Hot Keys: 1
+ Count:8 Key:ff5bd7cb3ee3822edc1f0000000000000000000000000000
+ </pre></div></div><div class="refsect2"><a name="idm140001396424592"></a><h3>getreclock</h3><p>
+ Show the name of the recovery lock file, if any.
+ </p><p>
+ Example output:
+ </p><pre class="screen">
+ Reclock file:/clusterfs/.ctdb/recovery.lock
+ </pre></div><div class="refsect2"><a name="idm140001396422432"></a><h3>
+ setreclock [<span class="optional"><em class="parameter"><code>FILE</code></em></span>]
+ </h3><p>
+ FILE specifies the name of the recovery lock file. If the
+ recovery lock file is changed at run-time then this will cause
+ a recovery, which in turn causes the recovery lock to be
+ retaken.
+ </p><p>
+ If no FILE is specified then a recovery lock file will no
+ longer be used.
+ </p><p>
+ This command only affects the run-time setting of a single
+ CTDB node. This setting <span class="emphasis"><em>must</em></span> be changed
+ on all nodes simultaneously. For information about configuring
+ the recovery lock file please see the
+ <em class="citetitle">CTDB_RECOVERY_LOCK</em> entry in
+ <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> and the
+ <em class="citetitle">--reclock</em> entry in
+ <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>. For information
+ about the recovery lock please see the <em class="citetitle">RECOVERY
+ LOCK</em> section in
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
+ </p></div><div class="refsect2"><a name="idm140001396415008"></a><h3>getdebug</h3><p>
+ Get the current debug level for the node. the debug level controls what information is written to the log file.
+ </p><p>
+ The debug levels are mapped to the corresponding syslog levels.
+ When a debug level is set, only those messages at that level and higher
+ levels will be printed.
+ </p><p>
+ The list of debug levels from highest to lowest are :
+ </p><p>
+ ERR WARNING NOTICE INFO DEBUG
+ </p></div><div class="refsect2"><a name="idm140001396412368"></a><h3>setdebug <em class="parameter"><code>DEBUGLEVEL</code></em></h3><p>
+ Set the debug level of a node. This controls what information will be logged.
+ </p><p>
+ The debuglevel is one of ERR WARNING NOTICE INFO DEBUG
+ </p></div><div class="refsect2"><a name="idm140001396410240"></a><h3>getpid</h3><p>
+ This command will return the process id of the ctdb daemon.
+ </p></div><div class="refsect2"><a name="idm140001396409088"></a><h3>disable</h3><p>
+ This command is used to administratively disable a node in the cluster.
+ A disabled node will still participate in the cluster and host
+ clustered TDB records but its public ip address has been taken over by
+ a different node and it no longer hosts any services.
+ </p></div><div class="refsect2"><a name="idm140001396407648"></a><h3>enable</h3><p>
+ Re-enable a node that has been administratively disabled.
+ </p></div><div class="refsect2"><a name="idm140001396406496"></a><h3>stop</h3><p>
+ This command is used to administratively STOP a node in the cluster.
+ A STOPPED node is connected to the cluster but will not host any
+ public ip addresse, nor does it participate in the VNNMAP.
+ The difference between a DISABLED node and a STOPPED node is that
+ a STOPPED node does not host any parts of the database which means
+ that a recovery is required to stop/continue nodes.
+ </p></div><div class="refsect2"><a name="idm140001396404944"></a><h3>continue</h3><p>
+ Re-start a node that has been administratively stopped.
+ </p></div><div class="refsect2"><a name="idm140001396403792"></a><h3>addip <em class="parameter"><code>IPADDR</code></em>/<em class="parameter"><code>mask</code></em> <em class="parameter"><code>IFACE</code></em></h3><p>
+ This command is used to add a new public ip to a node during runtime.
+ This allows public addresses to be added to a cluster without having
+ to restart the ctdb daemons.
+ </p><p>
+ Note that this only updates the runtime instance of ctdb. Any changes will be lost next time ctdb is restarted and the public addresses file is re-read.
+ If you want this change to be permanent you must also update the public addresses file manually.
+ </p></div><div class="refsect2"><a name="idm140001396400048"></a><h3>delip <em class="parameter"><code>IPADDR</code></em></h3><p>
+ This command is used to remove a public ip from a node during runtime.
+ If this public ip is currently hosted by the node it being removed from, the ip will first be failed over to another node, if possible, before it is removed.
+ </p><p>
+ Note that this only updates the runtime instance of ctdb. Any changes will be lost next time ctdb is restarted and the public addresses file is re-read.
+ If you want this change to be permanent you must also update the public addresses file manually.
+ </p></div><div class="refsect2"><a name="idm140001396397488"></a><h3>moveip <em class="parameter"><code>IPADDR</code></em> <em class="parameter"><code>PNN</code></em></h3><p>
+ This command can be used to manually fail a public ip address to a
+ specific node.
+ </p><p>
+ In order to manually override the "automatic" distribution of public
+ ip addresses that ctdb normally provides, this command only works
+ when you have changed the tunables for the daemon to:
+ </p><p>
+ DeterministicIPs = 0
+ </p><p>
+ NoIPFailback = 1
+ </p></div><div class="refsect2"><a name="idm140001396393728"></a><h3>shutdown</h3><p>
+ This command will shutdown a specific CTDB daemon.
+ </p></div><div class="refsect2"><a name="idm140001396392576"></a><h3>setlmasterrole on|off</h3><p>
+ This command is used ot enable/disable the LMASTER capability for a node at runtime. This capability determines whether or not a node can be used as an LMASTER for records in the database. A node that does not have the LMASTER capability will not show up in the vnnmap.
+ </p><p>
+ Nodes will by default have this capability, but it can be stripped off nodes by the setting in the sysconfig file or by using this command.
+ </p><p>
+ Once this setting has been enabled/disabled, you need to perform a recovery for it to take effect.
+ </p><p>
+ See also "ctdb getcapabilities"
+ </p></div><div class="refsect2"><a name="idm140001396389696"></a><h3>setrecmasterrole on|off</h3><p>
+ This command is used ot enable/disable the RECMASTER capability for a node at runtime. This capability determines whether or not a node can be used as an RECMASTER for the cluster. A node that does not have the RECMASTER capability can not win a recmaster election. A node that already is the recmaster for the cluster when the capability is stripped off the node will remain the recmaster until the next cluster election.
+ </p><p>
+ Nodes will by default have this capability, but it can be stripped off nodes by the setting in the sysconfig file or by using this command.
+ </p><p>
+ See also "ctdb getcapabilities"
+ </p></div><div class="refsect2"><a name="idm140001396387168"></a><h3>reloadnodes</h3><p>
+ This command is used when adding new nodes, or removing
+ existing nodes from an existing cluster.
+ </p><p>
+ Procedure to add nodes:
+ </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
+ To expand an existing cluster, first ensure with
+ <span class="command"><strong>ctdb status</strong></span> that all nodes are up and
+ running and that they are all healthy. Do not try to
+ expand a cluster unless it is completely healthy!
+ </p></li><li class="listitem"><p>
+ On all nodes, edit <code class="filename">/usr/local/etc/ctdb/nodes</code>
+ and <span class="emphasis"><em>add the new nodes at the end of this
+ file</em></span>.
+ </p></li><li class="listitem"><p>
+ Verify that all the nodes have identical
+ <code class="filename">/usr/local/etc/ctdb/nodes</code> files after adding
+ the new nodes.
+ </p></li><li class="listitem"><p>
+ Run <span class="command"><strong>ctdb reloadnodes</strong></span> to force all nodes
+ to reload the nodes file.
+ </p></li><li class="listitem"><p>
+ Use <span class="command"><strong>ctdb status</strong></span> on all nodes and verify
+ that they now show the additional nodes.
+ </p></li><li class="listitem"><p>
+ Install and configure the new node and bring it online.
+ </p></li></ol></div><p>
+ Procedure to remove nodes:
+ </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
+ To remove nodes from an existing cluster, first ensure
+ with <span class="command"><strong>ctdb status</strong></span> that all nodes, except
+ the node to be deleted, are up and running and that they
+ are all healthy. Do not try to remove nodes from a
+ cluster unless the cluster is completely healthy!
+ </p></li><li class="listitem"><p>
+ Shutdown and power off the node to be removed.
+ </p></li><li class="listitem"><p>
+ On all other nodes, edit the
+ <code class="filename">/usr/local/etc/ctdb/nodes</code> file and
+ <span class="emphasis"><em>comment out</em></span> the nodes to be removed.
+ <span class="emphasis"><em>Do not delete the lines for the deleted
+ nodes</em></span>, just comment them out by adding a '#' at
+ the beginning of the lines.
+ </p></li><li class="listitem"><p>
+ Run <span class="command"><strong>ctdb reloadnodes</strong></span> to force all nodes
+ to reload the nodes file.
+ </p></li><li class="listitem"><p>
+ Use <span class="command"><strong>ctdb status</strong></span> on all nodes and verify
+ that the deleted nodes are no longer listed.
+ </p></li></ol></div></div><div class="refsect2"><a name="idm140001396367344"></a><h3>
+ reloadips
+ [<span class="optional"><em class="parameter"><code>PNN-LIST</code></em></span>]
+ </h3><p>
+ This command reloads the public addresses configuration file
+ on the specified nodes. When it completes addresses will be
+ reconfigured and reassigned across the cluster as necessary.
+ </p></div><div class="refsect2"><a name="idm140001396365232"></a><h3>getdbmap</h3><p>
+ This command lists all clustered TDB databases that the CTDB daemon has attached to. Some databases are flagged as PERSISTENT, this means that the database stores data persistently and the data will remain across reboots. One example of such a database is secrets.tdb where information about how the cluster was joined to the domain is stored.
+ </p><p>
+ If a PERSISTENT database is not in a healthy state the database is
+ flagged as UNHEALTHY. If there's at least one completely healthy node running in
+ the cluster, it's possible that the content is restored by a recovery
+ run automaticly. Otherwise an administrator needs to analyze the
+ problem.
+ </p><p>
+ See also "ctdb getdbstatus", "ctdb backupdb", "ctdb restoredb",
+ "ctdb dumpbackup", "ctdb wipedb", "ctdb setvar AllowUnhealthyDBRead 1"
+ and (if samba or tdb-utils are installed) "tdbtool check".
+ </p><p>
+ Most databases are not persistent and only store the state information that the currently running samba daemons need. These databases are always wiped when ctdb/samba starts and when a node is rebooted.
+ </p><div class="refsect3"><a name="idm140001396361920"></a><h4>Example</h4><pre class="screen">
+# ctdb getdbmap
+Number of databases:10
+dbid:0x435d3410 name:notify.tdb path:/usr/local/var/lib/ctdb/notify.tdb.0
+dbid:0x42fe72c5 name:locking.tdb path:/usr/local/var/lib/ctdb/locking.tdb.0
+dbid:0x1421fb78 name:brlock.tdb path:/usr/local/var/lib/ctdb/brlock.tdb.0
+dbid:0x17055d90 name:connections.tdb path:/usr/local/var/lib/ctdb/connections.tdb.0
+dbid:0xc0bdde6a name:sessionid.tdb path:/usr/local/var/lib/ctdb/sessionid.tdb.0
+dbid:0x122224da name:test.tdb path:/usr/local/var/lib/ctdb/test.tdb.0
+dbid:0x2672a57f name:idmap2.tdb path:/usr/local/var/lib/ctdb/persistent/idmap2.tdb.0 PERSISTENT
+dbid:0xb775fff6 name:secrets.tdb path:/usr/local/var/lib/ctdb/persistent/secrets.tdb.0 PERSISTENT
+dbid:0xe98e08b6 name:group_mapping.tdb path:/usr/local/var/lib/ctdb/persistent/group_mapping.tdb.0 PERSISTENT
+dbid:0x7bbbd26c name:passdb.tdb path:/usr/local/var/lib/ctdb/persistent/passdb.tdb.0 PERSISTENT
+
+# ctdb getdbmap # example for unhealthy database
+Number of databases:1
+dbid:0xb775fff6 name:secrets.tdb path:/usr/local/var/lib/ctdb/persistent/secrets.tdb.0 PERSISTENT UNHEALTHY
+
+# ctdb -X getdbmap
+|ID|Name|Path|Persistent|Unhealthy|
+|0x7bbbd26c|passdb.tdb|/usr/local/var/lib/ctdb/persistent/passdb.tdb.0|1|0|
+ </pre></div></div><div class="refsect2"><a name="idm140001396359168"></a><h3>
+ backupdb
+ <em class="parameter"><code>DB</code></em>
+ <em class="parameter"><code>FILE</code></em>
+ </h3><p>
+ Copy the contents of database DB to FILE. FILE can later be
+ read back using <span class="command"><strong>restoredb</strong></span>. This is mainly
+ useful for backing up persistent databases such as
+ <code class="filename">secrets.tdb</code> and similar.
+ </p></div><div class="refsect2"><a name="idm140001396355344"></a><h3>
+ restoredb
+ <em class="parameter"><code>FILE</code></em>
+ [<span class="optional"><em class="parameter"><code>DB</code></em></span>]
+ </h3><p>
+ This command restores a persistent database that was
+ previously backed up using backupdb. By default the data will
+ be restored back into the same database as it was created
+ from. By specifying dbname you can restore the data into a
+ different database.
+ </p></div><div class="refsect2"><a name="idm140001396352528"></a><h3>setdbreadonly <em class="parameter"><code>DB</code></em></h3><p>
+ This command will enable the read-only record support for a
+ database. This is an experimental feature to improve
+ performance for contended records primarily in locking.tdb and
+ brlock.tdb. When enabling this feature you must set it on all
+ nodes in the cluster.
+ </p></div><div class="refsect2"><a name="idm140001396350592"></a><h3>setdbsticky <em class="parameter"><code>DB</code></em></h3><p>
+ This command will enable the sticky record support for the
+ specified database. This is an experimental feature to
+ improve performance for contended records primarily in
+ locking.tdb and brlock.tdb. When enabling this feature you
+ must set it on all nodes in the cluster.
+ </p></div></div><div class="refsect1"><a name="idm140001396348512"></a><h2>INTERNAL COMMANDS</h2><p>
+ Internal commands are used by CTDB's scripts and are not
+ required for managing a CTDB cluster. Their parameters and
+ behaviour are subject to change.
+ </p><div class="refsect2"><a name="idm140001396347296"></a><h3>gettickles <em class="parameter"><code>IPADDR</code></em></h3><p>
+ Show TCP connections that are registered with CTDB to be
+ "tickled" if there is a failover.
+ </p></div><div class="refsect2"><a name="idm140001396345536"></a><h3>gratiousarp <em class="parameter"><code>IPADDR</code></em> <em class="parameter"><code>INTERFACE</code></em></h3><p>
+ Send out a gratious ARP for the specified interface through
+ the specified interface. This command is mainly used by the
+ ctdb eventscripts.
+ </p></div><div class="refsect2"><a name="idm140001396343104"></a><h3>killtcp</h3><p>
+ Read a list of TCP connections, one per line, from standard
+ input and terminate each connection. A connection is
+ specified as:
+ </p><pre class="synopsis">
+ <em class="parameter"><code>SRC-IPADDR</code></em>:<em class="parameter"><code>SRC-PORT</code></em> <em class="parameter"><code>DST-IPADDR</code></em>:<em class="parameter"><code>DST-PORT</code></em>
+ </pre><p>
+ Each connection is terminated by issuing a TCP RST to the
+ SRC-IPADDR:SRC-PORT endpoint.
+ </p><p>
+ A single connection can be specified on the command-line
+ rather than on standard input.
+ </p></div><div class="refsect2"><a name="idm140001396337680"></a><h3>
+ pdelete <em class="parameter"><code>DB</code></em> <em class="parameter"><code>KEY</code></em>
+ </h3><p>
+ Delete KEY from DB.
+ </p></div><div class="refsect2"><a name="idm140001396335280"></a><h3>
+ pfetch <em class="parameter"><code>DB</code></em> <em class="parameter"><code>KEY</code></em>
+ </h3><p>
+ Print the value associated with KEY in DB.
+ </p></div><div class="refsect2"><a name="idm140001396332880"></a><h3>
+ pstore
+ <em class="parameter"><code>DB</code></em>
+ <em class="parameter"><code>KEY</code></em>
+ <em class="parameter"><code>FILE</code></em>
+ </h3><p>
+ Store KEY in DB with contents of FILE as the associated value.
+ </p></div><div class="refsect2"><a name="idm140001396329776"></a><h3>
+ ptrans
+ <em class="parameter"><code>DB</code></em>
+ [<span class="optional"><em class="parameter"><code>FILE</code></em></span>]
+ </h3><p>
+ Read a list of key-value pairs, one per line from FILE, and
+ store them in DB using a single transaction. An empty value
+ is equivalent to deleting the given key.
+ </p><p>
+ The key and value should be separated by spaces or tabs. Each
+ key/value should be a printable string enclosed in
+ double-quotes.
+ </p></div><div class="refsect2"><a name="idm140001396326512"></a><h3>runstate [setup|first_recovery|startup|running]</h3><p>
+ Print the runstate of the specified node. Runstates are used
+ to serialise important state transitions in CTDB, particularly
+ during startup.
+ </p><p>
+ If one or more optional runstate arguments are specified then
+ the node must be in one of these runstates for the command to
+ succeed.
+ </p><div class="refsect3"><a name="idm140001396324784"></a><h4>Example</h4><pre class="screen">
+# ctdb runstate
+RUNNING
+ </pre></div></div><div class="refsect2"><a name="idm140001396323264"></a><h3>setifacelink <em class="parameter"><code>IFACE</code></em> up|down</h3><p>
+ Set the internal state of network interface IFACE. This is
+ typically used in the <code class="filename">10.interface</code> script
+ in the "monitor" event.
+ </p><p>
+ Example: ctdb setifacelink eth0 up
+ </p></div><div class="refsect2"><a name="idm140001396320384"></a><h3>tickle <em class="parameter"><code>SRC-IPADDR</code></em>:<em class="parameter"><code>SRC-PORT</code></em> <em class="parameter"><code>DST-IPADDR</code></em>:<em class="parameter"><code>DST-PORT</code></em></h3><p>
+ Send a TCP tickle to the source host for the specified TCP
+ connection. A TCP tickle is a TCP ACK packet with an invalid
+ sequence and acknowledge number and will when received by the
+ source host result in it sending an immediate correct ACK back
+ to the other end.
+ </p><p>
+ TCP tickles are useful to "tickle" clients after a IP failover has
+ occured since this will make the client immediately recognize the
+ TCP connection has been disrupted and that the client will need
+ to reestablish. This greatly speeds up the time it takes for a client
+ to detect and reestablish after an IP failover in the ctdb cluster.
+ </p></div><div class="refsect2"><a name="idm140001396315824"></a><h3>version</h3><p>
+ Display the CTDB version.
+ </p></div></div><div class="refsect1"><a name="idm140001396314544"></a><h2>DEBUGGING COMMANDS</h2><p>
+ These commands are primarily used for CTDB development and testing and
+ should not be used for normal administration.
+ </p><div class="refsect2"><a name="idm140001396313376"></a><h3>OPTIONS</h3><div class="variablelist"><dl class="variablelist"><dt><span class="term">--print-emptyrecords</span></dt><dd><p>
+ This enables printing of empty records when dumping databases
+ with the catdb, cattbd and dumpdbbackup commands. Records with
+ empty data segment are considered deleted by ctdb and cleaned
+ by the vacuuming mechanism, so this switch can come in handy for
+ debugging the vacuuming behaviour.
+ </p></dd><dt><span class="term">--print-datasize</span></dt><dd><p>
+ This lets database dumps (catdb, cattdb, dumpdbbackup) print the
+ size of the record data instead of dumping the data contents.
+ </p></dd><dt><span class="term">--print-lmaster</span></dt><dd><p>
+ This lets catdb print the lmaster for each record.
+ </p></dd><dt><span class="term">--print-hash</span></dt><dd><p>
+ This lets database dumps (catdb, cattdb, dumpdbbackup) print the
+ hash for each record.
+ </p></dd><dt><span class="term">--print-recordflags</span></dt><dd><p>
+ This lets catdb and dumpdbbackup print the
+ record flags for each record. Note that cattdb always
+ prints the flags.
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm140001396304352"></a><h3>process-exists <em class="parameter"><code>PID</code></em></h3><p>
+ This command checks if a specific process exists on the CTDB host. This is mainly used by Samba to check if remote instances of samba are still running or not.
+ </p></div><div class="refsect2"><a name="idm140001396302512"></a><h3>getdbstatus <em class="parameter"><code>DB</code></em></h3><p>
+ This command displays more details about a database.
+ </p><div class="refsect3"><a name="idm140001396300912"></a><h4>Example</h4><pre class="screen">
+# ctdb getdbstatus test.tdb.0
+dbid: 0x122224da
+name: test.tdb
+path: /usr/local/var/lib/ctdb/test.tdb.0
+PERSISTENT: no
+HEALTH: OK
+
+# ctdb getdbstatus registry.tdb # with a corrupted TDB
+dbid: 0xf2a58948
+name: registry.tdb
+path: /usr/local/var/lib/ctdb/persistent/registry.tdb.0
+PERSISTENT: yes
+HEALTH: NO-HEALTHY-NODES - ERROR - Backup of corrupted TDB in '/usr/local/var/lib/ctdb/persistent/registry.tdb.0.corrupted.20091208091949.0Z'
+ </pre></div></div><div class="refsect2"><a name="idm140001396298944"></a><h3>catdb <em class="parameter"><code>DB</code></em></h3><p>
+ Print a dump of the clustered TDB database DB.
+ </p></div><div class="refsect2"><a name="idm140001396297296"></a><h3>cattdb <em class="parameter"><code>DB</code></em></h3><p>
+ Print a dump of the contents of the local TDB database DB.
+ </p></div><div class="refsect2"><a name="idm140001396295568"></a><h3>dumpdbbackup <em class="parameter"><code>FILE</code></em></h3><p>
+ Print a dump of the contents from database backup FILE,
+ similar to <span class="command"><strong>catdb</strong></span>.
+ </p></div><div class="refsect2"><a name="idm140001396293216"></a><h3>wipedb <em class="parameter"><code>DB</code></em></h3><p>
+ Remove all contents of database DB.
+ </p></div><div class="refsect2"><a name="idm140001396291568"></a><h3>recover</h3><p>
+ This command will trigger the recovery daemon to do a cluster
+ recovery.
+ </p></div><div class="refsect2"><a name="idm140001396290320"></a><h3>ipreallocate, sync</h3><p>
+ This command will force the recovery master to perform a full ip reallocation process and redistribute all ip addresses. This is useful to "reset" the allocations back to its default state if they have been changed using the "moveip" command. While a "recover" will also perform this reallocation, a recovery is much more hevyweight since it will also rebuild all the databases.
+ </p></div><div class="refsect2"><a name="idm140001396288768"></a><h3>getmonmode</h3><p>
+ This command returns the monutoring mode of a node. The monitoring mode is either ACTIVE or DISABLED. Normally a node will continuously monitor that all other nodes that are expected are in fact connected and that they respond to commands.
+ </p><p>
+ ACTIVE - This is the normal mode. The node is actively monitoring all other nodes, both that the transport is connected and also that the node responds to commands. If a node becomes unavailable, it will be marked as DISCONNECTED and a recovery is initiated to restore the cluster.
+ </p><p>
+ DISABLED - This node is not monitoring that other nodes are available. In this mode a node failure will not be detected and no recovery will be performed. This mode is useful when for debugging purposes one wants to attach GDB to a ctdb process but wants to prevent the rest of the cluster from marking this node as DISCONNECTED and do a recovery.
+ </p></div><div class="refsect2"><a name="idm140001396285904"></a><h3>setmonmode 0|1</h3><p>
+ This command can be used to explicitly disable/enable monitoring mode on a node. The main purpose is if one wants to attach GDB to a running ctdb daemon but wants to prevent the other nodes from marking it as DISCONNECTED and issuing a recovery. To do this, set monitoring mode to 0 on all nodes before attaching with GDB. Remember to set monitoring mode back to 1 afterwards.
+ </p></div><div class="refsect2"><a name="idm140001396284352"></a><h3>attach <em class="parameter"><code>DBNAME</code></em> [persistent]</h3><p>
+ Create a new CTDB database called DBNAME and attach to it on
+ all nodes.
+ </p></div><div class="refsect2"><a name="idm140001396282480"></a><h3>detach <em class="parameter"><code>DB-LIST</code></em></h3><p>
+ Detach specified non-persistent database(s) from the cluster. This
+ command will disconnect specified database(s) on all nodes in
+ the cluster. This command should only be used when none of the
+ specified database(s) are in use.
+ </p><p>
+ All nodes should be active and tunable AllowClientDBAccess should
+ be disabled on all nodes before detaching databases.
+ </p></div><div class="refsect2"><a name="idm140001396280048"></a><h3>dumpmemory</h3><p>
+ This is a debugging command. This command will make the ctdb
+ daemon to write a fill memory allocation map to standard output.
+ </p></div><div class="refsect2"><a name="idm140001396278752"></a><h3>rddumpmemory</h3><p>
+ This is a debugging command. This command will dump the talloc memory
+ allocation tree for the recovery daemon to standard output.
+ </p></div><div class="refsect2"><a name="idm140001396277440"></a><h3>thaw</h3><p>
+ Thaw a previously frozen node.
+ </p></div><div class="refsect2"><a name="idm140001396276288"></a><h3>eventscript <em class="parameter"><code>ARGUMENTS</code></em></h3><p>
+ This is a debugging command. This command can be used to manually
+ invoke and run the eventscritps with arbitrary arguments.
+ </p></div><div class="refsect2"><a name="idm140001396274496"></a><h3>ban <em class="parameter"><code>BANTIME</code></em></h3><p>
+ Administratively ban a node for BANTIME seconds. The node
+ will be unbanned after BANTIME seconds have elapsed.
+ </p><p>
+ A banned node does not participate in the cluster. It does
+ not host any records for the clustered TDB and does not host
+ any public IP addresses.
+ </p><p>
+ Nodes are automatically banned if they misbehave. For
+ example, a node may be banned if it causes too many cluster
+ recoveries.
+ </p><p>
+ To administratively exclude a node from a cluster use the
+ <span class="command"><strong>stop</strong></span> command.
+ </p></div><div class="refsect2"><a name="idm140001396270512"></a><h3>unban</h3><p>
+ This command is used to unban a node that has either been
+ administratively banned using the ban command or has been
+ automatically banned.
+ </p></div><div class="refsect2"><a name="idm140001396269200"></a><h3>
+ rebalancenode
+ [<span class="optional"><em class="parameter"><code>PNN-LIST</code></em></span>]
+ </h3><p>
+ This command marks the given nodes as rebalance targets in the
+ LCP2 IP allocation algorithm. The
+ <span class="command"><strong>reloadips</strong></span> command will do this as necessary
+ so this command should not be needed.
+ </p></div><div class="refsect2"><a name="idm140001396266464"></a><h3>check_srvids <em class="parameter"><code>SRVID</code></em> ...</h3><p>
+ This command checks whether a set of srvid message ports are
+ registered on the node or not. The command takes a list of
+ values to check.
+ </p><div class="refsect3"><a name="idm140001396264656"></a><h4>Example</h4><pre class="screen">
+# ctdb check_srvids 1 2 3 14765
+Server id 0:1 does not exist
+Server id 0:2 does not exist
+Server id 0:3 does not exist
+Server id 0:14765 exists
+ </pre></div></div></div><div class="refsect1"><a name="idm140001396262720"></a><h2>SEE ALSO</h2><p>
+ <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">onnode</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdb-statistics</span>(7)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span>,
+
+ <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
+ </p></div></div></body></html>
--- /dev/null
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdb.7"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb — Clustered TDB</p></div><div class="refsect1"><a name="idm140441723018176"></a><h2>DESCRIPTION</h2><p>
+ CTDB is a clustered database component in clustered Samba that
+ provides a high-availability load-sharing CIFS server cluster.
+ </p><p>
+ The main functions of CTDB are:
+ </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
+ Provide a clustered version of the TDB database with automatic
+ rebuild/recovery of the databases upon node failures.
+ </p></li><li class="listitem"><p>
+ Monitor nodes in the cluster and services running on each node.
+ </p></li><li class="listitem"><p>
+ Manage a pool of public IP addresses that are used to provide
+ services to clients. Alternatively, CTDB can be used with
+ LVS.
+ </p></li></ul></div><p>
+ Combined with a cluster filesystem CTDB provides a full
+ high-availablity (HA) environment for services such as clustered
+ Samba, NFS and other services.
+ </p></div><div class="refsect1"><a name="idm140441723037264"></a><h2>ANATOMY OF A CTDB CLUSTER</h2><p>
+ A CTDB cluster is a collection of nodes with 2 or more network
+ interfaces. All nodes provide network (usually file/NAS) services
+ to clients. Data served by file services is stored on shared
+ storage (usually a cluster filesystem) that is accessible by all
+ nodes.
+ </p><p>
+ CTDB provides an "all active" cluster, where services are load
+ balanced across all nodes.
+ </p></div><div class="refsect1"><a name="idm140441725338896"></a><h2>Recovery Lock</h2><p>
+ CTDB uses a <span class="emphasis"><em>recovery lock</em></span> to avoid a
+ <span class="emphasis"><em>split brain</em></span>, where a cluster becomes
+ partitioned and each partition attempts to operate
+ independently. Issues that can result from a split brain
+ include file data corruption, because file locking metadata may
+ not be tracked correctly.
+ </p><p>
+ CTDB uses a <span class="emphasis"><em>cluster leader and follower</em></span>
+ model of cluster management. All nodes in a cluster elect one
+ node to be the leader. The leader node coordinates privileged
+ operations such as database recovery and IP address failover.
+ CTDB refers to the leader node as the <span class="emphasis"><em>recovery
+ master</em></span>. This node takes and holds the recovery lock
+ to assert its privileged role in the cluster.
+ </p><p>
+ The recovery lock is implemented using a file residing in shared
+ storage (usually) on a cluster filesystem. To support a
+ recovery lock the cluster filesystem must support lock
+ coherence. See
+ <span class="citerefentry"><span class="refentrytitle">ping_pong</span>(1)</span> for more details.
+ </p><p>
+ If a cluster becomes partitioned (for example, due to a
+ communication failure) and a different recovery master is
+ elected by the nodes in each partition, then only one of these
+ recovery masters will be able to take the recovery lock. The
+ recovery master in the "losing" partition will not be able to
+ take the recovery lock and will be excluded from the cluster.
+ The nodes in the "losing" partition will elect each node in turn
+ as their recovery master so eventually all the nodes in that
+ partition will be excluded.
+ </p><p>
+ CTDB does sanity checks to ensure that the recovery lock is held
+ as expected.
+ </p><p>
+ CTDB can run without a recovery lock but this is not recommended
+ as there will be no protection from split brains.
+ </p></div><div class="refsect1"><a name="idm140441722733568"></a><h2>Private vs Public addresses</h2><p>
+ Each node in a CTDB cluster has multiple IP addresses assigned
+ to it:
+
+ </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
+ A single private IP address that is used for communication
+ between nodes.
+ </p></li><li class="listitem"><p>
+ One or more public IP addresses that are used to provide
+ NAS or other services.
+ </p></li></ul></div><p>
+ </p><div class="refsect2"><a name="idm140441727493008"></a><h3>Private address</h3><p>
+ Each node is configured with a unique, permanently assigned
+ private address. This address is configured by the operating
+ system. This address uniquely identifies a physical node in
+ the cluster and is the address that CTDB daemons will use to
+ communicate with the CTDB daemons on other nodes.
+ </p><p>
+ Private addresses are listed in the file specified by the
+ <code class="varname">CTDB_NODES</code> configuration variable (see
+ <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>, default
+ <code class="filename">/usr/local/etc/ctdb/nodes</code>). This file contains the
+ list of private addresses for all nodes in the cluster, one
+ per line. This file must be the same on all nodes in the
+ cluster.
+ </p><p>
+ Private addresses should not be used by clients to connect to
+ services provided by the cluster.
+ </p><p>
+ It is strongly recommended that the private addresses are
+ configured on a private network that is separate from client
+ networks.
+ </p><p>
+ Example <code class="filename">/usr/local/etc/ctdb/nodes</code> for a four node
+ cluster:
+ </p><pre class="screen">
+192.168.1.1
+192.168.1.2
+192.168.1.3
+192.168.1.4
+ </pre></div><div class="refsect2"><a name="idm140441727640272"></a><h3>Public addresses</h3><p>
+ Public addresses are used to provide services to clients.
+ Public addresses are not configured at the operating system
+ level and are not permanently associated with a particular
+ node. Instead, they are managed by CTDB and are assigned to
+ interfaces on physical nodes at runtime.
+ </p><p>
+ The CTDB cluster will assign/reassign these public addresses
+ across the available healthy nodes in the cluster. When one
+ node fails, its public addresses will be taken over by one or
+ more other nodes in the cluster. This ensures that services
+ provided by all public addresses are always available to
+ clients, as long as there are nodes available capable of
+ hosting this address.
+ </p><p>
+ The public address configuration is stored in a file on each
+ node specified by the <code class="varname">CTDB_PUBLIC_ADDRESSES</code>
+ configuration variable (see
+ <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>, recommended
+ <code class="filename">/usr/local/etc/ctdb/public_addresses</code>). This file
+ contains a list of the public addresses that the node is
+ capable of hosting, one per line. Each entry also contains
+ the netmask and the interface to which the address should be
+ assigned.
+ </p><p>
+ Example <code class="filename">/usr/local/etc/ctdb/public_addresses</code> for a
+ node that can host 4 public addresses, on 2 different
+ interfaces:
+ </p><pre class="screen">
+10.1.1.1/24 eth1
+10.1.1.2/24 eth1
+10.1.2.1/24 eth2
+10.1.2.2/24 eth2
+ </pre><p>
+ In many cases the public addresses file will be the same on
+ all nodes. However, it is possible to use different public
+ address configurations on different nodes.
+ </p><p>
+ Example: 4 nodes partitioned into two subgroups:
+ </p><pre class="screen">
+Node 0:/usr/local/etc/ctdb/public_addresses
+ 10.1.1.1/24 eth1
+ 10.1.1.2/24 eth1
+
+Node 1:/usr/local/etc/ctdb/public_addresses
+ 10.1.1.1/24 eth1
+ 10.1.1.2/24 eth1
+
+Node 2:/usr/local/etc/ctdb/public_addresses
+ 10.1.2.1/24 eth2
+ 10.1.2.2/24 eth2
+
+Node 3:/usr/local/etc/ctdb/public_addresses
+ 10.1.2.1/24 eth2
+ 10.1.2.2/24 eth2
+ </pre><p>
+ In this example nodes 0 and 1 host two public addresses on the
+ 10.1.1.x network while nodes 2 and 3 host two public addresses
+ for the 10.1.2.x network.
+ </p><p>
+ Public address 10.1.1.1 can be hosted by either of nodes 0 or
+ 1 and will be available to clients as long as at least one of
+ these two nodes are available.
+ </p><p>
+ If both nodes 0 and 1 become unavailable then public address
+ 10.1.1.1 also becomes unavailable. 10.1.1.1 can not be failed
+ over to nodes 2 or 3 since these nodes do not have this public
+ address configured.
+ </p><p>
+ The <span class="command"><strong>ctdb ip</strong></span> command can be used to view the
+ current assignment of public addresses to physical nodes.
+ </p></div></div><div class="refsect1"><a name="idm140441727555008"></a><h2>Node status</h2><p>
+ The current status of each node in the cluster can be viewed by the
+ <span class="command"><strong>ctdb status</strong></span> command.
+ </p><p>
+ A node can be in one of the following states:
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">OK</span></dt><dd><p>
+ This node is healthy and fully functional. It hosts public
+ addresses to provide services.
+ </p></dd><dt><span class="term">DISCONNECTED</span></dt><dd><p>
+ This node is not reachable by other nodes via the private
+ network. It is not currently participating in the cluster.
+ It <span class="emphasis"><em>does not</em></span> host public addresses to
+ provide services. It might be shut down.
+ </p></dd><dt><span class="term">DISABLED</span></dt><dd><p>
+ This node has been administratively disabled. This node is
+ partially functional and participates in the cluster.
+ However, it <span class="emphasis"><em>does not</em></span> host public
+ addresses to provide services.
+ </p></dd><dt><span class="term">UNHEALTHY</span></dt><dd><p>
+ A service provided by this node has failed a health check
+ and should be investigated. This node is partially
+ functional and participates in the cluster. However, it
+ <span class="emphasis"><em>does not</em></span> host public addresses to
+ provide services. Unhealthy nodes should be investigated
+ and may require an administrative action to rectify.
+ </p></dd><dt><span class="term">BANNED</span></dt><dd><p>
+ CTDB is not behaving as designed on this node. For example,
+ it may have failed too many recovery attempts. Such nodes
+ are banned from participating in the cluster for a
+ configurable time period before they attempt to rejoin the
+ cluster. A banned node <span class="emphasis"><em>does not</em></span> host
+ public addresses to provide services. All banned nodes
+ should be investigated and may require an administrative
+ action to rectify.
+ </p></dd><dt><span class="term">STOPPED</span></dt><dd><p>
+ This node has been administratively exclude from the
+ cluster. A stopped node does no participate in the cluster
+ and <span class="emphasis"><em>does not</em></span> host public addresses to
+ provide services. This state can be used while performing
+ maintenance on a node.
+ </p></dd><dt><span class="term">PARTIALLYONLINE</span></dt><dd><p>
+ A node that is partially online participates in a cluster
+ like a healthy (OK) node. Some interfaces to serve public
+ addresses are down, but at least one interface is up. See
+ also <span class="command"><strong>ctdb ifaces</strong></span>.
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm140441727667696"></a><h2>CAPABILITIES</h2><p>
+ Cluster nodes can have several different capabilities enabled.
+ These are listed below.
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">RECMASTER</span></dt><dd><p>
+ Indicates that a node can become the CTDB cluster recovery
+ master. The current recovery master is decided via an
+ election held by all active nodes with this capability.
+ </p><p>
+ Default is YES.
+ </p></dd><dt><span class="term">LMASTER</span></dt><dd><p>
+ Indicates that a node can be the location master (LMASTER)
+ for database records. The LMASTER always knows which node
+ has the latest copy of a record in a volatile database.
+ </p><p>
+ Default is YES.
+ </p></dd><dt><span class="term">LVS</span></dt><dd><p>
+ Indicates that a node is configued in Linux Virtual Server
+ (LVS) mode. In this mode the entire CTDB cluster uses one
+ single public address for the entire cluster instead of
+ using multiple public addresses in failover mode. This is
+ an alternative to using a load-balancing layer-4 switch.
+ See the <em class="citetitle">LVS</em> section for more
+ details.
+ </p></dd></dl></div><p>
+ The RECMASTER and LMASTER capabilities can be disabled when CTDB
+ is used to create a cluster spanning across WAN links. In this
+ case CTDB acts as a WAN accelerator.
+ </p></div><div class="refsect1"><a name="idm140441727658624"></a><h2>LVS</h2><p>
+ LVS is a mode where CTDB presents one single IP address for the
+ entire cluster. This is an alternative to using public IP
+ addresses and round-robin DNS to loadbalance clients across the
+ cluster.
+ </p><p>
+ This is similar to using a layer-4 loadbalancing switch but with
+ some restrictions.
+ </p><p>
+ In this mode the cluster selects a set of nodes in the cluster
+ and loadbalance all client access to the LVS address across this
+ set of nodes. This set of nodes are all LVS capable nodes that
+ are HEALTHY, or if no HEALTHY nodes exists all LVS capable nodes
+ regardless of health status. LVS will however never loadbalance
+ traffic to nodes that are BANNED, STOPPED, DISABLED or
+ DISCONNECTED. The <span class="command"><strong>ctdb lvs</strong></span> command is used to
+ show which nodes are currently load-balanced across.
+ </p><p>
+ One of the these nodes are elected as the LVSMASTER. This node
+ receives all traffic from clients coming in to the LVS address
+ and multiplexes it across the internal network to one of the
+ nodes that LVS is using. When responding to the client, that
+ node will send the data back directly to the client, bypassing
+ the LVSMASTER node. The command <span class="command"><strong>ctdb
+ lvsmaster</strong></span> will show which node is the current
+ LVSMASTER.
+ </p><p>
+ The path used for a client I/O is:
+ </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
+ Client sends request packet to LVSMASTER.
+ </p></li><li class="listitem"><p>
+ LVSMASTER passes the request on to one node across the
+ internal network.
+ </p></li><li class="listitem"><p>
+ Selected node processes the request.
+ </p></li><li class="listitem"><p>
+ Node responds back to client.
+ </p></li></ol></div><p>
+ </p><p>
+ This means that all incoming traffic to the cluster will pass
+ through one physical node, which limits scalability. You can
+ send more data to the LVS address that one physical node can
+ multiplex. This means that you should not use LVS if your I/O
+ pattern is write-intensive since you will be limited in the
+ available network bandwidth that node can handle. LVS does work
+ wery well for read-intensive workloads where only smallish READ
+ requests are going through the LVSMASTER bottleneck and the
+ majority of the traffic volume (the data in the read replies)
+ goes straight from the processing node back to the clients. For
+ read-intensive i/o patterns you can acheive very high throughput
+ rates in this mode.
+ </p><p>
+ Note: you can use LVS and public addresses at the same time.
+ </p><p>
+ If you use LVS, you must have a permanent address configured for
+ the public interface on each node. This address must be routable
+ and the cluster nodes must be configured so that all traffic
+ back to client hosts are routed through this interface. This is
+ also required in order to allow samba/winbind on the node to
+ talk to the domain controller. This LVS IP address can not be
+ used to initiate outgoing traffic.
+ </p><p>
+ Make sure that the domain controller and the clients are
+ reachable from a node <span class="emphasis"><em>before</em></span> you enable
+ LVS. Also ensure that outgoing traffic to these hosts is routed
+ out through the configured public interface.
+ </p><div class="refsect2"><a name="idm140441722121984"></a><h3>Configuration</h3><p>
+ To activate LVS on a CTDB node you must specify the
+ <code class="varname">CTDB_PUBLIC_INTERFACE</code> and
+ <code class="varname">CTDB_LVS_PUBLIC_IP</code> configuration variables.
+ Setting the latter variable also enables the LVS capability on
+ the node at startup.
+ </p><p>
+ Example:
+ </p><pre class="screen">
+CTDB_PUBLIC_INTERFACE=eth1
+CTDB_LVS_PUBLIC_IP=10.1.1.237
+ </pre><p>
+ </p></div></div><div class="refsect1"><a name="idm140441722118800"></a><h2>TRACKING AND RESETTING TCP CONNECTIONS</h2><p>
+ CTDB tracks TCP connections from clients to public IP addresses,
+ on known ports. When an IP address moves from one node to
+ another, all existing TCP connections to that IP address are
+ reset. The node taking over this IP address will also send
+ gratuitous ARPs (for IPv4, or neighbour advertisement, for
+ IPv6). This allows clients to reconnect quickly, rather than
+ waiting for TCP timeouts, which can be very long.
+ </p><p>
+ It is important that established TCP connections do not survive
+ a release and take of a public IP address on the same node.
+ Such connections can get out of sync with sequence and ACK
+ numbers, potentially causing a disruptive ACK storm.
+ </p></div><div class="refsect1"><a name="idm140441722116496"></a><h2>NAT GATEWAY</h2><p>
+ NAT gateway (NATGW) is an optional feature that is used to
+ configure fallback routing for nodes. This allows cluster nodes
+ to connect to external services (e.g. DNS, AD, NIS and LDAP)
+ when they do not host any public addresses (e.g. when they are
+ unhealthy).
+ </p><p>
+ This also applies to node startup because CTDB marks nodes as
+ UNHEALTHY until they have passed a "monitor" event. In this
+ context, NAT gateway helps to avoid a "chicken and egg"
+ situation where a node needs to access an external service to
+ become healthy.
+ </p><p>
+ Another way of solving this type of problem is to assign an
+ extra static IP address to a public interface on every node.
+ This is simpler but it uses an extra IP address per node, while
+ NAT gateway generally uses only one extra IP address.
+ </p><div class="refsect2"><a name="idm140441722113808"></a><h3>Operation</h3><p>
+ One extra NATGW public address is assigned on the public
+ network to each NATGW group. Each NATGW group is a set of
+ nodes in the cluster that shares the same NATGW address to
+ talk to the outside world. Normally there would only be one
+ NATGW group spanning an entire cluster, but in situations
+ where one CTDB cluster spans multiple physical sites it might
+ be useful to have one NATGW group for each site.
+ </p><p>
+ There can be multiple NATGW groups in a cluster but each node
+ can only be member of one NATGW group.
+ </p><p>
+ In each NATGW group, one of the nodes is selected by CTDB to
+ be the NATGW master and the other nodes are consider to be
+ NATGW slaves. NATGW slaves establish a fallback default route
+ to the NATGW master via the private network. When a NATGW
+ slave hosts no public IP addresses then it will use this route
+ for outbound connections. The NATGW master hosts the NATGW
+ public IP address and routes outgoing connections from
+ slave nodes via this IP address. It also establishes a
+ fallback default route.
+ </p></div><div class="refsect2"><a name="idm140441722110800"></a><h3>Configuration</h3><p>
+ NATGW is usually configured similar to the following example configuration:
+ </p><pre class="screen">
+CTDB_NATGW_NODES=/usr/local/etc/ctdb/natgw_nodes
+CTDB_NATGW_PRIVATE_NETWORK=192.168.1.0/24
+CTDB_NATGW_PUBLIC_IP=10.0.0.227/24
+CTDB_NATGW_PUBLIC_IFACE=eth0
+CTDB_NATGW_DEFAULT_GATEWAY=10.0.0.1
+ </pre><p>
+ Normally any node in a NATGW group can act as the NATGW
+ master. Some configurations may have special nodes that lack
+ connectivity to a public network. In such cases, those nodes
+ can be flagged with the "slave-only" option in the
+ <code class="varname">CTDB_NATGW_NODES</code> file to limit the NATGW
+ functionality of those nodes.
+ </p><p>
+ See the <em class="citetitle">NAT GATEWAY</em> section in
+ <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> for more details of
+ NATGW configuration.
+ </p></div><div class="refsect2"><a name="idm140441722106032"></a><h3>Implementation details</h3><p>
+ When the NATGW functionality is used, one of the nodes is
+ selected to act as a NAT gateway for all the other nodes in
+ the group when they need to communicate with the external
+ services. The NATGW master is selected to be a node that is
+ most likely to have usable networks.
+ </p><p>
+ The NATGW master hosts the NATGW public IP address
+ <code class="varname">CTDB_NATGW_PUBLIC_IP</code> on the configured public
+ interfaces <code class="varname">CTDB_NATGW_PUBLIC_IFACE</code> and acts as
+ a router, masquerading outgoing connections from slave nodes
+ via this IP address. If
+ <code class="varname">CTDB_NATGW_DEFAULT_GATEWAY</code> is set then it
+ also establishes a fallback default route to the configured
+ this gateway with a metric of 10. A metric 10 route is used
+ so it can co-exist with other default routes that may be
+ available.
+ </p><p>
+ A NATGW slave establishes its fallback default route to the
+ NATGW master via the private network
+ <code class="varname">CTDB_NATGW_PRIVATE_NETWORK</code>with a metric of 10.
+ This route is used for outbound connections when no other
+ default route is available because the node hosts no public
+ addresses. A metric 10 routes is used so that it can co-exist
+ with other default routes that may be available when the node
+ is hosting public addresses.
+ </p><p>
+ <code class="varname">CTDB_NATGW_STATIC_ROUTES</code> can be used to
+ have NATGW create more specific routes instead of just default
+ routes.
+ </p><p>
+ This is implemented in the <code class="filename">11.natgw</code>
+ eventscript. Please see the eventscript file and the
+ <em class="citetitle">NAT GATEWAY</em> section in
+ <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> for more details.
+ </p></div></div><div class="refsect1"><a name="idm140441722098208"></a><h2>POLICY ROUTING</h2><p>
+ Policy routing is an optional CTDB feature to support complex
+ network topologies. Public addresses may be spread across
+ several different networks (or VLANs) and it may not be possible
+ to route packets from these public addresses via the system's
+ default route. Therefore, CTDB has support for policy routing
+ via the <code class="filename">13.per_ip_routing</code> eventscript.
+ This allows routing to be specified for packets sourced from
+ each public address. The routes are added and removed as CTDB
+ moves public addresses between nodes.
+ </p><div class="refsect2"><a name="idm140441722095984"></a><h3>Configuration variables</h3><p>
+ There are 4 configuration variables related to policy routing:
+ <code class="varname">CTDB_PER_IP_ROUTING_CONF</code>,
+ <code class="varname">CTDB_PER_IP_ROUTING_RULE_PREF</code>,
+ <code class="varname">CTDB_PER_IP_ROUTING_TABLE_ID_LOW</code>,
+ <code class="varname">CTDB_PER_IP_ROUTING_TABLE_ID_HIGH</code>. See the
+ <em class="citetitle">POLICY ROUTING</em> section in
+ <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> for more details.
+ </p></div><div class="refsect2"><a name="idm140441722092016"></a><h3>Configuration</h3><p>
+ The format of each line of
+ <code class="varname">CTDB_PER_IP_ROUTING_CONF</code> is:
+ </p><pre class="screen">
+<public_address> <network> [ <gateway> ]
+ </pre><p>
+ Leading whitespace is ignored and arbitrary whitespace may be
+ used as a separator. Lines that have a "public address" item
+ that doesn't match an actual public address are ignored. This
+ means that comment lines can be added using a leading
+ character such as '#', since this will never match an IP
+ address.
+ </p><p>
+ A line without a gateway indicates a link local route.
+ </p><p>
+ For example, consider the configuration line:
+ </p><pre class="screen">
+ 192.168.1.99 192.168.1.1/24
+ </pre><p>
+ If the corresponding public_addresses line is:
+ </p><pre class="screen">
+ 192.168.1.99/24 eth2,eth3
+ </pre><p>
+ <code class="varname">CTDB_PER_IP_ROUTING_RULE_PREF</code> is 100, and
+ CTDB adds the address to eth2 then the following routing
+ information is added:
+ </p><pre class="screen">
+ ip rule add from 192.168.1.99 pref 100 table ctdb.192.168.1.99
+ ip route add 192.168.1.0/24 dev eth2 table ctdb.192.168.1.99
+ </pre><p>
+ This causes traffic from 192.168.1.1 to 192.168.1.0/24 go via
+ eth2.
+ </p><p>
+ The <span class="command"><strong>ip rule</strong></span> command will show (something
+ like - depending on other public addresses and other routes on
+ the system):
+ </p><pre class="screen">
+ 0: from all lookup local
+ 100: from 192.168.1.99 lookup ctdb.192.168.1.99
+ 32766: from all lookup main
+ 32767: from all lookup default
+ </pre><p>
+ <span class="command"><strong>ip route show table ctdb.192.168.1.99</strong></span> will show:
+ </p><pre class="screen">
+ 192.168.1.0/24 dev eth2 scope link
+ </pre><p>
+ The usual use for a line containing a gateway is to add a
+ default route corresponding to a particular source address.
+ Consider this line of configuration:
+ </p><pre class="screen">
+ 192.168.1.99 0.0.0.0/0 192.168.1.1
+ </pre><p>
+ In the situation described above this will cause an extra
+ routing command to be executed:
+ </p><pre class="screen">
+ ip route add 0.0.0.0/0 via 192.168.1.1 dev eth2 table ctdb.192.168.1.99
+ </pre><p>
+ With both configuration lines, <span class="command"><strong>ip route show table
+ ctdb.192.168.1.99</strong></span> will show:
+ </p><pre class="screen">
+ 192.168.1.0/24 dev eth2 scope link
+ default via 192.168.1.1 dev eth2
+ </pre></div><div class="refsect2"><a name="idm140441722076800"></a><h3>Sample configuration</h3><p>
+ Here is a more complete example configuration.
+ </p><pre class="screen">
+/usr/local/etc/ctdb/public_addresses:
+
+ 192.168.1.98 eth2,eth3
+ 192.168.1.99 eth2,eth3
+
+/usr/local/etc/ctdb/policy_routing:
+
+ 192.168.1.98 192.168.1.0/24
+ 192.168.1.98 192.168.200.0/24 192.168.1.254
+ 192.168.1.98 0.0.0.0/0 192.168.1.1
+ 192.168.1.99 192.168.1.0/24
+ 192.168.1.99 192.168.200.0/24 192.168.1.254
+ 192.168.1.99 0.0.0.0/0 192.168.1.1
+ </pre><p>
+ The routes local packets as expected, the default route is as
+ previously discussed, but packets to 192.168.200.0/24 are
+ routed via the alternate gateway 192.168.1.254.
+ </p></div></div><div class="refsect1"><a name="idm140441722073584"></a><h2>NOTIFICATION SCRIPT</h2><p>
+ When certain state changes occur in CTDB, it can be configured
+ to perform arbitrary actions via a notification script. For
+ example, sending SNMP traps or emails when a node becomes
+ unhealthy or similar.
+ </p><p>
+ This is activated by setting the
+ <code class="varname">CTDB_NOTIFY_SCRIPT</code> configuration variable.
+ The specified script must be executable.
+ </p><p>
+ Use of the provided <code class="filename">/usr/local/etc/ctdb/notify.sh</code>
+ script is recommended. It executes files in
+ <code class="filename">/usr/local/etc/ctdb/notify.d/</code>.
+ </p><p>
+ CTDB currently generates notifications after CTDB changes to
+ these states:
+ </p><table border="0" summary="Simple list" class="simplelist"><tr><td>init</td></tr><tr><td>setup</td></tr><tr><td>startup</td></tr><tr><td>healthy</td></tr><tr><td>unhealthy</td></tr></table></div><div class="refsect1"><a name="idm140441722066640"></a><h2>DEBUG LEVELS</h2><p>
+ Valid values for DEBUGLEVEL are:
+ </p><table border="0" summary="Simple list" class="simplelist"><tr><td>ERR (0)</td></tr><tr><td>WARNING (1)</td></tr><tr><td>NOTICE (2)</td></tr><tr><td>INFO (3)</td></tr><tr><td>DEBUG (4)</td></tr></table></div><div class="refsect1"><a name="idm140441722062944"></a><h2>REMOTE CLUSTER NODES</h2><p>
+It is possible to have a CTDB cluster that spans across a WAN link.
+For example where you have a CTDB cluster in your datacentre but you also
+want to have one additional CTDB node located at a remote branch site.
+This is similar to how a WAN accelerator works but with the difference
+that while a WAN-accelerator often acts as a Proxy or a MitM, in
+the ctdb remote cluster node configuration the Samba instance at the remote site
+IS the genuine server, not a proxy and not a MitM, and thus provides 100%
+correct CIFS semantics to clients.
+ </p><p>
+ See the cluster as one single multihomed samba server where one of
+ the NICs (the remote node) is very far away.
+ </p><p>
+ NOTE: This does require that the cluster filesystem you use can cope
+ with WAN-link latencies. Not all cluster filesystems can handle
+ WAN-link latencies! Whether this will provide very good WAN-accelerator
+ performance or it will perform very poorly depends entirely
+ on how optimized your cluster filesystem is in handling high latency
+ for data and metadata operations.
+ </p><p>
+ To activate a node as being a remote cluster node you need to set
+ the following two parameters in /etc/sysconfig/ctdb for the remote node:
+ </p><pre class="screen">
+CTDB_CAPABILITY_LMASTER=no
+CTDB_CAPABILITY_RECMASTER=no
+ </pre><p>
+ </p><p>
+ Verify with the command "ctdb getcapabilities" that that node no longer
+ has the recmaster or the lmaster capabilities.
+ </p></div><div class="refsect1"><a name="idm140441722058240"></a><h2>SEE ALSO</h2><p>
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdbd_wrapper</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ltdbtool</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">onnode</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ping_pong</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdb-statistics</span>(7)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span>,
+
+ <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
+ </p></div></div></body></html>
--- /dev/null
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdbd</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdbd.1"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdbd — The CTDB cluster daemon</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ctdbd</code> [<em class="replaceable"><code>OPTION</code></em>...]</p></div></div><div class="refsect1"><a name="idm139840524087616"></a><h2>DESCRIPTION</h2><p>
+ ctdbd is the main CTDB daemon.
+ </p><p>
+ Note that ctdbd is not usually invoked directly. It is invoked
+ via <span class="citerefentry"><span class="refentrytitle">ctdbd_wrapper</span>(1)</span> or via the initscript.
+ </p><p>
+ See <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for an overview of CTDB.
+ </p></div><div class="refsect1"><a name="idm139840525514688"></a><h2>GENERAL OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-d, --debug=<em class="parameter"><code>DEBUGLEVEL</code></em></span></dt><dd><p>
+ This option sets the debug level to DEBUGLEVEL, which
+ controls what will be written by the logging
+ subsystem. The default is 2.
+ </p><p>
+ See the <em class="citetitle">DEBUG LEVELS</em> section in
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
+ information.
+ </p></dd><dt><span class="term">--dbdir=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
+ DIRECTORY on local storage where ctdbd keeps a local copy of
+ TDB databases. This directory is local for each node and
+ should not be stored on the shared cluster filesystem.
+ </p><p>
+ Defaults to <code class="filename">/usr/local/var/lib/ctdb</code>.
+ </p></dd><dt><span class="term">--dbdir-persistent=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
+ DIRECTORY on local storage where ctdbd keeps a local copy of
+ persistent TDB databases. This directory is local for each
+ node and should not be stored on the shared cluster
+ filesystem.
+ </p><p>
+ Defaults to <code class="filename">/usr/local/var/lib/ctdb/persistent</code>.
+ </p></dd><dt><span class="term">--dbdir-state=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
+ DIRECTORY on local storage where ctdbd keep internal state
+ TDB files. This directory is local for each node and
+ should not be stored on the shared cluster filesystem.
+ </p><p>
+ Defaults to <code class="filename">/usr/local/var/lib/ctdb/state</code>.
+ </p></dd><dt><span class="term">--event-script-dir=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
+ DIRECTORY where the CTDB event scripts are stored. See the
+ <em class="citetitle">EVENT SCRIPTS</em> section in
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more information.
+ </p><p>
+ Default is <code class="envar">CTDB_BASE</code>/events.d, so usually
+ <code class="filename">/usr/local/etc/ctdb/events.d</code>, which is part of
+ the CTDB installation.
+ </p></dd><dt><span class="term">--listen=<em class="parameter"><code>IPADDR</code></em></span></dt><dd><p>
+ IPADDR is the private IP address that ctdbd will bind to.
+ </p><p>
+ By default ctdbd will select the first address from the
+ nodes list that in can bind to. See also
+ <em class="citetitle">--nlist</em>.
+ </p><p>
+ This option is only required when automatic address
+ detection can not be used. This can be the case when
+ running multiple ctdbd daemons/nodes on the same physical
+ host (usually for testing), using InfiniBand for the
+ private network or on Linux when sysctl
+ net.ipv4.ip_nonlocal_bind=1.
+ </p></dd><dt><span class="term">--logging=<em class="parameter"><code>STRING</code></em></span></dt><dd><p>
+ STRING specifies where ctdbd will write its log. The
+ default is
+ file:<code class="filename">/usr/local/var/log/log.ctdb</code>.
+ </p><p>
+ Valid values are:
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">file:<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ FILENAME where ctdbd will write its log. This is usually
+ <code class="filename">/usr/local/var/log/log.ctdb</code>.
+ </p></dd><dt><span class="term">syslog[<span class="optional">:<em class="parameter"><code>METHOD</code></em></span>]</span></dt><dd><p>
+ CTDB will log to syslog. By default this will use
+ the syslog(3) API.
+ </p><p>
+ Under heavy loads syslog(3) can block if the syslog
+ daemon processes messages too slowly. This can
+ cause CTDB to block when logging.
+ </p><p>
+ If METHOD is specified then it specifies an
+ extension that causes logging to be done in a
+ non-blocking mode. Note that <span class="emphasis"><em>this may
+ cause messages to be dropped</em></span>. METHOD
+ must be one of:
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">nonblocking</span></dt><dd><p>
+ CTDB will log to syslog via
+ <code class="filename">/dev/log</code> in non-blocking
+ mode.
+ </p></dd><dt><span class="term">udp</span></dt><dd><p>
+ CTDB will log to syslog via UDP to
+ localhost:514. The syslog daemon must be
+ configured to listen on (at least)
+ localhost:514. Most syslog daemons will log
+ the messages with hostname "localhost" - this
+ is a limitation of the implementation, for
+ compatibility with more syslog daemons.
+ </p></dd><dt><span class="term">udp-rfc5424</span></dt><dd><p>
+ As with "udp" but messages are sent in RFC5424
+ format. This method will log the correct
+ hostname but is not as widely implemented in
+ syslog daemons.
+ </p></dd></dl></div></dd></dl></div></dd><dt><span class="term">--lvs</span></dt><dd><p>
+ This option is used to activate the LVS capability on a CTDB
+ node. Please see the <em class="citetitle">LVS</em> section in
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
+ information.
+ </p></dd><dt><span class="term">--max-persistent-check-errors=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
+ NUM specifies the maximum number of health check failures
+ allowed for persistent databases during startup.
+ </p><p>
+ The default value is 0. Setting this to non-zero allows a
+ node with unhealthy persistent databases to startup and
+ join the cluster as long as there is another node with
+ healthy persistent databases.
+ </p></dd><dt><span class="term">--nlist=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ FILENAME containing a list of the private IP addresses, one
+ per line, for each node in the cluster. This file
+ <span class="emphasis"><em>must be the same on each node</em></span> in the
+ cluster.
+ </p><p>
+ Default is <code class="envar">CTDB_BASE</code>/nodes, so usually
+ <code class="filename">/usr/local/etc/ctdb/nodes</code>.
+ </p></dd><dt><span class="term">--no-lmaster</span></dt><dd><p>
+ This argument specifies that this node can NOT become an lmaster
+ for records in the database. This means that it will never show up
+ in the vnnmap. This feature is primarily used for making a cluster
+ span across a WAN link and use CTDB as a WAN-accelerator.
+ </p><p>
+ Please see the <em class="citetitle">REMOTE CLUSTER NODES</em>
+ section in <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
+ information.
+ </p></dd><dt><span class="term">--no-recmaster</span></dt><dd><p>
+ This argument specifies that this node can NOT become a recmaster
+ for the database. This feature is primarily used for making a cluster
+ span across a WAN link and use CTDB as a WAN-accelerator.
+ </p><p>
+ Please see the <em class="citetitle">REMOTE CLUSTER NODES</em>
+ section in <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
+ information.
+ </p></dd><dt><span class="term">--notification-script=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ FILENAME specifying a script to be invoked by ctdbd when
+ certain state changes occur.
+ </p><p>
+ This file is usually
+ <code class="filename">/usr/local/etc/ctdb/notify.sh</code>.
+ </p><p>
+ Please see the <em class="citetitle">NOTIFICATION SCRIPT</em>
+ section in <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
+ information.
+ </p></dd><dt><span class="term">--pidfile=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ FILENAME for file containing process ID of main CTDB
+ daemon. This file is automatically created and removed by
+ CTDB.
+ </p><p>
+ The default is to not create a PID file.
+ </p></dd><dt><span class="term">--public_addresses=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ FILENAME specifying a file containing the public IP
+ addresses to use on the cluster when CTDB should use IP
+ takeover. This file contains a list of IP addresses,
+ netmasks and interfaces. CTDB will distribute these public
+ IP addresses appropriately across the available nodes.
+ </p><p>
+ The IP addresses specified in this file can differ across
+ nodes.
+ </p><p>
+ This is usually the file
+ <code class="filename">/usr/local/etc/ctdb/public_addresses</code>
+ </p></dd><dt><span class="term">--public-interface=<em class="parameter"><code>INTERFACE</code></em></span></dt><dd><p>
+ INTERFACE on which to attach public IP addresses or on which
+ to attach the single-public-ip when used.
+ </p><p>
+ When using public IP addresses, this is only required if
+ interfaces are not explicitly specified in the public
+ addresses file.
+ </p></dd><dt><span class="term">--reclock=<em class="parameter"><code>FILE</code></em></span></dt><dd><p>
+ FILE is the name of the recovery lock file, stored in
+ <span class="emphasis"><em>shared storage</em></span>, that CTDB uses to
+ prevent split brains.
+ </p><p>
+ For information about the recovery lock please see the
+ <em class="citetitle">RECOVERY LOCK</em> section in
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
+ </p></dd><dt><span class="term">--single-public-ip=<em class="parameter"><code>IPADDR</code></em></span></dt><dd><p>
+ IPADDR specifies the single IP that CTDB will use in
+ conjunction with LVS.
+ </p><p>
+ Please see the <em class="citetitle">LVS</em> section in
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
+ information.
+ </p></dd><dt><span class="term">--start-as-disabled</span></dt><dd><p>
+ This makes ctdbd start in the DISABLED state.
+ </p><p>
+ To allow the node to host public IP addresses and
+ services, it must be manually enabled using the
+ <span class="command"><strong>ctdb enable</strong></span> command.
+ </p><p>
+ Please see the <em class="citetitle">NODE STATES</em> section
+ in <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
+ information about the DISABLED state.
+ </p></dd><dt><span class="term">--start-as-stopped</span></dt><dd><p>
+ This makes ctdbd start in the STOPPED state.
+ </p><p>
+ To allow the node to take part in the cluster it must be
+ manually continued with the the <span class="command"><strong>ctdb
+ enable</strong></span> command.
+ </p><p>
+ Please see the <em class="citetitle">NODE STATES</em> section
+ in <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
+ information about the STOPPED state.
+ </p></dd><dt><span class="term">--transport=tcp|infiniband</span></dt><dd><p>
+ This option specifies which transport to use for ctdbd
+ internode communications. The default is "tcp".
+ </p><p>
+ The "infiniband" support is not regularly tested.
+ </p></dd><dt><span class="term">-?, --help</span></dt><dd><p>
+ Display a summary of options.
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm139840521704176"></a><h2>DEBUGGING OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-i, --interactive</span></dt><dd><p>
+ Enable interactive mode. This will make ctdbd run in the
+ foreground and not detach from the terminal. By default
+ ctdbd will detach itself and run in the background as a
+ daemon.
+ </p></dd><dt><span class="term">--nopublicipcheck</span></dt><dd><p>
+ This option is used when testing with multiple local
+ daemons on a single machine. It disables checks related
+ to public IP addresses.
+ </p></dd><dt><span class="term">--nosetsched</span></dt><dd><p>
+ This is a debugging option. This option is only used when
+ debugging ctdbd.
+ </p><p>
+ Normally ctdbd will change its scheduler to run as a
+ real-time process. This is the default mode for a normal
+ ctdbd operation to gurarantee that ctdbd always gets the CPU
+ cycles that it needs.
+ </p><p>
+ This option is used to tell ctdbd to
+ <span class="emphasis"><em>not</em></span> run as a real-time process and
+ instead run ctdbd as a normal userspace process. This is
+ useful for debugging and when you want to run ctdbd under
+ valgrind or gdb. (You don't want to attach valgrind or gdb
+ to a real-time process.)
+ </p></dd><dt><span class="term">--socket=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ FILENAME specifies the name of the Unix domain socket that
+ ctdbd will create. This socket is used by local clients to
+ communicate with ctdbd.
+ </p><p>
+ The default is <code class="filename">/usr/local/var/run/ctdb/ctdbd.socket</code>.
+ You only need to use this option if you plan to run
+ multiple ctdbd daemons on the same physical host, usually
+ for testing.
+ </p></dd><dt><span class="term">--script-log-level=<em class="parameter"><code>DEBUGLEVEL</code></em></span></dt><dd><p>
+ This option sets the debug level of event script output to
+ DEBUGLEVEL. The default is ERR (0).
+ </p><p>
+ See the <em class="citetitle">DEBUG LEVELS</em> section in
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
+ information.
+ </p></dd><dt><span class="term">--sloppy-start</span></dt><dd><p>
+ This is debugging option. This speeds up the initial
+ recovery during startup at the expense of some consistency
+ checking. <span class="emphasis"><em>Don't use this option in
+ production</em></span>.
+ </p></dd><dt><span class="term">--torture</span></dt><dd><p>
+ This option is only used for development and testing of
+ CTDB. It adds artificial errors and failures to the
+ common codepaths in ctdbd to verify that ctdbd can recover
+ correctly from failures.
+ </p><p>
+ <span class="emphasis"><em>Do not use this option</em></span> unless you are
+ developing and testing new functionality in CTDB.
+ </p></dd><dt><span class="term">--valgrinding</span></dt><dd><p>
+ This is a debugging option. This option is only used when
+ debugging ctdbd. This enables additional debugging
+ capabilities and implies --nosetsched.
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm139840521682688"></a><h2>SEE ALSO</h2><p>
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdbd_wrapper</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">onnode</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span>,
+
+ <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
+ </p></div></div></body></html>
--- /dev/null
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdbd.conf</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdbd.conf.5"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdbd.conf — CTDB daemon configuration file</p></div><div class="refsect1"><a name="idm140222705806272"></a><h2>DESCRIPTION</h2><p>
+ This file contains CTDB configuration variables that are affect
+ the operation of CTDB. The default location of this file is
+ <code class="filename">/usr/local/etc/ctdb/ctdbd.conf</code>.
+ </p><p>
+ This file is a shell script (see
+ <span class="citerefentry"><span class="refentrytitle">sh</span>(1)</span>) but is usually limited
+ to simple variable assignments and shell-style comments.
+ </p><p>
+ CTDB configuration variables are grouped into several categories below.
+ </p><p>
+ Variables defined in this document can also be set in a
+ distribution-specific configuration file such as
+ <code class="filename">/etc/sysconfig/ctdb</code> (Red Hat) or
+ <code class="filename">/etc/default/ctdb</code> (Debian). However, these
+ files should be reserved for variables used by the initscript.
+ A historical alternative is
+ <code class="filename">/usr/local/etc/ctdb/sysconfig/ctdb</code> - this is
+ deprecated.
+ </p></div><div class="refsect1"><a name="idm140222708394512"></a><h2>
+ INITSCRIPT CONFIGURATION
+ </h2><p>
+ Some options must be available to the initscript so they need to
+ be set in the distribution-specific initscript configuration,
+ such as <code class="filename">/etc/sysconfig/ctdb</code> or
+ <code class="filename">/etc/default/ctdb</code>.
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_PIDFILE=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ FILENAME is the name of the file used to contain the
+ process ID (PID) of the main CTDB daemon when it is
+ running. This is passed from the initscript to
+ <span class="citerefentry"><span class="refentrytitle">ctdbd_wrapper</span>(1)</span>.
+ </p><p>
+ Default is <code class="filename">/usr/local/var/run/ctdb/ctdbd.pid</code>.
+ Corresponds to <code class="option">--pidfile</code>.
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm140222705452464"></a><h2>
+ GLOBAL CONFIGURATION
+ </h2><p>
+ These options may be used in the initscripts, daemon and
+ scripts.
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_BASE=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
+ DIRECTORY containing CTDB scripts and configuration files.
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm140222710281056"></a><h2>
+ DAEMON CONFIGURATION
+ </h2><p>
+ Variables in this section are processed by
+ <span class="citerefentry"><span class="refentrytitle">ctdbd_wrapper</span>(1)</span> and are converted into
+ command-line arguments to
+ <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>. Correspondence with
+ <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span> options is shown for
+ each variable. The the documentation for the relevant options
+ for more details.
+ </p><p>
+ Many of these variables are also used by event scripts.
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_CAPABILITY_LMASTER=yes|no</span></dt><dd><p>
+ Defaults to yes. Corresponds to <code class="option">--no-lmaster</code>.
+ </p></dd><dt><span class="term">CTDB_CAPABILITY_RECMASTER=yes|no</span></dt><dd><p>
+ Defaults to yes. Corresponds to
+ <code class="option">--no-recmaster</code>.
+ </p></dd><dt><span class="term">CTDB_DBDIR=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
+ Defaults to <code class="filename">/usr/local/var/lib/ctdb</code>.
+ </p><p>
+ Apart from a DIRECTORY, this can take a special value of
+ the form
+ <code class="option">tmpfs</code>[<span class="optional">:<em class="parameter"><code>OPTIONS</code></em></span>].
+ OPTIONS is a comma-separated list of any permissible
+ options to the tmpfs filesystem. The only pre-specified
+ default is <code class="option">mode=700</code>, which can
+ overriden by specifying <code class="option">mode</code> in
+ OPTIONS. It probably makes sense to specify a maximum
+ <code class="option">size</code>.
+ </p><p>
+ Corresponds to <code class="option">--dbdir</code>.
+ </p></dd><dt><span class="term">CTDB_DBDIR_PERSISTENT=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
+ Defaults to <code class="filename">/usr/local/var/lib/ctdb/persistent</code>.
+ </p><p>
+ Corresponds to <code class="option">--dbdir-persistent</code>.
+ </p></dd><dt><span class="term">CTDB_DBDIR_STATE=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
+ Defaults to <code class="filename">/usr/local/var/lib/ctdb/state</code>.
+ </p><p>
+ Corresponds to <code class="option">--dbdir-state</code>.
+ </p></dd><dt><span class="term">CTDB_DEBUGLEVEL=<em class="parameter"><code>DEBUGLEVEL</code></em></span></dt><dd><p>
+ Default is NOTICE (2). Corresponds to <code class="option">-d</code> or
+ <code class="option">--debug</code>.
+ </p></dd><dt><span class="term">CTDB_EVENT_SCRIPT_DIR=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
+ Default is <code class="varname">CTDB_BASE</code>/events.d, so usually
+ <code class="filename">/usr/local/etc/ctdb/events.d</code>. Corresponds to
+ <code class="option">--event-script-dir</code>.
+ </p></dd><dt><span class="term">CTDB_LOGGING=<em class="parameter"><code>STRING</code></em></span></dt><dd><p>
+ STRING specifies where ctdbd will write its log. The
+ default is
+ file:<code class="filename">/usr/local/var/log/log.ctdb</code>.
+ Corresponds to <code class="option">--logging</code>.
+ </p><p>
+ Valid values are:
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">file:<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ FILENAME where ctdbd will write its log. This is usually
+ <code class="filename">/usr/local/var/log/log.ctdb</code>.
+ </p></dd><dt><span class="term">syslog[<span class="optional">:<em class="parameter"><code>METHOD</code></em></span>]</span></dt><dd><p>
+ CTDB will log to syslog. By default this will use
+ the syslog(3) API.
+ </p><p>
+ If METHOD is specified then it specifies an
+ extension that causes logging to be done in a
+ non-blocking fashion. This can be useful under
+ heavy loads that might cause the syslog daemon to
+ dequeue messages too slowly, which would otherwise
+ cause CTDB to block when logging. METHOD must be
+ one of:
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">nonblocking</span></dt><dd><p>
+ CTDB will log to syslog via
+ <code class="filename">/dev/log</code> in non-blocking
+ mode.
+ </p></dd><dt><span class="term">udp</span></dt><dd><p>
+ CTDB will log to syslog via UDP to
+ localhost:514. The syslog daemon must be
+ configured to listen on (at least)
+ localhost:514. Most implementations will log
+ the messages against hostname "localhost" -
+ this is a limit of the implementation for
+ compatibility with more syslog daemon
+ implementations.
+ </p></dd><dt><span class="term">udp-rfc5424</span></dt><dd><p>
+ As with "udp" but messages are sent in RFC5424
+ format. This method will log the correct
+ hostname but is not as widely implemented in
+ syslog daemons.
+ </p></dd></dl></div></dd></dl></div></dd><dt><span class="term">CTDB_LVS_PUBLIC_IP=<em class="parameter"><code>IPADDR</code></em></span></dt><dd><p>
+ No default. Corresponds to "<code class="option">--lvs</code>
+ <code class="option">--single-public-ip IPADDR"</code>.
+ </p></dd><dt><span class="term">CTDB_NODES=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ Default is <code class="varname">CTDB_BASE</code>/nodes, so usually
+ <code class="filename">/usr/local/etc/ctdb/nodes</code>. Corresponds to
+ <code class="option">--nlist</code>.
+ </p></dd><dt><span class="term">CTDB_NOTIFY_SCRIPT=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ No default, usually
+ <code class="filename">/usr/local/etc/ctdb/notify.sh</code>. Corresponds to
+ <code class="option">--notification-script</code>.
+ </p></dd><dt><span class="term">CTDB_MAX_PERSISTENT_CHECK_ERRORS=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
+ Default 0. Corresponds to
+ <code class="option">--max-persistent-check-errors</code>.
+ </p></dd><dt><span class="term">CTDB_NODE_ADDRESS=<em class="parameter"><code>IPADDR</code></em></span></dt><dd><p>
+ IPADDR is the private IP address that ctdbd will bind to.
+ Corresponds to <code class="option">--listen</code>.
+ </p><p>
+ By default ctdbd will select the first address from the
+ nodes list that in can bind to. See also
+ <em class="citetitle">CTDB_NODES</em>.
+ </p><p>
+ This option is only required when automatic address
+ detection can not be used. This can be the case when
+ running multiple ctdbd daemons/nodes on the same physical
+ host (usually for testing), using InfiniBand for the
+ private network or on Linux when sysctl
+ net.ipv4.ip_nonlocal_bind=1.
+ </p></dd><dt><span class="term">CTDB_PUBLIC_ADDRESSES=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ No default, usually
+ <code class="filename">/usr/local/etc/ctdb/public_addresses</code>.
+ Corresponds to <code class="option">--public-addresses</code>.
+ </p></dd><dt><span class="term">CTDB_PUBLIC_INTERFACE=<em class="parameter"><code>INTERFACE</code></em></span></dt><dd><p>
+ No default. Corresponds to
+ <code class="option">--public-interface</code>.
+ </p></dd><dt><span class="term">CTDB_RECOVERY_LOCK=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ Defaults to
+ <code class="filename">/some/place/on/shared/storage</code>, which
+ should be change to a useful value. Corresponds to
+ <code class="option">--reclock</code>.
+ </p><p>
+ For information about the recovery lock please see the
+ <em class="citetitle">RECOVERY LOCK</em> section in
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
+ </p></dd><dt><span class="term">CTDB_SCRIPT_LOG_LEVEL=<em class="parameter"><code>DEBUGLEVEL</code></em></span></dt><dd><p>
+ Defaults to ERR (0). Corresponds to
+ <code class="option">--script-log-level</code>.
+ </p></dd><dt><span class="term">CTDB_SOCKET=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ Defaults to <code class="filename">/usr/local/var/run/ctdb/ctdbd.socket</code>.
+ Corresponds to <code class="option">--socket</code>.
+ </p><p>
+ If you change this then you probably want to set this in
+ root's environment (perhaps in a file in
+ <code class="filename">/etc/profile.d</code>) so that you can use
+ the <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span> command in a
+ straightforward manner.
+ </p></dd><dt><span class="term">CTDB_START_AS_DISABLED=yes|no</span></dt><dd><p>
+ Default is no. Corresponds to
+ <code class="option">--start-as-disabled</code>.
+ </p></dd><dt><span class="term">CTDB_START_AS_STOPPED=yes|no</span></dt><dd><p>
+ Default is no. Corresponds to
+ <code class="option">--start-as-stopped</code>.
+ </p></dd><dt><span class="term">CTDB_TRANSPORT=tcp|infiniband</span></dt><dd><p>
+ Defaults to tcp. Corresponds to
+ <code class="option">--transport</code>.
+ </p></dd></dl></div><p>
+ While the following variables do not translate into daemon
+ options they are used by
+ <span class="citerefentry"><span class="refentrytitle">ctdbd_wrapper</span>(1)</span> when starting and
+ stopping <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>.
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_SHUTDOWN_TIMEOUT=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
+ NUM is the number of seconds to wait for
+ <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span> to shut down
+ gracefully before giving up and killing it.
+ </p><p>
+ Defaults is 30.
+ </p></dd><dt><span class="term">CTDB_STARTUP_TIMEOUT=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
+ NUM is the number of seconds to wait for
+ <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span> complete early
+ initialisation up to a point where it is unlikely to
+ abort. If <span class="command"><strong>ctdbd</strong></span> doesn't complete the
+ "setup" event before this timeout then it is killed.
+ </p><p>
+ Defaults is 10.
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm140222704871744"></a><h2>NETWORK CONFIGURATION</h2><div class="refsect2"><a name="idm140222704871104"></a><h3>NAT GATEWAY</h3><p>
+ NAT gateway is used to configure fallback routing for nodes
+ when they do not host any public IP addresses. For example,
+ it allows unhealthy nodes to reliably communicate with
+ external infrastructure. One node in a NAT gateway group will
+ be designated as the NAT gateway master node and other (slave)
+ nodes will be configured with fallback routes via the NAT
+ gateway master node. For more information, see the
+ <em class="citetitle">NAT GATEWAY</em> section in
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_NATGW_DEFAULT_GATEWAY=<em class="parameter"><code>IPADDR</code></em></span></dt><dd><p>
+ IPADDR is an alternate network gateway to use on the NAT
+ gateway master node. If set, a fallback default route
+ is added via this network gateway.
+ </p><p>
+ No default. Setting this variable is optional - if not
+ set that no route is created on the NAT gateway master
+ node.
+ </p></dd><dt><span class="term">CTDB_NATGW_NODES=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ FILENAME contains the list of nodes that belong to the
+ same NAT gateway group.
+ </p><p>
+ File format:
+ </p><pre class="screen">
+<em class="parameter"><code>IPADDR</code></em> [<span class="optional">slave-only</span>]
+ </pre><p>
+ </p><p>
+ IPADDR is the private IP address of each node in the NAT
+ gateway group.
+ </p><p>
+ If "slave-only" is specified then the corresponding node
+ can not be the NAT gateway master node. In this case
+ <code class="varname">CTDB_NATGW_PUBLIC_IFACE</code> and
+ <code class="varname">CTDB_NATGW_PUBLIC_IP</code> are optional and
+ unused.
+ </p><p>
+ No default, usually
+ <code class="filename">/usr/local/etc/ctdb/natgw_nodes</code> when enabled.
+ </p></dd><dt><span class="term">CTDB_NATGW_PRIVATE_NETWORK=<em class="parameter"><code>IPADDR/MASK</code></em></span></dt><dd><p>
+ IPADDR/MASK is the private sub-network that is
+ internally routed via the NAT gateway master node. This
+ is usually the private network that is used for node
+ addresses.
+ </p><p>
+ No default.
+ </p></dd><dt><span class="term">CTDB_NATGW_PUBLIC_IFACE=<em class="parameter"><code>IFACE</code></em></span></dt><dd><p>
+ IFACE is the network interface on which the
+ CTDB_NATGW_PUBLIC_IP will be configured.
+ </p><p>
+ No default.
+ </p></dd><dt><span class="term">CTDB_NATGW_PUBLIC_IP=<em class="parameter"><code>IPADDR/MASK</code></em></span></dt><dd><p>
+ IPADDR/MASK indicates the IP address that is used for
+ outgoing traffic (originating from
+ CTDB_NATGW_PRIVATE_NETWORK) on the NAT gateway master
+ node. This <span class="emphasis"><em>must not</em></span> be a
+ configured public IP address.
+ </p><p>
+ No default.
+ </p></dd><dt><span class="term">CTDB_NATGW_STATIC_ROUTES=<em class="parameter"><code>IPADDR/MASK[@GATEWAY]</code></em> ...</span></dt><dd><p>
+ Each IPADDR/MASK identifies a network or host to which
+ NATGW should create a fallback route, instead of
+ creating a single default route. This can be used when
+ there is already a default route, via an interface that
+ can not reach required infrastructure, that overrides
+ the NAT gateway default route.
+ </p><p>
+ If GATEWAY is specified then the corresponding route on
+ the NATGW master node will be via GATEWAY. Such routes
+ are created even if
+ <code class="varname">CTDB_NATGW_DEFAULT_GATEWAY</code> is not
+ specified. If GATEWAY is not specified for some
+ networks then routes are only created on the NATGW
+ master node for those networks if
+ <code class="varname">CTDB_NATGW_DEFAULT_GATEWAY</code> is
+ specified.
+ </p><p>
+ This should be used with care to avoid causing traffic
+ to unnecessarily double-hop through the NAT gateway
+ master, even when a node is hosting public IP addresses.
+ Each specified network or host should probably have a
+ corresponding automatically created link route or static
+ route to avoid this.
+ </p><p>
+ No default.
+ </p></dd></dl></div><div class="refsect3"><a name="idm140222704844880"></a><h4>Example</h4><pre class="screen">
+CTDB_NATGW_NODES=/usr/local/etc/ctdb/natgw_nodes
+CTDB_NATGW_PRIVATE_NETWORK=192.168.1.0/24
+CTDB_NATGW_DEFAULT_GATEWAY=10.0.0.1
+CTDB_NATGW_PUBLIC_IP=10.0.0.227/24
+CTDB_NATGW_PUBLIC_IFACE=eth0
+ </pre><p>
+ A variation that ensures that infrastructure (ADS, DNS, ...)
+ directly attached to the public network (10.0.0.0/24) is
+ always reachable would look like this:
+ </p><pre class="screen">
+CTDB_NATGW_NODES=/usr/local/etc/ctdb/natgw_nodes
+CTDB_NATGW_PRIVATE_NETWORK=192.168.1.0/24
+CTDB_NATGW_PUBLIC_IP=10.0.0.227/24
+CTDB_NATGW_PUBLIC_IFACE=eth0
+CTDB_NATGW_STATIC_ROUTES=10.0.0.0/24
+ </pre><p>
+ Note that <code class="varname">CTDB_NATGW_DEFAULT_GATEWAY</code> is
+ not specified.
+ </p></div></div><div class="refsect2"><a name="idm140222704840976"></a><h3>POLICY ROUTING</h3><p>
+ A node running CTDB may be a component of a complex network
+ topology. In particular, public addresses may be spread
+ across several different networks (or VLANs) and it may not be
+ possible to route packets from these public addresses via the
+ system's default route. Therefore, CTDB has support for
+ policy routing via the <code class="filename">13.per_ip_routing</code>
+ eventscript. This allows routing to be specified for packets
+ sourced from each public address. The routes are added and
+ removed as CTDB moves public addresses between nodes.
+ </p><p>
+ For more information, see the <em class="citetitle">POLICY
+ ROUTING</em> section in
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_PER_IP_ROUTING_CONF=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ FILENAME contains elements for constructing the desired
+ routes for each source address.
+ </p><p>
+ The special FILENAME value
+ <code class="constant">__auto_link_local__</code> indicates that no
+ configuration file is provided and that CTDB should
+ generate reasonable link-local routes for each public IP
+ address.
+ </p><p>
+ File format:
+ </p><pre class="screen">
+<em class="parameter"><code>IPADDR</code></em> <em class="parameter"><code>DEST-IPADDR/MASK</code></em> [<span class="optional"><em class="parameter"><code>GATEWAY-IPADDR</code></em></span>]
+ </pre><p>
+ </p><p>
+ No default, usually
+ <code class="filename">/usr/local/etc/ctdb/policy_routing</code> when enabled.
+ </p></dd><dt><span class="term">CTDB_PER_IP_ROUTING_RULE_PREF=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
+ NUM sets the priority (or preference) for the routing
+ rules that are added by CTDB.
+ </p><p>
+ This should be (strictly) greater than 0 and (strictly)
+ less than 32766. A priority of 100 is recommended, unless
+ this conflicts with a priority already in use on the
+ system. See
+ <span class="citerefentry"><span class="refentrytitle">ip</span>(8)</span>, for more details.
+ </p></dd><dt><span class="term">
+ CTDB_PER_IP_ROUTING_TABLE_ID_LOW=<em class="parameter"><code>LOW-NUM</code></em>,
+ CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=<em class="parameter"><code>HIGH-NUM</code></em>
+ </span></dt><dd><p>
+ CTDB determines a unique routing table number to use for
+ the routing related to each public address. LOW-NUM and
+ HIGH-NUM indicate the minimum and maximum routing table
+ numbers that are used.
+ </p><p>
+ <span class="citerefentry"><span class="refentrytitle">ip</span>(8)</span> uses some
+ reserved routing table numbers below 255. Therefore,
+ CTDB_PER_IP_ROUTING_TABLE_ID_LOW should be (strictly)
+ greater than 255.
+ </p><p>
+ CTDB uses the standard file
+ <code class="filename">/etc/iproute2/rt_tables</code> to maintain
+ a mapping between the routing table numbers and labels.
+ The label for a public address
+ <em class="replaceable"><code>ADDR</code></em> will look like
+ ctdb.<em class="replaceable"><code>addr</code></em>. This means that
+ the associated rules and routes are easy to read (and
+ manipulate).
+ </p><p>
+ No default, usually 1000 and 9000.
+ </p></dd></dl></div><div class="refsect3"><a name="idm140222704819040"></a><h4>Example</h4><pre class="screen">
+CTDB_PER_IP_ROUTING_CONF=/usr/local/etc/ctdb/policy_routing
+CTDB_PER_IP_ROUTING_RULE_PREF=100
+CTDB_PER_IP_ROUTING_TABLE_ID_LOW=1000
+CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000
+ </pre></div></div><div class="refsect2"><a name="idm140222704817328"></a><h3>MISCELLANEOUS NETWORK CONFIGURATION</h3><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_PARTIALLY_ONLINE_INTERFACES=yes|no</span></dt><dd><p>
+ Whether one or more offline interfaces should cause a
+ monitor event to fail if there are other interfaces that
+ are up. If this is "yes" and a node has some interfaces
+ that are down then <span class="command"><strong>ctdb status</strong></span> will
+ display the node as "PARTIALLYONLINE".
+ </p><p>
+ Note that CTDB_PARTIALLY_ONLINE_INTERFACES=yes is
+ incompatible with NAT gateway, since NAT gateway relies
+ on the interface configured by CTDB_NATGW_PUBLIC_IFACE
+ to be up.
+ </p><p>
+ Default is "no".
+ </p></dd></dl></div></div></div><div class="refsect1"><a name="idm140222704812656"></a><h2>SERVICE CONFIGURATION</h2><p>
+ CTDB can be configured to manage and/or monitor various NAS (and
+ other) services via its eventscripts.
+ </p><p>
+ In the simplest case CTDB will manage a service. This means the
+ service will be started and stopped along with CTDB, CTDB will
+ monitor the service and CTDB will do any required
+ reconfiguration of the service when public IP addresses are
+ failed over.
+ </p><div class="refsect2"><a name="idm140222704810800"></a><h3>SAMBA</h3><div class="refsect3"><a name="idm140222704810160"></a><h4>Eventscripts</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">49.winbind</code></td></tr><tr><td><code class="filename">50.samba</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_SAMBA=yes|no</span></dt><dd><p>
+ Should CTDB manage Samba?
+ </p><p>
+ Default is no.
+ </p></dd><dt><span class="term">CTDB_MANAGES_WINBIND=yes|no</span></dt><dd><p>
+ Should CTDB manage Winbind?
+ </p><p>
+ Default is no.
+ </p></dd><dt><span class="term">CTDB_SAMBA_CHECK_PORTS=<em class="parameter"><code>PORT-LIST</code></em></span></dt><dd><p>
+ When monitoring Samba, check TCP ports in
+ space-separated PORT-LIST.
+ </p><p>
+ Default is to monitor ports that Samba is configured to listen on.
+ </p></dd><dt><span class="term">CTDB_SAMBA_SKIP_SHARE_CHECK=yes|no</span></dt><dd><p>
+ As part of monitoring, should CTDB skip the check for
+ the existence of each directory configured as share in
+ Samba. This may be desirable if there is a large number
+ of shares.
+ </p><p>
+ Default is no.
+ </p></dd><dt><span class="term">CTDB_SERVICE_NMB=<em class="parameter"><code>SERVICE</code></em></span></dt><dd><p>
+ Distribution specific SERVICE for managing nmbd.
+ </p><p>
+ Default is distribution-dependant.
+ </p></dd><dt><span class="term">CTDB_SERVICE_SMB=<em class="parameter"><code>SERVICE</code></em></span></dt><dd><p>
+ Distribution specific SERVICE for managing smbd.
+ </p><p>
+ Default is distribution-dependant.
+ </p></dd><dt><span class="term">CTDB_SERVICE_WINBIND=<em class="parameter"><code>SERVICE</code></em></span></dt><dd><p>
+ Distribution specific SERVICE for managing winbindd.
+ </p><p>
+ Default is "winbind".
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm140222704790816"></a><h3>NFS</h3><p>
+ This includes parameters for the kernel NFS server.
+ Alternative NFS subsystems (such as <a class="ulink" href="https://github.com/nfs-ganesha/nfs-ganesha/wiki" target="_top">NFS-Ganesha</a>)
+ can be integrated using <code class="varname">CTDB_NFS_CALLOUT</code>.
+ </p><div class="refsect3"><a name="idm140222704788672"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">60.nfs</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_CLUSTER_FILESYSTEM_TYPE=gpfs</span></dt><dd><p>
+ The type of cluster filesystem to use with NFS-ganesha.
+ Currently only "gpfs" is supported.
+ </p><p>
+ Default is "gpfs".
+ </p></dd><dt><span class="term">CTDB_MANAGES_NFS=yes|no</span></dt><dd><p>
+ Should CTDB manage NFS?
+ </p><p>
+ Default is no.
+ </p></dd><dt><span class="term">CTDB_NFS_CALLOUT=<em class="parameter"><code>COMMAND</code></em></span></dt><dd><p>
+ COMMAND specifies the path to a callout to handle
+ interactions with the configured NFS system, including
+ startup, shutdown, monitoring.
+ </p><p>
+ Default is the included
+ <span class="command"><strong>nfs-linux-kernel-callout</strong></span>.
+ </p></dd><dt><span class="term">CTDB_NFS_SKIP_SHARE_CHECK=yes|no</span></dt><dd><p>
+ As part of monitoring, should CTDB skip the check for
+ the existence of each directory exported via NFS. This
+ may be desirable if there is a large number of exports.
+ </p><p>
+ Default is no.
+ </p></dd><dt><span class="term">CTDB_RPCINFO_LOCALHOST=<em class="parameter"><code>IPADDR</code></em>|<em class="parameter"><code>HOSTNAME</code></em></span></dt><dd><p>
+ IPADDR or HOSTNAME indicates the address that
+ <span class="command"><strong>rpcinfo</strong></span> should connect to when doing
+ <span class="command"><strong>rpcinfo</strong></span> check on IPv4 RPC service during
+ monitoring. Optimally this would be "localhost".
+ However, this can add some performance overheads.
+ </p><p>
+ Default is "127.0.0.1".
+ </p></dd><dt><span class="term">CTDB_RPCINFO_LOCALHOST6=<em class="parameter"><code>IPADDR</code></em>|<em class="parameter"><code>HOSTNAME</code></em></span></dt><dd><p>
+ IPADDR or HOSTNAME indicates the address that
+ <span class="command"><strong>rpcinfo</strong></span> should connect to when doing
+ <span class="command"><strong>rpcinfo</strong></span> check on IPv6 RPC service
+ during monitoring. Optimally this would be "localhost6"
+ (or similar). However, this can add some performance
+ overheads.
+ </p><p>
+ Default is "::1".
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm140222704767600"></a><h3>APACHE HTTPD</h3><p>
+ CTDB can manage the Apache web server.
+ </p><div class="refsect3"><a name="idm140222704766576"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">41.httpd</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_HTTPD=yes|no</span></dt><dd><p>
+ Should CTDB manage the Apache web server?
+ </p><p>
+ Default is no.
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm140222704762000"></a><h3>CLAMAV</h3><p>
+ CTDB has support to manage the popular anti-virus daemon
+ ClamAV.
+ </p><div class="refsect3"><a name="idm140222704760880"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">31.clamd</code></td></tr></table><p>
+ This eventscript is not enabled by default. Use
+ <span class="command"><strong>ctdb enablescript</strong></span> to enable it.
+ </p></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_CLAMD=yes|no</span></dt><dd><p>
+ Should CTDB manage ClamAV?
+ </p><p>
+ Default is no.
+ </p></dd><dt><span class="term">CTDB_CLAMD_SOCKET=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ FILENAME is the socket to monitor ClamAV.
+ </p><p>
+ No default.
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm140222704752800"></a><h3>ISCSI</h3><p>
+ CTDB has support for managing the Linux iSCSI tgtd service.
+ </p><div class="refsect3"><a name="idm140222704751696"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">70.iscsi</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_ISCSI=yes|no</span></dt><dd><p>
+ Should CTDB manage iSCSI tgtd?
+ </p><p>
+ Default is no.
+ </p></dd><dt><span class="term">CTDB_START_ISCSI_SCRIPTS=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
+ DIRECTORY on shared storage containing scripts to start
+ tgtd for each public IP address.
+ </p><p>
+ No default.
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm140222704744576"></a><h3>MULTIPATHD</h3><p>
+ CTDB can monitor multipath devices to ensure that active paths
+ are available.
+ </p><div class="refsect3"><a name="idm140222704743456"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">20.multipathd</code></td></tr></table><p>
+ This eventscript is not enabled by default. Use
+ <span class="command"><strong>ctdb enablescript</strong></span> to enable it.
+ </p></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MONITOR_MPDEVICES=<em class="parameter"><code>MP-DEVICE-LIST</code></em></span></dt><dd><p>
+ MP-DEVICE-LIST is a list of multipath devices for CTDB to monitor?
+ </p><p>
+ No default.
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm140222704737200"></a><h3>VSFTPD</h3><p>
+ CTDB can manage the vsftpd FTP server.
+ </p><div class="refsect3"><a name="idm140222704736176"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">40.vsftpd</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_VSFTPD=yes|no</span></dt><dd><p>
+ Should CTDB manage the vsftpd FTP server?
+ </p><p>
+ Default is no.
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm140222704731600"></a><h3>
+ SYSTEM RESOURCE MONITORING CONFIGURATION
+ </h3><p>
+ CTDB can experience seemingly random (performance and other)
+ issues if system resources become too constrained. Options in
+ this section can be enabled to allow certain system resources
+ to be checked. They allows warnings to be logged and nodes to
+ be marked unhealthy when system resource usage reaches the
+ configured thresholds.
+ </p><p>
+ Some checks are enabled by default. It is recommended that
+ these checks remain enabled or are augmented by extra checks.
+ There is no supported way of completely disabling the checks.
+ </p><div class="refsect3"><a name="idm140222704729616"></a><h4>Eventscripts</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">05.system</code></td></tr></table><p>
+ Filesystem and memory usage monitoring is in
+ <code class="filename">05.system</code>.
+ </p></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MONITOR_FILESYSTEM_USAGE=<em class="parameter"><code>FS-LIMIT-LIST</code></em></span></dt><dd><p>
+ FS-LIMIT-LIST is a space-separated list of
+ <em class="parameter"><code>FILESYSTEM</code></em>:<em class="parameter"><code>WARN_LIMIT</code></em>[<span class="optional">:<em class="parameter"><code>UNHEALTHY_LIMIT</code></em></span>]
+ triples indicating that warnings should be logged if the
+ space used on FILESYSTEM reaches WARN_LIMIT%. If usage
+ reaches UNHEALTHY_LIMIT then the node should be flagged
+ unhealthy. Either WARN_LIMIT or UNHEALTHY_LIMIT may be
+ left blank, meaning that check will be omitted.
+ </p><p>
+ Default is to warn for each filesystem containing a
+ database directory (<code class="envar">CTDB_DBDIR</code>,
+ <code class="envar">CTDB_DBDIR_PERSISTENT</code>,
+ <code class="envar">CTDB_DBDIR_STATE</code>) with a threshold of
+ 90%.
+ </p></dd><dt><span class="term">CTDB_MONITOR_MEMORY_USAGE=<em class="parameter"><code>MEM-LIMITS</code></em></span></dt><dd><p>
+ MEM-LIMITS takes the form
+ <em class="parameter"><code>WARN_LIMIT</code></em>[<span class="optional">:<em class="parameter"><code>UNHEALTHY_LIMIT</code></em></span>]
+ indicating that warnings should be logged if memory
+ usage reaches WARN_LIMIT%. If usage reaches
+ UNHEALTHY_LIMIT then the node should be flagged
+ unhealthy. Either WARN_LIMIT or UNHEALTHY_LIMIT may be
+ left blank, meaning that check will be omitted.
+ </p><p>
+ Default is 80, so warnings will be logged when memory
+ usage reaches 80%.
+ </p></dd><dt><span class="term">CTDB_MONITOR_SWAP_USAGE=<em class="parameter"><code>SWAP-LIMITS</code></em></span></dt><dd><p>
+ SWAP-LIMITS takes the form
+ <em class="parameter"><code>WARN_LIMIT</code></em>[<span class="optional">:<em class="parameter"><code>UNHEALTHY_LIMIT</code></em></span>]
+ indicating that warnings should be logged if
+ swap usage reaches WARN_LIMIT%. If usage reaches
+ UNHEALTHY_LIMIT then the node should be flagged
+ unhealthy. Either WARN_LIMIT or UNHEALTHY_LIMIT may be
+ left blank, meaning that check will be omitted.
+ </p><p>
+ Default is 25, so warnings will be logged when swap
+ usage reaches 25%.
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm140222704711456"></a><h3>MISCELLANEOUS SERVICE-RELATED CONFIGURATION</h3><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGED_SERVICES=<em class="parameter"><code>SERVICE-LIST</code></em></span></dt><dd><p>
+ SERVICE-LIST is a space-separated list of SERVICEs that
+ CTDB should manage. This can be used as an alternative
+ to the
+ <code class="varname">CTDB_MANAGES_<em class="replaceable"><code>SERVICE</code></em></code>
+ variables.
+ </p><p>
+ No default.
+ </p></dd><dt><span class="term">CTDB_SERVICE_AUTOSTARTSTOP=yes|no</span></dt><dd><p>
+ When CTDB should start and stop services if they become
+ managed or unmanaged.
+ </p><p>
+ Default is no.
+ </p></dd></dl></div></div></div><div class="refsect1"><a name="idm140222704704928"></a><h2>
+ TUNABLES CONFIGURATION
+ </h2><p>
+ CTDB tunables (see
+ <span class="citerefentry"><span class="refentrytitle">ctdbd-tunables</span>(7)</span>) can be set from the
+ configuration file. They are set as follows:
+
+ </p><div class="literallayout"><p><br>
+CTDB_SET_<em class="replaceable"><code>TUNABLE</code></em>=<em class="replaceable"><code>VALUE</code></em><br>
+Â Â Â Â Â Â </p></div><p>
+ </p><p>
+ For example:
+
+ </p><pre class="screen">
+CTDB_SET_MonitorInterval=20
+ </pre><p>
+ </p></div><div class="refsect1"><a name="idm140222704700144"></a><h2>
+ DEBUG AND TEST
+ </h2><p>
+ Variable in this section are for debugging and testing CTDB.
+ They should not generally be needed.
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_DEBUG_HUNG_SCRIPT=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ FILENAME is a script to run to log debug information when
+ an event script times out.
+ </p><p>
+ Default is <code class="filename"><code class="varname">CTDB_BASE</code>/debug-hung-script.sh</code>.
+ </p></dd><dt><span class="term">CTDB_DEBUG_HUNG_SCRIPT_LOGFILE=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ FILENAME specifies where log messages should go when
+ debugging hung eventscripts. This is a testing option.
+ See also <em class="citetitle">CTDB_DEBUG_HUNG_SCRIPT</em>.
+ </p><p>
+ No default. Messages go to stdout/stderr and are logged
+ to the same place as other CTDB log messages.
+ </p></dd><dt><span class="term">CTDB_DEBUG_HUNG_SCRIPT_STACKPAT=<em class="parameter"><code>REGEXP</code></em></span></dt><dd><p>
+ REGEXP specifies interesting processes for which stack
+ traces should be logged when debugging hung eventscripts
+ and those processes are matched in pstree output. REGEXP
+ is an extended regexp so choices are separated by pipes
+ ('|'). However, REGEXP should not contain parentheses.
+ See also <em class="citetitle">CTDB_DEBUG_HUNG_SCRIPT</em>.
+ </p><p>
+ Default is "exportfs|rpcinfo".
+ </p></dd><dt><span class="term">CTDB_DEBUG_LOCKS=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ FILENAME is a script to run to log debug information when
+ an CTDB fails to freeze databases during recovery.
+ </p><p>
+ No default, usually
+ <code class="filename"><code class="varname">CTDB_BASE</code>/debug_locks.sh</code>.
+ </p></dd><dt><span class="term">CTDB_SYS_ETCDIR=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
+ DIRECTORY containing system configuration files. This is
+ used to provide alternate configuration when testing and
+ should not need to be changed from the default.
+ </p><p>
+ Default is <code class="filename">/etc</code>.
+ </p></dd><dt><span class="term">CTDB_INIT_STYLE=debian|redhat|suse</span></dt><dd><p>
+ This is the init style used by the Linux distribution (or
+ other operating system) being used. This is usually
+ determined dynamically by checking the system. This
+ variable is used by the initscript to determine which init
+ system primitives to use. It is also used by some
+ eventscripts to choose the name of initscripts for certain
+ services, since these can vary between distributions.
+ </p><p>
+ No fixed default.
+ </p><p>
+ If this option needs to be changed from the calculated
+ default for the initscript to function properly, then it
+ must be set in the distribution-specific initscript
+ configuration, such as
+ <code class="filename">/etc/sysconfig/ctdb</code>
+ </p></dd><dt><span class="term">CTDB_MAX_CORRUPT_DB_BACKUPS=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
+ NUM is the maximum number of volatile TDB database backups
+ to be kept (for each database) when a corrupt database is
+ found during startup. Volatile TDBs are zeroed during
+ startup so backups are needed to debug any corruption that
+ occurs before a restart.
+ </p><p>
+ Default is 10.
+ </p></dd><dt><span class="term">CTDB_MAX_OPEN_FILES=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
+ NUM is the maximum number of open files.
+ </p><p>
+ There is no default.
+ </p></dd><dt><span class="term">CTDB_RC_LOCAL=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ FILENAME is a script fragment to be sourced by the
+ <code class="filename">functions</code> that is sourced by scripts.
+ On example use would be to override function definitions
+ in unit tests. As a sanity check, this file must be
+ executable for it to be used.
+ </p><p>
+ No default.
+ </p></dd><dt><span class="term">CTDB_RUN_TIMEOUT_MONITOR=yes|no</span></dt><dd><p>
+ Whether CTDB should simulate timing out monitor events.
+ This uses the <code class="filename">99.timeout</code> eventscript.
+ </p><p>
+ Default is no.
+ </p></dd><dt><span class="term">CTDB_SCRIPT_DEBUGLEVEL=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
+ NUM is the level debugging messages printed by CTDB
+ scripts. Setting this to a higher number (e.g. 4) will
+ cause some scripts to log more messages.
+ </p><p>
+ Default is 2.
+ </p></dd><dt><span class="term">CTDB_SUPPRESS_COREFILE=yes|no</span></dt><dd><p>
+ Whether CTDB core files should be suppressed.
+ </p><p>
+ Default is no.
+ </p></dd><dt><span class="term">CTDB_VALGRIND=yes|no|<em class="parameter"><code>COMMAND</code></em></span></dt><dd><p>
+ If "yes", this causes
+ <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span> to be run under
+ <span class="citerefentry"><span class="refentrytitle">valgrind</span>(1)</span> with logs going to
+ <code class="filename">/usr/local/var/log/ctdb_valgrind</code>. If neither
+ "yes" nor "no" then the value is assumed to be a COMMAND
+ (e.g. a <span class="command"><strong>valgrind</strong></span> variation, a
+ <span class="citerefentry"><span class="refentrytitle">gdb</span>(1)</span> command) that is
+ used in place of the default <span class="command"><strong>valgrind</strong></span>
+ command. In either case, the <code class="option">--valgrind</code>
+ option is passed to <span class="command"><strong>ctdbd</strong></span>.
+ </p><p>
+ Default is no.
+ </p></dd><dt><span class="term">CTDB_VARDIR=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
+ DIRECTORY containing CTDB files that are modified at
+ runtime.
+ </p><p>
+ Defaults to <code class="filename">/usr/local/var/lib/ctdb</code>.
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm140222704651408"></a><h2>FILES</h2><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">/usr/local/etc/ctdb/ctdbd.conf</code></td></tr><tr><td><code class="filename">/etc/sysconfig/ctdb</code></td></tr><tr><td><code class="filename">/etc/default/ctdb</code></td></tr><tr><td><code class="filename">/usr/local/etc/ctdb/sysconfig/ctdb</code></td></tr></table></div><div class="refsect1"><a name="idm140222704647008"></a><h2>SEE ALSO</h2><p>
+ <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdbd_wrapper</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">onnode</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span>,
+
+ <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
+ </p></div></div></body></html>
--- /dev/null
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdbd_wrapper</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdbd_wrapper.1"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdbd_wrapper — Wrapper for ctdbd</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ctdbd_wrapper</code> {<em class="replaceable"><code>PIDFILE</code></em>} { start | stop }</p></div></div><div class="refsect1"><a name="idm140621592027056"></a><h2>DESCRIPTION</h2><p>
+ ctdbd_wrapper is used to start or stop the main CTDB daemon.
+ </p><p>
+ <em class="replaceable"><code>PIDFILE</code></em> specifies the location of the
+ file containing the PID of the main CTDB daemon.
+ </p><p>
+ ctdbd_wrapper constructs command-line options for ctdbd from
+ configuration variables specified in
+ <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>.
+ </p><p>
+ See <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for an overview of CTDB.
+ </p></div><div class="refsect1"><a name="idm140621591846720"></a><h2>SEE ALSO</h2><p>
+ <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+
+ <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
+ </p></div></div></body></html>
--- /dev/null
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ltdbtool</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ltdbtool.1"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ltdbtool — manipulate CTDB's local TDB files</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ltdbtool</code> [<em class="replaceable"><code>OPTION</code></em>...] {<em class="replaceable"><code>COMMAND</code></em>} [<em class="replaceable"><code>COMMAND-ARGS</code></em>]</p></div></div><div class="refsect1"><a name="idm139640830330400"></a><h2>DESCRIPTION</h2><p>
+ ltdbtool is a utility to manipulate CTDB's local TDB databases
+ (LTDBs) without connecting to a CTDB daemon.
+ </p><p>
+ It can be used to:
+ </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
+ dump the contents of a LTDB, optionally printing the CTDB
+ record header information,
+ </p></li><li class="listitem"><p>
+ convert between an LTDB and a non-clustered tdb
+ by adding or removing CTDB headers and
+ </p></li><li class="listitem"><p>convert between 64 and 32 bit LTDBs where the CTDB record
+ headers differ by 4 bytes of padding.
+ </p></li></ul></div></div><div class="refsect1"><a name="idm139640829958096"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-e</span></dt><dd><p>
+ Dump empty records. These are normally excluded.
+ </p></dd><dt><span class="term">-p</span></dt><dd><p>
+ Dump with header information, similar to "ctdb catdb".
+ </p></dd><dt><span class="term">
+ -s
+ { 0 | 32 | 64 }
+ </span></dt><dd><p>
+ Specify how to determine the CTDB record header size
+ for the input database:
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">0</span></dt><dd><p>no CTDB header</p></dd><dt><span class="term">32</span></dt><dd><p>CTDB header size of a 32 bit system (20 bytes)</p></dd><dt><span class="term">64</span></dt><dd><p>CTDB header size of a 64 bit system (24 bytes)</p></dd></dl></div><p>
+ The default is 32 or 64 depending on the system architecture.
+ </p></dd><dt><span class="term">
+ -o
+ { 0 | 32 | 64 }
+ </span></dt><dd><p>
+ Specify how to determine the CTDB record header size
+ for the output database, see -s.
+ </p></dd><dt><span class="term">-S <em class="parameter"><code>SIZE</code></em></span></dt><dd><p>
+ Explicitly specify the CTDB record header SIZE of the
+ input database in bytes.
+ </p></dd><dt><span class="term">-O <em class="parameter"><code>SIZE</code></em></span></dt><dd><p>
+ Explicitly specify the CTDB record header SIZE for the
+ output database in bytes.
+ </p></dd><dt><span class="term">-h</span></dt><dd><p>
+ Print help text.
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm139640833162512"></a><h2>COMMANDS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">help</span></dt><dd><p>
+ Print help text.
+ </p></dd><dt><span class="term">dump <em class="parameter"><code>IDB</code></em></span></dt><dd><p>
+ Dump the contents of an LTDB input file IDB to standard
+ output in a human-readable format.
+ </p></dd><dt><span class="term">
+ convert <em class="parameter"><code>IDB</code></em> <em class="parameter"><code>ODB</code></em>
+ </span></dt><dd><p>
+ Copy an LTDB input file IDB to output file ODB, optionally
+ adding or removing CTDB headers.
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm139640833154640"></a><h2>EXAMPLES</h2><p>
+ Print a local tdb in "tdbdump" style:
+ </p><pre class="screen">
+ ltdbtool dump idmap2.tdb.0
+ </pre><p>
+ Print a local tdb with header information similar to "ctdb catdb":
+ </p><pre class="screen">
+ ltdbtool dump -p idmap2.tdb.0
+ </pre><p>
+ Strip the CTDB headers from records:
+ </p><pre class="screen">
+ ltdbtool convert -o0 idmap2.tdb.0 idmap.tdb
+ </pre><p>
+ Strip 64 bit CTDB headers from records, running on i386:
+ </p><pre class="screen">
+ ltdbtool convert -s64 -o0 idmap2.tdb.0 idmap.tdb
+ </pre><p>
+ Strip the CTDB headers from records by piping through tdbrestore:
+ </p><pre class="screen">
+ ltdbtool dump idmap2.tdb.0 | tdbrestore idmap.tdb
+ </pre><p>
+ Convert a local tdb from a 64 bit system for usage on a 32 bit system:
+ </p><pre class="screen">
+ ltdbtool convert -s64 -o32 idmap2.tdb.0 idmap2.tdb.1
+ </pre><p>
+ Add a default header:
+ </p><pre class="screen">
+ ltdbtool convert -s0 idmap.tdb idmap2.tdb.0
+ </pre></div><div class="refsect1"><a name="idm139640833333616"></a><h2>SEE ALSO</h2><p>
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">tdbdump</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">tdbrestore</span>(1)</span>,
+
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+
+ <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
+ </p></div></div></body></html>
--- /dev/null
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>onnode</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="onnode.1"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>onnode — run commands on CTDB cluster nodes</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">onnode</code> [<em class="replaceable"><code>OPTION</code></em>...] {<em class="replaceable"><code>NODES</code></em>} {<em class="replaceable"><code>COMMAND</code></em>}</p></div></div><div class="refsect1"><a name="idm139965911351184"></a><h2>DESCRIPTION</h2><p>
+ onnode is a utility to run commands on a specific node of a CTDB
+ cluster, or on all nodes.
+ </p><p>
+ <em class="replaceable"><code>NODES</code></em> specifies which node(s) to run
+ a command on. See section <em class="citetitle">NODES
+ SPECIFICATION</em> for details.
+ </p><p>
+ <em class="replaceable"><code>COMMAND</code></em> can be any shell command. The
+ onnode utility uses ssh or rsh to connect to the remote nodes
+ and run the command.
+ </p></div><div class="refsect1"><a name="idm139965910891312"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-c</span></dt><dd><p>
+ Execute COMMAND in the current working directory on the
+ specified nodes.
+ </p></dd><dt><span class="term">-f <em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ Specify an alternative nodes FILENAME to use instead of
+ the default. This option overrides the CTDB_NODES_FILE
+ and CTDB_NODES variables. See the discussion of
+ <code class="filename">/usr/local/etc/ctdb/nodes</code> in the FILES section
+ for more details.
+ </p></dd><dt><span class="term">-i</span></dt><dd><p>
+ Keep standard input open, allowing data to be piped to
+ onnode. Normally onnode closes stdin to avoid surprises
+ when scripting. Note that this option is ignored when
+ using <code class="option">-p</code> or if <code class="envar">SSH</code> is set
+ to anything other than "ssh".
+ </p></dd><dt><span class="term">-n</span></dt><dd><p>
+ Allow nodes to be specified by name rather than node
+ numbers. These nodes don't need to be listed in the nodes
+ file. You can avoid the nodes file entirely by combining
+ this with <code class="code">-f /dev/null</code>.
+ </p></dd><dt><span class="term">-o <em class="parameter"><code>PREFIX</code></em></span></dt><dd><p>
+ Causes standard output from each node to be saved into a
+ file with name PREFIX.<em class="replaceable"><code>IP</code></em>.
+ </p></dd><dt><span class="term">-p</span></dt><dd><p>
+ Run COMMAND in parallel on the specified nodes. The
+ default is to run COMMAND sequentially on each node.
+ </p></dd><dt><span class="term">-P</span></dt><dd><p>
+ Push files to nodes. Names of files to push are specified
+ rather than the usual command. Quoting is fragile/broken
+ - filenames with whitespace in them are not supported.
+ </p></dd><dt><span class="term">-q</span></dt><dd><p>
+ Do not print node addresses. Normally, onnode prints
+ informational node addresses if more than one node is
+ specified. This overrides -v.
+ </p></dd><dt><span class="term">-v</span></dt><dd><p>
+ Print node addresses even if only one node is specified.
+ Normally, onnode prints informational node addresses when
+ more than one node is specified.
+ </p></dd><dt><span class="term">-h, --help</span></dt><dd><p>
+ Show a short usage guide.
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm139965914755584"></a><h2>NODES SPECIFICATION</h2><p>
+ Nodes can be specified via numeric node numbers (from 0 to N-1)
+ or mnemonics. Multiple nodes are specified using lists of
+ nodes, separated by commas, and ranges of numeric node numbers,
+ separated by dashes. If nodes are specified multiple times then
+ the command will be executed multiple times on those nodes. The
+ order of nodes is significant.
+ </p><p>
+ The following mnemonics are available:
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">all</span></dt><dd><p>
+ All nodes.
+ </p></dd><dt><span class="term">any</span></dt><dd><p>
+ A node where ctdbd is running. This semi-random but
+ there is a bias towards choosing a low numbered node.
+ </p></dd><dt><span class="term">ok | healthy</span></dt><dd><p>
+ All nodes that are not disconnected, banned, disabled or
+ unhealthy.
+ </p></dd><dt><span class="term">con | connected</span></dt><dd><p>
+ All nodes that are not disconnected.
+ </p></dd><dt><span class="term">lvs | lvsmaster</span></dt><dd><p>
+ The current LVS master.
+ </p></dd><dt><span class="term">natgw | natgwlist</span></dt><dd><p>
+ The current NAT gateway.
+ </p></dd><dt><span class="term">rm | recmaster</span></dt><dd><p>
+ The current recovery master.
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm139965914612928"></a><h2>EXAMPLES</h2><p>
+ The following command would show the process ID of ctdbd on all nodes
+ </p><pre class="screen">
+ onnode all ctdb getpid
+ </pre><p>
+ The following command would show the last 5 lines of log on each
+ node, preceded by the node's hostname
+ </p><pre class="screen">
+ onnode all "hostname; tail -5 /usr/local/var/log/log.ctdb"
+ </pre><p>
+ The following command would restart the ctdb service on all
+ nodes, in parallel.
+ </p><pre class="screen">
+ onnode -p all service ctdb restart
+ </pre><p>
+ The following command would run ./foo in the current working
+ directory, in parallel, on nodes 0, 2, 3 and 4.
+ </p><pre class="screen">
+ onnode -c -p 0,2-4 ./foo
+ </pre></div><div class="refsect1"><a name="idm139965914607472"></a><h2>ENVIRONMENT</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="envar">CTDB_BASE</code></span></dt><dd><p>
+ Directory containing CTDB configuration files. The
+ default is <code class="filename">/usr/local/etc/ctdb</code>.
+ </p></dd><dt><span class="term"><code class="envar">CTDB_NODES_FILE</code></span></dt><dd><p>
+ Name of alternative nodes file to use instead of the
+ default. See the <em class="citetitle">FILES</em> section for
+ more details.
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm139965914789184"></a><h2>FILES</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="filename">/usr/local/etc/ctdb/nodes</code></span></dt><dd><p>
+ Default file containing a list of each node's IP address
+ or hostname.
+ </p><p>
+ As above, a file specified via the <code class="option">-f</code> or
+ <code class="envar">CTDB_NODES_FILE</code> is given precedence. If a
+ relative path is specified and no corresponding file
+ exists relative to the current directory then the file is
+ also searched for in the <code class="filename">$CTDB_BASE</code>
+ directory.
+ </p><p>
+ If <code class="envar">CTDB_NODES_FILE</code> is not set and
+ <code class="envar">CTDB_NODES</code> is set in configuration then the
+ file pointed to by <code class="envar">CTDB_NODES</code> is used.
+ </p><p>
+ Otherwise the default is
+ <code class="filename">$CTDB_BASE/nodes</code>, where
+ <code class="envar">CTDB_BASE</code> defaults to
+ <code class="filename">/usr/local/etc/ctdb</code>.
+ </p></dd><dt><span class="term"><code class="filename">/usr/local/etc/ctdb/onnode.conf</code></span></dt><dd><p>
+ If this file exists it is sourced by onnode. The main
+ purpose is to allow the administrator to set
+ <code class="envar">SSH</code> to something other than "ssh". In this
+ case the -t option is ignored. For example, the
+ administrator may choose to use use rsh instead of ssh.
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm139965914777120"></a><h2>SEE ALSO</h2><p>
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+
+ <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
+ </p></div></div></body></html>
--- /dev/null
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ping_pong</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ping_pong.1"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ping_pong — measures the ping-pong byte range lock latency</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ping_pong</code> { -r | -w | -rw } [-m] [-c] {<em class="replaceable"><code>FILENAME</code></em>} {<em class="replaceable"><code>NUM-LOCKS</code></em>}</p></div></div><div class="refsect1"><a name="idm140370556517440"></a><h2>DESCRIPTION</h2><p>
+ ping_pong measures the byte range lock latency. It is especially
+ useful on a cluster of nodes sharing a common lock manager as it
+ will give some indication of the lock manager's performance
+ under stress.
+ </p><p>
+ FILENAME is a file on shared storage to use for byte range
+ locking tests.
+ </p><p>
+ NUM-LOCKS is the number of byte range locks, so needs to be
+ (strictly) greater than the number of nodes in the cluster.
+ </p></div><div class="refsect1"><a name="idm140370557909952"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-r</span></dt><dd><p>
+ test read performance
+ </p></dd><dt><span class="term">-w</span></dt><dd><p>
+ test write performance
+ </p></dd><dt><span class="term">-m</span></dt><dd><p>
+ use mmap
+ </p></dd><dt><span class="term">-c</span></dt><dd><p>
+ validate the locks
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm140370560882016"></a><h2>EXAMPLES</h2><p>
+ Testing lock coherence
+ </p><pre class="screen">
+ ping_pong test.dat N
+ </pre><p>
+ Testing lock coherence with lock validation
+ </p><pre class="screen">
+ ping_pong -c test.dat N
+ </pre><p>
+ Testing IO coherence
+ </p><pre class="screen">
+ ping_pong -rw test.dat N
+ </pre></div><div class="refsect1"><a name="idm140370561032480"></a><h2>SEE ALSO</h2><p>
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+
+ <a class="ulink" href="https://wiki.samba.org/index.php/Ping_pong" target="_top">https://wiki.samba.org/index.php/Ping_pong</a>
+
+ </p></div></div></body></html>
git.samba.org / martins / ctdb-web.git / commitdiff