<li><a href="/manpages/ping_pong.1.html">ping_pong (1)</a>
</ul>
-<p>Man pages for CTDB in Samba 4.8:</p>
-<ul>
-<li><a href="/manpages/4.8/ctdb.1.html">ctdb (1)</a>
-<li><a href="/manpages/4.8/ctdb_diagnostics.1.html">ctdb_diagnostics (1)</a>
-<li><a href="/manpages/4.8/ctdbd.1.html">ctdbd (1)</a>
-<li><a href="/manpages/4.8/ctdbd_wrapper.1.html">ctdbd_wrapper (1)</a>
-<li><a href="/manpages/4.8/ctdbd.conf.5.html">ctdbd.conf (5)</a>
-<li><a href="/manpages/4.8/ctdb.7.html">ctdb (7)</a>
-<li><a href="/manpages/4.8/ctdb-etcd.7.html">ctdb-etcd (7)</a>
-<li><a href="/manpages/4.8/ctdb_mutex_ceph_rados_helper.7.html">ctdb_mutex_ceph_rados_helper (7)</a>
-<li><a href="/manpages/4.8/ctdb-statistics.7.html">ctdb-statistics (7)</a>
-<li><a href="/manpages/4.8/ctdb-tunables.7.html">ctdb-tunables (7)</a>
-<li><a href="/manpages/4.8/onnode.1.html">onnode (1)</a>
-<li><a href="/manpages/4.8/ltdbtool.1.html">ltdbtool (1)</a>
-<li><a href="/manpages/4.8/ping_pong.1.html">ping_pong (1)</a>
-</ul>
-
<p>
Additional documentation that might not yet be fully migrated to the
wiki:
+++ /dev/null
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb-etcd</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-etcd.7"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb-etcd — CTDB etcd integration</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ctdb_etcd_lock</code> </p></div></div><div class="refsect1"><a name="idm24"></a><h2>DESCRIPTION</h2><p>
- ctdb_etcd_lock is intended to be run as a mutex helper for CTDB. It
- will try to connect to an existing etcd cluster and grab a lock in that
- cluster to function as CTDB's recovery lock. Please see
- <span class="emphasis"><em>ctdb/doc/cluster_mutex_helper.txt</em></span> for details on
- the mutex helper API. To use this, include the following line in your
- CTDB config file:
- </p><pre class="screen">
-CTDB_RECOVERY_LOCK="!/usr/local/usr/libexec/ctdb/ctdb_etcd_lock"
- </pre><p>
- You can also pass "-v", "-vv", or "-vvv" to include verbose output in
- the CTDB log. Additional "v"s indicate increases in verbosity.
- </p><p>
- This mutex helper expects the system Python interpreter to have access
- to the etcd Python module. It also expects an etcd cluster to be
- configured and running. To integrate with this, there is an optional
- config file of the following format:
- </p><pre class="screen">
-key = value
- </pre><p>
- The following configuration parameters (and their defaults) are defined
- for use by ctdb_etcd_lock:
- </p><pre class="screen">
-port = 2379 # connecting port for the etcd cluster
-lock_ttl = 9 # seconds for TTL
-refresh = 2 # seconds between attempts to maintain lock
-locks_dir = _ctdb # where to store CTDB locks in etcd
- # The final etcd directory for any given lock looks like:
- # /_locks/{locks_dir}/{netbios name}/
- </pre><p>
- In addition, any keyword parameter that can be used to configure an
- etcd client may be specified and modified here. For more documentation
- on these parameters, see here: https://github.com/jplana/python-etcd/
- </p></div><div class="refsect1"><a name="idm35"></a><h2>SEE ALSO</h2><p>
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
-
- <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
- </p></div></div></body></html>
+++ /dev/null
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb-statistics</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-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="idm10"></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="idm18"></a><h3>Example: ctdb statistics</h3><pre class="screen">
-CTDB version 1
-Current time of statistics : Fri Sep 12 13:32:32 2014
-Statistics collected since : (000 01:49:20) Fri Sep 12 11:43:12 2014
- num_clients 6
- frozen 0
- recovering 0
- num_recoveries 2
- client_packets_sent 281293
- client_packets_recv 296317
- node_packets_sent 452387
- node_packets_recv 182394
- keepalive_packets_sent 3927
- keepalive_packets_recv 3928
- node
- req_call 48605
- reply_call 1
- req_dmaster 23404
- reply_dmaster 24917
- reply_error 0
- req_message 958
- req_control 197513
- reply_control 153705
- client
- req_call 130866
- req_message 770
- req_control 168921
- timeouts
- call 0
- control 0
- traverse 0
- locks
- num_calls 220
- num_current 0
- num_pending 0
- num_failed 0
- total_calls 130866
- pending_calls 0
- childwrite_calls 1
- pending_childwrite_calls 0
- memory_used 334490
- max_hop_count 18
- total_ro_delegations 2
- total_ro_revokes 2
- hop_count_buckets: 42816 5464 26 1 0 0 0 0 0 0 0 0 0 0 0 0
- lock_buckets: 9 165 14 15 7 2 2 0 0 0 0 0 0 0 0 0
- locks_latency MIN/AVG/MAX 0.000685/0.160302/6.369342 sec out of 214
- reclock_ctdbd MIN/AVG/MAX 0.004940/0.004969/0.004998 sec out of 2
- reclock_recd MIN/AVG/MAX 0.000000/0.000000/0.000000 sec out of 0
- call_latency MIN/AVG/MAX 0.000006/0.000719/4.562991 sec out of 126626
- childwrite_latency MIN/AVG/MAX 0.014527/0.014527/0.014527 sec out of 1
- </pre></div><div class="refsect2"><a name="idm21"></a><h3>CTDB version</h3><p>
- Version of the ctdb protocol used by the node.
- </p></div><div class="refsect2"><a name="idm24"></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="idm28"></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="idm31"></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="idm34"></a><h3>frozen</h3><p>
- 1 if the the databases are currently frozen, 0 otherwise.
- </p></div><div class="refsect2"><a name="idm37"></a><h3>recovering</h3><p>
- 1 if recovery is active, 0 otherwise.
- </p></div><div class="refsect2"><a name="idm40"></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="idm43"></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="idm46"></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="idm49"></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="idm52"></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="idm55"></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="idm63"></a><h3>keepalive_packets_recv</h3><p>
- Number of keepalive messages received from other nodes.
- </p></div><div class="refsect2"><a name="idm66"></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="idm69"></a><h4>req_call</h4><p>
- Number of REQ_CALL messages from the other nodes.
- </p></div><div class="refsect3"><a name="idm72"></a><h4>reply_call</h4><p>
- Number of REPLY_CALL messages from the other nodes.
- </p></div><div class="refsect3"><a name="idm75"></a><h4>req_dmaster</h4><p>
- Number of REQ_DMASTER messages from the other nodes.
- </p></div><div class="refsect3"><a name="idm78"></a><h4>reply_dmaster</h4><p>
- Number of REPLY_DMASTER messages from the other nodes.
- </p></div><div class="refsect3"><a name="idm81"></a><h4>reply_error</h4><p>
- Number of REPLY_ERROR messages from the other nodes.
- </p></div><div class="refsect3"><a name="idm84"></a><h4>req_message</h4><p>
- Number of REQ_MESSAGE messages from the other nodes.
- </p></div><div class="refsect3"><a name="idm87"></a><h4>req_control</h4><p>
- Number of REQ_CONTROL messages from the other nodes.
- </p></div><div class="refsect3"><a name="idm90"></a><h4>reply_control</h4><p>
- Number of REPLY_CONTROL messages from the other nodes.
- </p></div><div class="refsect3"><a name="idm93"></a><h4>req_tunnel</h4><p>
- Number of REQ_TUNNEL messages from the other nodes.
- </p></div></div><div class="refsect2"><a name="idm96"></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="idm99"></a><h4>req_call</h4><p>
- Number of REQ_CALL messages from the clients.
- </p></div><div class="refsect3"><a name="idm102"></a><h4>req_message</h4><p>
- Number of REQ_MESSAGE messages from the clients.
- </p></div><div class="refsect3"><a name="idm105"></a><h4>req_control</h4><p>
- Number of REQ_CONTROL messages from the clients.
- </p></div><div class="refsect3"><a name="idm108"></a><h4>req_tunnel</h4><p>
- Number of REQ_TUNNEL messages from the clients.
- </p></div></div><div class="refsect2"><a name="idm111"></a><h3>timeouts</h3><p>
- This section lists timeouts occurred when sending various messages.
- </p><div class="refsect3"><a name="idm114"></a><h4>call</h4><p>
- Number of timeouts for REQ_CALL messages.
- </p></div><div class="refsect3"><a name="idm117"></a><h4>control</h4><p>
- Number of timeouts for REQ_CONTROL messages.
- </p></div><div class="refsect3"><a name="idm120"></a><h4>traverse</h4><p>
- Number of timeouts for database traverse operations.
- </p></div></div><div class="refsect2"><a name="idm123"></a><h3>locks</h3><p>
- This section lists locking statistics.
- </p><div class="refsect3"><a name="idm126"></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="idm129"></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="idm132"></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="idm135"></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="idm138"></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="idm141"></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="idm144"></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="idm147"></a><h3>pending_childwrite_calls</h3><p>
- Number of record update calls currently active.
- </p></div><div class="refsect2"><a name="idm150"></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="idm153"></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="idm156"></a><h3>total_ro_delegations</h3><p>
- Number of readonly delegations created.
- </p></div><div class="refsect2"><a name="idm159"></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="idm162"></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="idm165"></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="idm168"></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="idm171"></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="idm174"></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="idm177"></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="idm180"></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="idm184"></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="idm191"></a><h3>Example: ctdb dbstatistics notify_index.tdb</h3><pre class="screen">
-DB Statistics: notify_index.tdb
- ro_delegations 0
- ro_revokes 0
- locks
- total 131
- failed 0
- current 0
- pending 0
- hop_count_buckets: 9890 5454 26 1 0 0 0 0 0 0 0 0 0 0 0 0
- lock_buckets: 4 117 10 0 0 0 0 0 0 0 0 0 0 0 0 0
- locks_latency MIN/AVG/MAX 0.000683/0.004198/0.014730 sec out of 131
- Num Hot Keys: 3
- Count:7 Key:2f636c75737465726673
- Count:18 Key:2f636c757374657266732f64617461
- Count:7 Key:2f636c757374657266732f646174612f636c69656e7473
- </pre></div><div class="refsect2"><a name="idm194"></a><h3>DB Statistics</h3><p>
- Name of the database.
- </p></div><div class="refsect2"><a name="idm197"></a><h3>ro_delegations</h3><p>
- Number of readonly delegations created in the database.
- </p></div><div class="refsect2"><a name="idm200"></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="idm203"></a><h3>locks</h3><p>
- This section lists locking statistics.
- </p><div class="refsect3"><a name="idm206"></a><h4>total</h4><p>
- Number of completed lock calls. This includes database locks
- and record locks.
- </p></div><div class="refsect3"><a name="idm209"></a><h4>failed</h4><p>
- Number of failed lock calls. This includes database locks and
- record locks.
- </p></div><div class="refsect3"><a name="idm212"></a><h4>current</h4><p>
- Number of scheduled lock calls. This includes database locks
- and record locks.
- </p></div><div class="refsect3"><a name="idm215"></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="idm218"></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="idm221"></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="idm224"></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="idm227"></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="idm230"></a><h2>SEE ALSO</h2><p>
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span>,
-
- <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
- </p></div></div></body></html>
+++ /dev/null
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb-tunables</title><meta name="generator" content="DocBook XSL Stylesheets V1.79.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><p>
- Unless otherwise stated, tunables should be set to the same
- value on all nodes. Setting tunables to different values across
- nodes may produce unexpected results. Future releases may set
- (some or most) tunables globally across the cluster but doing so
- is currently a manual process.
- </p><p>
- The tunable variables are listed alphabetically.
- </p><div class="refsect2"><a name="idm21"></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="idm25"></a><h3>AllowMixedVersions</h3><p>Default: 0</p><p>
- CTDB will not allow incompatible versions to co-exist in
- a cluster. If a version mismatch is found, then losing CTDB
- will shutdown. To disable the incompatible version check,
- set this tunable to 1.
- </p><p>
- For version checking, CTDB uses major and minor version.
- For example, CTDB 4.6.1 and CTDB CTDB 4.6.2 are matching versions;
- CTDB 4.5.x and CTDB 4.6.y do not match.
- </p><p>
- CTDB with version check support will lose to CTDB without
- version check support. Between two different CTDB versions with
- version check support, one running for less time will lose.
- If the running time for both CTDB versions with version check
- support is equal (to seconds), then the older version will lose.
- The losing CTDB daemon will shutdown.
- </p></div><div class="refsect2"><a name="idm31"></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="idm35"></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="idm39"></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="idm43"></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="idm47"></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="idm51"></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="idm55"></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="idm59"></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>
- 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="idm64"></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>
- 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="idm69"></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="idm73"></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.
- </p></div><div class="refsect2"><a name="idm78"></a><h3>EventScriptTimeout</h3><p>Default: 30</p><p>
- Maximum time in seconds to allow an event to run before timing
- out. This is the total time for all enabled scripts that are
- run for an event, not just a single event script.
- </p><p>
- Note that timeouts are ignored for some events ("takeip",
- "releaseip", "startrecovery", "recovered") and converted to
- success. The logic here is that the callers of these events
- implement their own additional timeout.
- </p></div><div class="refsect2"><a name="idm83"></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>
- 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="idm88"></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="idm95"></a><h3>IPAllocAlgorithm</h3><p>Default: 2</p><p>
- Selects the algorithm that CTDB should use when doing public
- IP address allocation. Meaningful values are:
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">0</span></dt><dd><p>
- Deterministic IP address allocation.
- </p><p>
- This is a simple and fast option. However, it can cause
- unnecessary address movement during fail-over because
- each address has a "home" node. Works badly when some
- nodes do not have any addresses defined. Should be used
- with care when addresses are defined across multiple
- networks.
- </p></dd><dt><span class="term">1</span></dt><dd><p>
- Non-deterministic IP address allocation.
- </p><p>
- This is a relatively fast option that attempts to do a
- minimise unnecessary address movements. Addresses do
- not have a "home" node. Rebalancing is limited but it
- usually adequate. Works badly when addresses are
- defined across multiple networks.
- </p></dd><dt><span class="term">2</span></dt><dd><p>
- LCP2 IP address allocation.
- </p><p>
- Uses a heuristic to assign addresses defined across
- multiple networks, usually balancing addresses on each
- network evenly across nodes. Addresses do not have a
- "home" node. Minimises unnecessary address movements.
- The algorithm is complex, so is slower than other
- choices for a large number of addresses. However, it
- can calculate an optimal assignment of 900 addresses in
- under 10 seconds on modern hardware.
- </p></dd></dl></div><p>
- If the specified value is not one of these then the default
- will be used.
- </p></div><div class="refsect2"><a name="idm116"></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="idm120"></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="idm127"></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="idm131"></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="idm135"></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="idm139"></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="idm143"></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="idm147"></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>
- Use with caution! Normally when a node becomes available to the
- cluster ctdb will try to reassign public IP addresses onto the
- new node as a way to distribute the workload evenly across the
- clusternode. Ctdb tries to make sure that all running nodes have
- approximately the same number of public addresses it hosts.
- </p><p>
- When you enable this tunable, ctdb will no longer attempt to
- rebalance the cluster by failing IP addresses back to the new
- nodes. An unbalanced cluster will therefore remain unbalanced
- until there is manual intervention from the administrator. When
- this parameter is set, you can manually fail public IP addresses
- over to the new node(s) using the 'ctdb moveip' command.
- </p></div><div class="refsect2"><a name="idm153"></a><h3>NoIPHostOnAllDisabled</h3><p>Default: 0</p><p>
- If no nodes are HEALTHY then by default ctdb will happily host
- public IPs on disabled (unhealthy or administratively disabled)
- nodes. This can cause problems, for example if the underlying
- cluster filesystem is not mounted. When set to 1 and a 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="idm157"></a><h3>NoIPTakeover</h3><p>Default: 0</p><p>
- When set to 1, ctdb will not allow IP addresses to be failed
- over to other nodes. Any IP addresses already hosted on
- healthy nodes will remain. Usually IP addresses hosted on
- unhealthy nodes will also remain, if NoIPHostOnAllDisabled is
- 0. However, if NoIPHostOnAllDisabled is 1 then IP addresses
- will be released by unhealthy nodes and will become un-hosted.
- </p></div><div class="refsect2"><a name="idm161"></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="idm165"></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>
- 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="idm170"></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="idm174"></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="idm178"></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="idm183"></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="idm187"></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="idm191"></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="idm195"></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>
- 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="idm200"></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="idm204"></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="idm208"></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>
- 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="idm216"></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="idm220"></a><h3>SeqnumInterval</h3><p>Default: 1000</p><p>
- Some databases have seqnum tracking enabled, so that samba will
- be able to detect asynchronously when there has been updates
- to the database. Everytime a database is updated its sequence
- number is increased.
- </p><p>
- This tunable is used to specify in 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="idm225"></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="idm229"></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="idm233"></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="idm237"></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="idm241"></a><h3>TDBMutexEnabled</h3><p>Default: 1</p><p>
- This parameter 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="idm245"></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="idm250"></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="idm254"></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="idm259"></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="idm263"></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="idm271"></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="idm275"></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="idm279"></a><h2>SEE ALSO</h2><p>
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
-
- <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
- </p></div></div></body></html>
+++ /dev/null
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb</title><meta name="generator" content="DocBook XSL Stylesheets V1.79.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
- cluster:
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">PNN</span></dt><dd><p>
- Physical Node Number. The physical node number is an
- integer that describes the node in the cluster. The
- first node has physical node number 0. in a cluster.
- </p></dd><dt><span class="term">PNN-LIST</span></dt><dd><p>
- This is either a single PNN, a comma-separate list of PNNs
- or "all".
- </p></dd></dl></div><p>
- </p><p>
- Commands that reference a database use the following terms:
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">DB</span></dt><dd><p>
- This is either a database name, such as
- <code class="filename">locking.tdb</code> or a database ID such
- as "0x42fe72c5".
- </p></dd><dt><span class="term">DB-LIST</span></dt><dd><p>
- A space separated list of at least one
- <em class="parameter"><code>DB</code></em>.
- </p></dd></dl></div><p>
- </p></div><div class="refsect1"><a name="idm56"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-n <em class="parameter"><code>PNN</code></em></span></dt><dd><p>
- The node specified by PNN should be queried for the
- requested information. Default is to query the daemon
- running on the local host.
- </p></dd><dt><span class="term">-Y</span></dt><dd><p>
- Produce output in machine readable form for easier parsing
- by scripts. This uses a field delimiter of ':'. Not all
- commands support this option.
- </p></dd><dt><span class="term">-x <em class="parameter"><code>SEPARATOR</code></em></span></dt><dd><p>
- Use SEPARATOR to delimit fields in machine readable output.
- This implies -Y.
- </p></dd><dt><span class="term">-X</span></dt><dd><p>
- Produce output in machine readable form for easier parsing
- by scripts. This uses a field delimiter of '|'. Not all
- commands support this option.
- </p><p>
- This is equivalent to "-x|" and avoids some shell quoting
- issues.
- </p></dd><dt><span class="term">-t <em class="parameter"><code>TIMEOUT</code></em></span></dt><dd><p>
- Indicates that ctdb should wait up to TIMEOUT seconds for
- a response to most commands sent to the CTDB daemon. The
- default is 10 seconds.
- </p></dd><dt><span class="term">-T <em class="parameter"><code>TIMELIMIT</code></em></span></dt><dd><p>
- Indicates that TIMELIMIT is the maximum run time (in
- seconds) for the ctdb command. When TIMELIMIT is exceeded
- the ctdb command will terminate with an error. The default
- is 120 seconds.
- </p></dd><dt><span class="term">-? --help</span></dt><dd><p>
- Print some help text to the screen.
- </p></dd><dt><span class="term">--usage</span></dt><dd><p>
- Print useage information to the screen.
- </p></dd><dt><span class="term">-d --debug=<em class="parameter"><code>DEBUGLEVEL</code></em></span></dt><dd><p>
- Change the debug level for the command. Default is NOTICE.
- </p></dd><dt><span class="term">--socket=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- Specify that FILENAME is the name of the Unix domain
- socket to use when connecting to the local CTDB
- daemon. The default is
- <code class="filename">/usr/local/var/run/ctdb/ctdbd.socket</code>.
- </p></dd></dl></div></div><div class="refsect1"><a name="idm107"></a><h2>ADMINISTRATIVE COMMANDS</h2><p>
- These are commands used to monitor and administer a CTDB cluster.
- </p><div class="refsect2"><a name="idm110"></a><h3>pnn</h3><p>
- This command displays the PNN of the current node.
- </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="idm117"></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="idm123"></a><h4>Generation</h4><p>
- The generation id is a number that indicates the current generation
- of a cluster instance. Each time a cluster goes through a
- reconfiguration or a recovery its generation id will be changed.
- </p><p>
- This number does not have any particular meaning other than
- to keep track of when a cluster has gone through a
- recovery. It is a random number that represents the current
- instance of a ctdb cluster and its databases. The CTDB
- daemon uses this number internally to be able to tell when
- commands to operate on the cluster and the databases was
- issued in a different generation of the cluster, to ensure
- that commands that operate on the databases will not survive
- across a cluster database recovery. After a recovery, all
- old outstanding commands will automatically become invalid.
- </p><p>
- Sometimes this number will be shown as "INVALID". This only means that
- the ctdbd daemon has started but it has not yet merged with the cluster through a recovery.
- All nodes start with generation "INVALID" and are not assigned a real
- generation id until they have successfully been merged with a cluster
- through a recovery.
- </p></div><div class="refsect3"><a name="idm128"></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. Only nodes
- that are participating in the VNN map can become lmaster for
- database records.
- </p></div><div class="refsect3"><a name="idm131"></a><h4>Recovery mode</h4><p>
- This is the current recovery mode of the cluster. There are two possible modes:
- </p><p>
- NORMAL - The cluster is fully operational.
- </p><p>
- RECOVERY - The cluster databases have all been frozen, pausing all services while the cluster awaits a recovery process to complete. A recovery process should finish within seconds. If a cluster is stuck in the RECOVERY state this would indicate a cluster malfunction which needs to be investigated.
- </p><p>
- Once the recovery master detects an inconsistency, for example a node
- becomes disconnected/connected, the recovery daemon will trigger a
- cluster recovery process, where all databases are remerged across the
- cluster. When this process starts, the recovery master will first
- "freeze" all databases to prevent applications such as samba from
- accessing the databases and it will also mark the recovery mode as
- RECOVERY.
- </p><p>
- When the CTDB daemon starts up, it will start in RECOVERY
- mode. Once the node has been merged into a cluster and all
- databases have been recovered, the node mode will change into
- NORMAL mode and the databases will be "thawed", allowing samba
- to access the databases again.
- </p></div><div class="refsect3"><a name="idm138"></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="idm142"></a><h4>Example</h4><pre class="screen">
-# ctdb status
-Number of nodes:4
-pnn:0 192.168.2.200 OK (THIS NODE)
-pnn:1 192.168.2.201 OK
-pnn:2 192.168.2.202 OK
-pnn:3 192.168.2.203 OK
-Generation:1362079228
-Size:4
-hash:0 lmaster:0
-hash:1 lmaster:1
-hash:2 lmaster:2
-hash:3 lmaster:3
-Recovery mode:NORMAL (0)
-Recovery master:0
- </pre></div></div><div class="refsect2"><a name="idm145"></a><h3>nodestatus [<span class="optional"><em class="parameter"><code>PNN-LIST</code></em></span>]</h3><p>
- This command is similar to the <span class="command"><strong>status</strong></span>
- command. It displays the "node status" subset of output. The
- main differences are:
- </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
- The exit code is the bitwise-OR of the flags for each
- specified node, while <span class="command"><strong>ctdb status</strong></span> exits
- with 0 if it was able to retrieve status for all nodes.
- </p></li><li class="listitem"><p>
- <span class="command"><strong>ctdb status</strong></span> provides status information
- for all nodes. <span class="command"><strong>ctdb nodestatus</strong></span>
- defaults to providing status for only the current node.
- If PNN-LIST is provided then status is given for
- the indicated node(s).
- </p></li></ul></div><p>
- A common invocation in scripts is <span class="command"><strong>ctdb nodestatus
- all</strong></span> to check whether all nodes in a cluster are
- healthy.
- </p><div class="refsect3"><a name="idm161"></a><h4>Example</h4><pre class="screen">
-# ctdb nodestatus
-pnn:0 10.0.0.30 OK (THIS NODE)
-
-# ctdb nodestatus all
-Number of nodes:2
-pnn:0 10.0.0.30 OK (THIS NODE)
-pnn:1 10.0.0.31 OK
- </pre></div></div><div class="refsect2"><a name="idm164"></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="idm168"></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="idm171"></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="idm174"></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="idm177"></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="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></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="idm209"></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="idm212"></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="idm215"></a><h4>Example</h4><pre class="screen">
-# ctdb ifaces
-Interfaces on node 0
-name:eth5 link:up references:2
-name:eth4 link:down references:0
-name:eth3 link:up references:1
-name:eth2 link:up references:1
-
-# ctdb -X ifaces
-|Name|LinkStatus|References|
-|eth5|1|2|
-|eth4|0|0|
-|eth3|1|1|
-|eth2|1|1|
- </pre></div></div><div class="refsect2"><a name="idm218"></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="idm221"></a><h4>Example</h4><pre class="screen">
-# ctdb ip -v
-Public IPs on node 0
-172.31.91.82 node[1] active[] available[eth2,eth3] configured[eth2,eth3]
-172.31.91.83 node[0] active[eth3] available[eth2,eth3] configured[eth2,eth3]
-172.31.91.84 node[1] active[] available[eth2,eth3] configured[eth2,eth3]
-172.31.91.85 node[0] active[eth2] available[eth2,eth3] configured[eth2,eth3]
-172.31.92.82 node[1] active[] available[eth5] configured[eth4,eth5]
-172.31.92.83 node[0] active[eth5] available[eth5] configured[eth4,eth5]
-172.31.92.84 node[1] active[] available[eth5] configured[eth4,eth5]
-172.31.92.85 node[0] active[eth5] available[eth5] configured[eth4,eth5]
-
-# ctdb -X ip -v
-|Public IP|Node|ActiveInterface|AvailableInterfaces|ConfiguredInterfaces|
-|172.31.91.82|1||eth2,eth3|eth2,eth3|
-|172.31.91.83|0|eth3|eth2,eth3|eth2,eth3|
-|172.31.91.84|1||eth2,eth3|eth2,eth3|
-|172.31.91.85|0|eth2|eth2,eth3|eth2,eth3|
-|172.31.92.82|1||eth5|eth4,eth5|
-|172.31.92.83|0|eth5|eth5|eth4,eth5|
-|172.31.92.84|1||eth5|eth4,eth5|
-|172.31.92.85|0|eth5|eth5|eth4,eth5|
- </pre></div></div><div class="refsect2"><a name="idm224"></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="idm228"></a><h4>Example</h4><pre class="screen">
-# ctdb ipinfo 172.31.92.85
-Public IP[172.31.92.85] info on node 0
-IP:172.31.92.85
-CurrentNode:0
-NumInterfaces:2
-Interface[1]: Name:eth4 Link:down References:0
-Interface[2]: Name:eth5 Link:up References:2 (active)
- </pre></div></div><div class="refsect2"><a name="idm231"></a><h3>event run|status|script list|script enable|script disable</h3><p>
- This command is used to control event daemon and to inspect
- status of various events.
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">run <em class="parameter"><code>EVENT</code></em> <em class="parameter"><code>TIMEOUT</code></em> [<span class="optional"><em class="parameter"><code>ARGUMENTS</code></em></span>] </span></dt><dd><p>
- This command can be used to manually run specified EVENT
- with optional ARGUMENTS. The event will be allowed to run
- a maximum of TIMEOUT seconds. If TIMEOUT is 0, then there
- is no time limit for running the event.
- </p></dd><dt><span class="term">status [<span class="optional"><em class="parameter"><code>EVENT</code></em></span>] [<span class="optional">lastrun|lastpass|lastfail</span>]</span></dt><dd><p>
- This command displays the last execution status of the
- specified EVENT. If no event is specified, then the status
- of last executed monitor event will be displayed.
- </p><p>
- To see the last successful execution of the event, lastpass
- can be specified. Similarly lastfail can be specified
- to see the last unsuccessful execution of the event.
- The optional lastrun can be specified to query the last
- execution of the event.
- </p><p>
- The command will terminate with the exit status
- corresponding to the overall status of event that is
- displayed. If lastpass is specified, then the command will
- always terminate with 0. If lastfail is specified then the
- command will always terminate with non-zero exit status.
- If lastrun is specified, then the command will terminate
- with 0 or not depending on if the last execution of the
- event was successful or not.
- </p><p>
- The output is the list of event scripts executed.
- Each line shows the name, status, duration and start time
- for each script.
- </p><p>
- Example output:
- </p><pre class="screen">
-00.ctdb OK 0.014 Sat Dec 17 19:39:11 2016
-01.reclock OK 0.013 Sat Dec 17 19:39:11 2016
-05.system OK 0.029 Sat Dec 17 19:39:11 2016
-06.nfs OK 0.014 Sat Dec 17 19:39:11 2016
-10.external DISABLED
-10.interface OK 0.037 Sat Dec 17 19:39:11 2016
-11.natgw OK 0.011 Sat Dec 17 19:39:11 2016
-11.routing OK 0.007 Sat Dec 17 19:39:11 2016
-13.per_ip_routing OK 0.007 Sat Dec 17 19:39:11 2016
-20.multipathd OK 0.007 Sat Dec 17 19:39:11 2016
-31.clamd OK 0.007 Sat Dec 17 19:39:11 2016
-40.vsftpd OK 0.013 Sat Dec 17 19:39:11 2016
-41.httpd OK 0.018 Sat Dec 17 19:39:11 2016
-49.winbind OK 0.023 Sat Dec 17 19:39:11 2016
-50.samba OK 0.100 Sat Dec 17 19:39:12 2016
-60.nfs OK 0.376 Sat Dec 17 19:39:12 2016
-70.iscsi OK 0.009 Sat Dec 17 19:39:12 2016
-91.lvs OK 0.007 Sat Dec 17 19:39:12 2016
-99.timeout OK 0.007 Sat Dec 17 19:39:12 2016
- </pre></dd><dt><span class="term">script list</span></dt><dd><p>
- List the available event scripts.
- </p><p>
- Example output:
- </p><pre class="screen">
-00.ctdb
-01.reclock
-05.system
-06.nfs
-10.external DISABLED
-10.interface
-11.natgw
-11.routing
-13.per_ip_routing
-20.multipathd
-31.clamd
-40.vsftpd
-41.httpd
-49.winbind
-50.samba
-60.nfs
-70.iscsi
-91.lvs
-99.timeout
- </pre></dd><dt><span class="term">script enable <em class="parameter"><code>SCRIPT</code></em></span></dt><dd><p>
- Enable the specified event SCRIPT. Only enabled scripts will be
- executed when running any event.
- </p></dd><dt><span class="term">script disable <em class="parameter"><code>SCRIPT</code></em></span></dt><dd><p>
- Disable the specified event SCRIPT. This will prevent the script
- from executing when running any event.
- </p></dd></dl></div></div><div class="refsect2"><a name="idm271"></a><h3>scriptstatus</h3><p>
- This command displays which event 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><p>
- This command is deprecated. It's provided for backward
- compatibility. In place of <span class="command"><strong>ctdb scriptstatus</strong></span>,
- use <span class="command"><strong>ctdb event status</strong></span>.
- </p><div class="refsect3"><a name="idm277"></a><h4>Example</h4><pre class="screen">
-# ctdb scriptstatus
-00.ctdb OK 0.011 Sat Dec 17 19:40:46 2016
-01.reclock OK 0.010 Sat Dec 17 19:40:46 2016
-05.system OK 0.030 Sat Dec 17 19:40:46 2016
-06.nfs OK 0.014 Sat Dec 17 19:40:46 2016
-10.external DISABLED
-10.interface OK 0.041 Sat Dec 17 19:40:46 2016
-11.natgw OK 0.008 Sat Dec 17 19:40:46 2016
-11.routing OK 0.007 Sat Dec 17 19:40:46 2016
-13.per_ip_routing OK 0.007 Sat Dec 17 19:40:46 2016
-20.multipathd OK 0.007 Sat Dec 17 19:40:46 2016
-31.clamd OK 0.007 Sat Dec 17 19:40:46 2016
-40.vsftpd OK 0.013 Sat Dec 17 19:40:46 2016
-41.httpd OK 0.015 Sat Dec 17 19:40:46 2016
-49.winbind OK 0.022 Sat Dec 17 19:40:46 2016
-50.samba ERROR 0.077 Sat Dec 17 19:40:46 2016
- OUTPUT: ERROR: samba tcp port 445 is not responding
- </pre></div></div><div class="refsect2"><a name="idm280"></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="idm283"></a><h4>Example</h4><pre class="screen">
-# ctdb listvars
-SeqnumInterval = 1000
-ControlTimeout = 60
-TraverseTimeout = 20
-KeepaliveInterval = 5
-KeepaliveLimit = 5
-RecoverTimeout = 120
-RecoverInterval = 1
-ElectionTimeout = 3
-TakeoverTimeout = 9
-MonitorInterval = 15
-TickleUpdateInterval = 20
-EventScriptTimeout = 30
-MonitorTimeoutCount = 20
-RecoveryGracePeriod = 120
-RecoveryBanPeriod = 300
-DatabaseHashSize = 100001
-DatabaseMaxDead = 5
-RerecoveryTimeout = 10
-EnableBans = 1
-NoIPFailback = 0
-DisableIPFailover = 0
-VerboseMemoryNames = 0
-RecdPingTimeout = 60
-RecdFailCount = 10
-LogLatencyMs = 0
-RecLockLatencyMs = 1000
-RecoveryDropAllIPs = 120
-VacuumInterval = 10
-VacuumMaxRunTime = 120
-RepackLimit = 10000
-VacuumLimit = 5000
-VacuumFastPathCount = 60
-MaxQueueDropMsg = 1000000
-AllowUnhealthyDBRead = 0
-StatHistoryInterval = 1
-DeferredAttachTO = 120
-AllowClientDBAttach = 1
-RecoverPDBBySeqNum = 1
-DeferredRebalanceOnNodeAdd = 300
-FetchCollapse = 1
-HopcountMakeSticky = 50
-StickyDuration = 600
-StickyPindown = 200
-NoIPTakeover = 0
-DBRecordCountWarn = 100000
-DBRecordSizeWarn = 10000000
-DBSizeWarn = 100000000
-PullDBPreallocation = 10485760
-NoIPHostOnAllDisabled = 0
-TDBMutexEnabled = 1
-LockProcessesPerDB = 200
-RecBufferSizeLimit = 1000000
-QueueBufferSize = 1024
-IPAllocAlgorithm = 2
- </pre></div></div><div class="refsect2"><a name="idm286"></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="idm290"></a><h4>Example</h4><pre class="screen">
-# ctdb getvar MonitorInterval
-MonitorInterval = 15
- </pre></div></div><div class="refsect2"><a name="idm293"></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><div class="refsect3"><a name="idm298"></a><h4>Example</h4><pre class="screen">
-# ctdb setvar MonitorInterval 20
- </pre></div></div><div class="refsect2"><a name="idm301"></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">
-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="idm327"></a><h3>getcapabilities</h3><p>
- This command shows the capabilities of the current node. See
- the <em class="citetitle">CAPABILITIES</em> section in
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more details.
- </p><p>
- Example output:
- </p><pre class="screen">
-RECMASTER: YES
-LMASTER: YES
- </pre></div><div class="refsect2"><a name="idm336"></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="idm342"></a><h4>Example</h4><pre class="screen">
-# ctdb statistics
-CTDB version 1
-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="idm345"></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="idm349"></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="idm356"></a><h4>Example</h4><pre class="screen">
-# ctdb dbstatistics locking.tdb
-DB Statistics: locking.tdb
- ro_delegations 0
- ro_revokes 0
- locks
- total 14356
- failed 0
- current 0
- pending 0
- hop_count_buckets: 28087 2 1 0 0 0 0 0 0 0 0 0 0 0 0 0
- lock_buckets: 0 14188 38 76 32 19 3 0 0 0 0 0 0 0 0 0
- locks_latency MIN/AVG/MAX 0.001066/0.012686/4.202292 sec out of 14356
- 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="idm359"></a><h3>getreclock</h3><p>
- Show details of the recovery lock, if any.
- </p><p>
- Example output:
- </p><pre class="screen">
- /clusterfs/.ctdb/recovery.lock
- </pre></div><div class="refsect2"><a name="idm364"></a><h3>getdebug</h3><p>
- Get the current debug level for the node. the debug level controls what information is written to the log file.
- </p><p>
- The debug levels are mapped to the corresponding syslog levels.
- When a debug level is set, only those messages at that level and higher
- levels will be printed.
- </p><p>
- The list of debug levels from highest to lowest are :
- </p><p>
- ERROR WARNING NOTICE INFO DEBUG
- </p></div><div class="refsect2"><a name="idm370"></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 ERROR WARNING NOTICE INFO DEBUG
- </p></div><div class="refsect2"><a name="idm375"></a><h3>getpid</h3><p>
- This command will return the process id of the ctdb daemon.
- </p></div><div class="refsect2"><a name="idm378"></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="idm381"></a><h3>enable</h3><p>
- Re-enable a node that has been administratively disabled.
- </p></div><div class="refsect2"><a name="idm384"></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="idm387"></a><h3>continue</h3><p>
- Re-start a node that has been administratively stopped.
- </p></div><div class="refsect2"><a name="idm390"></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="idm398"></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="idm404"></a><h3>moveip <em class="parameter"><code>IPADDR</code></em> <em class="parameter"><code>PNN</code></em></h3><p>
- This command can be used to manually fail a public ip address to a
- specific node.
- </p><p>
- In order to manually override the "automatic" distribution of public
- ip addresses that ctdb normally provides, this command only works
- when you have changed the tunables for the daemon to:
- </p><p>
- IPAllocAlgorithm != 0
- </p><p>
- NoIPFailback = 1
- </p></div><div class="refsect2"><a name="idm412"></a><h3>shutdown</h3><p>
- This command will shutdown a specific CTDB daemon.
- </p></div><div class="refsect2"><a name="idm415"></a><h3>setlmasterrole on|off</h3><p>
- This command is used ot enable/disable the LMASTER capability for a node at runtime. This capability determines whether or not a node can be used as an LMASTER for records in the database. A node that does not have the LMASTER capability will not show up in the vnnmap.
- </p><p>
- Nodes will by default have this capability, but it can be stripped off nodes by the setting in the sysconfig file or by using this command.
- </p><p>
- Once this setting has been enabled/disabled, you need to perform a recovery for it to take effect.
- </p><p>
- See also "ctdb getcapabilities"
- </p></div><div class="refsect2"><a name="idm421"></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="idm426"></a><h3>reloadnodes</h3><p>
- This command is used when adding new nodes, or removing
- existing nodes from an existing cluster.
- </p><p>
- Procedure to add nodes:
- </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
- To expand an existing cluster, first ensure with
- <span class="command"><strong>ctdb status</strong></span> that all nodes are up and
- running and that they are all healthy. Do not try to
- expand a cluster unless it is completely healthy!
- </p></li><li class="listitem"><p>
- On all nodes, edit <code class="filename">/usr/local/etc/ctdb/nodes</code>
- and <span class="emphasis"><em>add the new nodes at the end of this
- file</em></span>.
- </p></li><li class="listitem"><p>
- Verify that all the nodes have identical
- <code class="filename">/usr/local/etc/ctdb/nodes</code> files after adding
- the new nodes.
- </p></li><li class="listitem"><p>
- Run <span class="command"><strong>ctdb reloadnodes</strong></span> to force all nodes
- to reload the nodes file.
- </p></li><li class="listitem"><p>
- Use <span class="command"><strong>ctdb status</strong></span> on all nodes and verify
- that they now show the additional nodes.
- </p></li><li class="listitem"><p>
- Install and configure the new node and bring it online.
- </p></li></ol></div><p>
- Procedure to remove nodes:
- </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
- To remove nodes from an existing cluster, first ensure
- with <span class="command"><strong>ctdb status</strong></span> that all nodes, except
- the node to be deleted, are up and running and that they
- are all healthy. Do not try to remove nodes from a
- cluster unless the cluster is completely healthy!
- </p></li><li class="listitem"><p>
- Shutdown and power off the node to be removed.
- </p></li><li class="listitem"><p>
- On all other nodes, edit the
- <code class="filename">/usr/local/etc/ctdb/nodes</code> file and
- <span class="emphasis"><em>comment out</em></span> the nodes to be removed.
- <span class="emphasis"><em>Do not delete the lines for the deleted
- nodes</em></span>, just comment them out by adding a '#' at
- the beginning of the lines.
- </p></li><li class="listitem"><p>
- Run <span class="command"><strong>ctdb reloadnodes</strong></span> to force all nodes
- to reload the nodes file.
- </p></li><li class="listitem"><p>
- Use <span class="command"><strong>ctdb status</strong></span> on all nodes and verify
- that the deleted nodes are no longer listed.
- </p></li></ol></div></div><div class="refsect2"><a name="idm467"></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><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="idm473"></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. Some database are flagged as REPLICATED,
- this means that the data in that database is replicated across all
- the nodes. But the data will not remain across reboots. This
- type of database is used by CTDB to store it's internal state.
- </p><p>
- If a PERSISTENT database is not in a healthy state the database
- is flagged as UNHEALTHY. If there's at least one completely
- healthy node running in the cluster, it's possible that the
- content is restored by a recovery run automaticly. Otherwise an
- administrator needs to analyze the problem.
- </p><p>
- See also "ctdb getdbstatus", "ctdb backupdb", "ctdb restoredb",
- "ctdb dumpbackup", "ctdb wipedb", "ctdb setvar AllowUnhealthyDBRead 1"
- and (if samba or tdb-utils are installed) "tdbtool check".
- </p><p>
- Most databases are not persistent and only store the state
- information that the currently running samba daemons need. These
- databases are always wiped when ctdb/samba starts and when a
- node is rebooted.
- </p><div class="refsect3"><a name="idm479"></a><h4>Example</h4><pre class="screen">
-# ctdb getdbmap
-Number of databases:10
-dbid:0x435d3410 name:notify.tdb path:/usr/local/var/lib/ctdb/notify.tdb.0
-dbid:0x42fe72c5 name:locking.tdb path:/usr/local/var/lib/ctdb/locking.tdb.0
-dbid:0x1421fb78 name:brlock.tdb path:/usr/local/var/lib/ctdb/brlock.tdb.0
-dbid:0x17055d90 name:connections.tdb path:/usr/local/var/lib/ctdb/connections.tdb.0
-dbid:0xc0bdde6a name:sessionid.tdb path:/usr/local/var/lib/ctdb/sessionid.tdb.0
-dbid:0x122224da name:test.tdb path:/usr/local/var/lib/ctdb/test.tdb.0
-dbid:0x2672a57f name:idmap2.tdb path:/usr/local/var/lib/ctdb/persistent/idmap2.tdb.0 PERSISTENT
-dbid:0xb775fff6 name:secrets.tdb path:/usr/local/var/lib/ctdb/persistent/secrets.tdb.0 PERSISTENT
-dbid:0xe98e08b6 name:group_mapping.tdb path:/usr/local/var/lib/ctdb/persistent/group_mapping.tdb.0 PERSISTENT
-dbid:0x7bbbd26c name:passdb.tdb path:/usr/local/var/lib/ctdb/persistent/passdb.tdb.0 PERSISTENT
-
-# ctdb getdbmap # example for unhealthy database
-Number of databases:1
-dbid:0xb775fff6 name:secrets.tdb path:/usr/local/var/lib/ctdb/persistent/secrets.tdb.0 PERSISTENT UNHEALTHY
-
-# ctdb -X getdbmap
-|ID|Name|Path|Persistent|Unhealthy|
-|0x7bbbd26c|passdb.tdb|/usr/local/var/lib/ctdb/persistent/passdb.tdb.0|1|0|
- </pre></div></div><div class="refsect2"><a name="idm482"></a><h3>
- backupdb
- <em class="parameter"><code>DB</code></em>
- <em class="parameter"><code>FILE</code></em>
- </h3><p>
- Copy the contents of database DB to FILE. FILE can later be
- read back using <span class="command"><strong>restoredb</strong></span>. This is mainly
- useful for backing up persistent databases such as
- <code class="filename">secrets.tdb</code> and similar.
- </p></div><div class="refsect2"><a name="idm489"></a><h3>
- restoredb
- <em class="parameter"><code>FILE</code></em>
- [<span class="optional"><em class="parameter"><code>DB</code></em></span>]
- </h3><p>
- This command restores a persistent database that was
- previously backed up using backupdb. By default the data will
- be restored back into the same database as it was created
- from. By specifying dbname you can restore the data into a
- different database.
- </p></div><div class="refsect2"><a name="idm495"></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="idm499"></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="idm503"></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="idm506"></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="idm510"></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="idm515"></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="idm520"></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="idm525"></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="idm531"></a><h3>
- ptrans
- <em class="parameter"><code>DB</code></em>
- [<span class="optional"><em class="parameter"><code>FILE</code></em></span>]
- </h3><p>
- Read a list of key-value pairs, one per line from FILE, and
- store them in DB using a single transaction. An empty value
- is equivalent to deleting the given key.
- </p><p>
- The key and value should be separated by spaces or tabs. Each
- key/value should be a printable string enclosed in
- double-quotes.
- </p></div><div class="refsect2"><a name="idm538"></a><h3>runstate [setup|first_recovery|startup|running]</h3><p>
- Print the runstate of the specified node. Runstates are used
- to serialise important state transitions in CTDB, particularly
- during startup.
- </p><p>
- If one or more optional runstate arguments are specified then
- the node must be in one of these runstates for the command to
- succeed.
- </p><div class="refsect3"><a name="idm542"></a><h4>Example</h4><pre class="screen">
-# ctdb runstate
-RUNNING
- </pre></div></div><div class="refsect2"><a name="idm545"></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="idm551"></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
- occurred 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="idm562"></a><h3>version</h3><p>
- Display the CTDB version.
- </p></div></div><div class="refsect1"><a name="idm565"></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="idm568"></a><h3>OPTIONS</h3><div class="variablelist"><dl class="variablelist"><dt><span class="term">--print-emptyrecords</span></dt><dd><p>
- This enables printing of empty records when dumping databases
- with the catdb, cattbd and dumpdbbackup commands. Records with
- empty data segment are considered deleted by ctdb and cleaned
- by the vacuuming mechanism, so this switch can come in handy for
- debugging the vacuuming behaviour.
- </p></dd><dt><span class="term">--print-datasize</span></dt><dd><p>
- This lets database dumps (catdb, cattdb, dumpdbbackup) print the
- size of the record data instead of dumping the data contents.
- </p></dd><dt><span class="term">--print-lmaster</span></dt><dd><p>
- This lets catdb print the lmaster for each record.
- </p></dd><dt><span class="term">--print-hash</span></dt><dd><p>
- This lets database dumps (catdb, cattdb, dumpdbbackup) print the
- hash for each record.
- </p></dd><dt><span class="term">--print-recordflags</span></dt><dd><p>
- This lets catdb and dumpdbbackup print the
- record flags for each record. Note that cattdb always
- prints the flags.
- </p></dd></dl></div></div><div class="refsect2"><a name="idm591"></a><h3>process-exists <em class="parameter"><code>PID</code></em> <em class="parameter"><code>[SRVID]</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. When the optional SRVID
- argument is specified, the command check if a specific process
- exists on the CTDB host and has registered for specified SRVID.
- </p></div><div class="refsect2"><a name="idm596"></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="idm600"></a><h4>Example</h4><pre class="screen">
-# ctdb getdbstatus test.tdb.0
-dbid: 0x122224da
-name: test.tdb
-path: /usr/local/var/lib/ctdb/test.tdb.0
-PERSISTENT: no
-HEALTH: OK
-
-# ctdb getdbstatus registry.tdb # with a corrupted TDB
-dbid: 0xf2a58948
-name: registry.tdb
-path: /usr/local/var/lib/ctdb/persistent/registry.tdb.0
-PERSISTENT: yes
-HEALTH: NO-HEALTHY-NODES - ERROR - Backup of corrupted TDB in '/usr/local/var/lib/ctdb/persistent/registry.tdb.0.corrupted.20091208091949.0Z'
- </pre></div></div><div class="refsect2"><a name="idm603"></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="idm607"></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="idm611"></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="idm616"></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="idm620"></a><h3>recover</h3><p>
- This command will trigger the recovery daemon to do a cluster
- recovery.
- </p></div><div class="refsect2"><a name="idm623"></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="idm626"></a><h3>attach <em class="parameter"><code>DBNAME</code></em> [persistent|replicated]</h3><p>
- Create a new CTDB database called DBNAME and attach to it on
- all nodes.
- </p></div><div class="refsect2"><a name="idm630"></a><h3>detach <em class="parameter"><code>DB-LIST</code></em></h3><p>
- Detach specified non-persistent database(s) from the cluster. This
- command will disconnect specified database(s) on all nodes in
- the cluster. This command should only be used when none of the
- specified database(s) are in use.
- </p><p>
- All nodes should be active and tunable AllowClientDBAccess should
- be disabled on all nodes before detaching databases.
- </p></div><div class="refsect2"><a name="idm635"></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="idm638"></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="idm641"></a><h3>ban <em class="parameter"><code>BANTIME</code></em></h3><p>
- Administratively ban a node for BANTIME seconds. The node
- will be unbanned after BANTIME seconds have elapsed.
- </p><p>
- A banned node does not participate in the cluster. It does
- not host any records for the clustered TDB and does not host
- any public IP addresses.
- </p><p>
- Nodes are automatically banned if they misbehave. For
- example, a node may be banned if it causes too many cluster
- recoveries.
- </p><p>
- To administratively exclude a node from a cluster use the
- <span class="command"><strong>stop</strong></span> command.
- </p></div><div class="refsect2"><a name="idm649"></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><div class="refsect1"><a name="idm652"></a><h2>SEE ALSO</h2><p>
- <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">onnode</span>(1)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdb-statistics</span>(7)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span>,
-
- <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
- </p></div></div></body></html>
+++ /dev/null
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb</title><meta name="generator" content="DocBook XSL Stylesheets V1.79.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>
- The main functions of CTDB are:
- </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
- Provide a clustered version of the TDB database with automatic
- rebuild/recovery of the databases upon node failures.
- </p></li><li class="listitem"><p>
- Monitor nodes in the cluster and services running on each node.
- </p></li><li class="listitem"><p>
- Manage a pool of public IP addresses that are used to provide
- services to clients. Alternatively, CTDB can be used with
- LVS.
- </p></li></ul></div><p>
- Combined with a cluster filesystem CTDB provides a full
- high-availablity (HA) environment for services such as clustered
- Samba, NFS and other services.
- </p></div><div class="refsect1"><a name="idm22"></a><h2>ANATOMY OF A CTDB CLUSTER</h2><p>
- A CTDB cluster is a collection of nodes with 2 or more network
- interfaces. All nodes provide network (usually file/NAS) services
- to clients. Data served by file services is stored on shared
- storage (usually a cluster filesystem) that is accessible by all
- nodes.
- </p><p>
- CTDB provides an "all active" cluster, where services are load
- balanced across all nodes.
- </p></div><div class="refsect1"><a name="idm26"></a><h2>Recovery Lock</h2><p>
- CTDB uses a <span class="emphasis"><em>recovery lock</em></span> to avoid a
- <span class="emphasis"><em>split brain</em></span>, where a cluster becomes
- partitioned and each partition attempts to operate
- independently. Issues that can result from a split brain
- include file data corruption, because file locking metadata may
- not be tracked correctly.
- </p><p>
- CTDB uses a <span class="emphasis"><em>cluster leader and follower</em></span>
- model of cluster management. All nodes in a cluster elect one
- node to be the leader. The leader node coordinates privileged
- operations such as database recovery and IP address failover.
- CTDB refers to the leader node as the <span class="emphasis"><em>recovery
- master</em></span>. This node takes and holds the recovery lock
- to assert its privileged role in the cluster.
- </p><p>
- 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
- elected by the nodes in each partition, then only one of these
- recovery masters will be able to take the recovery lock. The
- recovery master in the "losing" partition will not be able to
- take the recovery lock and will be excluded from the cluster.
- The nodes in the "losing" partition will elect each node in turn
- as their recovery master so eventually all the nodes in that
- partition will be excluded.
- </p><p>
- CTDB does sanity checks to ensure that the recovery lock is held
- as expected.
- </p><p>
- CTDB can run without a recovery lock but this is not recommended
- as there will be no protection from split brains.
- </p></div><div class="refsect1"><a name="idm45"></a><h2>Private vs Public addresses</h2><p>
- Each node in a CTDB cluster has multiple IP addresses assigned
- to it:
-
- </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
- A single private IP address that is used for communication
- between nodes.
- </p></li><li class="listitem"><p>
- One or more public IP addresses that are used to provide
- NAS or other services.
- </p></li></ul></div><p>
- </p><div class="refsect2"><a name="idm53"></a><h3>Private address</h3><p>
- Each node is configured with a unique, permanently assigned
- private address. This address is configured by the operating
- system. This address uniquely identifies a physical node in
- the cluster and is the address that CTDB daemons will use to
- communicate with the CTDB daemons on other nodes.
- </p><p>
- Private addresses are listed in the file specified by the
- <code class="varname">CTDB_NODES</code> configuration variable (see
- <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>, default
- <code class="filename">/usr/local/etc/ctdb/nodes</code>). This file contains the
- list of private addresses for all nodes in the cluster, one
- per line. This file must be the same on all nodes in the
- cluster.
- </p><p>
- Private addresses should not be used by clients to connect to
- services provided by the cluster.
- </p><p>
- It is strongly recommended that the private addresses are
- configured on a private network that is separate from client
- networks. 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:
- </p><pre class="screen">
-192.168.1.1
-192.168.1.2
-192.168.1.3
-192.168.1.4
- </pre></div><div class="refsect2"><a name="idm67"></a><h3>Public addresses</h3><p>
- Public addresses are used to provide services to clients.
- Public addresses are not configured at the operating system
- level and are not permanently associated with a particular
- node. Instead, they are managed by CTDB and are assigned to
- interfaces on physical nodes at runtime.
- </p><p>
- The CTDB cluster will assign/reassign these public addresses
- across the available healthy nodes in the cluster. When one
- node fails, its public addresses will be taken over by one or
- more other nodes in the cluster. This ensures that services
- provided by all public addresses are always available to
- clients, as long as there are nodes available capable of
- hosting this address.
- </p><p>
- The public address configuration is stored in a file on each
- node specified by the <code class="varname">CTDB_PUBLIC_ADDRESSES</code>
- configuration variable (see
- <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>, recommended
- <code class="filename">/usr/local/etc/ctdb/public_addresses</code>). This file
- contains a list of the public addresses that the node is
- capable of hosting, one per line. Each entry also contains
- the netmask and the interface to which the address should be
- assigned.
- </p><p>
- Example <code class="filename">/usr/local/etc/ctdb/public_addresses</code> for a
- node that can host 4 public addresses, on 2 different
- interfaces:
- </p><pre class="screen">
-10.1.1.1/24 eth1
-10.1.1.2/24 eth1
-10.1.2.1/24 eth2
-10.1.2.2/24 eth2
- </pre><p>
- In many cases the public addresses file will be the same on
- all nodes. However, it is possible to use different public
- address configurations on different nodes.
- </p><p>
- Example: 4 nodes partitioned into two subgroups:
- </p><pre class="screen">
-Node 0:/usr/local/etc/ctdb/public_addresses
- 10.1.1.1/24 eth1
- 10.1.1.2/24 eth1
-
-Node 1:/usr/local/etc/ctdb/public_addresses
- 10.1.1.1/24 eth1
- 10.1.1.2/24 eth1
-
-Node 2:/usr/local/etc/ctdb/public_addresses
- 10.1.2.1/24 eth2
- 10.1.2.2/24 eth2
-
-Node 3:/usr/local/etc/ctdb/public_addresses
- 10.1.2.1/24 eth2
- 10.1.2.2/24 eth2
- </pre><p>
- In this example nodes 0 and 1 host two public addresses on the
- 10.1.1.x network while nodes 2 and 3 host two public addresses
- for the 10.1.2.x network.
- </p><p>
- Public address 10.1.1.1 can be hosted by either of nodes 0 or
- 1 and will be available to clients as long as at least one of
- these two nodes are available.
- </p><p>
- If both nodes 0 and 1 become unavailable then public address
- 10.1.1.1 also becomes unavailable. 10.1.1.1 can not be failed
- over to nodes 2 or 3 since these nodes do not have this public
- address configured.
- </p><p>
- The <span class="command"><strong>ctdb ip</strong></span> command can be used to view the
- current assignment of public addresses to physical nodes.
- </p></div></div><div class="refsect1"><a name="idm88"></a><h2>Node status</h2><p>
- The current status of each node in the cluster can be viewed by the
- <span class="command"><strong>ctdb status</strong></span> command.
- </p><p>
- A node can be in one of the following states:
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">OK</span></dt><dd><p>
- This node is healthy and fully functional. It hosts public
- addresses to provide services.
- </p></dd><dt><span class="term">DISCONNECTED</span></dt><dd><p>
- This node is not reachable by other nodes via the private
- network. It is not currently participating in the cluster.
- It <span class="emphasis"><em>does not</em></span> host public addresses to
- provide services. It might be shut down.
- </p></dd><dt><span class="term">DISABLED</span></dt><dd><p>
- This node has been administratively disabled. This node is
- partially functional and participates in the cluster.
- However, it <span class="emphasis"><em>does not</em></span> host public
- addresses to provide services.
- </p></dd><dt><span class="term">UNHEALTHY</span></dt><dd><p>
- A service provided by this node has failed a health check
- and should be investigated. This node is partially
- functional and participates in the cluster. However, it
- <span class="emphasis"><em>does not</em></span> host public addresses to
- provide services. Unhealthy nodes should be investigated
- and may require an administrative action to rectify.
- </p></dd><dt><span class="term">BANNED</span></dt><dd><p>
- CTDB is not behaving as designed on this node. For example,
- it may have failed too many recovery attempts. Such nodes
- are banned from participating in the cluster for a
- configurable time period before they attempt to rejoin the
- cluster. A banned node <span class="emphasis"><em>does not</em></span> host
- public addresses to provide services. All banned nodes
- should be investigated and may require an administrative
- action to rectify.
- </p></dd><dt><span class="term">STOPPED</span></dt><dd><p>
- This node has been administratively exclude from the
- cluster. A stopped node does no participate in the cluster
- and <span class="emphasis"><em>does not</em></span> host public addresses to
- provide services. This state can be used while performing
- maintenance on a node.
- </p></dd><dt><span class="term">PARTIALLYONLINE</span></dt><dd><p>
- A node that is partially online participates in a cluster
- like a healthy (OK) node. Some interfaces to serve public
- addresses are down, but at least one interface is up. See
- also <span class="command"><strong>ctdb ifaces</strong></span>.
- </p></dd></dl></div></div><div class="refsect1"><a name="idm128"></a><h2>CAPABILITIES</h2><p>
- Cluster nodes can have several different capabilities enabled.
- These are listed below.
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">RECMASTER</span></dt><dd><p>
- Indicates that a node can become the CTDB cluster recovery
- master. The current recovery master is decided via an
- election held by all active nodes with this capability.
- </p><p>
- Default is YES.
- </p></dd><dt><span class="term">LMASTER</span></dt><dd><p>
- Indicates that a node can be the location master (LMASTER)
- for database records. The LMASTER always knows which node
- has the latest copy of a record in a volatile database.
- </p><p>
- Default is YES.
- </p></dd></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="idm143"></a><h2>LVS</h2><p>
- LVS is a mode where CTDB presents one single IP address for the
- entire cluster. This is an alternative to using public IP
- addresses and round-robin DNS to loadbalance clients across the
- cluster.
- </p><p>
- This is similar to using a layer-4 loadbalancing switch but with
- some restrictions.
- </p><p>
- 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>
- 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 lvs master</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>
- Client sends request packet to LVSMASTER.
- </p></li><li class="listitem"><p>
- LVSMASTER passes the request on to one node across the
- internal network.
- </p></li><li class="listitem"><p>
- Selected node processes the request.
- </p></li><li class="listitem"><p>
- Node responds back to client.
- </p></li></ol></div><p>
- </p><p>
- This means that all incoming traffic to the cluster will pass
- through one physical node, which limits scalability. You can
- send more data to the LVS address that one physical node can
- multiplex. This means that you should not use LVS if your I/O
- pattern is write-intensive since you will be limited in the
- available network bandwidth that node can handle. LVS does work
- very well for read-intensive workloads where only smallish READ
- requests are going through the LVSMASTER bottleneck and the
- majority of the traffic volume (the data in the read replies)
- goes straight from the processing node back to the clients. For
- read-intensive i/o patterns you can achieve very high throughput
- rates in this mode.
- </p><p>
- Note: you can use LVS and public addresses at the same time.
- </p><p>
- If you use LVS, you must have a permanent address configured for
- the public interface on each node. This address must be routable
- and the cluster nodes must be configured so that all traffic
- back to client hosts are routed through this interface. This is
- also required in order to allow samba/winbind on the node to
- talk to the domain controller. This LVS IP address can not be
- used to initiate outgoing traffic.
- </p><p>
- Make sure that the domain controller and the clients are
- reachable from a node <span class="emphasis"><em>before</em></span> you enable
- LVS. Also ensure that outgoing traffic to these hosts is routed
- out through the configured public interface.
- </p><div class="refsect2"><a name="idm167"></a><h3>Configuration</h3><p>
- To activate LVS on a CTDB node you must specify the
- <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_LVS_PUBLIC_IFACE=eth1
-CTDB_LVS_PUBLIC_IP=10.1.1.237
-CTDB_LVS_NODES=/usr/local/etc/ctdb/lvs_nodes
- </pre><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
- reset. The node taking over this IP address will also send
- gratuitous ARPs (for IPv4, or neighbour advertisement, for
- IPv6). This allows clients to reconnect quickly, rather than
- waiting for TCP timeouts, which can be very long.
- </p><p>
- It is important that established TCP connections do not survive
- a release and take of a public IP address on the same node.
- Such connections can get out of sync with sequence and ACK
- numbers, potentially causing a disruptive ACK storm.
- </p></div><div class="refsect1"><a name="idm187"></a><h2>NAT GATEWAY</h2><p>
- NAT gateway (NATGW) is an optional feature that is used to
- configure fallback routing for nodes. This allows cluster nodes
- to connect to external services (e.g. DNS, AD, NIS and LDAP)
- when they do not host any public addresses (e.g. when they are
- unhealthy).
- </p><p>
- This also applies to node startup because CTDB marks nodes as
- UNHEALTHY until they have passed a "monitor" event. In this
- context, NAT gateway helps to avoid a "chicken and egg"
- situation where a node needs to access an external service to
- become healthy.
- </p><p>
- Another way of solving this type of problem is to assign an
- extra static IP address to a public interface on every node.
- This is simpler but it uses an extra IP address per node, while
- NAT gateway generally uses only one extra IP address.
- </p><div class="refsect2"><a name="idm192"></a><h3>Operation</h3><p>
- One extra NATGW public address is assigned on the public
- network to each NATGW group. Each NATGW group is a set of
- nodes in the cluster that shares the same NATGW address to
- talk to the outside world. Normally there would only be one
- NATGW group spanning an entire cluster, but in situations
- where one CTDB cluster spans multiple physical sites it might
- be useful to have one NATGW group for each site.
- </p><p>
- There can be multiple NATGW groups in a cluster but each node
- can only be member of one NATGW group.
- </p><p>
- In each NATGW group, one of the nodes is selected by CTDB to
- be the NATGW master and the other nodes are consider to be
- NATGW slaves. NATGW slaves establish a fallback default route
- to the NATGW master via the private network. When a NATGW
- slave hosts no public IP addresses then it will use this route
- for outbound connections. The NATGW master hosts the NATGW
- public IP address and routes outgoing connections from
- slave nodes via this IP address. It also establishes a
- fallback default route.
- </p></div><div class="refsect2"><a name="idm197"></a><h3>Configuration</h3><p>
- NATGW is usually configured similar to the following example configuration:
- </p><pre class="screen">
-CTDB_NATGW_NODES=/usr/local/etc/ctdb/natgw_nodes
-CTDB_NATGW_PRIVATE_NETWORK=192.168.1.0/24
-CTDB_NATGW_PUBLIC_IP=10.0.0.227/24
-CTDB_NATGW_PUBLIC_IFACE=eth0
-CTDB_NATGW_DEFAULT_GATEWAY=10.0.0.1
- </pre><p>
- Normally any node in a NATGW group can act as the NATGW
- master. Some configurations may have special nodes that lack
- connectivity to a public network. In such cases, those nodes
- can be flagged with the "slave-only" option in the
- <code class="varname">CTDB_NATGW_NODES</code> file to limit the NATGW
- functionality of those nodes.
- </p><p>
- See the <em class="citetitle">NAT GATEWAY</em> section in
- <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> for more details of
- NATGW configuration.
- </p></div><div class="refsect2"><a name="idm208"></a><h3>Implementation details</h3><p>
- When the NATGW functionality is used, one of the nodes is
- selected to act as a NAT gateway for all the other nodes in
- the group when they need to communicate with the external
- services. The NATGW master is selected to be a node that is
- most likely to have usable networks.
- </p><p>
- The NATGW master hosts the NATGW public IP address
- <code class="varname">CTDB_NATGW_PUBLIC_IP</code> on the configured public
- interfaces <code class="varname">CTDB_NATGW_PUBLIC_IFACE</code> and acts as
- a router, masquerading outgoing connections from slave nodes
- via this IP address. If
- <code class="varname">CTDB_NATGW_DEFAULT_GATEWAY</code> is set then it
- also establishes a fallback default route to the configured
- this gateway with a metric of 10. A metric 10 route is used
- so it can co-exist with other default routes that may be
- available.
- </p><p>
- A NATGW slave establishes its fallback default route to the
- NATGW master via the private network
- <code class="varname">CTDB_NATGW_PRIVATE_NETWORK</code>with a metric of 10.
- This route is used for outbound connections when no other
- default route is available because the node hosts no public
- addresses. A metric 10 routes is used so that it can co-exist
- with other default routes that may be available when the node
- is hosting public addresses.
- </p><p>
- <code class="varname">CTDB_NATGW_STATIC_ROUTES</code> can be used to
- have NATGW create more specific routes instead of just default
- routes.
- </p><p>
- This is implemented in the <code class="filename">11.natgw</code>
- eventscript. Please see the eventscript file and the
- <em class="citetitle">NAT GATEWAY</em> section in
- <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> for more details.
- </p></div></div><div class="refsect1"><a name="idm225"></a><h2>POLICY ROUTING</h2><p>
- Policy routing is an optional CTDB feature to support complex
- network topologies. Public addresses may be spread across
- several different networks (or VLANs) and it may not be possible
- to route packets from these public addresses via the system's
- default route. Therefore, CTDB has support for policy routing
- via the <code class="filename">13.per_ip_routing</code> eventscript.
- This allows routing to be specified for packets sourced from
- each public address. The routes are added and removed as CTDB
- moves public addresses between nodes.
- </p><div class="refsect2"><a name="idm229"></a><h3>Configuration variables</h3><p>
- There are 4 configuration variables related to policy routing:
- <code class="varname">CTDB_PER_IP_ROUTING_CONF</code>,
- <code class="varname">CTDB_PER_IP_ROUTING_RULE_PREF</code>,
- <code class="varname">CTDB_PER_IP_ROUTING_TABLE_ID_LOW</code>,
- <code class="varname">CTDB_PER_IP_ROUTING_TABLE_ID_HIGH</code>. See the
- <em class="citetitle">POLICY ROUTING</em> section in
- <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> for more details.
- </p></div><div class="refsect2"><a name="idm240"></a><h3>Configuration</h3><p>
- The format of each line of
- <code class="varname">CTDB_PER_IP_ROUTING_CONF</code> is:
- </p><pre class="screen">
-<public_address> <network> [ <gateway> ]
- </pre><p>
- Leading whitespace is ignored and arbitrary whitespace may be
- used as a separator. Lines that have a "public address" item
- that doesn't match an actual public address are ignored. This
- means that comment lines can be added using a leading
- character such as '#', since this will never match an IP
- address.
- </p><p>
- A line without a gateway indicates a link local route.
- </p><p>
- For example, consider the configuration line:
- </p><pre class="screen">
- 192.168.1.99 192.168.1.1/24
- </pre><p>
- If the corresponding public_addresses line is:
- </p><pre class="screen">
- 192.168.1.99/24 eth2,eth3
- </pre><p>
- <code class="varname">CTDB_PER_IP_ROUTING_RULE_PREF</code> is 100, and
- CTDB adds the address to eth2 then the following routing
- information is added:
- </p><pre class="screen">
- ip rule add from 192.168.1.99 pref 100 table ctdb.192.168.1.99
- ip route add 192.168.1.0/24 dev eth2 table ctdb.192.168.1.99
- </pre><p>
- This causes traffic from 192.168.1.1 to 192.168.1.0/24 go via
- eth2.
- </p><p>
- The <span class="command"><strong>ip rule</strong></span> command will show (something
- like - depending on other public addresses and other routes on
- the system):
- </p><pre class="screen">
- 0: from all lookup local
- 100: from 192.168.1.99 lookup ctdb.192.168.1.99
- 32766: from all lookup main
- 32767: from all lookup default
- </pre><p>
- <span class="command"><strong>ip route show table ctdb.192.168.1.99</strong></span> will show:
- </p><pre class="screen">
- 192.168.1.0/24 dev eth2 scope link
- </pre><p>
- The usual use for a line containing a gateway is to add a
- default route corresponding to a particular source address.
- Consider this line of configuration:
- </p><pre class="screen">
- 192.168.1.99 0.0.0.0/0 192.168.1.1
- </pre><p>
- In the situation described above this will cause an extra
- routing command to be executed:
- </p><pre class="screen">
- ip route add 0.0.0.0/0 via 192.168.1.1 dev eth2 table ctdb.192.168.1.99
- </pre><p>
- With both configuration lines, <span class="command"><strong>ip route show table
- ctdb.192.168.1.99</strong></span> will show:
- </p><pre class="screen">
- 192.168.1.0/24 dev eth2 scope link
- default via 192.168.1.1 dev eth2
- </pre></div><div class="refsect2"><a name="idm268"></a><h3>Sample configuration</h3><p>
- Here is a more complete example configuration.
- </p><pre class="screen">
-/usr/local/etc/ctdb/public_addresses:
-
- 192.168.1.98 eth2,eth3
- 192.168.1.99 eth2,eth3
-
-/usr/local/etc/ctdb/policy_routing:
-
- 192.168.1.98 192.168.1.0/24
- 192.168.1.98 192.168.200.0/24 192.168.1.254
- 192.168.1.98 0.0.0.0/0 192.168.1.1
- 192.168.1.99 192.168.1.0/24
- 192.168.1.99 192.168.200.0/24 192.168.1.254
- 192.168.1.99 0.0.0.0/0 192.168.1.1
- </pre><p>
- The routes local packets as expected, the default route is as
- previously discussed, but packets to 192.168.200.0/24 are
- routed via the alternate gateway 192.168.1.254.
- </p></div></div><div class="refsect1"><a name="idm273"></a><h2>NOTIFICATION SCRIPT</h2><p>
- When certain state changes occur in CTDB, it can be configured
- to perform arbitrary actions via a notification script. For
- example, sending SNMP traps or emails when a node becomes
- unhealthy or similar.
- </p><p>
- This is activated by setting the
- <code class="varname">CTDB_NOTIFY_SCRIPT</code> configuration variable.
- The specified script must be executable.
- </p><p>
- Use of the provided <code class="filename">/usr/local/etc/ctdb/notify.sh</code>
- script is recommended. It executes files in
- <code class="filename">/usr/local/etc/ctdb/notify.d/</code>.
- </p><p>
- CTDB currently generates notifications after CTDB changes to
- these states:
- </p><table border="0" summary="Simple list" class="simplelist"><tr><td>init</td></tr><tr><td>setup</td></tr><tr><td>startup</td></tr><tr><td>healthy</td></tr><tr><td>unhealthy</td></tr></table></div><div class="refsect1"><a name="idm288"></a><h2>DEBUG LEVELS</h2><p>
- Valid values for DEBUGLEVEL are:
- </p><table border="0" summary="Simple list" class="simplelist"><tr><td>ERR</td></tr><tr><td>WARNING</td></tr><tr><td>NOTICE</td></tr><tr><td>INFO</td></tr><tr><td>DEBUG</td></tr></table></div><div class="refsect1"><a name="idm297"></a><h2>REMOTE CLUSTER NODES</h2><p>
-It is possible to have a CTDB cluster that spans across a WAN link.
-For example where you have a CTDB cluster in your datacentre but you also
-want to have one additional CTDB node located at a remote branch site.
-This is similar to how a WAN accelerator works but with the difference
-that while a WAN-accelerator often acts as a Proxy or a MitM, in
-the ctdb remote cluster node configuration the Samba instance at the remote site
-IS the genuine server, not a proxy and not a MitM, and thus provides 100%
-correct CIFS semantics to clients.
- </p><p>
- See the cluster as one single multihomed samba server where one of
- the NICs (the remote node) is very far away.
- </p><p>
- NOTE: This does require that the cluster filesystem you use can cope
- with WAN-link latencies. Not all cluster filesystems can handle
- WAN-link latencies! Whether this will provide very good WAN-accelerator
- performance or it will perform very poorly depends entirely
- on how optimized your cluster filesystem is in handling high latency
- for data and metadata operations.
- </p><p>
- To activate a node as being a remote cluster node you need to set
- the following two parameters in /etc/sysconfig/ctdb for the remote node:
- </p><pre class="screen">
-CTDB_CAPABILITY_LMASTER=no
-CTDB_CAPABILITY_RECMASTER=no
- </pre><p>
- </p><p>
- Verify with the command "ctdb getcapabilities" that that node no longer
- has the recmaster or the lmaster capabilities.
- </p></div><div class="refsect1"><a name="idm305"></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>,
-
- <span class="citerefentry"><span class="refentrytitle">ping_pong</span>(1)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdb-statistics</span>(7)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span>,
-
- <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
- </p></div></div></body></html>
+++ /dev/null
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>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>
+++ /dev/null
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Ceph RADOS Mutex</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_mutex_ceph_rados_helper.7"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb_mutex_ceph_rados_helper — Ceph RADOS cluster mutex helper</p></div><div class="refsect1"><a name="idm10"></a><h2>DESCRIPTION</h2><p>
- ctdb_mutex_ceph_rados_helper can be used as a recovery lock provider
- for CTDB. When configured, split brain avoidance during CTDB recovery
- will be handled using locks against an object located in a Ceph RADOS
- pool.
- To enable this functionality, include the following line in your CTDB
- config file:
- </p><pre class="screen">
-CTDB_RECOVERY_LOCK="!ctdb_mutex_ceph_rados_helper [Cluster] [User] [Pool] [Object]"
-
-Cluster: Ceph cluster name (e.g. ceph)
-User: Ceph cluster user name (e.g. client.admin)
-Pool: Ceph RADOS pool name
-Object: Ceph RADOS object name
- </pre><p>
- The Ceph cluster <em class="parameter"><code>Cluster</code></em> must be up and running,
- with a configuration, and keyring file for <em class="parameter"><code>User</code></em>
- located in a librados default search path (e.g. /etc/ceph/).
- <em class="parameter"><code>Pool</code></em> must already exist.
- </p></div><div class="refsect1"><a name="idm18"></a><h2>SEE ALSO</h2><p>
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
-
- <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
- </p></div></div></body></html>
+++ /dev/null
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdbd</title><meta name="generator" content="DocBook XSL Stylesheets V1.79.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="idm26"></a><h2>GENERAL OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-d, --debug=<em class="parameter"><code>DEBUGLEVEL</code></em></span></dt><dd><p>
- This option sets the debug level to DEBUGLEVEL, which
- controls what will be written by the logging
- subsystem. The default is 2.
- </p><p>
- See the <em class="citetitle">DEBUG LEVELS</em> section in
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
- information.
- </p></dd><dt><span class="term">--dbdir=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
- DIRECTORY on local storage where ctdbd keeps a local copy of
- TDB databases. This directory is local for each node and
- should not be stored on the shared cluster filesystem.
- </p><p>
- Defaults to <code class="filename">/usr/local/var/lib/ctdb</code>.
- </p></dd><dt><span class="term">--dbdir-persistent=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
- DIRECTORY on local storage where ctdbd keeps a local copy of
- persistent TDB databases. This directory is local for each
- node and should not be stored on the shared cluster
- filesystem.
- </p><p>
- Defaults to <code class="filename">/usr/local/var/lib/ctdb/persistent</code>.
- </p></dd><dt><span class="term">--dbdir-state=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
- DIRECTORY on local storage where ctdbd keep internal state
- TDB files. This directory is local for each node and
- should not be stored on the shared cluster filesystem.
- </p><p>
- Defaults to <code class="filename">/usr/local/var/lib/ctdb/state</code>.
- </p></dd><dt><span class="term">--event-script-dir=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
- DIRECTORY where the CTDB event scripts are stored. See the
- <em class="citetitle">EVENT SCRIPTS</em> section in
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more information.
- </p><p>
- Default is <code class="envar">CTDB_BASE</code>/events.d, so usually
- <code class="filename">/usr/local/etc/ctdb/events.d</code>, which is part of
- the CTDB installation.
- </p></dd><dt><span class="term">--listen=<em class="parameter"><code>IPADDR</code></em></span></dt><dd><p>
- IPADDR is the private IP address that ctdbd will bind to.
- </p><p>
- By default ctdbd will select the first address from the
- nodes list that in can bind to. See also
- <em class="citetitle">--nlist</em>.
- </p><p>
- This option is only required when automatic address
- detection can not be used. This can be the case when
- running multiple ctdbd daemons/nodes on the same physical
- host (usually for testing), using InfiniBand for the
- private network or on Linux when sysctl
- net.ipv4.ip_nonlocal_bind=1.
- </p></dd><dt><span class="term">--logging=<em class="parameter"><code>STRING</code></em></span></dt><dd><p>
- STRING specifies where ctdbd will write its log. The
- default is
- file:<code class="filename">/usr/local/var/log/log.ctdb</code>.
- </p><p>
- Valid values are:
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">file:<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- FILENAME where ctdbd will write its log. This is usually
- <code class="filename">/usr/local/var/log/log.ctdb</code>.
- </p></dd><dt><span class="term">syslog[<span class="optional">:<em class="parameter"><code>METHOD</code></em></span>]</span></dt><dd><p>
- CTDB will log to syslog. By default this will use
- the syslog(3) API.
- </p><p>
- Under heavy loads syslog(3) can block if the syslog
- daemon processes messages too slowly. This can
- cause CTDB to block when logging.
- </p><p>
- If METHOD is specified then it specifies an
- extension that causes logging to be done in a
- non-blocking mode. Note that <span class="emphasis"><em>this may
- cause messages to be dropped</em></span>. METHOD
- must be one of:
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">nonblocking</span></dt><dd><p>
- CTDB will log to syslog via
- <code class="filename">/dev/log</code> in non-blocking
- mode.
- </p></dd><dt><span class="term">udp</span></dt><dd><p>
- CTDB will log to syslog via UDP to
- localhost:514. The syslog daemon must be
- configured to listen on (at least)
- localhost:514. Most syslog daemons will log
- the messages with hostname "localhost" - this
- is a limitation of the implementation, for
- compatibility with more syslog daemons.
- </p></dd><dt><span class="term">udp-rfc5424</span></dt><dd><p>
- As with "udp" but messages are sent in RFC5424
- format. This method will log the correct
- hostname but is not as widely implemented in
- syslog daemons.
- </p></dd></dl></div></dd></dl></div></dd><dt><span class="term">--max-persistent-check-errors=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
- NUM specifies the maximum number of health check failures
- allowed for persistent databases during startup.
- </p><p>
- The default value is 0. Setting this to non-zero allows a
- node with unhealthy persistent databases to startup and
- join the cluster as long as there is another node with
- healthy persistent databases.
- </p></dd><dt><span class="term">--nlist=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- FILENAME containing a list of the private IP addresses, one
- per line, for each node in the cluster. This file
- <span class="emphasis"><em>must be the same on each node</em></span> in the
- cluster.
- </p><p>
- Default is <code class="envar">CTDB_BASE</code>/nodes, so usually
- <code class="filename">/usr/local/etc/ctdb/nodes</code>.
- </p></dd><dt><span class="term">--no-lmaster</span></dt><dd><p>
- This argument specifies that this node can NOT become an lmaster
- for records in the database. This means that it will never show up
- in the vnnmap. This feature is primarily used for making a cluster
- span across a WAN link and use CTDB as a WAN-accelerator.
- </p><p>
- Please see the <em class="citetitle">REMOTE CLUSTER NODES</em>
- section in <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
- information.
- </p></dd><dt><span class="term">--no-recmaster</span></dt><dd><p>
- This argument specifies that this node can NOT become a recmaster
- for the database. This feature is primarily used for making a cluster
- span across a WAN link and use CTDB as a WAN-accelerator.
- </p><p>
- Please see the <em class="citetitle">REMOTE CLUSTER NODES</em>
- section in <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
- information.
- </p></dd><dt><span class="term">--notification-script=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- FILENAME specifying a script to be invoked by ctdbd when
- certain state changes occur.
- </p><p>
- This file is usually
- <code class="filename">/usr/local/etc/ctdb/notify.sh</code>.
- </p><p>
- Please see the <em class="citetitle">NOTIFICATION SCRIPT</em>
- section in <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
- information.
- </p></dd><dt><span class="term">--pidfile=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- FILENAME for file containing process ID of main CTDB
- daemon. This file is automatically created and removed by
- CTDB.
- </p><p>
- The default is to not create a PID file.
- </p></dd><dt><span class="term">--public_addresses=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- FILENAME specifying a file containing the public IP
- addresses to use on the cluster when CTDB should use IP
- takeover. This file contains a list of IP addresses,
- netmasks and interfaces. CTDB will distribute these public
- IP addresses appropriately across the available nodes.
- </p><p>
- The IP addresses specified in this file can differ across
- nodes.
- </p><p>
- This is usually the file
- <code class="filename">/usr/local/etc/ctdb/public_addresses</code>
- </p></dd><dt><span class="term">--public-interface=<em class="parameter"><code>INTERFACE</code></em></span></dt><dd><p>
- 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>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">--start-as-disabled</span></dt><dd><p>
- This makes ctdbd start in the DISABLED state.
- </p><p>
- To allow the node to host public IP addresses and
- services, it must be manually enabled using the
- <span class="command"><strong>ctdb enable</strong></span> command.
- </p><p>
- Please see the <em class="citetitle">NODE STATES</em> section
- in <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
- information about the DISABLED state.
- </p></dd><dt><span class="term">--start-as-stopped</span></dt><dd><p>
- This makes ctdbd start in the STOPPED state.
- </p><p>
- To allow the node to take part in the cluster it must be
- manually continued with the the <span class="command"><strong>ctdb
- enable</strong></span> command.
- </p><p>
- Please see the <em class="citetitle">NODE STATES</em> section
- in <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
- information about the STOPPED state.
- </p></dd><dt><span class="term">--transport=tcp|infiniband</span></dt><dd><p>
- This option specifies which transport to use for ctdbd
- internode communications. The default is "tcp".
- </p><p>
- The "infiniband" support is not regularly tested.
- </p></dd><dt><span class="term">-?, --help</span></dt><dd><p>
- Display a summary of options.
- </p></dd></dl></div></div><div class="refsect1"><a name="idm223"></a><h2>DEBUGGING OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-i, --interactive</span></dt><dd><p>
- Enable interactive mode. This will make ctdbd run in the
- foreground and not detach from the terminal. By default
- ctdbd will detach itself and run in the background as a
- daemon.
- </p></dd><dt><span class="term">--nopublicipcheck</span></dt><dd><p>
- This option is used when testing with multiple local
- daemons on a single machine. It disables checks related
- to public IP addresses.
- </p></dd><dt><span class="term">--nosetsched</span></dt><dd><p>
- This is a debugging option. This option is only used when
- debugging ctdbd.
- </p><p>
- Normally ctdbd will change its scheduler to run as a
- real-time process. This is the default mode for a normal
- ctdbd operation to gurarantee that ctdbd always gets the CPU
- cycles that it needs.
- </p><p>
- This option is used to tell ctdbd to
- <span class="emphasis"><em>not</em></span> run as a real-time process and
- instead run ctdbd as a normal userspace process. This is
- useful for debugging and when you want to run ctdbd under
- valgrind or gdb. (You don't want to attach valgrind or gdb
- to a real-time process.)
- </p></dd><dt><span class="term">--socket=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- FILENAME specifies the name of the Unix domain socket that
- ctdbd will create. This socket is used by local clients to
- communicate with ctdbd.
- </p><p>
- The default is <code class="filename">/usr/local/var/run/ctdb/ctdbd.socket</code>.
- You only need to use this option if you plan to run
- multiple ctdbd daemons on the same physical host, usually
- for testing.
- </p></dd><dt><span class="term">--script-log-level=<em class="parameter"><code>DEBUGLEVEL</code></em></span></dt><dd><p>
- This option sets the debug level of event script output to
- DEBUGLEVEL. The default is ERR.
- </p><p>
- See the <em class="citetitle">DEBUG LEVELS</em> section in
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
- information.
- </p></dd><dt><span class="term">--sloppy-start</span></dt><dd><p>
- This is debugging option. This speeds up the initial
- recovery during startup at the expense of some consistency
- checking. <span class="emphasis"><em>Don't use this option in
- production</em></span>.
- </p></dd><dt><span class="term">--torture</span></dt><dd><p>
- This option is only used for development and testing of
- CTDB. It adds artificial errors and failures to the
- common codepaths in ctdbd to verify that ctdbd can recover
- correctly from failures.
- </p><p>
- <span class="emphasis"><em>Do not use this option</em></span> unless you are
- developing and testing new functionality in CTDB.
- </p></dd><dt><span class="term">--valgrinding</span></dt><dd><p>
- This is a debugging option. This option is only used when
- debugging ctdbd. This enables additional debugging
- capabilities and implies --nosetsched.
- </p></dd></dl></div></div><div class="refsect1"><a name="idm273"></a><h2>SEE ALSO</h2><p>
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdbd_wrapper</span>(1)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">onnode</span>(1)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span>,
-
- <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
- </p></div></div></body></html>
+++ /dev/null
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdbd.conf</title><meta name="generator" content="DocBook XSL Stylesheets V1.79.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="idm140600397309584"></a><h2>DESCRIPTION</h2><p>
- This file contains CTDB configuration variables that are affect
- the operation of CTDB. The default location of this file is
- <code class="filename">/usr/local/etc/ctdb/ctdbd.conf</code>.
- </p><p>
- This file is a shell script (see
- <span class="citerefentry"><span class="refentrytitle">sh</span>(1)</span>) but is usually limited
- to simple variable assignments and shell-style comments.
- </p><p>
- CTDB configuration variables are grouped into several categories below.
- </p><p>
- Variables defined in this document can also be set in a
- distribution-specific configuration file such as
- <code class="filename">/etc/sysconfig/ctdb</code> (Red Hat) or
- <code class="filename">/etc/default/ctdb</code> (Debian). However, these
- files should be reserved for variables used by the initscript.
- A historical alternative is
- <code class="filename">/usr/local/etc/ctdb/sysconfig/ctdb</code> - this is
- deprecated.
- </p></div><div class="refsect1"><a name="idm140600395872352"></a><h2>
- INITSCRIPT CONFIGURATION
- </h2><p>
- Some options must be available to the initscript so they need to
- be set in the distribution-specific initscript configuration,
- such as <code class="filename">/etc/sysconfig/ctdb</code> or
- <code class="filename">/etc/default/ctdb</code>.
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_PIDFILE=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- FILENAME is the name of the file used to contain the
- process ID (PID) of the main CTDB daemon when it is
- running. This is passed from the initscript to
- <span class="citerefentry"><span class="refentrytitle">ctdbd_wrapper</span>(1)</span>.
- </p><p>
- Default is <code class="filename">/usr/local/var/run/ctdb/ctdbd.pid</code>.
- Corresponds to <code class="option">--pidfile</code>.
- </p></dd></dl></div></div><div class="refsect1"><a name="idm140600398014368"></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="idm140600399841344"></a><h2>
- DAEMON CONFIGURATION
- </h2><p>
- Variables in this section are processed by
- <span class="citerefentry"><span class="refentrytitle">ctdbd_wrapper</span>(1)</span> and are converted into
- command-line arguments to
- <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>. Correspondence with
- <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span> options is shown for
- each variable. The the documentation for the relevant options
- for more details.
- </p><p>
- Many of these variables are also used by event scripts.
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_CAPABILITY_LMASTER=yes|no</span></dt><dd><p>
- Defaults to yes. Corresponds to <code class="option">--no-lmaster</code>.
- </p></dd><dt><span class="term">CTDB_CAPABILITY_RECMASTER=yes|no</span></dt><dd><p>
- Defaults to yes. Corresponds to
- <code class="option">--no-recmaster</code>.
- </p></dd><dt><span class="term">CTDB_DBDIR=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
- Defaults to <code class="filename">/usr/local/var/lib/ctdb</code>.
- </p><p>
- Apart from a DIRECTORY, this can take a special value of
- the form
- <code class="option">tmpfs</code>[<span class="optional">:<em class="parameter"><code>OPTIONS</code></em></span>].
- OPTIONS is a comma-separated list of any permissible
- options to the tmpfs filesystem. The only pre-specified
- default is <code class="option">mode=700</code>, which can
- overridden by specifying <code class="option">mode</code> in
- OPTIONS. It probably makes sense to specify a maximum
- <code class="option">size</code>.
- </p><p>
- Corresponds to <code class="option">--dbdir</code>.
- </p></dd><dt><span class="term">CTDB_DBDIR_PERSISTENT=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
- Defaults to <code class="filename">/usr/local/var/lib/ctdb/persistent</code>.
- </p><p>
- Corresponds to <code class="option">--dbdir-persistent</code>.
- </p></dd><dt><span class="term">CTDB_DBDIR_STATE=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
- Defaults to <code class="filename">/usr/local/var/lib/ctdb/state</code>.
- </p><p>
- Corresponds to <code class="option">--dbdir-state</code>.
- </p></dd><dt><span class="term">CTDB_DEBUGLEVEL=<em class="parameter"><code>DEBUGLEVEL</code></em></span></dt><dd><p>
- Default is NOTICE. Corresponds to <code class="option">-d</code> or
- <code class="option">--debug</code>.
- </p></dd><dt><span class="term">CTDB_EVENT_SCRIPT_DIR=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
- Default is <code class="varname">CTDB_BASE</code>/events.d, so usually
- <code class="filename">/usr/local/etc/ctdb/events.d</code>. Corresponds to
- <code class="option">--event-script-dir</code>.
- </p></dd><dt><span class="term">CTDB_LOGGING=<em class="parameter"><code>STRING</code></em></span></dt><dd><p>
- STRING specifies where ctdbd will write its log. The
- default is
- file:<code class="filename">/usr/local/var/log/log.ctdb</code>.
- Corresponds to <code class="option">--logging</code>.
- </p><p>
- Valid values are:
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">file:<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- FILENAME where ctdbd will write its log. This is usually
- <code class="filename">/usr/local/var/log/log.ctdb</code>.
- </p></dd><dt><span class="term">syslog[<span class="optional">:<em class="parameter"><code>METHOD</code></em></span>]</span></dt><dd><p>
- CTDB will log to syslog. By default this will use
- the syslog(3) API.
- </p><p>
- If METHOD is specified then it specifies an
- extension that causes logging to be done in a
- non-blocking fashion. This can be useful under
- heavy loads that might cause the syslog daemon to
- dequeue messages too slowly, which would otherwise
- cause CTDB to block when logging. METHOD must be
- one of:
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">nonblocking</span></dt><dd><p>
- CTDB will log to syslog via
- <code class="filename">/dev/log</code> in non-blocking
- mode.
- </p></dd><dt><span class="term">udp</span></dt><dd><p>
- CTDB will log to syslog via UDP to
- localhost:514. The syslog daemon must be
- configured to listen on (at least)
- localhost:514. Most implementations will log
- the messages against hostname "localhost" -
- this is a limit of the implementation for
- compatibility with more syslog daemon
- implementations.
- </p></dd><dt><span class="term">udp-rfc5424</span></dt><dd><p>
- As with "udp" but messages are sent in RFC5424
- format. This method will log the correct
- hostname but is not as widely implemented in
- syslog daemons.
- </p></dd></dl></div></dd></dl></div></dd><dt><span class="term">CTDB_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
- <code class="option">--notification-script</code>.
- </p></dd><dt><span class="term">CTDB_MAX_PERSISTENT_CHECK_ERRORS=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
- Default 0. Corresponds to
- <code class="option">--max-persistent-check-errors</code>.
- </p></dd><dt><span class="term">CTDB_NODE_ADDRESS=<em class="parameter"><code>IPADDR</code></em></span></dt><dd><p>
- IPADDR is the private IP address that ctdbd will bind to.
- Corresponds to <code class="option">--listen</code>.
- </p><p>
- By default ctdbd will select the first address from the
- nodes list that in can bind to. See also
- <em class="citetitle">CTDB_NODES</em>.
- </p><p>
- This option is only required when automatic address
- detection can not be used. This can be the case when
- running multiple ctdbd daemons/nodes on the same physical
- host (usually for testing), using InfiniBand for the
- private network or on Linux when sysctl
- net.ipv4.ip_nonlocal_bind=1.
- </p></dd><dt><span class="term">CTDB_PUBLIC_ADDRESSES=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- No default, usually
- <code class="filename">/usr/local/etc/ctdb/public_addresses</code>.
- Corresponds to <code class="option">--public-addresses</code>.
- </p></dd><dt><span class="term">CTDB_PUBLIC_INTERFACE=<em class="parameter"><code>INTERFACE</code></em></span></dt><dd><p>
- No default. Corresponds to
- <code class="option">--public-interface</code>.
- </p></dd><dt><span class="term">CTDB_RECOVERY_LOCK=<em class="parameter"><code>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>.
- </p><p>
- For information about the recovery lock please see the
- <em class="citetitle">RECOVERY LOCK</em> section in
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
- </p></dd><dt><span class="term">CTDB_SCRIPT_LOG_LEVEL=<em class="parameter"><code>DEBUGLEVEL</code></em></span></dt><dd><p>
- Defaults to ERR. Corresponds to
- <code class="option">--script-log-level</code>.
- </p></dd><dt><span class="term">CTDB_SOCKET=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- Defaults to <code class="filename">/usr/local/var/run/ctdb/ctdbd.socket</code>.
- Corresponds to <code class="option">--socket</code>.
- </p><p>
- If you change this then you probably want to set this in
- root's environment (perhaps in a file in
- <code class="filename">/etc/profile.d</code>) so that you can use
- the <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span> command in a
- straightforward manner.
- </p></dd><dt><span class="term">CTDB_START_AS_DISABLED=yes|no</span></dt><dd><p>
- Default is no. Corresponds to
- <code class="option">--start-as-disabled</code>.
- </p></dd><dt><span class="term">CTDB_START_AS_STOPPED=yes|no</span></dt><dd><p>
- Default is no. Corresponds to
- <code class="option">--start-as-stopped</code>.
- </p></dd><dt><span class="term">CTDB_TRANSPORT=tcp|infiniband</span></dt><dd><p>
- Defaults to tcp. Corresponds to
- <code class="option">--transport</code>.
- </p></dd></dl></div><p>
- While the following variables do not translate into daemon
- options they are used by
- <span class="citerefentry"><span class="refentrytitle">ctdbd_wrapper</span>(1)</span> when starting and
- stopping <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>.
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_SHUTDOWN_TIMEOUT=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
- NUM is the number of seconds to wait for
- <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span> to shut down
- gracefully before giving up and killing it.
- </p><p>
- Defaults is 30.
- </p></dd><dt><span class="term">CTDB_STARTUP_TIMEOUT=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
- NUM is the number of seconds to wait for
- <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span> complete early
- initialisation up to a point where it is unlikely to
- abort. If <span class="command"><strong>ctdbd</strong></span> doesn't complete the
- "setup" event before this timeout then it is killed.
- </p><p>
- Defaults is 10.
- </p></dd></dl></div></div><div class="refsect1"><a name="idm140600394866464"></a><h2>NETWORK CONFIGURATION</h2><div class="refsect2"><a name="idm140600394865824"></a><h3>NAT GATEWAY</h3><p>
- NAT gateway is used to configure fallback routing for nodes
- when they do not host any public IP addresses. For example,
- it allows unhealthy nodes to reliably communicate with
- external infrastructure. One node in a NAT gateway group will
- be designated as the NAT gateway master node and other (slave)
- nodes will be configured with fallback routes via the NAT
- gateway master node. For more information, see the
- <em class="citetitle">NAT GATEWAY</em> section in
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_NATGW_DEFAULT_GATEWAY=<em class="parameter"><code>IPADDR</code></em></span></dt><dd><p>
- IPADDR is an alternate network gateway to use on the NAT
- gateway master node. If set, a fallback default route
- is added via this network gateway.
- </p><p>
- No default. Setting this variable is optional - if not
- set that no route is created on the NAT gateway master
- node.
- </p></dd><dt><span class="term">CTDB_NATGW_NODES=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- FILENAME contains the list of nodes that belong to the
- same NAT gateway group.
- </p><p>
- File format:
- </p><pre class="screen">
-<em class="parameter"><code>IPADDR</code></em> [<span class="optional">slave-only</span>]
- </pre><p>
- </p><p>
- IPADDR is the private IP address of each node in the NAT
- gateway group.
- </p><p>
- If "slave-only" is specified then the corresponding node
- can not be the NAT gateway master node. In this case
- <code class="varname">CTDB_NATGW_PUBLIC_IFACE</code> and
- <code class="varname">CTDB_NATGW_PUBLIC_IP</code> are optional and
- unused.
- </p><p>
- No default, usually
- <code class="filename">/usr/local/etc/ctdb/natgw_nodes</code> when enabled.
- </p></dd><dt><span class="term">CTDB_NATGW_PRIVATE_NETWORK=<em class="parameter"><code>IPADDR/MASK</code></em></span></dt><dd><p>
- IPADDR/MASK is the private sub-network that is
- internally routed via the NAT gateway master node. This
- is usually the private network that is used for node
- addresses.
- </p><p>
- No default.
- </p></dd><dt><span class="term">CTDB_NATGW_PUBLIC_IFACE=<em class="parameter"><code>IFACE</code></em></span></dt><dd><p>
- IFACE is the network interface on which the
- CTDB_NATGW_PUBLIC_IP will be configured.
- </p><p>
- No default.
- </p></dd><dt><span class="term">CTDB_NATGW_PUBLIC_IP=<em class="parameter"><code>IPADDR/MASK</code></em></span></dt><dd><p>
- IPADDR/MASK indicates the IP address that is used for
- outgoing traffic (originating from
- CTDB_NATGW_PRIVATE_NETWORK) on the NAT gateway master
- node. This <span class="emphasis"><em>must not</em></span> be a
- configured public IP address.
- </p><p>
- No default.
- </p></dd><dt><span class="term">CTDB_NATGW_STATIC_ROUTES=<em class="parameter"><code>IPADDR/MASK[@GATEWAY]</code></em> ...</span></dt><dd><p>
- Each IPADDR/MASK identifies a network or host to which
- NATGW should create a fallback route, instead of
- creating a single default route. This can be used when
- there is already a default route, via an interface that
- can not reach required infrastructure, that overrides
- the NAT gateway default route.
- </p><p>
- If GATEWAY is specified then the corresponding route on
- the NATGW master node will be via GATEWAY. Such routes
- are created even if
- <code class="varname">CTDB_NATGW_DEFAULT_GATEWAY</code> is not
- specified. If GATEWAY is not specified for some
- networks then routes are only created on the NATGW
- master node for those networks if
- <code class="varname">CTDB_NATGW_DEFAULT_GATEWAY</code> is
- specified.
- </p><p>
- This should be used with care to avoid causing traffic
- to unnecessarily double-hop through the NAT gateway
- master, even when a node is hosting public IP addresses.
- Each specified network or host should probably have a
- corresponding automatically created link route or static
- route to avoid this.
- </p><p>
- No default.
- </p></dd></dl></div><div class="refsect3"><a name="idm140600394839600"></a><h4>Example</h4><pre class="screen">
-CTDB_NATGW_NODES=/usr/local/etc/ctdb/natgw_nodes
-CTDB_NATGW_PRIVATE_NETWORK=192.168.1.0/24
-CTDB_NATGW_DEFAULT_GATEWAY=10.0.0.1
-CTDB_NATGW_PUBLIC_IP=10.0.0.227/24
-CTDB_NATGW_PUBLIC_IFACE=eth0
- </pre><p>
- A variation that ensures that infrastructure (ADS, DNS, ...)
- directly attached to the public network (10.0.0.0/24) is
- always reachable would look like this:
- </p><pre class="screen">
-CTDB_NATGW_NODES=/usr/local/etc/ctdb/natgw_nodes
-CTDB_NATGW_PRIVATE_NETWORK=192.168.1.0/24
-CTDB_NATGW_PUBLIC_IP=10.0.0.227/24
-CTDB_NATGW_PUBLIC_IFACE=eth0
-CTDB_NATGW_STATIC_ROUTES=10.0.0.0/24
- </pre><p>
- Note that <code class="varname">CTDB_NATGW_DEFAULT_GATEWAY</code> is
- not specified.
- </p></div></div><div class="refsect2"><a name="idm140600394835696"></a><h3>POLICY ROUTING</h3><p>
- A node running CTDB may be a component of a complex network
- topology. In particular, public addresses may be spread
- across several different networks (or VLANs) and it may not be
- possible to route packets from these public addresses via the
- system's default route. Therefore, CTDB has support for
- policy routing via the <code class="filename">13.per_ip_routing</code>
- eventscript. This allows routing to be specified for packets
- sourced from each public address. The routes are added and
- removed as CTDB moves public addresses between nodes.
- </p><p>
- For more information, see the <em class="citetitle">POLICY
- ROUTING</em> section in
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_PER_IP_ROUTING_CONF=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- FILENAME contains elements for constructing the desired
- routes for each source address.
- </p><p>
- The special FILENAME value
- <code class="constant">__auto_link_local__</code> indicates that no
- configuration file is provided and that CTDB should
- generate reasonable link-local routes for each public IP
- address.
- </p><p>
- File format:
- </p><pre class="screen">
-<em class="parameter"><code>IPADDR</code></em> <em class="parameter"><code>DEST-IPADDR/MASK</code></em> [<span class="optional"><em class="parameter"><code>GATEWAY-IPADDR</code></em></span>]
- </pre><p>
- </p><p>
- No default, usually
- <code class="filename">/usr/local/etc/ctdb/policy_routing</code> when enabled.
- </p></dd><dt><span class="term">CTDB_PER_IP_ROUTING_RULE_PREF=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
- NUM sets the priority (or preference) for the routing
- rules that are added by CTDB.
- </p><p>
- This should be (strictly) greater than 0 and (strictly)
- less than 32766. A priority of 100 is recommended, unless
- this conflicts with a priority already in use on the
- system. See
- <span class="citerefentry"><span class="refentrytitle">ip</span>(8)</span>, for more details.
- </p></dd><dt><span class="term">
- CTDB_PER_IP_ROUTING_TABLE_ID_LOW=<em class="parameter"><code>LOW-NUM</code></em>,
- CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=<em class="parameter"><code>HIGH-NUM</code></em>
- </span></dt><dd><p>
- CTDB determines a unique routing table number to use for
- the routing related to each public address. LOW-NUM and
- HIGH-NUM indicate the minimum and maximum routing table
- numbers that are used.
- </p><p>
- <span class="citerefentry"><span class="refentrytitle">ip</span>(8)</span> uses some
- reserved routing table numbers below 255. Therefore,
- CTDB_PER_IP_ROUTING_TABLE_ID_LOW should be (strictly)
- greater than 255.
- </p><p>
- CTDB uses the standard file
- <code class="filename">/etc/iproute2/rt_tables</code> to maintain
- a mapping between the routing table numbers and labels.
- The label for a public address
- <em class="replaceable"><code>ADDR</code></em> will look like
- ctdb.<em class="replaceable"><code>addr</code></em>. This means that
- the associated rules and routes are easy to read (and
- manipulate).
- </p><p>
- No default, usually 1000 and 9000.
- </p></dd></dl></div><div class="refsect3"><a name="idm140600394813760"></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="idm140600394812048"></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="idm140600394809744"></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="idm140600394795392"></a><h3>MISCELLANEOUS NETWORK CONFIGURATION</h3><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_PARTIALLY_ONLINE_INTERFACES=yes|no</span></dt><dd><p>
- Whether one or more offline interfaces should cause a
- monitor event to fail if there are other interfaces that
- are up. If this is "yes" and a node has some interfaces
- that are down then <span class="command"><strong>ctdb status</strong></span> will
- display the node as "PARTIALLYONLINE".
- </p><p>
- Note that CTDB_PARTIALLY_ONLINE_INTERFACES=yes is
- incompatible with NAT gateway, since NAT gateway relies
- on the interface configured by CTDB_NATGW_PUBLIC_IFACE
- to be up.
- </p><p>
- Default is "no".
- </p></dd></dl></div></div></div><div class="refsect1"><a name="idm140600394790720"></a><h2>SERVICE CONFIGURATION</h2><p>
- CTDB can be configured to manage and/or monitor various NAS (and
- other) services via its eventscripts.
- </p><p>
- In the simplest case CTDB will manage a service. This means the
- service will be started and stopped along with CTDB, CTDB will
- monitor the service and CTDB will do any required
- reconfiguration of the service when public IP addresses are
- failed over.
- </p><div class="refsect2"><a name="idm140600394788864"></a><h3>SAMBA</h3><div class="refsect3"><a name="idm140600394788224"></a><h4>Eventscripts</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">49.winbind</code></td></tr><tr><td><code class="filename">50.samba</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_SAMBA=yes|no</span></dt><dd><p>
- Should CTDB manage Samba?
- </p><p>
- Default is no.
- </p></dd><dt><span class="term">CTDB_MANAGES_WINBIND=yes|no</span></dt><dd><p>
- Should CTDB manage Winbind?
- </p><p>
- Default is no.
- </p></dd><dt><span class="term">CTDB_SAMBA_CHECK_PORTS=<em class="parameter"><code>PORT-LIST</code></em></span></dt><dd><p>
- When monitoring Samba, check TCP ports in
- space-separated PORT-LIST.
- </p><p>
- Default is to monitor ports that Samba is configured to listen on.
- </p></dd><dt><span class="term">CTDB_SAMBA_SKIP_SHARE_CHECK=yes|no</span></dt><dd><p>
- As part of monitoring, should CTDB skip the check for
- the existence of each directory configured as share in
- Samba. This may be desirable if there is a large number
- of shares.
- </p><p>
- Default is no.
- </p></dd><dt><span class="term">CTDB_SERVICE_NMB=<em class="parameter"><code>SERVICE</code></em></span></dt><dd><p>
- Distribution specific SERVICE for managing nmbd.
- </p><p>
- Default is distribution-dependant.
- </p></dd><dt><span class="term">CTDB_SERVICE_SMB=<em class="parameter"><code>SERVICE</code></em></span></dt><dd><p>
- Distribution specific SERVICE for managing smbd.
- </p><p>
- Default is distribution-dependant.
- </p></dd><dt><span class="term">CTDB_SERVICE_WINBIND=<em class="parameter"><code>SERVICE</code></em></span></dt><dd><p>
- Distribution specific SERVICE for managing winbindd.
- </p><p>
- Default is "winbind".
- </p></dd></dl></div></div><div class="refsect2"><a name="idm140600394768960"></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="idm140600394766816"></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.
- </p></dd><dt><span class="term">CTDB_NFS_CALLOUT=<em class="parameter"><code>COMMAND</code></em></span></dt><dd><p>
- COMMAND specifies the path to a callout to handle
- interactions with the configured NFS system, including
- startup, shutdown, monitoring.
- </p><p>
- Default is the included
- <span class="command"><strong>nfs-linux-kernel-callout</strong></span>.
- </p></dd><dt><span class="term">CTDB_NFS_CHECKS_DIR=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
- Specifies the path to a DIRECTORY containing files that
- describe how to monitor the responsiveness of NFS RPC
- services. See the README file for this directory for an
- explanation of the contents of these "check" files.
- </p><p>
- CTDB_NFS_CHECKS_DIR can be used to point to different
- sets of checks for different NFS servers.
- </p><p>
- One way of using this is to have it point to, say,
- <code class="filename">/usr/local/etc/ctdb/nfs-checks-enabled.d</code>
- and populate it with symbolic links to the desired check
- files. This avoids duplication and is upgrade-safe.
- </p><p>
- Default is
- <code class="filename">/usr/local/etc/ctdb/nfs-checks.d</code>,
- which contains NFS RPC checks suitable for Linux kernel
- NFS.
- </p></dd><dt><span class="term">CTDB_NFS_SKIP_SHARE_CHECK=yes|no</span></dt><dd><p>
- As part of monitoring, should CTDB skip the check for
- the existence of each directory exported via NFS. This
- may be desirable if there is a large number of exports.
- </p><p>
- Default is no.
- </p></dd><dt><span class="term">CTDB_RPCINFO_LOCALHOST=<em class="parameter"><code>IPADDR</code></em>|<em class="parameter"><code>HOSTNAME</code></em></span></dt><dd><p>
- IPADDR or HOSTNAME indicates the address that
- <span class="command"><strong>rpcinfo</strong></span> should connect to when doing
- <span class="command"><strong>rpcinfo</strong></span> check on IPv4 RPC service during
- monitoring. Optimally this would be "localhost".
- However, this can add some performance overheads.
- </p><p>
- Default is "127.0.0.1".
- </p></dd><dt><span class="term">CTDB_RPCINFO_LOCALHOST6=<em class="parameter"><code>IPADDR</code></em>|<em class="parameter"><code>HOSTNAME</code></em></span></dt><dd><p>
- IPADDR or HOSTNAME indicates the address that
- <span class="command"><strong>rpcinfo</strong></span> should connect to when doing
- <span class="command"><strong>rpcinfo</strong></span> check on IPv6 RPC service
- during monitoring. Optimally this would be "localhost6"
- (or similar). However, this can add some performance
- overheads.
- </p><p>
- Default is "::1".
- </p></dd><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="idm564"></a><h3>APACHE HTTPD</h3><p>
- CTDB can manage the Apache web server.
- </p><div class="refsect3"><a name="idm567"></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="idm578"></a><h3>CLAMAV</h3><p>
- CTDB has support to manage the popular anti-virus daemon
- ClamAV.
- </p><div class="refsect3"><a name="idm581"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">31.clamd</code></td></tr></table><p>
- This eventscript is not enabled by default. Use
- <span class="command"><strong>ctdb enablescript</strong></span> to enable it.
- </p></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_CLAMD=yes|no</span></dt><dd><p>
- Should CTDB manage ClamAV?
- </p><p>
- Default is no.
- </p></dd><dt><span class="term">CTDB_CLAMD_SOCKET=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- FILENAME is the socket to monitor ClamAV.
- </p><p>
- No default.
- </p></dd></dl></div></div><div class="refsect2"><a name="idm600"></a><h3>ISCSI</h3><p>
- CTDB has support for managing the Linux iSCSI tgtd service.
- </p><div class="refsect3"><a name="idm603"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">70.iscsi</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_ISCSI=yes|no</span></dt><dd><p>
- Should CTDB manage iSCSI tgtd?
- </p><p>
- Default is no.
- </p></dd><dt><span class="term">CTDB_START_ISCSI_SCRIPTS=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
- DIRECTORY on shared storage containing scripts to start
- tgtd for each public IP address.
- </p><p>
- No default.
- </p></dd></dl></div></div><div class="refsect2"><a name="idm620"></a><h3>MULTIPATHD</h3><p>
- CTDB can monitor multipath devices to ensure that active paths
- are available.
- </p><div class="refsect3"><a name="idm623"></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="idm637"></a><h3>VSFTPD</h3><p>
- CTDB can manage the vsftpd FTP server.
- </p><div class="refsect3"><a name="idm640"></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="idm651"></a><h3>
- SYSTEM RESOURCE MONITORING CONFIGURATION
- </h3><p>
- CTDB can experience seemingly random (performance and other)
- issues if system resources become too constrained. Options in
- this section can be enabled to allow certain system resources
- to be checked. They allows warnings to be logged and nodes to
- be marked unhealthy when system resource usage reaches the
- configured thresholds.
- </p><p>
- Some checks are enabled by default. It is recommended that
- these checks remain enabled or are augmented by extra checks.
- There is no supported way of completely disabling the checks.
- </p><div class="refsect3"><a name="idm655"></a><h4>Eventscripts</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">05.system</code></td></tr></table><p>
- Filesystem and memory usage monitoring is in
- <code class="filename">05.system</code>.
- </p></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MONITOR_FILESYSTEM_USAGE=<em class="parameter"><code>FS-LIMIT-LIST</code></em></span></dt><dd><p>
- FS-LIMIT-LIST is a space-separated list of
- <em class="parameter"><code>FILESYSTEM</code></em>:<em class="parameter"><code>WARN_LIMIT</code></em>[<span class="optional">:<em class="parameter"><code>UNHEALTHY_LIMIT</code></em></span>]
- triples indicating that warnings should be logged if the
- space used on FILESYSTEM reaches WARN_LIMIT%. If usage
- reaches UNHEALTHY_LIMIT then the node should be flagged
- unhealthy. Either WARN_LIMIT or UNHEALTHY_LIMIT may be
- left blank, meaning that check will be omitted.
- </p><p>
- Default is to warn for each filesystem containing a
- database directory (<code class="envar">CTDB_DBDIR</code>,
- <code class="envar">CTDB_DBDIR_PERSISTENT</code>,
- <code class="envar">CTDB_DBDIR_STATE</code>) with a threshold of
- 90%.
- </p></dd><dt><span class="term">CTDB_MONITOR_MEMORY_USAGE=<em class="parameter"><code>MEM-LIMITS</code></em></span></dt><dd><p>
- MEM-LIMITS takes the form
- <em class="parameter"><code>WARN_LIMIT</code></em>[<span class="optional">:<em class="parameter"><code>UNHEALTHY_LIMIT</code></em></span>]
- indicating that warnings should be logged if memory
- usage reaches WARN_LIMIT%. If usage reaches
- UNHEALTHY_LIMIT then the node should be flagged
- unhealthy. Either WARN_LIMIT or UNHEALTHY_LIMIT may be
- left blank, meaning that check will be omitted.
- </p><p>
- Default is 80, so warnings will be logged when memory
- usage reaches 80%.
- </p></dd><dt><span class="term">CTDB_MONITOR_SWAP_USAGE=<em class="parameter"><code>SWAP-LIMITS</code></em></span></dt><dd><p>
- SWAP-LIMITS takes the form
- <em class="parameter"><code>WARN_LIMIT</code></em>[<span class="optional">:<em class="parameter"><code>UNHEALTHY_LIMIT</code></em></span>]
- indicating that warnings should be logged if
- swap usage reaches WARN_LIMIT%. If usage reaches
- UNHEALTHY_LIMIT then the node should be flagged
- unhealthy. Either WARN_LIMIT or UNHEALTHY_LIMIT may be
- left blank, meaning that check will be omitted.
- </p><p>
- Default is 25, so warnings will be logged when swap
- usage reaches 25%.
- </p></dd></dl></div></div><div class="refsect2"><a name="idm694"></a><h3>MISCELLANEOUS SERVICE-RELATED CONFIGURATION</h3><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGED_SERVICES=<em class="parameter"><code>SERVICE-LIST</code></em></span></dt><dd><p>
- SERVICE-LIST is a space-separated list of SERVICEs that
- CTDB should manage. This can be used as an alternative
- to the
- <code class="varname">CTDB_MANAGES_<em class="replaceable"><code>SERVICE</code></em></code>
- variables.
- </p><p>
- No default.
- </p></dd></dl></div></div></div><div class="refsect1"><a name="idm705"></a><h2>
- TUNABLES CONFIGURATION
- </h2><p>
- CTDB tunables (see
- <span class="citerefentry"><span class="refentrytitle">ctdbd-tunables</span>(7)</span>) can be set from the
- configuration file. They are set as follows:
-
- </p><div class="literallayout"><p><br>
-CTDB_SET_<em class="replaceable"><code>TUNABLE</code></em>=<em class="replaceable"><code>VALUE</code></em><br>
- </p></div><p>
- </p><p>
- For example:
-
- </p><pre class="screen">
-CTDB_SET_MonitorInterval=20
- </pre><p>
- </p></div><div class="refsect1"><a name="idm716"></a><h2>
- DEBUG AND TEST
- </h2><p>
- Variable in this section are for debugging and testing CTDB.
- They should not generally be needed.
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_DEBUG_HUNG_SCRIPT=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- FILENAME is a script to run to log debug information when
- an event script times out.
- </p><p>
- Default is <code class="filename"><code class="varname">CTDB_BASE</code>/debug-hung-script.sh</code>.
- </p></dd><dt><span class="term">CTDB_DEBUG_HUNG_SCRIPT_LOGFILE=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- FILENAME specifies where log messages should go when
- debugging hung eventscripts. This is a testing option.
- See also <em class="citetitle">CTDB_DEBUG_HUNG_SCRIPT</em>.
- </p><p>
- No default. Messages go to stdout/stderr and are logged
- to the same place as other CTDB log messages.
- </p></dd><dt><span class="term">CTDB_DEBUG_HUNG_SCRIPT_STACKPAT=<em class="parameter"><code>REGEXP</code></em></span></dt><dd><p>
- REGEXP specifies interesting processes for which stack
- traces should be logged when debugging hung eventscripts
- and those processes are matched in pstree output. REGEXP
- is an extended regexp so choices are separated by pipes
- ('|'). However, REGEXP should not contain parentheses.
- See also <em class="citetitle">CTDB_DEBUG_HUNG_SCRIPT</em>.
- </p><p>
- Default is "exportfs|rpcinfo".
- </p></dd><dt><span class="term">CTDB_DEBUG_LOCKS=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- FILENAME is a script to run to log debug information when
- an CTDB fails to freeze databases during recovery.
- </p><p>
- No default, usually
- <code class="filename"><code class="varname">CTDB_BASE</code>/debug_locks.sh</code>.
- </p></dd><dt><span class="term">CTDB_SYS_ETCDIR=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
- DIRECTORY containing system configuration files. This is
- used to provide alternate configuration when testing and
- should not need to be changed from the default.
- </p><p>
- Default is <code class="filename">/etc</code>.
- </p></dd><dt><span class="term">CTDB_INIT_STYLE=debian|redhat|suse</span></dt><dd><p>
- This is the init style used by the Linux distribution (or
- other operating system) being used. This is usually
- determined dynamically by checking the system. This
- variable is used by the initscript to determine which init
- system primitives to use. It is also used by some
- eventscripts to choose the name of initscripts for certain
- services, since these can vary between distributions.
- </p><p>
- No fixed default.
- </p><p>
- If this option needs to be changed from the calculated
- default for the initscript to function properly, then it
- must be set in the distribution-specific initscript
- configuration, such as
- <code class="filename">/etc/sysconfig/ctdb</code>
- </p></dd><dt><span class="term">CTDB_MAX_CORRUPT_DB_BACKUPS=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
- NUM is the maximum number of volatile TDB database backups
- to be kept (for each database) when a corrupt database is
- found during startup. Volatile TDBs are zeroed during
- startup so backups are needed to debug any corruption that
- occurs before a restart.
- </p><p>
- Default is 10.
- </p></dd><dt><span class="term">CTDB_MAX_OPEN_FILES=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
- NUM is the maximum number of open files.
- </p><p>
- There is no default.
- </p></dd><dt><span class="term">CTDB_RC_LOCAL=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- FILENAME is a script fragment to be sourced by the
- <code class="filename">functions</code> that is sourced by scripts.
- On example use would be to override function definitions
- in unit tests. As a sanity check, this file must be
- executable for it to be used.
- </p><p>
- No default.
- </p></dd><dt><span class="term">CTDB_RUN_TIMEOUT_MONITOR=yes|no</span></dt><dd><p>
- Whether CTDB should simulate timing out monitor events.
- This uses the <code class="filename">99.timeout</code> eventscript.
- </p><p>
- Default is no.
- </p></dd><dt><span class="term">CTDB_SUPPRESS_COREFILE=yes|no</span></dt><dd><p>
- Whether CTDB core files should be suppressed.
- </p><p>
- Default is no.
- </p></dd><dt><span class="term">CTDB_VALGRIND=yes|no|<em class="parameter"><code>COMMAND</code></em></span></dt><dd><p>
- If "yes", this causes
- <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span> to be run under
- <span class="citerefentry"><span class="refentrytitle">valgrind</span>(1)</span> with logs going to
- <code class="filename">/usr/local/var/log/ctdb_valgrind</code>. If neither
- "yes" nor "no" then the value is assumed to be a COMMAND
- (e.g. a <span class="command"><strong>valgrind</strong></span> variation, a
- <span class="citerefentry"><span class="refentrytitle">gdb</span>(1)</span> command) that is
- used in place of the default <span class="command"><strong>valgrind</strong></span>
- command. In either case, the <code class="option">--valgrind</code>
- option is passed to <span class="command"><strong>ctdbd</strong></span>.
- </p><p>
- Default is no.
- </p></dd><dt><span class="term">CTDB_VARDIR=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
- DIRECTORY containing CTDB files that are modified at
- runtime.
- </p><p>
- Defaults to <code class="filename">/usr/local/var/lib/ctdb</code>.
- </p></dd></dl></div></div><div class="refsect1"><a name="idm821"></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="idm832"></a><h2>SEE ALSO</h2><p>
- <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdbd_wrapper</span>(1)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">onnode</span>(1)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span>,
-
- <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
- </p></div></div></body></html>
+++ /dev/null
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdbd_wrapper</title><meta name="generator" content="DocBook XSL Stylesheets V1.79.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="idm18"></a><h2>DESCRIPTION</h2><p>
- ctdbd_wrapper is used to start or stop the main CTDB daemon.
- </p><p>
- <em class="replaceable"><code>PIDFILE</code></em> specifies the location of the
- file containing the PID of the main CTDB daemon.
- </p><p>
- ctdbd_wrapper constructs command-line options for ctdbd from
- configuration variables specified in
- <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>.
- </p><p>
- See <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for an overview of CTDB.
- </p></div><div class="refsect1"><a name="idm31"></a><h2>SEE ALSO</h2><p>
- <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
-
- <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
- </p></div></div></body></html>
+++ /dev/null
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ltdbtool</title><meta name="generator" content="DocBook XSL Stylesheets V1.79.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="idm19"></a><h2>DESCRIPTION</h2><p>
- ltdbtool is a utility to manipulate CTDB's local TDB databases
- (LTDBs) without connecting to a CTDB daemon.
- </p><p>
- It can be used to:
- </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
- dump the contents of a LTDB, optionally printing the CTDB
- record header information,
- </p></li><li class="listitem"><p>
- convert between an LTDB and a non-clustered tdb
- by adding or removing CTDB headers and
- </p></li><li class="listitem"><p>convert between 64 and 32 bit LTDBs where the CTDB record
- headers differ by 4 bytes of padding.
- </p></li></ul></div></div><div class="refsect1"><a name="idm30"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-e</span></dt><dd><p>
- Dump empty records. These are normally excluded.
- </p></dd><dt><span class="term">-p</span></dt><dd><p>
- Dump with header information, similar to "ctdb catdb".
- </p></dd><dt><span class="term">
- -s
- { 0 | 32 | 64 }
- </span></dt><dd><p>
- Specify how to determine the CTDB record header size
- for the input database:
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">0</span></dt><dd><p>no CTDB header</p></dd><dt><span class="term">32</span></dt><dd><p>CTDB header size of a 32 bit system (20 bytes)</p></dd><dt><span class="term">64</span></dt><dd><p>CTDB header size of a 64 bit system (24 bytes)</p></dd></dl></div><p>
- The default is 32 or 64 depending on the system architecture.
- </p></dd><dt><span class="term">
- -o
- { 0 | 32 | 64 }
- </span></dt><dd><p>
- Specify how to determine the CTDB record header size
- for the output database, see -s.
- </p></dd><dt><span class="term">-S <em class="parameter"><code>SIZE</code></em></span></dt><dd><p>
- Explicitly specify the CTDB record header SIZE of the
- input database in bytes.
- </p></dd><dt><span class="term">-O <em class="parameter"><code>SIZE</code></em></span></dt><dd><p>
- Explicitly specify the CTDB record header SIZE for the
- output database in bytes.
- </p></dd><dt><span class="term">-h</span></dt><dd><p>
- Print help text.
- </p></dd></dl></div></div><div class="refsect1"><a name="idm84"></a><h2>COMMANDS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">help</span></dt><dd><p>
- Print help text.
- </p></dd><dt><span class="term">dump <em class="parameter"><code>IDB</code></em></span></dt><dd><p>
- Dump the contents of an LTDB input file IDB to standard
- output in a human-readable format.
- </p></dd><dt><span class="term">
- convert <em class="parameter"><code>IDB</code></em> <em class="parameter"><code>ODB</code></em>
- </span></dt><dd><p>
- Copy an LTDB input file IDB to output file ODB, optionally
- adding or removing CTDB headers.
- </p></dd></dl></div></div><div class="refsect1"><a name="idm102"></a><h2>EXAMPLES</h2><p>
- Print a local tdb in "tdbdump" style:
- </p><pre class="screen">
- ltdbtool dump idmap2.tdb.0
- </pre><p>
- Print a local tdb with header information similar to "ctdb catdb":
- </p><pre class="screen">
- ltdbtool dump -p idmap2.tdb.0
- </pre><p>
- Strip the CTDB headers from records:
- </p><pre class="screen">
- ltdbtool convert -o0 idmap2.tdb.0 idmap.tdb
- </pre><p>
- Strip 64 bit CTDB headers from records, running on i386:
- </p><pre class="screen">
- ltdbtool convert -s64 -o0 idmap2.tdb.0 idmap.tdb
- </pre><p>
- Strip the CTDB headers from records by piping through tdbrestore:
- </p><pre class="screen">
- ltdbtool dump idmap2.tdb.0 | tdbrestore idmap.tdb
- </pre><p>
- Convert a local tdb from a 64 bit system for usage on a 32 bit system:
- </p><pre class="screen">
- ltdbtool convert -s64 -o32 idmap2.tdb.0 idmap2.tdb.1
- </pre><p>
- Add a default header:
- </p><pre class="screen">
- ltdbtool convert -s0 idmap.tdb idmap2.tdb.0
- </pre></div><div class="refsect1"><a name="idm118"></a><h2>SEE ALSO</h2><p>
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">tdbdump</span>(1)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">tdbrestore</span>(1)</span>,
-
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
-
- <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
- </p></div></div></body></html>
+++ /dev/null
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>onnode</title><meta name="generator" content="DocBook XSL Stylesheets V1.79.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>NODES</code></em> specifies which node(s) to run
- a command on. See section <em class="citetitle">NODES
- SPECIFICATION</em> for details.
- </p><p>
- <em class="replaceable"><code>COMMAND</code></em> can be any shell command. The
- onnode utility uses ssh or rsh to connect to the remote nodes
- and run the command.
- </p></div><div class="refsect1"><a name="idm27"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-c</span></dt><dd><p>
- Execute COMMAND in the current working directory on the
- specified nodes.
- </p></dd><dt><span class="term">-f <em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
- Specify an alternative nodes FILENAME to use instead of
- the default. This option overrides the CTDB_NODES_FILE
- and CTDB_NODES variables. See the discussion of
- <code class="filename">/usr/local/etc/ctdb/nodes</code> in the FILES section
- for more details.
- </p></dd><dt><span class="term">-i</span></dt><dd><p>
- Keep standard input open, allowing data to be piped to
- onnode. Normally onnode closes stdin to avoid surprises
- when scripting. Note that this option is ignored when
- using <code class="option">-p</code> or if <code class="envar">SSH</code> is set
- to anything other than "ssh".
- </p></dd><dt><span class="term">-n</span></dt><dd><p>
- Allow nodes to be specified by name rather than node
- numbers. These nodes don't need to be listed in the nodes
- file. You can avoid the nodes file entirely by combining
- this with <code class="code">-f /dev/null</code>.
- </p></dd><dt><span class="term">-o <em class="parameter"><code>PREFIX</code></em></span></dt><dd><p>
- Causes standard output from each node to be saved into a
- file with name PREFIX.<em class="replaceable"><code>IP</code></em>.
- </p></dd><dt><span class="term">-p</span></dt><dd><p>
- Run COMMAND in parallel on the specified nodes. The
- default is to run COMMAND sequentially on each node.
- </p></dd><dt><span class="term">-P</span></dt><dd><p>
- Push files to nodes. Names of files to push are specified
- rather than the usual command. Quoting is fragile/broken
- - filenames with whitespace in them are not supported.
- </p></dd><dt><span class="term">-q</span></dt><dd><p>
- Do not print node addresses. Normally, onnode prints
- informational node addresses if more than one node is
- specified. This overrides -v.
- </p></dd><dt><span class="term">-v</span></dt><dd><p>
- Print node addresses even if only one node is specified.
- Normally, onnode prints informational node addresses when
- more than one node is specified.
- </p></dd><dt><span class="term">-h, --help</span></dt><dd><p>
- Show a short usage guide.
- </p></dd></dl></div></div><div class="refsect1"><a name="idm77"></a><h2>NODES SPECIFICATION</h2><p>
- Nodes can be specified via numeric node numbers (from 0 to N-1)
- or mnemonics. Multiple nodes are specified using lists of
- nodes, separated by commas, and ranges of numeric node numbers,
- separated by dashes. If nodes are specified multiple times then
- the command will be executed multiple times on those nodes. The
- order of nodes is significant.
- </p><p>
- The following mnemonics are available:
- </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">all</span></dt><dd><p>
- All nodes.
- </p></dd><dt><span class="term">any</span></dt><dd><p>
- A node where ctdbd is running. This semi-random but
- there is a bias towards choosing a low numbered node.
- </p></dd><dt><span class="term">ok | healthy</span></dt><dd><p>
- All nodes that are not disconnected, banned, disabled or
- unhealthy.
- </p></dd><dt><span class="term">con | connected</span></dt><dd><p>
- All nodes that are not disconnected.
- </p></dd></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
- </pre><p>
- The following command would show the last 5 lines of log on each
- node, preceded by the node's hostname
- </p><pre class="screen">
- onnode all "hostname; tail -5 /usr/local/var/log/log.ctdb"
- </pre><p>
- The following command would restart the ctdb service on all
- nodes, in parallel.
- </p><pre class="screen">
- onnode -p all service ctdb restart
- </pre><p>
- The following command would run ./foo in the current working
- directory, in parallel, on nodes 0, 2, 3 and 4.
- </p><pre class="screen">
- onnode -c -p 0,2-4 ./foo
- </pre></div><div class="refsect1"><a name="idm108"></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="idm123"></a><h2>FILES</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="filename">/usr/local/etc/ctdb/nodes</code></span></dt><dd><p>
- Default file containing a list of each node's IP address
- or hostname.
- </p><p>
- As above, a file specified via the <code class="option">-f</code> or
- <code class="envar">CTDB_NODES_FILE</code> is given precedence. If a
- relative path is specified and no corresponding file
- exists relative to the current directory then the file is
- also searched for in the <code class="filename">$CTDB_BASE</code>
- directory.
- </p><p>
- If <code class="envar">CTDB_NODES_FILE</code> is not set and
- <code class="envar">CTDB_NODES</code> is set in configuration then the
- file pointed to by <code class="envar">CTDB_NODES</code> is used.
- </p><p>
- Otherwise the default is
- <code class="filename">$CTDB_BASE/nodes</code>, where
- <code class="envar">CTDB_BASE</code> defaults to
- <code class="filename">/usr/local/etc/ctdb</code>.
- </p></dd><dt><span class="term"><code class="filename">/usr/local/etc/ctdb/onnode.conf</code></span></dt><dd><p>
- If this file exists it is sourced by onnode. The main
- purpose is to allow the administrator to set
- <code class="envar">SSH</code> to something other than "ssh". In this
- case the -t option is ignored. For example, the
- administrator may choose to use use rsh instead of ssh.
- </p></dd></dl></div></div><div class="refsect1"><a name="idm149"></a><h2>SEE ALSO</h2><p>
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
-
- <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
- </p></div></div></body></html>
+++ /dev/null
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ping_pong</title><meta name="generator" content="DocBook XSL Stylesheets V1.79.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="idm23"></a><h2>DESCRIPTION</h2><p>
- ping_pong measures the byte range lock latency. It is especially
- useful on a cluster of nodes sharing a common lock manager as it
- will give some indication of the lock manager's performance
- under stress.
- </p><p>
- FILENAME is a file on shared storage to use for byte range
- locking tests.
- </p><p>
- NUM-LOCKS is the number of byte range locks, so needs to be
- (strictly) greater than the number of nodes in the cluster.
- </p></div><div class="refsect1"><a name="idm28"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-r</span></dt><dd><p>
- test read performance
- </p></dd><dt><span class="term">-w</span></dt><dd><p>
- test write performance
- </p></dd><dt><span class="term">-m</span></dt><dd><p>
- use mmap
- </p></dd><dt><span class="term">-c</span></dt><dd><p>
- validate the locks
- </p></dd></dl></div></div><div class="refsect1"><a name="idm47"></a><h2>EXAMPLES</h2><p>
- Testing lock coherence
- </p><pre class="screen">
- ping_pong test.dat N
- </pre><p>
- Testing lock coherence with lock validation
- </p><pre class="screen">
- ping_pong -c test.dat N
- </pre><p>
- Testing IO coherence
- </p><pre class="screen">
- ping_pong -rw test.dat N
- </pre></div><div class="refsect1"><a name="idm55"></a><h2>SEE ALSO</h2><p>
- <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
-
- <a class="ulink" href="https://wiki.samba.org/index.php/Ping_pong" target="_top">https://wiki.samba.org/index.php/Ping_pong</a>
-
- </p></div></div></body></html>
</p><p>
Default is 80, so warnings will be logged when memory
usage reaches 80%.
- </p></dd><dt><span class="term">
- CTDB_MONITOR_SWAP_USAGE=<em class="parameter"><code>SWAP-LIMITS</code></em>
- </span></dt><dd><p>
- SWAP-LIMITS takes the form
- <em class="parameter"><code>WARN_LIMIT</code></em>[<span class="optional">:<em class="parameter"><code>UNHEALTHY_LIMIT</code></em></span>]
- indicating that warnings should be logged if
- swap usage reaches WARN_LIMIT%. If usage reaches
- UNHEALTHY_LIMIT then the node should be flagged
- unhealthy. Either WARN_LIMIT or UNHEALTHY_LIMIT may be
- left blank, meaning that check will be omitted.
- </p><p>
- Default is 25, so warnings will be logged when swap
- usage reaches 25%.
- </p></dd></dl></div></div></div><div class="refsect1"><a name="idm377"></a><h2>EVENT SCRIPT DEBUGGING</h2><div class="refsect2"><a name="idm379"></a><h3>
+ </p></dd></dl></div></div></div><div class="refsect1"><a name="idm368"></a><h2>EVENT SCRIPT DEBUGGING</h2><div class="refsect2"><a name="idm370"></a><h3>
debug-hung-script.sh
</h3><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_DEBUG_HUNG_SCRIPT_STACKPAT=<em class="parameter"><code>REGEXP</code></em></span></dt><dd><p>
REGEXP specifies interesting processes for which stack
[event] "debug script" option.
</p><p>
Default is "exportfs|rpcinfo".
- </p></dd></dl></div></div></div><div class="refsect1"><a name="idm3
91"></a><h2>FILES</h2><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">/usr/local/etc/ctdb/script.options</code></td></tr></table></div><div class="refsect1"><a name="idm396"></a><h2>SEE ALSO</h2><p>
+ </p></dd></dl></div></div></div><div class="refsect1"><a name="idm3
82"></a><h2>FILES</h2><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">/usr/local/etc/ctdb/script.options</code></td></tr></table></div><div class="refsect1"><a name="idm387"></a><h2>SEE ALSO</h2><p>
<span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
<span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
number of currently active readonly delegations.
</p></div><div class="refsect2"><a name="idm162"></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.
+ Buckets are 0, < 2, < 4, < 8,
+ < 16, < 32, < 64, < 128,
+ < 256, < 512, < 1024, < 2048,
+ < 4096, < 8192, < 16384, ≥ 16384.
</p></div><div class="refsect2"><a name="idm165"></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.
+ obtain locks. Buckets are < 1ms, < 10ms,
+ < 100ms, < 1s, < 2s, < 4s,
+ < 8s, < 16s, < 32s, < 64s,
+ ≥ 64s.
</p></div><div class="refsect2"><a name="idm168"></a><h3>locks_latency</h3><p>
The minimum, the average and the maximum time (in seconds)
required to obtain record locks.
record locks.
</p></div></div><div class="refsect2"><a name="idm218"></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.
+ Buckets are 0, < 2, < 4, < 8,
+ < 16, < 32, < 64, < 128,
+ < 256, < 512, < 1024, < 2048,
+ < 4096, < 8192, < 16384, ≥ 16384.
</p></div><div class="refsect2"><a name="idm221"></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.
+ obtain locks. Buckets are < 1ms, < 10ms,
+ < 100ms, < 1s, < 2s, < 4s,
+ < 8s, < 16s, < 32s, < 64s,
+ ≥ 64s.
</p></div><div class="refsect2"><a name="idm224"></a><h3>locks_latency</h3><p>
The minimum, the average and the maximum time (in seconds)
required to obtain record locks.
See <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for an overview of CTDB.
</p></div><div class="refsect1"><a name="idm26"></a><h2>GENERAL OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-i, --interactive</span></dt><dd><p>
Enable interactive mode. This will make ctdbd run in the
- foreground and not detach from the terminal. By default
- ctdbd will detach itself and run in the background as a
- daemon.
+ foreground and not detach from the terminal. In this mode
+ ctdbd will log to stderr.
+ </p><p>
+ By default ctdbd will detach itself and run in the
+ background as a daemon, logging to the configured
+ destination.
</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="idm3
7"></a><h2>SEE ALSO</h2><p>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm3
8"></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_wrapper</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="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="idm18"></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.79.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> {
start | stop }</p></div></div><div class="refsect1"><a name="idm16"></a><h2>DESCRIPTION</h2><p>
ctdbd_wrapper is used to start or stop the main CTDB daemon.
- </p><p>
- <em class="replaceable"><code>PIDFILE</code></em> specifies the location of the
- file containing the PID of the main CTDB daemon.
</p><p>
See <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for an overview of CTDB.
- </p></div><div class="refsect1"><a name="idm2
7"></a><h2>SEE ALSO</h2><p>
+ </p></div><div class="refsect1"><a name="idm2
3"></a><h2>SEE ALSO</h2><p>
<span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
<span class="citerefentry"><span class="refentrytitle">ctdb.sysconfig</span>(5)</span>,
numbers. These nodes don't need to be listed in the nodes
file. You can avoid the nodes file entirely by combining
this with <code class="code">-f /dev/null</code>.
- </p></dd><dt><span class="term">-o <em class="parameter"><code>PREFIX</code></em></span></dt><dd><p>
- Causes standard output from each node to be saved into a
- file with name PREFIX.<em class="replaceable"><code>IP</code></em>.
</p></dd><dt><span class="term">-p</span></dt><dd><p>
Run COMMAND in parallel on the specified nodes. The
default is to run COMMAND sequentially on each node.
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="idm7
7"></a><h2>NODES SPECIFICATION</h2><p>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm7
1"></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></dl></div></div><div class="refsect1"><a name="idm9
8"></a><h2>EXAMPLES</h2><p>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm9
2"></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="idm10
8"></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>
+ </pre></div><div class="refsect1"><a name="idm10
2"></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>
purpose is to allow the administrator to set
<code class="envar">ONNODE_SSH</code> to something other than "ssh".
In this case the -t option is ignored.
- </p></dd></dl></div></div><div class="refsect1"><a name="idm12
6"></a><h2>SEE ALSO</h2><p>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm12
0"></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>
git.samba.org / martins / ctdb-web.git / commitdiff