Add missing ctdb_diagnostics manpage.
Signed-off-by: Martin Schwenke <martin@meltin.net>
-<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.7
8.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>
+<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.7
9.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="idm45666704138096"></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="idm
139938144880704"></a><h3>Example: ctdb statistics</h3><pre class="screen">
+ </p><div class="refsect2"><a name="idm
45666707089168"></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
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="idm
139938144074928"></a><h3>CTDB version</h3><p>
+ </pre></div><div class="refsect2"><a name="idm
45666704399024"></a><h3>CTDB version</h3><p>
Version of the ctdb protocol used by the node.
- </p></div><div class="refsect2"><a name="idm
139938141891920"></a><h3>Current time of statistics</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666706168112"></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="idm
139938144102064"></a><h3>Statistics collected since</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666705078144"></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="idm
139938141729504"></a><h3>num_clients</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666704201184"></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="idm
139938142880032"></a><h3>frozen</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666704697120"></a><h3>frozen</h3><p>
1 if the the databases are currently frozen, 0 otherwise.
- </p></div><div class="refsect2"><a name="idm
139938142575152"></a><h3>recovering</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666706354160"></a><h3>recovering</h3><p>
1 if recovery is active, 0 otherwise.
- </p></div><div class="refsect2"><a name="idm
139938141022688"></a><h3>num_recoveries</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666707461312"></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="idm
139938142040320"></a><h3>client_packets_sent</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666706887904"></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="idm
139938141224144"></a><h3>client_packets_recv</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666706278896"></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="idm
139938144042032"></a><h3>node_packets_sent</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666706962656"></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="idm
139938141988928"></a><h3>node_packets_recv</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666704515184"></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="idm
139938143080240"></a><h3>keepalive_packets_sent</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666705429360"></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="idm
139938142460160"></a><h3>keepalive_packets_recv</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666704475952"></a><h3>keepalive_packets_recv</h3><p>
Number of keepalive messages received from other nodes.
- </p></div><div class="refsect2"><a name="idm
139938142634128"></a><h3>node</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666706198368"></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="idm
139938142037088"></a><h4>req_call</h4><p>
+ </p><div class="refsect3"><a name="idm
45666706312336"></a><h4>req_call</h4><p>
Number of REQ_CALL messages from the other nodes.
- </p></div><div class="refsect3"><a name="idm
139938144753248"></a><h4>reply_call</h4><p>
+ </p></div><div class="refsect3"><a name="idm
45666706469664"></a><h4>reply_call</h4><p>
Number of REPLY_CALL messages from the other nodes.
- </p></div><div class="refsect3"><a name="idm
139938142887920"></a><h4>req_dmaster</h4><p>
+ </p></div><div class="refsect3"><a name="idm
45666704000096"></a><h4>req_dmaster</h4><p>
Number of REQ_DMASTER messages from the other nodes.
- </p></div><div class="refsect3"><a name="idm
139938145081184"></a><h4>reply_dmaster</h4><p>
+ </p></div><div class="refsect3"><a name="idm
45666705750000"></a><h4>reply_dmaster</h4><p>
Number of REPLY_DMASTER messages from the other nodes.
- </p></div><div class="refsect3"><a name="idm
139938142797792"></a><h4>reply_error</h4><p>
+ </p></div><div class="refsect3"><a name="idm
45666703982512"></a><h4>reply_error</h4><p>
Number of REPLY_ERROR messages from the other nodes.
- </p></div><div class="refsect3"><a name="idm
139938141620704"></a><h4>req_message</h4><p>
+ </p></div><div class="refsect3"><a name="idm
45666704293456"></a><h4>req_message</h4><p>
Number of REQ_MESSAGE messages from the other nodes.
- </p></div><div class="refsect3"><a name="idm
139938144156784"></a><h4>req_control</h4><p>
+ </p></div><div class="refsect3"><a name="idm
45666706873728"></a><h4>req_control</h4><p>
Number of REQ_CONTROL messages from the other nodes.
- </p></div><div class="refsect3"><a name="idm
139938140997424"></a><h4>reply_control</h4><p>
+ </p></div><div class="refsect3"><a name="idm
45666706590272"></a><h4>reply_control</h4><p>
Number of REPLY_CONTROL messages from the other nodes.
- </p></div></div><div class="refsect2"><a name="idm
139938143466848"></a><h3>client</h3><p>
+ </p></div></div><div class="refsect2"><a name="idm
45666704913984"></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="idm
139938141519088"></a><h4>req_call</h4><p>
+ </p><div class="refsect3"><a name="idm
45666706632368"></a><h4>req_call</h4><p>
Number of REQ_CALL messages from the clients.
- </p></div><div class="refsect3"><a name="idm
139938142138032"></a><h4>req_message</h4><p>
+ </p></div><div class="refsect3"><a name="idm
45666705538640"></a><h4>req_message</h4><p>
Number of REQ_MESSAGE messages from the clients.
- </p></div><div class="refsect3"><a name="idm
139938143399744"></a><h4>req_control</h4><p>
+ </p></div><div class="refsect3"><a name="idm
45666706260256"></a><h4>req_control</h4><p>
Number of REQ_CONTROL messages from the clients.
- </p></div></div><div class="refsect2"><a name="idm
139938142804592"></a><h3>timeouts</h3><p>
+ </p></div></div><div class="refsect2"><a name="idm
45666705870080"></a><h3>timeouts</h3><p>
This section lists timeouts occurred when sending various messages.
- </p><div class="refsect3"><a name="idm
139938143685040"></a><h4>call</h4><p>
+ </p><div class="refsect3"><a name="idm
45666705119472"></a><h4>call</h4><p>
Number of timeouts for REQ_CALL messages.
- </p></div><div class="refsect3"><a name="idm
139938141590784"></a><h4>control</h4><p>
+ </p></div><div class="refsect3"><a name="idm
45666704066976"></a><h4>control</h4><p>
Number of timeouts for REQ_CONTROL messages.
- </p></div><div class="refsect3"><a name="idm
139938142988736"></a><h4>traverse</h4><p>
+ </p></div><div class="refsect3"><a name="idm
45666706001328"></a><h4>traverse</h4><p>
Number of timeouts for database traverse operations.
- </p></div></div><div class="refsect2"><a name="idm
139938140879008"></a><h3>locks</h3><p>
+ </p></div></div><div class="refsect2"><a name="idm
45666705806528"></a><h3>locks</h3><p>
This section lists locking statistics.
- </p><div class="refsect3"><a name="idm
139938142459456"></a><h4>num_calls</h4><p>
+ </p><div class="refsect3"><a name="idm
45666705919456"></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="idm
139938141728352"></a><h4>num_current</h4><p>
+ </p></div><div class="refsect3"><a name="idm
45666704200928"></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="idm
139938141930096"></a><h4>num_pending</h4><p>
+ </p></div><div class="refsect3"><a name="idm
45666704894592"></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="idm
139938142666848"></a><h4>num_failed</h4><p>
+ </p></div><div class="refsect3"><a name="idm
45666704625024"></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="idm
139938143981744"></a><h3>total_calls</h3><p>
+ </p></div></div><div class="refsect2"><a name="idm
45666705217824"></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="idm
139938141503504"></a><h3>pending_calls</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666704771808"></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="idm
139938141551456"></a><h3>childwrite_calls</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666705513152"></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="idm
139938142822896"></a><h3>pending_childwrite_calls</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666706009424"></a><h3>pending_childwrite_calls</h3><p>
Number of record update calls currently active.
- </p></div><div class="refsect2"><a name="idm
139938144013152"></a><h3>memory_used</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666705362400"></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="idm
139938142962048"></a><h3>max_hop_count</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666705898528"></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="idm
139938143508848"></a><h3>total_ro_delegations</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666705017760"></a><h3>total_ro_delegations</h3><p>
Number of readonly delegations created.
- </p></div><div class="refsect2"><a name="idm
139938142708592"></a><h3>total_ro_revokes</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666706125568"></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="idm
139938141590240"></a><h3>hop_count_buckets</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666706454272"></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="idm
139938143414000"></a><h3>lock_buckets</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666704925792"></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="idm
139938141409200"></a><h3>locks_latency</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666704747424"></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="idm
139938142745920"></a><h3>reclock_ctdbd</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666703876976"></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="idm
139938143025616"></a><h3>reclock_recd</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666703934784"></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="idm
139938142519424"></a><h3>call_latency</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666704968688"></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="idm
139938141604624"></a><h3>childwrite_latency</h3><p>Default: 0</p><p>
+ </p></div><div class="refsect2"><a name="idm
45666704700384"></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="idm
139938143655776"></a><h2>DATABASE STATISTICS</h2><p>
+ </p></div></div><div class="refsect1"><a name="idm
45666704604208"></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="idm
139938143465056"></a><h3>Example: ctdb dbstatistics notify_index.tdb</h3><pre class="screen">
+ </p><div class="refsect2"><a name="idm
45666703819616"></a><h3>Example: ctdb dbstatistics notify_index.tdb</h3><pre class="screen">
DB Statistics: notify_index.tdb
ro_delegations 0
ro_revokes 0
Count:7 Key:2f636c75737465726673
Count:18 Key:2f636c757374657266732f64617461
Count:7 Key:2f636c757374657266732f646174612f636c69656e7473
- </pre></div><div class="refsect2"><a name="idm
139938142129200"></a><h3>DB Statistics</h3><p>
+ </pre></div><div class="refsect2"><a name="idm
45666706608144"></a><h3>DB Statistics</h3><p>
Name of the database.
- </p></div><div class="refsect2"><a name="idm
139938142084448"></a><h3>ro_delegations</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666706503952"></a><h3>ro_delegations</h3><p>
Number of readonly delegations created in the database.
- </p></div><div class="refsect2"><a name="idm
139938142116336"></a><h3>ro_revokes</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666703792800"></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="idm
139938144070224"></a><h3>locks</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666704366832"></a><h3>locks</h3><p>
This section lists locking statistics.
- </p><div class="refsect3"><a name="idm
139938143763344"></a><h4>total</h4><p>
+ </p><div class="refsect3"><a name="idm
45666705473168"></a><h4>total</h4><p>
Number of completed lock calls. This includes database locks
and record locks.
- </p></div><div class="refsect3"><a name="idm
139938143591696"></a><h4>failed</h4><p>
+ </p></div><div class="refsect3"><a name="idm
45666704277744"></a><h4>failed</h4><p>
Number of failed lock calls. This includes database locks and
record locks.
- </p></div><div class="refsect3"><a name="idm
139938141660528"></a><h4>current</h4><p>
+ </p></div><div class="refsect3"><a name="idm
45666705164528"></a><h4>current</h4><p>
Number of scheduled lock calls. This includes database locks
and record locks.
- </p></div><div class="refsect3"><a name="idm
139938141103264"></a><h4>pending</h4><p>
+ </p></div><div class="refsect3"><a name="idm
45666707562784"></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="idm
139938141836608"></a><h3>hop_count_buckets</h3><p>
+ </p></div></div><div class="refsect2"><a name="idm
45666704716832"></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="idm
139938144268496"></a><h3>lock_buckets</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666704548256"></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="idm
139938141023712"></a><h3>locks_latency</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666705836992"></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="idm
139938142295568"></a><h3>Num Hot Keys</h3><p>
+ </p></div><div class="refsect2"><a name="idm
45666706809744"></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="idm
139938143557184"></a><h2>SEE ALSO</h2><p>
+ </p></div></div><div class="refsect1"><a name="idm
45666704640496"></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>,
-<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.7
8.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>
+<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.7
9.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="idm10"></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>
+ The tunable variables are listed alphabetically.
+ </p><div class="refsect2"><a name="idm20"></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. This is mainly used
+ for detaching a volatile database using 'ctdb detach'.
+ </p></div><div class="refsect2"><a name="idm24"></a><h3>AllowUnhealthyDBRead</h3><p>Default: 0</p><p>
+ When set to 1, ctdb allows database traverses to read unhealthy
+ databases. By default, ctdb does not allow reading records from
+ unhealthy databases.
+ </p></div><div class="refsect2"><a name="idm28"></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="idm32"></a><h3>DatabaseHashSize</h3><p>Default: 100001</p><p>
+ Number of the hash chains for the local store of the tdbs that
+ ctdb manages.
+ </p></div><div class="refsect2"><a name="idm36"></a><h3>DatabaseMaxDead</h3><p>Default: 5</p><p>
+ Maximum number of dead records per hash chain for the tdb databses
+ managed by ctdb.
+ </p></div><div class="refsect2"><a name="idm40"></a><h3>DBRecordCountWarn</h3><p>Default: 100000</p><p>
+ When set to non-zero, ctdb will log a warning during recovery if
+ a database has 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="idm44"></a><h3>DBRecordSizeWarn</h3><p>Default: 10000000</p><p>
+ When set to non-zero, ctdb will log a warning during recovery
+ if a single record is bigger than this size. This will produce
+ a warning if a database record grows uncontrollably.
+ </p></div><div class="refsect2"><a name="idm48"></a><h3>DBSizeWarn</h3><p>Default: 1000000000</p><p>
+ When set to non-zero, ctdb will log a warning during recovery if
+ a database size is bigger than this. This will produce a warning
+ if a database grows uncontrollably.
+ </p></div><div class="refsect2"><a name="idm52"></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
+ client, the attach request from the client is deferred until
+ the database becomes available again at which stage we respond
+ to the client.
</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.
+ 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="idm57"></a><h3>DeterministicIPs</h3><p>Default: 0</p><p>
+ When set to 1, ctdb will 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>
- 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.
+ 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="idm62"></a><h3>DisableIPFailover</h3><p>Default: 0</p><p>
+ When set to non-zero, 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>
- 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>
+ When this tunable is enabled, 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 IP failover to replacement nodes using the
+ 'ctdb moveip' command.
+ </p></div><div class="refsect2"><a name="idm67"></a><h3>ElectionTimeout</h3><p>Default: 3</p><p>
+ The number of seconds to wait for the election of recovery
+ master to complete. If the election is not completed during this
+ interval, then that round of election fails and ctdb starts a
+ new election.
+ </p></div><div class="refsect2"><a name="idm71"></a><h3>EnableBans</h3><p>Default: 1</p><p>
+ This parameter allows ctdb to ban a node if the node is misbehaving.
+ </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="idm76"></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.
"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></div><div class="refsect2"><a name="idm81"></a><h3>FetchCollapse</h3><p>Default: 1</p><p>
+ This parameter is used to avoid multiple migration requests for
+ the same record from a single node. All the record requests for
+ the same record are queued up and processed when the record is
+ migrated to the current node.
</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.
+ 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.
+ This can improve performance and reduce CPU utilization for
+ certain workloads.
+ </p></div><div class="refsect2"><a name="idm86"></a><h3>HopcountMakeSticky</h3><p>Default: 50</p><p>
+ For database(s) marked STICKY (using 'ctdb setdbsticky'),
+ any record that is migrating so fast that hopcount
+ exceeds this limit is marked as STICKY record for
+ <code class="varname">StickyDuration</code> seconds. This means that
+ after each migration the sticky record will be kept on the node
+ <code class="varname">StickyPindown</code>milliseconds and prevented from
+ being migrated off the node.
+ </p><p>
+ 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="idm93"></a><h3>KeepaliveInterval</h3><p>Default: 5</p><p>
+ How often in seconds should the nodes send keep-alive packets to
+ each other.
+ </p></div><div class="refsect2"><a name="idm97"></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 take
+ <code class="varname">KeepaliveInterval</code> *
+ (<code class="varname">KeepaliveLimit</code> + 1) seconds before
+ ctdb determines that the node is DISCONNECTED and performs
+ a recovery. This limit should not be set too high to enable
+ early detection and avoid any application timeouts (e.g. SMB1)
+ to kick in before the fail over is completed.
+ </p></div><div class="refsect2"><a name="idm104"></a><h3>LCP2PublicIPs</h3><p>Default: 1</p><p>
+ When set to 1, ctdb uses the LCP2 ip allocation algorithm.
+ </p></div><div class="refsect2"><a name="idm108"></a><h3>LockProcessesPerDB</h3><p>Default: 200</p><p>
+ This is the maximum number of lock helper processes ctdb will
+ create for obtaining record locks. When ctdb cannot get a record
+ lock without blocking, it creates a helper process that waits
+ for the lock to be obtained.
+ </p></div><div class="refsect2"><a name="idm112"></a><h3>LogLatencyMs</h3><p>Default: 0</p><p>
+ When set to non-zero, ctdb will log if certains operations
+ take longer than this value, in milliseconds, to complete.
+ These operations include "process a record request from client",
+ "take a record or database lock", "update a persistent database
+ record" and "vaccum a database".
+ </p></div><div class="refsect2"><a name="idm116"></a><h3>MaxQueueDropMsg</h3><p>Default: 1000000</p><p>
+ This is the maximum number of messages to be queued up for
+ a client before ctdb will treat the client as hung and will
+ terminate the client connection.
+ </p></div><div class="refsect2"><a name="idm120"></a><h3>MonitorInterval</h3><p>Default: 15</p><p>
+ How often should ctdb run the 'monitor' event in seconds to check
+ for a node's health.
+ </p></div><div class="refsect2"><a name="idm124"></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="idm128"></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. When a node becomes UNHEALTHY,
+ ctdb WILL perform failover of public IP addresses, but when the
+ node becomes HEALTHY again, ctdb will not fail the addresses back.
</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.
+ 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 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
+ 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="idm134"></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
+ 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
+ that node is disabled, 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></div><div class="refsect2"><a name="idm138"></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="idm142"></a><h3>PullDBPreallocation</h3><p>Default: 10*1024*1024</p><p>
+ This is the size of a record buffer to pre-allocate for sending
+ reply to PULLDB control. Usually record buffer starts with size
+ of the first record and gets reallocated every time a new record
+ is added to the record buffer. For a large number of records,
+ this can be very inefficient to grow the record buffer one record
+ at a time.
+ </p></div><div class="refsect2"><a name="idm146"></a><h3>QueueBufferSize</h3><p>Default: 1024</p><p>
+ This is the maximum amount of data (in bytes) ctdb will read
+ from a socket at a time.
</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.
+ For a busy setup, if ctdb is not able to process the TCP sockets
+ fast enough (large amount of data in Recv-Q for tcp sockets),
+ then this tunable value should be increased. However, large
+ values can keep ctdb busy processing packets and prevent ctdb
+ from handling other events.
+ </p></div><div class="refsect2"><a name="idm151"></a><h3>RecBufferSizeLimit</h3><p>Default: 1000000</p><p>
+ This is the limit on the size of the record buffer to be sent
+ in various controls. This limit is used by new controls used
+ for recovery and controls used in vacuuming.
+ </p></div><div class="refsect2"><a name="idm155"></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="idm159"></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. This also increments a
+ counter which is checked against <code class="varname">RecdFailCount</code>
+ for detection of hung recovery daemon.
+ </p></div><div class="refsect2"><a name="idm164"></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 milliseconds.
+ </p></div><div class="refsect2"><a name="idm168"></a><h3>RecoverInterval</h3><p>Default: 1</p><p>
+ How frequently in seconds should the recovery daemon perform the
+ consistency checks to determine if it should perform a recovery.
+ </p></div><div class="refsect2"><a name="idm172"></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.
+ "__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></div><div class="refsect2"><a name="idm178"></a><h3>RecoverTimeout</h3><p>Default: 120</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="idm182"></a><h3>RecoveryBanPeriod</h3><p>Default: 300</p><p>
+ The duration in seconds for which a node is banned if the node
+ fails during recovery. After this time has elapsed the node will
+ automatically get unbanned and will attempt to rejoin the cluster.
</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.
+ A node usually gets banned due to real problems with the node.
+ Don't set this value too small. Otherwise, a problematic node
+ will try to re-join cluster too soon causing unnecessary recoveries.
+ </p></div><div class="refsect2"><a name="idm187"></a><h3>RecoveryDropAllIPs</h3><p>Default: 120</p><p>
+ If a node is stuck in recovery, or stopped, or banned, for this
+ many seconds, then ctdb will release all public addresses on
+ that node.
+ </p></div><div class="refsect2"><a name="idm191"></a><h3>RecoveryGracePeriod</h3><p>Default: 120</p><p>
+ During recoveries, if a node has not caused recovery failures
+ during the last grace period in seconds, 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="idm195"></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 the database is repacked
+ to get rid of the freelist records to avoid fragmentation.
</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).
+ 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="idm203"></a><h3>RerecoveryTimeout</h3><p>Default: 10</p><p>
+ Once a recovery has completed, no additional recoveries are
+ permitted until this timeout in seconds has expired.
+ </p></div><div class="refsect2"><a name="idm207"></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 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>
+ This tunable is used to specify in milliseconds 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="idm212"></a><h3>StatHistoryInterval</h3><p>Default: 1</p><p>
+ Granularity of the statistics collected in the statistics
+ history. This is reported by 'ctdb stats' command.
+ </p></div><div class="refsect2"><a name="idm216"></a><h3>StickyDuration</h3><p>Default: 600</p><p>
+ Once a record has been marked STICKY, this is the duration in
+ seconds, the record will be flagged as a STICKY record.
+ </p></div><div class="refsect2"><a name="idm220"></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 milliseconds. Any
+ request from other nodes to migrate the record off the node will
+ be deferred.
+ </p></div><div class="refsect2"><a name="idm224"></a><h3>TakeoverTimeout</h3><p>Default: 9</p><p>
+ This is the duration in seconds in which ctdb tries to complete IP
+ failover.
+ </p></div><div class="refsect2"><a name="idm228"></a><h3>TDBMutexEnabled</h3><p>Default: 0</p><p>
+ This paramter enables TDB_MUTEX_LOCKING feature on volatile
+ databases if the robust mutexes are supported. This optimizes the
+ record locking using robust mutexes and is much more efficient
+ that using posix locks.
+ </p></div><div class="refsect2"><a name="idm232"></a><h3>TickleUpdateInterval</h3><p>Default: 20</p><p>
+ Every <code class="varname">TickleUpdateInterval</code> seconds, ctdb
+ synchronizes the client connection information across nodes.
+ </p></div><div class="refsect2"><a name="idm237"></a><h3>TraverseTimeout</h3><p>Default: 20</p><p>
+ This is the duration in seconds for which a database traverse
+ is allowed to run. If the traverse does not complete during
+ this interval, ctdb will abort the traverse.
+ </p></div><div class="refsect2"><a name="idm241"></a><h3>VacuumFastPathCount</h3><p>Default: 60</p><p>
+ During a vacuuming run, ctdb usually processes only the records
+ marked for deletion also called the fast path vacuuming. After
+ finishing <code class="varname">VacuumFastPathCount</code> number of fast
+ path vacuuming runs, ctdb will trigger a scan of complete database
+ for any empty records that need to be deleted.
+ </p></div><div class="refsect2"><a name="idm246"></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="idm250"></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="idm258"></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="idm262"></a><h3>VerboseMemoryNames</h3><p>Default: 0</p><p>
+ When set to non-zero, ctdb assigns verbose names for some of
+ the talloc allocated memory objects. These names are visible
+ in the talloc memory report generated by 'ctdb dumpmemory'.
+ </p></div></div><div class="refsect1"><a name="idm266"></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>,
-<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.7
8.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>
+<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.7
9.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="idm31"></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
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="idm
140001402008576"></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>
+ </p></div><div class="refsect1"><a name="idm
56"></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.
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="idm1
40001397612864"></a><h2>ADMINISTRATIVE COMMANDS</h2><p>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm1
07"></a><h2>ADMINISTRATIVE COMMANDS</h2><p>
These are commands used to monitor and administer a CTDB cluster.
- </p><div class="refsect2"><a name="idm1
40001397611712"></a><h3>pnn</h3><p>
+ </p><div class="refsect2"><a name="idm1
10"></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>
+ </p></div><div class="refsect2"><a name="idm113"></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="idm1
40001402039168"></a><h4>Node status</h4><p>
+ </p><div class="refsect3"><a name="idm1
17"></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="idm1
40001402036912"></a><h4>Generation</h4><p>
+ </p></div><div class="refsect3"><a name="idm1
23"></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.
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="idm1
40001402033136"></a><h4>Virtual Node Number (VNN) map</h4><p>
+ </p></div><div class="refsect3"><a name="idm1
28"></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="idm1
40001402031664"></a><h4>Recovery mode</h4><p>
+ </p></div><div class="refsect3"><a name="idm1
31"></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.
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="idm1
40001402027760"></a><h4>Recovery master</h4><p>
+ </p></div><div class="refsect3"><a name="idm1
38"></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="idm14
0001402025760"></a><h4>Example</h4><pre class="screen">
+ </p></div><div class="refsect3"><a name="idm14
2"></a><h4>Example</h4><pre class="screen">
# ctdb status
Number of nodes:4
pnn:0 192.168.2.200 OK (THIS NODE)
hash:3 lmaster:3
Recovery mode:NORMAL (0)
Recovery master:0
- </pre></div></div><div class="refsect2"><a name="idm14
0001402023856"></a><h3>nodestatus [<span class="optional"><em class="parameter"><code>PNN-LIST</code></em></span>]</h3><p>
+ </pre></div></div><div class="refsect2"><a name="idm14
5"></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:
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="idm1
40001396491728"></a><h4>Example</h4><pre class="screen">
+ </p><div class="refsect3"><a name="idm1
61"></a><h4>Example</h4><pre class="screen">
# ctdb nodestatus
pnn:0 10.0.0.30 OK (THIS NODE)
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="idm1
40001396490032"></a><h3>recmaster</h3><p>
+ </pre></div></div><div class="refsect2"><a name="idm1
64"></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="idm1
40001396488288"></a><h3>uptime</h3><p>
+ </p></div><div class="refsect2"><a name="idm1
68"></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="idm1
40001396486976"></a><h4>Example</h4><pre class="screen">
+ </p><div class="refsect3"><a name="idm1
71"></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="idm1
40001396485152"></a><h3>listnodes</h3><p>
+ </pre></div></div><div class="refsect2"><a name="idm1
74"></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="idm1
40001396484032"></a><h4>Example</h4><pre class="screen">
+ </p><div class="refsect3"><a name="idm1
77"></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)
+ </pre></div></div><div class="refsect2"><a name="idm180"></a><h3>natgw {master|list|status}</h3><p>
+ This command shows different aspects of NAT gateway status.
+ For an overview of CTDB's NAT gateway functionality please 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">master</span></dt><dd><p>
+ Show the PNN and private IP address of the current NAT
+ gateway master node.
+ </p><p>
+ Example output:
+ </p><pre class="screen">
+1 192.168.2.201
+ </pre></dd><dt><span class="term">list</span></dt><dd><p>
+ List the private IP addresses of nodes in the current
+ NAT gateway group, annotating the master node.
+ </p><p>
+ Example output:
+ </p><pre class="screen">
+192.168.2.200
+192.168.2.201 MASTER
+192.168.2.202
+192.168.2.203
+ </pre></dd><dt><span class="term">status</span></dt><dd><p>
+ List the nodes in the current NAT gateway group and
+ their status.
+ </p><p>
+ Example output:
+ </p><pre class="screen">
+pnn:0 192.168.2.200 UNHEALTHY (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>
+
</pre></dd></dl></div></div><div class="refsect2"><a name="idm206"></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="idm
140001396477136"></a><h4>Example</h4><pre class="screen">
+ </p><div class="refsect3"><a name="idm
209"></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="idm
140001396475616"></a><h3>ifaces</h3><p>
+ </pre></div></div><div class="refsect2"><a name="idm
212"></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="idm
140001396474448"></a><h4>Example</h4><pre class="screen">
+ </p><div class="refsect3"><a name="idm
215"></a><h4>Example</h4><pre class="screen">
# ctdb ifaces
Interfaces on node 0
name:eth5 link:up references:2
|eth4|0|0|
|eth3|1|1|
|eth2|1|1|
- </pre></div></div><div class="refsect2"><a name="idm
140001396472656"></a><h3>ip</h3><p>
+ </pre></div></div><div class="refsect2"><a name="idm
218"></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="idm
140001396471280"></a><h4>Example</h4><pre class="screen">
+ </p><div class="refsect3"><a name="idm
221"></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.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="idm
140001396467728"></a><h3>ipinfo <em class="parameter"><code>IP</code></em></h3><p>
+ </pre></div></div><div class="refsect2"><a name="idm
224"></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="idm
140001396466112"></a><h4>Example</h4><pre class="screen">
+ </p><div class="refsect3"><a name="idm
228"></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
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="idm
140001396464368"></a><h3>scriptstatus</h3><p>
+ </pre></div></div><div class="refsect2"><a name="idm
231"></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="idm
140001396463088"></a><h4>Example</h4><pre class="screen">
+ </p><div class="refsect3"><a name="idm
234"></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
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="idm
140001396460864"></a><h3>disablescript <em class="parameter"><code>SCRIPT</code></em></h3><p>
+ </pre></div></div><div class="refsect2"><a name="idm
237"></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="idm
140001396458656"></a><h3>enablescript <em class="parameter"><code>SCRIPT</code></em></h3><p>
+ </p></div><div class="refsect2"><a name="idm
242"></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="idm
140001396456448"></a><h3>listvars</h3><p>
+ </p></div><div class="refsect2"><a name="idm
247"></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="idm
140001396455216"></a><h4>Example</h4><pre class="screen">
+ </p><div class="refsect3"><a name="idm
250"></a><h4>Example</h4><pre class="screen">
# ctdb listvars
-MaxRedirectCount = 3
SeqnumInterval = 1000
ControlTimeout = 60
TraverseTimeout = 20
KeepaliveInterval = 5
KeepaliveLimit = 5
-RecoverTimeout = 20
+RecoverTimeout = 120
RecoverInterval = 1
ElectionTimeout = 3
TakeoverTimeout = 9
MonitorInterval = 15
TickleUpdateInterval = 20
EventScriptTimeout = 30
-MonitorTimeoutCount = 1
+MonitorTimeoutCount = 20
RecoveryGracePeriod = 120
RecoveryBanPeriod = 300
DatabaseHashSize = 100001
EnableBans = 1
DeterministicIPs = 0
LCP2PublicIPs = 1
-ReclockPingPeriod = 60
NoIPFailback = 0
DisableIPFailover = 0
VerboseMemoryNames = 0
RecLockLatencyMs = 1000
RecoveryDropAllIPs = 120
VacuumInterval = 10
-VacuumMaxRunTime = 30
+VacuumMaxRunTime = 120
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>
+RecoverPDBBySeqNum = 1
+DeferredRebalanceOnNodeAdd = 300
+FetchCollapse = 1
+HopcountMakeSticky = 50
+StickyDuration = 600
+StickyPindown = 200
+NoIPTakeover = 0
+DBRecordCountWarn = 100000
+DBRecordSizeWarn = 10000000
+DBSizeWarn = 100000000
+PullDBPreallocation = 10485760
+NoIPHostOnAllDisabled = 0
+Samba3AvoidDeadlocks = 0
+TDBMutexEnabled = 0
+LockProcessesPerDB = 200
+ </pre></div></div><div class="refsect2"><a name="idm253"></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="idm
140001396449632"></a><h4>Example</h4><pre class="screen">
-# ctdb getvar MaxRedirectCount
-MaxRedirectCount = 3
- </pre></div></div><div class="refsect2"><a name="idm
140001396448112"></a><h3>setvar <em class="parameter"><code>NAME</code></em> <em class="parameter"><code>VALUE</code></em></h3><p>
+ </p><div class="refsect3"><a name="idm
257"></a><h4>Example</h4><pre class="screen">
+# ctdb getvar MonitorInterval
+MonitorInterval = 15
+ </pre></div></div><div class="refsect2"><a name="idm
260"></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>
+ </p><div class="refsect3"><a name="idm265"></a><h4>Example</h4><pre class="screen">
+# ctdb setvar MonitorInterval 20
+ </pre></div></div><div class="refsect2"><a name="idm268"></a><h3>lvs {master|list|status}</h3><p>
+ This command shows different aspects of LVS status. For an
+ overview of CTDB's LVS functionality please see the
+ <em class="citetitle">LVS</em> section in
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">master</span></dt><dd><p>
+ Shows the PNN of the current LVS master node.
+ </p><p>
+ Example output:
+ </p><pre class="screen">
+2
+ </pre></dd><dt><span class="term">list</span></dt><dd><p>
+ Lists the currently usable LVS nodes.
+ </p><p>
+ Example output:
+ </p><pre class="screen">
+2 10.0.0.13
+3 10.0.0.14
+ </pre></dd><dt><span class="term">status</span></dt><dd><p>
+ List the nodes in the current LVS group and their status.
+ </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>
+pnn:0 10.0.0.11 UNHEALTHY (THIS NODE)
+pnn:1 10.0.0.12 UNHEALTHY
+pnn:2 10.0.0.13 OK
+pnn:3 10.0.0.14 OK
+ </pre></dd></dl></div></div><div class="refsect2"><a name="idm294"></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><pre class="screen">
RECMASTER: YES
LMASTER: YES
-LVS: NO
- </pre></div><div class="refsect2"><a name="idm140001396436848"></a><h3>statistics</h3><p>
+ </pre></div><div class="refsect2"><a name="idm303"></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="idm
140001396434752"></a><h4>Example</h4><pre class="screen">
+ </p><div class="refsect3"><a name="idm
309"></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>
+Current time of statistics : Tue Mar 8 15:18:51 2016
+Statistics collected since : (003 21:31:32) Fri Mar 4 17:47:19 2016
+ num_clients 9
+ frozen 0
+ recovering 0
+ num_recoveries 2
+ client_packets_sent 8170534
+ client_packets_recv 7166132
+ node_packets_sent 16549998
+ node_packets_recv 5244418
+ keepalive_packets_sent 201969
+ keepalive_packets_recv 201969
+ node
+ req_call 26
+ reply_call 0
+ req_dmaster 9
+ reply_dmaster 12
+ reply_error 0
+ req_message 1339231
+ req_control 8177506
+ reply_control 6831284
+ client
+ req_call 15
+ req_message 334809
+ req_control 6831308
+ timeouts
+ call 0
+ control 0
+ traverse 0
+ locks
+ num_calls 8
+ num_current 0
+ num_pending 0
+ num_failed 0
+ total_calls 15
+ pending_calls 0
+ childwrite_calls 0
+ pending_childwrite_calls 0
+ memory_used 394879
+ max_hop_count 1
+ total_ro_delegations 0
+ total_ro_revokes 0
+ hop_count_buckets: 8 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0
+ lock_buckets: 0 0 8 0 0 0 0 0 0 0 0 0 0 0 0 0
+ locks_latency MIN/AVG/MAX 0.010005/0.010418/0.011010 sec out of 8
+ reclock_ctdbd MIN/AVG/MAX 0.002538/0.002538/0.002538 sec out of 1
+ reclock_recd MIN/AVG/MAX 0.000000/0.000000/0.000000 sec out of 0
+ call_latency MIN/AVG/MAX 0.000044/0.002142/0.011702 sec out of 15
+ childwrite_latency MIN/AVG/MAX 0.000000/0.000000/0.000000 sec out of 0
+ </pre></div></div><div class="refsect2"><a name="idm312"></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="idm
140001396429248"></a><h3>dbstatistics <em class="parameter"><code>DB</code></em></h3><p>
+ </p></div><div class="refsect2"><a name="idm
316"></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="idm
140001396426704"></a><h4>Example</h4><pre class="screen">
+ </p><div class="refsect3"><a name="idm
323"></a><h4>Example</h4><pre class="screen">
# ctdb dbstatistics locking.tdb
DB Statistics: locking.tdb
ro_delegations 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
+ vacuum_latency MIN/AVG/MAX 0.000472/0.002207/15.243570 sec out of 224530
Num Hot Keys: 1
Count:8 Key:ff5bd7cb3ee3822edc1f0000000000000000000000000000
- </pre></div></div><div class="refsect2"><a name="idm
140001396424592"></a><h3>getreclock</h3><p>
- Show the name of the recovery lock file, if any.
+ </pre></div></div><div class="refsect2"><a name="idm
326"></a><h3>getreclock</h3><p>
+ Show details of the recovery lock, 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>
+ /clusterfs/.ctdb/recovery.lock
+ </pre></div><div class="refsect2"><a name="idm331"></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.
</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="idm
140001396412368"></a><h3>setdebug <em class="parameter"><code>DEBUGLEVEL</code></em></h3><p>
+ ERROR WARNING NOTICE INFO DEBUG
+ </p></div><div class="refsect2"><a name="idm
337"></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="idm
140001396410240"></a><h3>getpid</h3><p>
+ The debuglevel is one of ERROR WARNING NOTICE INFO DEBUG
+ </p></div><div class="refsect2"><a name="idm
342"></a><h3>getpid</h3><p>
This command will return the process id of the ctdb daemon.
- </p></div><div class="refsect2"><a name="idm
140001396409088"></a><h3>disable</h3><p>
+ </p></div><div class="refsect2"><a name="idm
345"></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="idm
140001396407648"></a><h3>enable</h3><p>
+ </p></div><div class="refsect2"><a name="idm
348"></a><h3>enable</h3><p>
Re-enable a node that has been administratively disabled.
- </p></div><div class="refsect2"><a name="idm
140001396406496"></a><h3>stop</h3><p>
+ </p></div><div class="refsect2"><a name="idm
351"></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="idm
140001396404944"></a><h3>continue</h3><p>
+ </p></div><div class="refsect2"><a name="idm
354"></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>
+ </p></div><div class="refsect2"><a name="idm357"></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. It should be followed by a <span class="command"><strong>ctdb
+ ipreallocate</strong></span>. 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="idm365"></a><h3>delip <em class="parameter"><code>IPADDR</code></em></h3><p>
+ This command flags IPADDR for deletion from a node at runtime.
+ It should be followed by a <span class="command"><strong>ctdb
+ ipreallocate</strong></span>. If IPADDR is currently hosted by the
+ node it is being removed from, this ensures that the IP will
+ first be failed over to another node, if possible, and that it
+ is then actually 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="idm371"></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>
DeterministicIPs = 0
</p><p>
NoIPFailback = 1
- </p></div><div class="refsect2"><a name="idm
140001396393728"></a><h3>shutdown</h3><p>
+ </p></div><div class="refsect2"><a name="idm
379"></a><h3>shutdown</h3><p>
This command will shutdown a specific CTDB daemon.
- </p></div><div class="refsect2"><a name="idm
140001396392576"></a><h3>setlmasterrole on|off</h3><p>
+ </p></div><div class="refsect2"><a name="idm
382"></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.
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="idm
140001396389696"></a><h3>setrecmasterrole on|off</h3><p>
+ </p></div><div class="refsect2"><a name="idm
388"></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="idm
140001396387168"></a><h3>reloadnodes</h3><p>
+ </p></div><div class="refsect2"><a name="idm
393"></a><h3>reloadnodes</h3><p>
This command is used when adding new nodes, or removing
existing nodes from an existing cluster.
</p><p>
</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>
+ </p></li></ol></div></div><div class="refsect2"><a name="idm434"></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>
+ </p><p>
+ This command is currently unable to make changes to the
+ netmask or interfaces associated with existing addresses.
+ Such changes must be made in 2 steps by deleting addresses in
+ question and re-adding then. Unfortunately this will disrupt
+ connections to the changed addresses.
+ </p></div><div class="refsect2"><a name="idm440"></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
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="idm
140001396361920"></a><h4>Example</h4><pre class="screen">
+ </p><div class="refsect3"><a name="idm
446"></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
# 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>
+ </pre></div></div><div class="refsect2"><a name="idm449"></a><h3>
backupdb
<em class="parameter"><code>DB</code></em>
<em class="parameter"><code>FILE</code></em>
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>
+ </p></div><div class="refsect2"><a name="idm456"></a><h3>
restoredb
<em class="parameter"><code>FILE</code></em>
[<span class="optional"><em class="parameter"><code>DB</code></em></span>]
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="idm
140001396352528"></a><h3>setdbreadonly <em class="parameter"><code>DB</code></em></h3><p>
+ </p></div><div class="refsect2"><a name="idm
462"></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="idm
140001396350592"></a><h3>setdbsticky <em class="parameter"><code>DB</code></em></h3><p>
+ </p></div><div class="refsect2"><a name="idm
466"></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="idm
140001396348512"></a><h2>INTERNAL COMMANDS</h2><p>
+ </p></div></div><div class="refsect1"><a name="idm
470"></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="idm
140001396347296"></a><h3>gettickles <em class="parameter"><code>IPADDR</code></em></h3><p>
+ </p><div class="refsect2"><a name="idm
473"></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="idm
140001396345536"></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
+ </p></div><div class="refsect2"><a name="idm
477"></a><h3>gratarp <em class="parameter"><code>IPADDR</code></em> <em class="parameter"><code>INTERFACE</code></em></h3><p>
+ Send out a gratuitous 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>
+ </p></div><div class="refsect2"><a name="idm482"></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>
+ </p></div><div class="refsect2"><a name="idm487"></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>
+ </p></div><div class="refsect2"><a name="idm492"></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>
+ </p></div><div class="refsect2"><a name="idm498"></a><h3>
ptrans
<em class="parameter"><code>DB</code></em>
[<span class="optional"><em class="parameter"><code>FILE</code></em></span>]
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="idm
140001396326512"></a><h3>runstate [setup|first_recovery|startup|running]</h3><p>
+ </p></div><div class="refsect2"><a name="idm
505"></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.
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="idm
140001396324784"></a><h4>Example</h4><pre class="screen">
+ </p><div class="refsect3"><a name="idm
509"></a><h4>Example</h4><pre class="screen">
# ctdb runstate
RUNNING
- </pre></div></div><div class="refsect2"><a name="idm
140001396323264"></a><h3>setifacelink <em class="parameter"><code>IFACE</code></em> up|down</h3><p>
+ </pre></div></div><div class="refsect2"><a name="idm
512"></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></div><div class="refsect2"><a name="idm518"></a><h3>tickle</h3><p>
+ Read a list of TCP connections, one per line, from standard
+ input and send a TCP tickle to the source host for 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>
+ A single connection can be specified on the command-line
+ rather than on standard input.
+ </p><p>
+ 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="idm
140001396315824"></a><h3>version</h3><p>
+ </p></div><div class="refsect2"><a name="idm
529"></a><h3>version</h3><p>
Display the CTDB version.
- </p></div></div><div class="refsect1"><a name="idm
140001396314544"></a><h2>DEBUGGING COMMANDS</h2><p>
+ </p></div></div><div class="refsect1"><a name="idm
532"></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="idm
140001396313376"></a><h3>OPTIONS</h3><div class="variablelist"><dl class="variablelist"><dt><span class="term">--print-emptyrecords</span></dt><dd><p>
+ </p><div class="refsect2"><a name="idm
535"></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
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="idm
140001396304352"></a><h3>process-exists <em class="parameter"><code>PID</code></em></h3><p>
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm
558"></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="idm
140001396302512"></a><h3>getdbstatus <em class="parameter"><code>DB</code></em></h3><p>
+ </p></div><div class="refsect2"><a name="idm
562"></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="idm
140001396300912"></a><h4>Example</h4><pre class="screen">
+ </p><div class="refsect3"><a name="idm
566"></a><h4>Example</h4><pre class="screen">
# ctdb getdbstatus test.tdb.0
dbid: 0x122224da
name: test.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="idm
140001396298944"></a><h3>catdb <em class="parameter"><code>DB</code></em></h3><p>
+ </pre></div></div><div class="refsect2"><a name="idm
569"></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="idm
140001396297296"></a><h3>cattdb <em class="parameter"><code>DB</code></em></h3><p>
+ </p></div><div class="refsect2"><a name="idm
573"></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="idm
140001396295568"></a><h3>dumpdbbackup <em class="parameter"><code>FILE</code></em></h3><p>
+ </p></div><div class="refsect2"><a name="idm
577"></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="idm
140001396293216"></a><h3>wipedb <em class="parameter"><code>DB</code></em></h3><p>
+ </p></div><div class="refsect2"><a name="idm
582"></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="idm
140001396291568"></a><h3>recover</h3><p>
+ </p></div><div class="refsect2"><a name="idm
586"></a><h3>recover</h3><p>
This command will trigger the recovery daemon to do a cluster
recovery.
- </p></div><div class="refsect2"><a name="idm
140001396290320"></a><h3>ipreallocate, sync</h3><p>
+ </p></div><div class="refsect2"><a name="idm
589"></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>
+ </p></div><div class="refsect2"><a name="idm592"></a><h3>getmonmode</h3><p>
+ This command prints the monitoring mode of a node. This
+ indicates when CTDB is monitoring services on the node. The
+ monitoring mode is either ENABLED or DISABLED.
+ </p></div><div class="refsect2"><a name="idm595"></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="idm
140001396282480"></a><h3>detach <em class="parameter"><code>DB-LIST</code></em></h3><p>
+ </p></div><div class="refsect2"><a name="idm
599"></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
</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="idm
140001396280048"></a><h3>dumpmemory</h3><p>
+ </p></div><div class="refsect2"><a name="idm
604"></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="idm
140001396278752"></a><h3>rddumpmemory</h3><p>
+ </p></div><div class="refsect2"><a name="idm
607"></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>
+ </p></div><div class="refsect2"><a name="idm610"></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="idm
140001396274496"></a><h3>ban <em class="parameter"><code>BANTIME</code></em></h3><p>
+ </p></div><div class="refsect2"><a name="idm
614"></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>
</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="idm
140001396270512"></a><h3>unban</h3><p>
+ </p></div><div class="refsect2"><a name="idm
622"></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>
+ </p></div><div class="refsect2"><a name="idm625"></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="idm
140001396264656"></a><h4>Example</h4><pre class="screen">
+ </p><div class="refsect3"><a name="idm
629"></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="idm
140001396262720"></a><h2>SEE ALSO</h2><p>
+ </pre></div></div></div><div class="refsect1"><a name="idm
632"></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>,
-<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.7
8.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>
+<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.7
9.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="idm10"></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>
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="idm
140441723037264"></a><h2>ANATOMY OF A CTDB CLUSTER</h2><p>
+ </p></div><div class="refsect1"><a name="idm
22"></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
</p><p>
CTDB provides an "all active" cluster, where services are load
balanced across all nodes.
- </p></div><div class="refsect1"><a name="idm
140441725338896"></a><h2>Recovery Lock</h2><p>
+ </p></div><div class="refsect1"><a name="idm
26"></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
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
+ By default, the recovery lock is implemented using a file
+ (specified by <em class="parameter"><code>CTDB_RECOVERY_LOCK</code></em>)
+ 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>
+ The recovery lock can also be implemented using an arbitrary
+ cluster mutex call-out by using an exclamation point ('!') as
+ the first character of
+ <em class="parameter"><code>CTDB_RECOVERY_LOCK</code></em>. For example, a value
+ of <span class="command"><strong>!/usr/local/bin/myhelper recovery</strong></span> would
+ run the given helper with the specified arguments. See the
+ source code relating to cluster mutexes for clues about writing
+ call-outs.
</p><p>
If a cluster becomes partitioned (for example, due to a
communication failure) and a different recovery master is
</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="idm
140441722733568"></a><h2>Private vs Public addresses</h2><p>
+ </p></div><div class="refsect1"><a name="idm
45"></a><h2>Private vs Public addresses</h2><p>
Each node in a CTDB cluster has multiple IP addresses assigned
to it:
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="idm
140441727493008"></a><h3>Private address</h3><p>
+ </p><div class="refsect2"><a name="idm
53"></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
</p><p>
It is strongly recommended that the private addresses are
configured on a private network that is separate from client
- networks.
+ networks. This is because the CTDB protocol is both
+ unauthenticated and unencrypted. If clients share the private
+ network then steps need to be taken to stop injection of
+ packets to relevant ports on the private addresses. It is
+ also likely that CTDB protocol traffic between nodes could
+ leak sensitive information if it can be intercepted.
</p><p>
Example <code class="filename">/usr/local/etc/ctdb/nodes</code> for a four node
cluster:
192.168.1.2
192.168.1.3
192.168.1.4
- </pre></div><div class="refsect2"><a name="idm
140441727640272"></a><h3>Public addresses</h3><p>
+ </pre></div><div class="refsect2"><a name="idm
67"></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
</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="idm
140441727555008"></a><h2>Node status</h2><p>
+ </p></div></div><div class="refsect1"><a name="idm
88"></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>
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="idm1
40441727667696"></a><h2>CAPABILITIES</h2><p>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm1
28"></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>
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="idm14
0441727658624"></a><h2>LVS</h2><p>
+ </p></div><div class="refsect1"><a name="idm14
3"></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
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.
+ One extra LVS public address is assigned on the public network
+ to each LVS group. Each LVS group is a set of nodes in the
+ cluster that presents the same LVS address public address to the
+ outside world. Normally there would only be one LVS group
+ spanning an entire cluster, but in situations where one CTDB
+ cluster spans multiple physical sites it might be useful to have
+ one LVS group for each site. There can be multiple LVS groups
+ in a cluster but each node can only be member of one LVS group.
+ </p><p>
+ Client access to the cluster is load-balanced across the HEALTHY
+ nodes in an LVS group. If no HEALTHY nodes exists then all
+ nodes in the group are used, regardless of health status. CTDB
+ will, however never load-balance LVS 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.
+ In each LVS group, one of the nodes is selected by CTDB to be
+ the LVS master. This node receives all traffic from clients
+ coming in to the LVS public 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 LVS master node. The
+ command <span class="command"><strong>ctdb lvsmaster</strong></span> will show which node
+ is the current LVS master.
</p><p>
The path used for a client I/O is:
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
</p></li><li class="listitem"><p>
Node responds back to client.
</p></li></ol></div><p>
- </p><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
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="idm1
40441722121984"></a><h3>Configuration</h3><p>
+ </p><div class="refsect2"><a name="idm1
67"></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.
+ <code class="varname">CTDB_LVS_PUBLIC_IFACE</code>,
+ <code class="varname">CTDB_LVS_PUBLIC_IP</code> and
+ <code class="varname">CTDB_LVS_NODES</code> configuration variables.
+ <code class="varname">CTDB_LVS_NODES</code> specifies a file containing
+ the private address of all nodes in the current node's LVS
+ group.
</p><p>
Example:
</p><pre class="screen">
-CTDB_PUBLIC_INTERFACE=eth1
+CTDB_LVS_PUBLIC_IFACE=eth1
CTDB_LVS_PUBLIC_IP=10.1.1.237
+CTDB_LVS_NODES=/usr/local/etc/ctdb/lvs_nodes
</pre><p>
- </p></div></div><div class="refsect1"><a name="idm140441722118800"></a><h2>TRACKING AND RESETTING TCP CONNECTIONS</h2><p>
+ </p><p>
+ Example <code class="filename">/usr/local/etc/ctdb/lvs_nodes</code>:
+ </p><pre class="screen">
+192.168.1.2
+192.168.1.3
+192.168.1.4
+ </pre><p>
+ Normally any node in an LVS group can act as the LVS master.
+ Nodes that are highly loaded due to other demands maybe
+ flagged with the "slave-only" option in the
+ <code class="varname">CTDB_LVS_NODES</code> file to limit the LVS
+ functionality of those nodes.
+ </p><p>
+ LVS nodes file that excludes 192.168.1.4 from being
+ the LVS master node:
+ </p><pre class="screen">
+192.168.1.2
+192.168.1.3
+192.168.1.4 slave-only
+ </pre></div></div><div class="refsect1"><a name="idm183"></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
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="idm1
40441722116496"></a><h2>NAT GATEWAY</h2><p>
+ </p></div><div class="refsect1"><a name="idm1
87"></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)
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="idm1
40441722113808"></a><h3>Operation</h3><p>
+ </p><div class="refsect2"><a name="idm1
92"></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
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="idm1
40441722110800"></a><h3>Configuration</h3><p>
+ </p></div><div class="refsect2"><a name="idm1
97"></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
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="idm
140441722106032"></a><h3>Implementation details</h3><p>
+ </p></div><div class="refsect2"><a name="idm
208"></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
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="idm
140441722098208"></a><h2>POLICY ROUTING</h2><p>
+ </p></div></div><div class="refsect1"><a name="idm
225"></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
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="idm
140441722095984"></a><h3>Configuration variables</h3><p>
+ </p><div class="refsect2"><a name="idm
229"></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_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="idm
140441722092016"></a><h3>Configuration</h3><p>
+ </p></div><div class="refsect2"><a name="idm
240"></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">
</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="idm
140441722076800"></a><h3>Sample configuration</h3><p>
+ </pre></div><div class="refsect2"><a name="idm
268"></a><h3>Sample configuration</h3><p>
Here is a more complete example configuration.
</p><pre class="screen">
/usr/local/etc/ctdb/public_addresses:
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="idm
140441722073584"></a><h2>NOTIFICATION SCRIPT</h2><p>
+ </p></div></div><div class="refsect1"><a name="idm
273"></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
</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="idm
140441722066640"></a><h2>DEBUG LEVELS</h2><p>
+ </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="idm
288"></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="idm
140441722062944"></a><h2>REMOTE CLUSTER NODES</h2><p>
+ </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="idm
297"></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.
</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="idm
140441722058240"></a><h2>SEE ALSO</h2><p>
+ </p></div><div class="refsect1"><a name="idm
305"></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">ctdb_diagnostics</span>(1)</span>,
+
<span class="citerefentry"><span class="refentrytitle">ltdbtool</span>(1)</span>,
<span class="citerefentry"><span class="refentrytitle">onnode</span>(1)</span>,
--- /dev/null
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb_diagnostics</title><meta name="generator" content="DocBook XSL Stylesheets V1.79.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdb_diagnostics.1"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb_diagnostics — dump diagnostic information about CTDB/Samba installation</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ctdb_diagnostics</code> [OPTIONS] ... </p></div></div><div class="refsect1"><a name="idm15"></a><h2>DESCRIPTION</h2><p>
+ ctdb_diagnostics is used to dump diagnostic information about a
+ clustered Samba installation. This includes configuration
+ files, output of relevant commands and logs. This information
+ can be used to check the correctness of the configuration and to
+ diagnose problems.
+ </p></div><div class="refsect1"><a name="idm18"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-n <nodes></span></dt><dd><p>
+ Comma separated list of nodes to operate on
+ </p></dd><dt><span class="term">-c</span></dt><dd><p>
+ Ignore comment lines (starting with '#') in file comparisons
+ </p></dd><dt><span class="term">-w</span></dt><dd><p>
+ Ignore whitespace in file comparisons
+ </p></dd><dt><span class="term">--no-ads</span></dt><dd><p>
+ Do not use commands that assume an Active Directory Server
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm37"></a><h2>SEE ALSO</h2><p>
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
+ <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+ <a class="ulink" href="https://ctdb.samba.org/" target="_top">https://ctdb.samba.org/</a>
+ </p></div></div></body></html>
-<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.7
8.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>
+<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.7
9.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="idm15"></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="idm
139840525514688"></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>
+ </p></div><div class="refsect1"><a name="idm
26"></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.
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>
+ </p></dd></dl></div></dd></dl></div></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>
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.
+ Default INTERFACE on which to attach public IP addresses.
</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></dd><dt><span class="term">--reclock=<em class="parameter"><code>LOCK</code></em></span></dt><dd><p>
+ LOCK specifies the cluster-wide mutex used to detect and
+ prevent a partitioned cluster (or "split brain").
</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>
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="idm
139840521704176"></a><h2>DEBUGGING OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-i, --interactive</span></dt><dd><p>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm
223"></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
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="idm
139840521682688"></a><h2>SEE ALSO</h2><p>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm
273"></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>,
-<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.7
8.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>
+<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.7
9.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="idm10"></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>.
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>
+ </p></div><div class="refsect1"><a name="idm23"></a><h2>
INITSCRIPT CONFIGURATION
</h2><p>
Some options must be available to the initscript so they need to
</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>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm40"></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>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm49"></a><h2>
DAEMON CONFIGURATION
</h2><p>
Variables in this section are processed by
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>
+ </p></dd></dl></div></dd></dl></div></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_NOSETSCHED=yes|no</span></dt><dd><p>
+ Defaults to no. Corresponds to <code class="option">--nosetsched</code>.
+ </p><p>
+ Usually CTDB runs with real-time priority. If you are running
+ CTDB on a platform that does not support real-time priority,
+ you can set this.
</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
</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
+ </p></dd><dt><span class="term">CTDB_RECOVERY_LOCK=<em class="parameter"><code>LOCK</code></em></span></dt><dd><p>
+ LOCK specifies the cluster-wide mutex used to detect and
+ prevent a partitioned cluster (or "split brain").
+ </p><p>
+ No default, but the default configuration file specifies
<code class="filename">/some/place/on/shared/storage</code>, which
should be change to a useful value. Corresponds to
<code class="option">--reclock</code>.
"setup" event before this timeout then it is killed.
</p><p>
Defaults is 10.
- </p></dd></dl></div></div><div class="refsect1"><a name="idm
140222704871744"></a><h2>NETWORK CONFIGURATION</h2><div class="refsect2"><a name="idm140222704871104"></a><h3>NAT GATEWAY</h3><p>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm
277"></a><h2>NETWORK CONFIGURATION</h2><div class="refsect2"><a name="idm279"></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
route to avoid this.
</p><p>
No default.
- </p></dd></dl></div><div class="refsect3"><a name="idm
140222704844880"></a><h4>Example</h4><pre class="screen">
+ </p></dd></dl></div><div class="refsect3"><a name="idm
337"></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
</pre><p>
Note that <code class="varname">CTDB_NATGW_DEFAULT_GATEWAY</code> is
not specified.
- </p></div></div><div class="refsect2"><a name="idm
140222704840976"></a><h3>POLICY ROUTING</h3><p>
+ </p></div></div><div class="refsect2"><a name="idm
344"></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
manipulate).
</p><p>
No default, usually 1000 and 9000.
- </p></dd></dl></div><div class="refsect3"><a name="idm
140222704819040"></a><h4>Example</h4><pre class="screen">
+ </p></dd></dl></div><div class="refsect3"><a name="idm
393"></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>
+ </pre></div></div><div class="refsect2"><a name="idm396"></a><h3>LVS</h3><p>
+ For a general description see the <em class="citetitle">LVS</em>
+ section in <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
+ </p><div class="refsect3"><a name="idm403"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">91.lvs</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_LVS_NODES=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+ FILENAME contains the list of nodes that belong to the
+ same LVS 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 LVS
+ group.
+ </p><p>
+ If "slave-only" is specified then the corresponding node
+ can not be the LVS master node. In this case
+ <code class="varname">CTDB_LVS_PUBLIC_IFACE</code> and
+ <code class="varname">CTDB_LVS_PUBLIC_IP</code> are optional and
+ unused.
+ </p><p>
+ No default, usually
+ <code class="filename">/usr/local/etc/ctdb/lvs_nodes</code> when enabled.
+ </p></dd><dt><span class="term">CTDB_LVS_PUBLIC_IFACE=<em class="parameter"><code>INTERFACE</code></em></span></dt><dd><p>
+ INTERFACE is the network interface that clients will use
+ to connection to <code class="varname">CTDB_LVS_PUBLIC_IP</code>.
+ This is optional for slave-only nodes.
+ No default.
+ </p></dd><dt><span class="term">CTDB_LVS_PUBLIC_IP=<em class="parameter"><code>IPADDR</code></em></span></dt><dd><p>
+ CTDB_LVS_PUBLIC_IP is the LVS public address. No
+ default.
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm435"></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
to be up.
</p><p>
Default is "no".
- </p></dd></dl></div></div></div><div class="refsect1"><a name="idm
140222704812656"></a><h2>SERVICE CONFIGURATION</h2><p>
+ </p></dd></dl></div></div></div><div class="refsect1"><a name="idm
445"></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>
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="idm
140222704810800"></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>
+ </p><div class="refsect2"><a name="idm
449"></a><h3>SAMBA</h3><div class="refsect3"><a name="idm451"></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.
Distribution specific SERVICE for managing winbindd.
</p><p>
Default is "winbind".
- </p></dd></dl></div></div><div class="refsect2"><a name="idm
140222704790816"></a><h3>NFS</h3><p>
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm
498"></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>
+ </p><div class="refsect3"><a name="idm503"></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_MANAGES_NFS=yes|no</span></dt><dd><p>
Should CTDB manage NFS?
</p><p>
Default is no.
overheads.
</p><p>
Default is "::1".
- </p></dd></dl></div></div><div class="refsect2"><a name="idm140222704767600"></a><h3>APACHE HTTPD</h3><p>
+ </p></dd><dt><span class="term">CTDB_NFS_STATE_FS_TYPE=<em class="parameter"><code>TYPE</code></em></span></dt><dd><p>
+ The type of filesystem used for a clustered NFS' shared
+ state. No default.
+ </p></dd><dt><span class="term">CTDB_NFS_STATE_MNT=<em class="parameter"><code>DIR</code></em></span></dt><dd><p>
+ The directory where a clustered NFS' shared state will be
+ located. No default.
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm554"></a><h3>APACHE HTTPD</h3><p>
CTDB can manage the Apache web server.
- </p><div class="refsect3"><a name="idm
140222704766576"></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>
+ </p><div class="refsect3"><a name="idm
557"></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="idm
140222704762000"></a><h3>CLAMAV</h3><p>
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm
568"></a><h3>CLAMAV</h3><p>
CTDB has support to manage the popular anti-virus daemon
ClamAV.
- </p><div class="refsect3"><a name="idm
140222704760880"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">31.clamd</code></td></tr></table><p>
+ </p><div class="refsect3"><a name="idm
571"></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>
FILENAME is the socket to monitor ClamAV.
</p><p>
No default.
- </p></dd></dl></div></div><div class="refsect2"><a name="idm
140222704752800"></a><h3>ISCSI</h3><p>
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm
590"></a><h3>ISCSI</h3><p>
CTDB has support for managing the Linux iSCSI tgtd service.
- </p><div class="refsect3"><a name="idm
140222704751696"></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>
+ </p><div class="refsect3"><a name="idm
593"></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.
tgtd for each public IP address.
</p><p>
No default.
- </p></dd></dl></div></div><div class="refsect2"><a name="idm
140222704744576"></a><h3>MULTIPATHD</h3><p>
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm
610"></a><h3>MULTIPATHD</h3><p>
CTDB can monitor multipath devices to ensure that active paths
are available.
- </p><div class="refsect3"><a name="idm
140222704743456"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">20.multipathd</code></td></tr></table><p>
+ </p><div class="refsect3"><a name="idm
613"></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="idm
140222704737200"></a><h3>VSFTPD</h3><p>
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm
627"></a><h3>VSFTPD</h3><p>
CTDB can manage the vsftpd FTP server.
- </p><div class="refsect3"><a name="idm
140222704736176"></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>
+ </p><div class="refsect3"><a name="idm
630"></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>
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm641"></a><h3>
SYSTEM RESOURCE MONITORING CONFIGURATION
</h3><p>
CTDB can experience seemingly random (performance and other)
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="idm
140222704729616"></a><h4>Eventscripts</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">05.system</code></td></tr></table><p>
+ </p><div class="refsect3"><a name="idm
645"></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>
</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="idm
140222704711456"></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>
+ </p></dd></dl></div></div><div class="refsect2"><a name="idm
684"></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
managed or unmanaged.
</p><p>
Default is no.
- </p></dd></dl></div></div></div><div class="refsect1"><a name="idm140222704704928"></a><h2>
+ </p></dd></dl></div></div></div><div class="refsect1"><a name="idm700"></a><h2>
TUNABLES CONFIGURATION
</h2><p>
CTDB tunables (see
</p><pre class="screen">
CTDB_SET_MonitorInterval=20
</pre><p>
- </p></div><div class="refsect1"><a name="idm140222704700144"></a><h2>
+ </p></div><div class="refsect1"><a name="idm711"></a><h2>
DEBUG AND TEST
</h2><p>
Variable in this section are for debugging and testing CTDB.
runtime.
</p><p>
Defaults to <code class="filename">/usr/local/var/lib/ctdb</code>.
- </p></dd></dl></div></div><div class="refsect1"><a name="idm
140222704651408"></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>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm
822"></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="idm833"></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>,
-<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.7
8.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>
+<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.7
9.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="idm46088121867040"></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
<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="idm
140621591846720"></a><h2>SEE ALSO</h2><p>
+ </p></div><div class="refsect1"><a name="idm
46088123065984"></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>,
-<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.7
8.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>
+<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.7
9.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="idm46526557164304"></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>
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="idm
139640829958096"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-e</span></dt><dd><p>
+ </p></li></ul></div></div><div class="refsect1"><a name="idm
46526557607696"></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".
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="idm
139640833162512"></a><h2>COMMANDS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">help</span></dt><dd><p>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm
46526561410160"></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
</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="idm
139640833154640"></a><h2>EXAMPLES</h2><p>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm
46526561595136"></a><h2>EXAMPLES</h2><p>
Print a local tdb in "tdbdump" style:
</p><pre class="screen">
ltdbtool dump idmap2.tdb.0
Add a default header:
</p><pre class="screen">
ltdbtool convert -s0 idmap.tdb idmap2.tdb.0
- </pre></div><div class="refsect1"><a name="idm
139640833333616"></a><h2>SEE ALSO</h2><p>
+ </pre></div><div class="refsect1"><a name="idm
46526561586960"></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>,
-<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.7
8.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>
+<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.7
9.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="idm19"></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>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="idm
139965910891312"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-c</span></dt><dd><p>
+ </p></div><div class="refsect1"><a name="idm
27"></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>
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="idm
139965914755584"></a><h2>NODES SPECIFICATION</h2><p>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm
77"></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,
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>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm98"></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
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="idm1
39965914607472"></a><h2>ENVIRONMENT</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="envar">CTDB_BASE</code></span></dt><dd><p>
+ </pre></div><div class="refsect1"><a name="idm1
08"></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="idm1
39965914789184"></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>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm1
23"></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>
<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="idm1
39965914777120"></a><h2>SEE ALSO</h2><p>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm1
49"></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>
-<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.7
8.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>
+<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.7
9.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="idm45847900673440"></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
</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="idm
140370557909952"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-r</span></dt><dd><p>
+ </p></div><div class="refsect1"><a name="idm
45847899428656"></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
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="idm
140370560882016"></a><h2>EXAMPLES</h2><p>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm
45847903379600"></a><h2>EXAMPLES</h2><p>
Testing lock coherence
</p><pre class="screen">
ping_pong test.dat N
Testing IO coherence
</p><pre class="screen">
ping_pong -rw test.dat N
- </pre></div><div class="refsect1"><a name="idm
140370561032480"></a><h2>SEE ALSO</h2><p>
+ </pre></div><div class="refsect1"><a name="idm
45847903438176"></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>
git.samba.org / amitay / ctdb-web.git / commitdiff