ctdb-web: Update manpages to current 4.5.4
authorMartin Schwenke <martin@meltin.net>
Sun, 29 Jan 2017 05:45:29 +0000 (16:45 +1100)
committerAmitay Isaacs <amitay@gmail.com>
Mon, 30 Jan 2017 06:23:37 +0000 (17:23 +1100)
Add missing ctdb_diagnostics manpage.

Signed-off-by: Martin Schwenke <martin@meltin.net>
web/manpages/ctdb-statistics.7.html
web/manpages/ctdb-tunables.7.html
web/manpages/ctdb.1.html
web/manpages/ctdb.7.html
web/manpages/ctdb_diagnostics.1.html [new file with mode: 0644]
web/manpages/ctdbd.1.html
web/manpages/ctdbd.conf.5.html
web/manpages/ctdbd_wrapper.1.html
web/manpages/ltdbtool.1.html
web/manpages/onnode.1.html
web/manpages/ping_pong.1.html

index c43db4b..6807bc7 100644 (file)
@@ -1,10 +1,10 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb-statistics</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdb-statistics.7"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb-statistics &#8212; CTDB statistics output</p></div><div class="refsect1"><a name="idm139938143499680"></a><h2>OVERALL STATISTICS</h2><p>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb-statistics</title><meta name="generator" content="DocBook XSL Stylesheets V1.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 &#8212; CTDB statistics output</p></div><div class="refsect1"><a name="idm45666704138096"></a><h2>OVERALL STATISTICS</h2><p>
       CTDB maintains information about various messages communicated
       and some of the important operations per node.  See the
       <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span> commands
       <span class="command"><strong>statistics</strong></span> and <span class="command"><strong>statisticsreset</strong></span>
       for displaying statistics.
-    </p><div class="refsect2"><a name="idm139938144880704"></a><h3>Example: ctdb statistics</h3><pre class="screen">
+    </p><div class="refsect2"><a name="idm45666707089168"></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
@@ -55,151 +55,151 @@ Statistics collected since  : (000 01:49:20) Fri Sep 12 11:43:12 2014
  reclock_recd       MIN/AVG/MAX     0.000000/0.000000/0.000000 sec out of 0
  call_latency       MIN/AVG/MAX     0.000006/0.000719/4.562991 sec out of 126626
  childwrite_latency MIN/AVG/MAX     0.014527/0.014527/0.014527 sec out of 1
-       </pre></div><div class="refsect2"><a name="idm139938144074928"></a><h3>CTDB version</h3><p>
+       </pre></div><div class="refsect2"><a name="idm45666704399024"></a><h3>CTDB version</h3><p>
         Version of the ctdb protocol used by the node.
-      </p></div><div class="refsect2"><a name="idm139938141891920"></a><h3>Current time of statistics</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666706168112"></a><h3>Current time of statistics</h3><p>
         Time when the statistics are generated.
       </p><p>
         This is useful when collecting statistics output periodically
         for post-processing.
-      </p></div><div class="refsect2"><a name="idm139938144102064"></a><h3>Statistics collected since</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666705078144"></a><h3>Statistics collected since</h3><p>
        Time when ctdb was started or the last time statistics was reset.
        The output shows the duration and the timestamp.
-      </p></div><div class="refsect2"><a name="idm139938141729504"></a><h3>num_clients</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666704201184"></a><h3>num_clients</h3><p>
         Number of processes currently connected to CTDB's unix socket.
         This includes recovery daemon, ctdb tool and samba processes
         (smbd, winbindd).
-      </p></div><div class="refsect2"><a name="idm139938142880032"></a><h3>frozen</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666704697120"></a><h3>frozen</h3><p>
        1 if the the databases are currently frozen, 0 otherwise.
-      </p></div><div class="refsect2"><a name="idm139938142575152"></a><h3>recovering</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666706354160"></a><h3>recovering</h3><p>
        1 if recovery is active, 0 otherwise.
-      </p></div><div class="refsect2"><a name="idm139938141022688"></a><h3>num_recoveries</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666707461312"></a><h3>num_recoveries</h3><p>
        Number of recoveries since the start of ctdb or since the last
        statistics reset.
-      </p></div><div class="refsect2"><a name="idm139938142040320"></a><h3>client_packets_sent</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666706887904"></a><h3>client_packets_sent</h3><p>
        Number of packets sent to client processes via unix domain socket.
-      </p></div><div class="refsect2"><a name="idm139938141224144"></a><h3>client_packets_recv</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666706278896"></a><h3>client_packets_recv</h3><p>
        Number of packets received from client processes via unix domain socket.
-      </p></div><div class="refsect2"><a name="idm139938144042032"></a><h3>node_packets_sent</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666706962656"></a><h3>node_packets_sent</h3><p>
        Number of packets sent to the other nodes in the cluster via TCP.
-      </p></div><div class="refsect2"><a name="idm139938141988928"></a><h3>node_packets_recv</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666704515184"></a><h3>node_packets_recv</h3><p>
        Number of packets received from the other nodes in the cluster via TCP.
-      </p></div><div class="refsect2"><a name="idm139938143080240"></a><h3>keepalive_packets_sent</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666705429360"></a><h3>keepalive_packets_sent</h3><p>
        Number of keepalive messages sent to other nodes.
       </p><p>
        CTDB periodically sends keepalive messages to other nodes.
        See <em class="citetitle">KeepaliveInterval</em> tunable in
        <span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span> for more details.
-      </p></div><div class="refsect2"><a name="idm139938142460160"></a><h3>keepalive_packets_recv</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666704475952"></a><h3>keepalive_packets_recv</h3><p>
        Number of keepalive messages received from other nodes.
-      </p></div><div class="refsect2"><a name="idm139938142634128"></a><h3>node</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666706198368"></a><h3>node</h3><p>
        This section lists various types of messages processed which
        originated from other nodes via TCP.
-      </p><div class="refsect3"><a name="idm139938142037088"></a><h4>req_call</h4><p>
+      </p><div class="refsect3"><a name="idm45666706312336"></a><h4>req_call</h4><p>
         Number of REQ_CALL messages from the other nodes.
-      </p></div><div class="refsect3"><a name="idm139938144753248"></a><h4>reply_call</h4><p>
+      </p></div><div class="refsect3"><a name="idm45666706469664"></a><h4>reply_call</h4><p>
         Number of REPLY_CALL messages from the other nodes.
-      </p></div><div class="refsect3"><a name="idm139938142887920"></a><h4>req_dmaster</h4><p>
+      </p></div><div class="refsect3"><a name="idm45666704000096"></a><h4>req_dmaster</h4><p>
         Number of REQ_DMASTER messages from the other nodes.
-      </p></div><div class="refsect3"><a name="idm139938145081184"></a><h4>reply_dmaster</h4><p>
+      </p></div><div class="refsect3"><a name="idm45666705750000"></a><h4>reply_dmaster</h4><p>
         Number of REPLY_DMASTER messages from the other nodes.
-      </p></div><div class="refsect3"><a name="idm139938142797792"></a><h4>reply_error</h4><p>
+      </p></div><div class="refsect3"><a name="idm45666703982512"></a><h4>reply_error</h4><p>
         Number of REPLY_ERROR messages from the other nodes.
-      </p></div><div class="refsect3"><a name="idm139938141620704"></a><h4>req_message</h4><p>
+      </p></div><div class="refsect3"><a name="idm45666704293456"></a><h4>req_message</h4><p>
         Number of REQ_MESSAGE messages from the other nodes.
-      </p></div><div class="refsect3"><a name="idm139938144156784"></a><h4>req_control</h4><p>
+      </p></div><div class="refsect3"><a name="idm45666706873728"></a><h4>req_control</h4><p>
         Number of REQ_CONTROL messages from the other nodes.
-      </p></div><div class="refsect3"><a name="idm139938140997424"></a><h4>reply_control</h4><p>
+      </p></div><div class="refsect3"><a name="idm45666706590272"></a><h4>reply_control</h4><p>
         Number of REPLY_CONTROL messages from the other nodes.
-      </p></div></div><div class="refsect2"><a name="idm139938143466848"></a><h3>client</h3><p>
+      </p></div></div><div class="refsect2"><a name="idm45666704913984"></a><h3>client</h3><p>
        This section lists various types of messages processed which
        originated from clients via unix domain socket.
-      </p><div class="refsect3"><a name="idm139938141519088"></a><h4>req_call</h4><p>
+      </p><div class="refsect3"><a name="idm45666706632368"></a><h4>req_call</h4><p>
         Number of REQ_CALL messages from the clients.
-      </p></div><div class="refsect3"><a name="idm139938142138032"></a><h4>req_message</h4><p>
+      </p></div><div class="refsect3"><a name="idm45666705538640"></a><h4>req_message</h4><p>
         Number of REQ_MESSAGE messages from the clients.
-      </p></div><div class="refsect3"><a name="idm139938143399744"></a><h4>req_control</h4><p>
+      </p></div><div class="refsect3"><a name="idm45666706260256"></a><h4>req_control</h4><p>
         Number of REQ_CONTROL messages from the clients.
-      </p></div></div><div class="refsect2"><a name="idm139938142804592"></a><h3>timeouts</h3><p>
+      </p></div></div><div class="refsect2"><a name="idm45666705870080"></a><h3>timeouts</h3><p>
        This section lists timeouts occurred when sending various messages.
-      </p><div class="refsect3"><a name="idm139938143685040"></a><h4>call</h4><p>
+      </p><div class="refsect3"><a name="idm45666705119472"></a><h4>call</h4><p>
         Number of timeouts for REQ_CALL messages.
-      </p></div><div class="refsect3"><a name="idm139938141590784"></a><h4>control</h4><p>
+      </p></div><div class="refsect3"><a name="idm45666704066976"></a><h4>control</h4><p>
         Number of timeouts for REQ_CONTROL messages.
-      </p></div><div class="refsect3"><a name="idm139938142988736"></a><h4>traverse</h4><p>
+      </p></div><div class="refsect3"><a name="idm45666706001328"></a><h4>traverse</h4><p>
         Number of timeouts for database traverse operations.
-      </p></div></div><div class="refsect2"><a name="idm139938140879008"></a><h3>locks</h3><p>
+      </p></div></div><div class="refsect2"><a name="idm45666705806528"></a><h3>locks</h3><p>
        This section lists locking statistics.
-      </p><div class="refsect3"><a name="idm139938142459456"></a><h4>num_calls</h4><p>
+      </p><div class="refsect3"><a name="idm45666705919456"></a><h4>num_calls</h4><p>
         Number of completed lock calls.  This includes database locks
         and record locks.
-      </p></div><div class="refsect3"><a name="idm139938141728352"></a><h4>num_current</h4><p>
+      </p></div><div class="refsect3"><a name="idm45666704200928"></a><h4>num_current</h4><p>
         Number of scheduled lock calls.  This includes database locks
         and record locks.
-      </p></div><div class="refsect3"><a name="idm139938141930096"></a><h4>num_pending</h4><p>
+      </p></div><div class="refsect3"><a name="idm45666704894592"></a><h4>num_pending</h4><p>
         Number of queued lock calls.  This includes database locks and
         record locks.
-      </p></div><div class="refsect3"><a name="idm139938142666848"></a><h4>num_failed</h4><p>
+      </p></div><div class="refsect3"><a name="idm45666704625024"></a><h4>num_failed</h4><p>
         Number of failed lock calls.  This includes database locks and
         record locks.
-      </p></div></div><div class="refsect2"><a name="idm139938143981744"></a><h3>total_calls</h3><p>
+      </p></div></div><div class="refsect2"><a name="idm45666705217824"></a><h3>total_calls</h3><p>
        Number of req_call messages processed from clients.  This number
        should be same as client --&gt; req_call.
-      </p></div><div class="refsect2"><a name="idm139938141503504"></a><h3>pending_calls</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666704771808"></a><h3>pending_calls</h3><p>
        Number of req_call messages which are currenly being processed.
        This number indicates the number of record migrations in flight.
-      </p></div><div class="refsect2"><a name="idm139938141551456"></a><h3>childwrite_calls</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666705513152"></a><h3>childwrite_calls</h3><p>
        Number of record update calls.  Record update calls are used to
        update a record under a transaction.
-      </p></div><div class="refsect2"><a name="idm139938142822896"></a><h3>pending_childwrite_calls</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666706009424"></a><h3>pending_childwrite_calls</h3><p>
        Number of record update calls currently active.
-      </p></div><div class="refsect2"><a name="idm139938144013152"></a><h3>memory_used</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666705362400"></a><h3>memory_used</h3><p>
        The amount of memory in bytes currently used by CTDB using
        talloc.  This includes all the memory used for CTDB's internal
        data structures.  This does not include the memory mapped TDB
        databases.
-      </p></div><div class="refsect2"><a name="idm139938142962048"></a><h3>max_hop_count</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666705898528"></a><h3>max_hop_count</h3><p>
        The maximum number of hops required for a record migration request
        to obtain the record.  High numbers indicate record contention.
-      </p></div><div class="refsect2"><a name="idm139938143508848"></a><h3>total_ro_delegations</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666705017760"></a><h3>total_ro_delegations</h3><p>
        Number of readonly delegations created.
-      </p></div><div class="refsect2"><a name="idm139938142708592"></a><h3>total_ro_revokes</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666706125568"></a><h3>total_ro_revokes</h3><p>
        Number of readonly delegations that were revoked.  The difference
        between total_ro_revokes and total_ro_delegations gives the
        number of currently active readonly delegations.
-      </p></div><div class="refsect2"><a name="idm139938141590240"></a><h3>hop_count_buckets</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666706454272"></a><h3>hop_count_buckets</h3><p>
        Distribution of migration requests based on hop counts values.
        Buckets are 1, &lt; 4, &lt; 8, &lt; 16, &lt; 32, &lt; 64, &lt;
        128, &lt; 256, &lt; 512, &#8805; 512.
-      </p></div><div class="refsect2"><a name="idm139938143414000"></a><h3>lock_buckets</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666704925792"></a><h3>lock_buckets</h3><p>
        Distribution of record lock requests based on time required to
        obtain locks.  Buckets are &lt; 1ms, &lt; 10ms, &lt; 100ms,
        &lt; 1s, &lt; 2s, &lt; 4s, &lt; 8s, &lt; 16s, &lt; 32s, &lt;
        64s, &#8805; 64s.
-      </p></div><div class="refsect2"><a name="idm139938141409200"></a><h3>locks_latency</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666704747424"></a><h3>locks_latency</h3><p>
        The minimum, the average and the maximum time (in seconds)
        required to obtain record locks.
-      </p></div><div class="refsect2"><a name="idm139938142745920"></a><h3>reclock_ctdbd</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666703876976"></a><h3>reclock_ctdbd</h3><p>
        The minimum, the average and the maximum time (in seconds)
        required to check if recovery lock is still held by recovery
        daemon when recovery mode is changed.  This check is done in ctdb daemon.
-      </p></div><div class="refsect2"><a name="idm139938143025616"></a><h3>reclock_recd</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666703934784"></a><h3>reclock_recd</h3><p>
         The minimum, the average and the maximum time (in seconds)
         required to check if recovery lock is still held by recovery
         daemon during recovery.  This check is done in recovery daemon.
-      </p></div><div class="refsect2"><a name="idm139938142519424"></a><h3>call_latency</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666704968688"></a><h3>call_latency</h3><p>
        The minimum, the average and the maximum time (in seconds) required
        to process a REQ_CALL message from client.  This includes the time
        required to migrate a record from remote node, if the record is
        not available on the local node.
-      </p></div><div class="refsect2"><a name="idm139938141604624"></a><h3>childwrite_latency</h3><p>Default: 0</p><p>
+      </p></div><div class="refsect2"><a name="idm45666704700384"></a><h3>childwrite_latency</h3><p>Default: 0</p><p>
        The minimum, the average and the maximum time (in seconds)
        required to update records under a transaction.
-      </p></div></div><div class="refsect1"><a name="idm139938143655776"></a><h2>DATABASE STATISTICS</h2><p>
+      </p></div></div><div class="refsect1"><a name="idm45666704604208"></a><h2>DATABASE STATISTICS</h2><p>
       CTDB maintains per database statistics about important operations.
       See the <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span> command
       <span class="command"><strong>dbstatistics</strong></span> for displaying database statistics.
-    </p><div class="refsect2"><a name="idm139938143465056"></a><h3>Example: ctdb dbstatistics notify_index.tdb</h3><pre class="screen">
+    </p><div class="refsect2"><a name="idm45666703819616"></a><h3>Example: ctdb dbstatistics notify_index.tdb</h3><pre class="screen">
 DB Statistics: notify_index.tdb
  ro_delegations                     0
  ro_revokes                         0
@@ -215,45 +215,45 @@ DB Statistics: notify_index.tdb
      Count:7 Key:2f636c75737465726673
      Count:18 Key:2f636c757374657266732f64617461
      Count:7 Key:2f636c757374657266732f646174612f636c69656e7473
-       </pre></div><div class="refsect2"><a name="idm139938142129200"></a><h3>DB Statistics</h3><p>
+       </pre></div><div class="refsect2"><a name="idm45666706608144"></a><h3>DB Statistics</h3><p>
        Name of the database.
-      </p></div><div class="refsect2"><a name="idm139938142084448"></a><h3>ro_delegations</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666706503952"></a><h3>ro_delegations</h3><p>
        Number of readonly delegations created in the database.
-      </p></div><div class="refsect2"><a name="idm139938142116336"></a><h3>ro_revokes</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666703792800"></a><h3>ro_revokes</h3><p>
        Number of readonly delegations revoked.  The difference in
        ro_delegations and ro_revokes indicates the currently active
        readonly delegations.
-      </p></div><div class="refsect2"><a name="idm139938144070224"></a><h3>locks</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666704366832"></a><h3>locks</h3><p>
        This section lists locking statistics.
-      </p><div class="refsect3"><a name="idm139938143763344"></a><h4>total</h4><p>
+      </p><div class="refsect3"><a name="idm45666705473168"></a><h4>total</h4><p>
         Number of completed lock calls.  This includes database locks
         and record locks.
-      </p></div><div class="refsect3"><a name="idm139938143591696"></a><h4>failed</h4><p>
+      </p></div><div class="refsect3"><a name="idm45666704277744"></a><h4>failed</h4><p>
         Number of failed lock calls.  This includes database locks and
         record locks.
-      </p></div><div class="refsect3"><a name="idm139938141660528"></a><h4>current</h4><p>
+      </p></div><div class="refsect3"><a name="idm45666705164528"></a><h4>current</h4><p>
         Number of scheduled lock calls.  This includes database locks
         and record locks.
-      </p></div><div class="refsect3"><a name="idm139938141103264"></a><h4>pending</h4><p>
+      </p></div><div class="refsect3"><a name="idm45666707562784"></a><h4>pending</h4><p>
         Number of queued lock calls.  This includes database locks and
         record locks.
-      </p></div></div><div class="refsect2"><a name="idm139938141836608"></a><h3>hop_count_buckets</h3><p>
+      </p></div></div><div class="refsect2"><a name="idm45666704716832"></a><h3>hop_count_buckets</h3><p>
        Distribution of migration requests based on hop counts values.
        Buckets are 1, &lt; 4, &lt; 8, &lt; 16, &lt; 32, &lt; 64, &lt;
        128, &lt; 256, &lt; 512, &#8805; 512.
-      </p></div><div class="refsect2"><a name="idm139938144268496"></a><h3>lock_buckets</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666704548256"></a><h3>lock_buckets</h3><p>
        Distribution of record lock requests based on time required to
        obtain locks.  Buckets are &lt; 1ms, &lt; 10ms, &lt; 100ms,
        &lt; 1s, &lt; 2s, &lt; 4s, &lt; 8s, &lt; 16s, &lt; 32s, &lt;
        64s, &#8805; 64s.
-      </p></div><div class="refsect2"><a name="idm139938141023712"></a><h3>locks_latency</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666705836992"></a><h3>locks_latency</h3><p>
        The minimum, the average and the maximum time (in seconds)
        required to obtain record locks.
-      </p></div><div class="refsect2"><a name="idm139938142295568"></a><h3>Num Hot Keys</h3><p>
+      </p></div><div class="refsect2"><a name="idm45666706809744"></a><h3>Num Hot Keys</h3><p>
         Number of contended records determined by hop count.  CTDB keeps
         track of top 10 hot records and the output shows hex encoded
         keys for the hot records.
-      </p></div></div><div class="refsect1"><a name="idm139938143557184"></a><h2>SEE ALSO</h2><p>
+      </p></div></div><div class="refsect1"><a name="idm45666704640496"></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>,
index ea52162..0dd7879 100644 (file)
@@ -1,70 +1,84 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb-tunables</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdb-tunables.7"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb-tunables &#8212; CTDB tunable configuration variables</p></div><div class="refsect1"><a name="idm140250114160032"></a><h2>DESCRIPTION</h2><p>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb-tunables</title><meta name="generator" content="DocBook XSL Stylesheets V1.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 &#8212; CTDB tunable configuration variables</p></div><div class="refsect1"><a name="idm10"></a><h2>DESCRIPTION</h2><p>
       CTDB's behaviour can be configured by setting run-time tunable
       variables.  This lists and describes all tunables.  See the
       <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>
       <span class="command"><strong>listvars</strong></span>, <span class="command"><strong>setvar</strong></span> and
       <span class="command"><strong>getvar</strong></span> commands for more details.
-    </p><div class="refsect2"><a name="idm140250113977776"></a><h3>MaxRedirectCount</h3><p>Default: 3</p><p>
-       If we are not the DMASTER and need to fetch a record across the network
-       we first send the request to the LMASTER after which the record
-       is passed onto the current DMASTER. If the DMASTER changes before
-       the request has reached that node, the request will be passed onto the
-       "next" DMASTER. For very hot records that migrate rapidly across the
-       cluster this can cause a request to "chase" the record for many hops
-       before it catches up with the record.
-
-       this is how many hops we allow trying to chase the DMASTER before we
-       switch back to the LMASTER again to ask for new directions.
+    </p><p>
+      The tunable variables are listed alphabetically.
+    </p><div class="refsect2"><a name="idm20"></a><h3>AllowClientDBAttach</h3><p>Default: 1</p><p>
+       When set to 0, clients are not allowed to attach to any databases.
+       This can be used to temporarily block any new processes from
+       attaching to and accessing the databases.  This is mainly used
+       for detaching a volatile database using 'ctdb detach'.
+      </p></div><div class="refsect2"><a name="idm24"></a><h3>AllowUnhealthyDBRead</h3><p>Default: 0</p><p>
+       When set to 1, ctdb allows database traverses to read unhealthy
+       databases.  By default, ctdb does not allow reading records from
+       unhealthy databases.
+      </p></div><div class="refsect2"><a name="idm28"></a><h3>ControlTimeout</h3><p>Default: 60</p><p>
+       This is the default setting for timeout for when sending a
+       control message to either the local or a remote ctdb daemon.
+      </p></div><div class="refsect2"><a name="idm32"></a><h3>DatabaseHashSize</h3><p>Default: 100001</p><p>
+       Number of the hash chains for the local store of the tdbs that
+       ctdb manages.
+      </p></div><div class="refsect2"><a name="idm36"></a><h3>DatabaseMaxDead</h3><p>Default: 5</p><p>
+       Maximum number of dead records per hash chain for the tdb databses
+       managed by ctdb.
+      </p></div><div class="refsect2"><a name="idm40"></a><h3>DBRecordCountWarn</h3><p>Default: 100000</p><p>
+       When set to non-zero, ctdb will log a warning during recovery if
+       a database has more than this many records. This will produce a
+       warning if a database grows uncontrollably with orphaned records.
+      </p></div><div class="refsect2"><a name="idm44"></a><h3>DBRecordSizeWarn</h3><p>Default: 10000000</p><p>
+       When set to non-zero, ctdb will log a warning during recovery
+       if a single record is bigger than this size. This will produce
+       a warning if a database record grows uncontrollably.
+      </p></div><div class="refsect2"><a name="idm48"></a><h3>DBSizeWarn</h3><p>Default: 1000000000</p><p>
+       When set to non-zero, ctdb will log a warning during recovery if
+       a database size is bigger than this. This will produce a warning
+       if a database grows uncontrollably.
+      </p></div><div class="refsect2"><a name="idm52"></a><h3>DeferredAttachTO</h3><p>Default: 120</p><p>
+       When databases are frozen we do not allow clients to attach to
+       the databases. Instead of returning an error immediately to the
+       client, the attach request from the client is deferred until
+       the database becomes available again at which stage we respond
+       to the client.
       </p><p>
-       When chasing a record, this is how many hops we will chase the record
-       for before going back to the LMASTER to ask for new guidance.
-      </p></div><div class="refsect2"><a name="idm140250112552272"></a><h3>SeqnumInterval</h3><p>Default: 1000</p><p>
-       Some databases have seqnum tracking enabled, so that samba will be able
-       to detect asynchronously when there has been updates to the database.
-       Everytime a database is updated its sequence number is increased.
+       This timeout controls how long we will defer the request from the
+       client before timing it out and returning an error to the client.
+      </p></div><div class="refsect2"><a name="idm57"></a><h3>DeterministicIPs</h3><p>Default: 0</p><p>
+       When set to 1, ctdb will try to keep public IP addresses locked
+       to specific nodes as far as possible. This makes it easier
+       for debugging since you can know that as long as all nodes are
+       healthy public IP X will always be hosted by node Y.
       </p><p>
-       This tunable is used to specify in 'ms' how frequently ctdb will
-       send out updates to remote nodes to inform them that the sequence
-       number is increased.
-      </p></div><div class="refsect2"><a name="idm140250112801136"></a><h3>ControlTimeout</h3><p>Default: 60</p><p>
-       This is the default
-       setting for timeout for when sending a control message to either the
-       local or a remote ctdb daemon.
-      </p></div><div class="refsect2"><a name="idm140250112625904"></a><h3>TraverseTimeout</h3><p>Default: 20</p><p>
-       This setting controls how long we allow a traverse process to run.
-       After this timeout triggers, the main ctdb daemon will abort the
-       traverse if it has not yet finished.
-      </p></div><div class="refsect2"><a name="idm140250112994768"></a><h3>KeepaliveInterval</h3><p>Default: 5</p><p>
-       How often in seconds should the nodes send keepalives to eachother.
-      </p></div><div class="refsect2"><a name="idm140250113999488"></a><h3>KeepaliveLimit</h3><p>Default: 5</p><p>
-       After how many keepalive intervals without any traffic should a node
-       wait until marking the peer as DISCONNECTED.
+       The cost of using deterministic IP address assignment is that it
+       disables part of the logic where ctdb tries to reduce the number
+       of public IP assignment changes in the cluster. This tunable may
+       increase the number of IP failover/failbacks that are performed
+       on the cluster by a small margin.
+      </p></div><div class="refsect2"><a name="idm62"></a><h3>DisableIPFailover</h3><p>Default: 0</p><p>
+       When set to non-zero, ctdb will not perform failover or
+       failback. Even if a node fails while holding public IPs, ctdb
+       will not recover the IPs or assign them to another node.
       </p><p>
-       If a node has hung, it can thus take KeepaliveInterval*(KeepaliveLimit+1)
-       seconds before we determine that the node is DISCONNECTED and that we
-       require a recovery. This limitshould not be set too high since we want
-       a hung node to be detectec, and expunged from the cluster well before
-       common CIFS timeouts (45-90 seconds) kick in.
-      </p></div><div class="refsect2"><a name="idm140250113832160"></a><h3>RecoverTimeout</h3><p>Default: 20</p><p>
-       This is the default setting for timeouts for controls when sent from the
-       recovery daemon. We allow longer control timeouts from the recovery daemon
-       than from normal use since the recovery dameon often use controls that 
-       can take a lot longer than normal controls.
-      </p></div><div class="refsect2"><a name="idm140250113438992"></a><h3>RecoverInterval</h3><p>Default: 1</p><p>
-       How frequently in seconds should the recovery daemon perform the
-       consistency checks that determine if we need to perform a recovery or not.
-      </p></div><div class="refsect2"><a name="idm140250113236784"></a><h3>ElectionTimeout</h3><p>Default: 3</p><p>
-       When electing a new recovery master, this is how many seconds we allow
-       the election to take before we either deem the election finished
-       or we fail the election and start a new one.
-      </p></div><div class="refsect2"><a name="idm140250113440720"></a><h3>TakeoverTimeout</h3><p>Default: 9</p><p>
-       This is how many seconds we allow controls to take for IP failover events.
-      </p></div><div class="refsect2"><a name="idm140250111963200"></a><h3>MonitorInterval</h3><p>Default: 15</p><p>
-       How often should ctdb run the event scripts to check for a nodes health.
-      </p></div><div class="refsect2"><a name="idm140250112163600"></a><h3>TickleUpdateInterval</h3><p>Default: 20</p><p>
-       How often will ctdb record and store the "tickle" information used to
-       kickstart stalled tcp connections after a recovery.
-      </p></div><div class="refsect2"><a name="idm140250115209376"></a><h3>EventScriptTimeout</h3><p>Default: 30</p><p>
+       When this tunable is enabled, ctdb will no longer attempt
+       to recover the cluster by failing IP addresses over to other
+       nodes. This leads to a service outage until the administrator
+       has manually performed IP failover to replacement nodes using the
+       'ctdb moveip' command.
+      </p></div><div class="refsect2"><a name="idm67"></a><h3>ElectionTimeout</h3><p>Default: 3</p><p>
+       The number of seconds to wait for the election of recovery
+       master to complete. If the election is not completed during this
+       interval, then that round of election fails and ctdb starts a
+       new election.
+      </p></div><div class="refsect2"><a name="idm71"></a><h3>EnableBans</h3><p>Default: 1</p><p>
+        This parameter allows ctdb to ban a node if the node is misbehaving.
+      </p><p>
+       When set to 0, this disables banning completely in the cluster
+       and thus nodes can not get banned, even it they break. Don't
+       set to 0 unless you know what you are doing.  You should set
+       this to the same value on all nodes to avoid unexpected behaviour.
+      </p></div><div class="refsect2"><a name="idm76"></a><h3>EventScriptTimeout</h3><p>Default: 30</p><p>
        Maximum time in seconds to allow an event to run before timing
        out.  This is the total time for all enabled scripts that are
        run for an event, not just a single event script.
        "releaseip", "startrecovery", "recovered") and converted to
        success.  The logic here is that the callers of these events
        implement their own additional timeout.
-      </p></div><div class="refsect2"><a name="idm140250113300784"></a><h3>MonitorTimeoutCount</h3><p>Default: 20</p><p>
-       How many monitor events in a row need to timeout before a node
-       is flagged as UNHEALTHY.  This setting is useful if scripts
-       can not be written so that they do not hang for benign
-       reasons.
-      </p></div><div class="refsect2"><a name="idm140250113467376"></a><h3>RecoveryGracePeriod</h3><p>Default: 120</p><p>
-       During recoveries, if a node has not caused recovery failures during the
-       last grace period, any records of transgressions that the node has caused
-       recovery failures will be forgiven. This resets the ban-counter back to 
-       zero for that node.
-      </p></div><div class="refsect2"><a name="idm140250112493824"></a><h3>RecoveryBanPeriod</h3><p>Default: 300</p><p>
-       If a node becomes banned causing repetitive recovery failures. The node will
-       eventually become banned from the cluster.
-       This controls how long the culprit node will be banned from the cluster
-       before it is allowed to try to join the cluster again.
-       Don't set to small. A node gets banned for a reason and it is usually due
-       to real problems with the node.
-      </p></div><div class="refsect2"><a name="idm140250111569040"></a><h3>DatabaseHashSize</h3><p>Default: 100001</p><p>
-       Size of the hash chains for the local store of the tdbs that ctdb manages.
-      </p></div><div class="refsect2"><a name="idm140250112323888"></a><h3>DatabaseMaxDead</h3><p>Default: 5</p><p>
-       How many dead records per hashchain in the TDB database do we allow before
-       the freelist needs to be processed.
-      </p></div><div class="refsect2"><a name="idm140250114315872"></a><h3>RerecoveryTimeout</h3><p>Default: 10</p><p>
-       Once a recovery has completed, no additional recoveries are permitted
-       until this timeout has expired.
-      </p></div><div class="refsect2"><a name="idm140250113887312"></a><h3>EnableBans</h3><p>Default: 1</p><p>
-       When set to 0, this disables BANNING completely in the cluster and thus
-       nodes can not get banned, even it they break. Don't set to 0 unless you
-       know what you are doing.  You should set this to the same value on
-       all nodes to avoid unexpected behaviour.
-      </p></div><div class="refsect2"><a name="idm140250111531200"></a><h3>DeterministicIPs</h3><p>Default: 0</p><p>
-       When enabled, this tunable makes ctdb try to keep public IP addresses
-       locked to specific nodes as far as possible. This makes it easier for
-       debugging since you can know that as long as all nodes are healthy
-       public IP X will always be hosted by node Y. 
+      </p></div><div class="refsect2"><a name="idm81"></a><h3>FetchCollapse</h3><p>Default: 1</p><p>
+       This parameter is used to avoid multiple migration requests for
+       the same record from a single node. All the record requests for
+       the same record are queued up and processed when the record is
+       migrated to the current node.
       </p><p>
-       The cost of using deterministic IP address assignment is that it
-       disables part of the logic where ctdb tries to reduce the number of
-       public IP assignment changes in the cluster. This tunable may increase
-       the number of IP failover/failbacks that are performed on the cluster
-       by a small margin.
-      </p></div><div class="refsect2"><a name="idm140250112209184"></a><h3>LCP2PublicIPs</h3><p>Default: 1</p><p>
-       When enabled this switches ctdb to use the LCP2 ip allocation
-       algorithm.
-      </p></div><div class="refsect2"><a name="idm140250114324944"></a><h3>ReclockPingPeriod</h3><p>Default: x</p><p>
-       Obsolete
-      </p></div><div class="refsect2"><a name="idm140250113649088"></a><h3>NoIPFailback</h3><p>Default: 0</p><p>
-       When set to 1, ctdb will not perform failback of IP addresses when a node
-       becomes healthy. Ctdb WILL perform failover of public IP addresses when a
-       node becomes UNHEALTHY, but when the node becomes HEALTHY again, ctdb
-       will not fail the addresses back.
-      </p><p>
-       Use with caution! Normally when a node becomes available to the cluster
-       ctdb will try to reassign public IP addresses onto the new node as a way
-       to distribute the workload evenly across the clusternode. Ctdb tries to
-       make sure that all running nodes have approximately the same number of
-       public addresses it hosts.
+       When many clients across many nodes try to access the same record
+       at the same time this can lead to a fetch storm where the record
+       becomes very active and bounces between nodes very fast. This
+       leads to high CPU utilization of the ctdbd daemon, trying to
+       bounce that record around very fast, and poor performance.
+       This can improve performance and reduce CPU utilization for
+       certain workloads.
+      </p></div><div class="refsect2"><a name="idm86"></a><h3>HopcountMakeSticky</h3><p>Default: 50</p><p>
+       For database(s) marked STICKY (using 'ctdb setdbsticky'),
+       any record that is migrating so fast that hopcount
+       exceeds this limit is marked as STICKY record for
+       <code class="varname">StickyDuration</code> seconds. This means that
+       after each migration the sticky record will be kept on the node
+       <code class="varname">StickyPindown</code>milliseconds and prevented from
+       being migrated off the node.
+       </p><p>
+       This will improve performance for certain workloads, such as
+       locking.tdb if many clients are opening/closing the same file
+       concurrently.
+      </p></div><div class="refsect2"><a name="idm93"></a><h3>KeepaliveInterval</h3><p>Default: 5</p><p>
+       How often in seconds should the nodes send keep-alive packets to
+       each other.
+      </p></div><div class="refsect2"><a name="idm97"></a><h3>KeepaliveLimit</h3><p>Default: 5</p><p>
+       After how many keepalive intervals without any traffic should
+       a node wait until marking the peer as DISCONNECTED.
+       </p><p>
+       If a node has hung, it can take
+       <code class="varname">KeepaliveInterval</code> *
+       (<code class="varname">KeepaliveLimit</code> + 1) seconds before
+       ctdb determines that the node is DISCONNECTED and performs
+       a recovery. This limit should not be set too high to enable
+       early detection and avoid any application timeouts (e.g. SMB1)
+       to kick in before the fail over is completed.
+      </p></div><div class="refsect2"><a name="idm104"></a><h3>LCP2PublicIPs</h3><p>Default: 1</p><p>
+       When set to 1, ctdb uses the LCP2 ip allocation algorithm.
+      </p></div><div class="refsect2"><a name="idm108"></a><h3>LockProcessesPerDB</h3><p>Default: 200</p><p>
+       This is the maximum number of lock helper processes ctdb will
+       create for obtaining record locks.  When ctdb cannot get a record
+       lock without blocking, it creates a helper process that waits
+       for the lock to be obtained.
+      </p></div><div class="refsect2"><a name="idm112"></a><h3>LogLatencyMs</h3><p>Default: 0</p><p>
+       When set to non-zero, ctdb will log if certains operations
+       take longer than this value, in milliseconds, to complete.
+       These operations include "process a record request from client",
+       "take a record or database lock", "update a persistent database
+       record" and "vaccum a database".
+      </p></div><div class="refsect2"><a name="idm116"></a><h3>MaxQueueDropMsg</h3><p>Default: 1000000</p><p>
+       This is the maximum number of messages to be queued up for
+       a client before ctdb will treat the client as hung and will
+       terminate the client connection.
+      </p></div><div class="refsect2"><a name="idm120"></a><h3>MonitorInterval</h3><p>Default: 15</p><p>
+       How often should ctdb run the 'monitor' event in seconds to check
+       for a node's health.
+      </p></div><div class="refsect2"><a name="idm124"></a><h3>MonitorTimeoutCount</h3><p>Default: 20</p><p>
+       How many 'monitor' events in a row need to timeout before a node
+       is flagged as UNHEALTHY.  This setting is useful if scripts can
+       not be written so that they do not hang for benign reasons.
+      </p></div><div class="refsect2"><a name="idm128"></a><h3>NoIPFailback</h3><p>Default: 0</p><p>
+       When set to 1, ctdb will not perform failback of IP addresses
+       when a node becomes healthy. When a node becomes UNHEALTHY,
+       ctdb WILL perform failover of public IP addresses, but when the
+       node becomes HEALTHY again, ctdb will not fail the addresses back.
       </p><p>
-       When you enable this tunable, CTDB will no longer attempt to rebalance
-       the cluster by failing IP addresses back to the new nodes. An unbalanced
-       cluster will therefore remain unbalanced until there is manual
-       intervention from the administrator. When this parameter is set, you can
-       manually fail public IP addresses over to the new node(s) using the
-       'ctdb moveip' command.
-      </p></div><div class="refsect2"><a name="idm140250112149232"></a><h3>DisableIPFailover</h3><p>Default: 0</p><p>
-       When enabled, ctdb will not perform failover or failback. Even if a
-       node fails while holding public IPs, ctdb will not recover the IPs or
-       assign them to another node.
+       Use with caution! Normally when a node becomes available to the
+       cluster ctdb will try to reassign public IP addresses onto the
+       new node as a way to distribute the workload evenly across the
+       clusternode. Ctdb tries to make sure that all running nodes have
+       approximately the same number of public addresses it hosts.
       </p><p>
-       When you enable this tunable, CTDB will no longer attempt to recover
-       the cluster by failing IP addresses over to other nodes. This leads to
-       a service outage until the administrator has manually performed failover
-       to replacement nodes using the 'ctdb moveip' command.
-      </p></div><div class="refsect2"><a name="idm140250112776944"></a><h3>NoIPTakeover</h3><p>Default: 0</p><p>
-       When set to 1, ctdb will not allow IP addresses to be failed over
-       onto this node. Any IP addresses that the node currently hosts
-       will remain on the node but no new IP addresses can be failed over
-       to the node.
-      </p></div><div class="refsect2"><a name="idm140250114993088"></a><h3>NoIPHostOnAllDisabled</h3><p>Default: 0</p><p>
-       If no nodes are healthy then by default ctdb will happily host
+       When you enable this tunable, ctdb will no longer attempt to
+       rebalance the cluster by failing IP addresses back to the new
+       nodes. An unbalanced cluster will therefore remain unbalanced
+       until there is manual intervention from the administrator. When
+       this parameter is set, you can manually fail public IP addresses
+       over to the new node(s) using the 'ctdb moveip' command.
+      </p></div><div class="refsect2"><a name="idm134"></a><h3>NoIPHostOnAllDisabled</h3><p>Default: 0</p><p>
+       If no nodes are HEALTHY then by default ctdb will happily host
        public IPs on disabled (unhealthy or administratively disabled)
-       nodes.  This can cause problems, for example if the underlying
+       nodes.  This can cause problems, for example if the underlying
        cluster filesystem is not mounted.  When set to 1 on a node and
-       that node is disabled it, any IPs hosted by this node will be
+       that node is disabled, any IPs hosted by this node will be
        released and the node will not takeover any IPs until it is no
        longer disabled.
-      </p></div><div class="refsect2"><a name="idm140250113809520"></a><h3>DBRecordCountWarn</h3><p>Default: 100000</p><p>
-       When set to non-zero, ctdb will log a warning when we try to recover a
-       database with more than this many records. This will produce a warning
-       if a database grows uncontrollably with orphaned records.
-      </p></div><div class="refsect2"><a name="idm140250113368688"></a><h3>DBRecordSizeWarn</h3><p>Default: 10000000</p><p>
-       When set to non-zero, ctdb will log a warning when we try to recover a
-       database where a single record is bigger than this. This will produce
-       a warning if a database record grows uncontrollably with orphaned
-       sub-records.
-      </p></div><div class="refsect2"><a name="idm140250112645408"></a><h3>DBSizeWarn</h3><p>Default: 1000000000</p><p>
-       When set to non-zero, ctdb will log a warning when we try to recover a
-       database bigger than this. This will produce
-       a warning if a database grows uncontrollably.
-      </p></div><div class="refsect2"><a name="idm140250114616832"></a><h3>VerboseMemoryNames</h3><p>Default: 0</p><p>
-       This feature consumes additional memory. when used the talloc library
-       will create more verbose names for all talloc allocated objects.
-      </p></div><div class="refsect2"><a name="idm140250113342448"></a><h3>RecdPingTimeout</h3><p>Default: 60</p><p>
-       If the main dameon has not heard a "ping" from the recovery dameon for
-       this many seconds, the main dameon will log a message that the recovery
-       daemon is potentially hung.
-      </p></div><div class="refsect2"><a name="idm140250113524352"></a><h3>RecdFailCount</h3><p>Default: 10</p><p>
-       If the recovery daemon has failed to ping the main dameon for this many
-       consecutive intervals, the main daemon will consider the recovery daemon
-       as hung and will try to restart it to recover.
-      </p></div><div class="refsect2"><a name="idm140250114731216"></a><h3>LogLatencyMs</h3><p>Default: 0</p><p>
-       When set to non-zero, this will make the main daemon log any operation that
-       took longer than this value, in 'ms', to complete.
-       These include "how long time a lockwait child process needed", 
-       "how long time to write to a persistent database" but also
-       "how long did it take to get a response to a CALL from a remote node".
-      </p></div><div class="refsect2"><a name="idm140250111628960"></a><h3>RecLockLatencyMs</h3><p>Default: 1000</p><p>
-       When using a reclock file for split brain prevention, if set to non-zero
-       this tunable will make the recovery dameon log a message if the fcntl()
-       call to lock/testlock the recovery file takes longer than this number of 
-       ms.
-      </p></div><div class="refsect2"><a name="idm140250112069552"></a><h3>RecoveryDropAllIPs</h3><p>Default: 120</p><p>
-       If we have been stuck in recovery, or stopped, or banned, mode for
-       this many seconds we will force drop all held public addresses.
-      </p></div><div class="refsect2"><a name="idm140250112936832"></a><h3>VacuumInterval</h3><p>Default: 10</p><p>
-        Periodic interval in seconds when vacuuming is triggered for
-        volatile databases.
-      </p></div><div class="refsect2"><a name="idm140250112117984"></a><h3>VacuumMaxRunTime</h3><p>Default: 120</p><p>
-        The maximum time in seconds for which the vacuuming process is
-        allowed to run.  If vacuuming process takes longer than this
-        value, then the vacuuming process is terminated.
-      </p></div><div class="refsect2"><a name="idm140250111996192"></a><h3>RepackLimit</h3><p>Default: 10000</p><p>
-        During vacuuming, if the number of freelist records are more
-        than <code class="varname">RepackLimit</code>, then databases are
-        repacked to get rid of the freelist records to avoid
-        fragmentation.
-      </p><p>
-        Databases are repacked only if both
-        <code class="varname">RepackLimit</code> and
-        <code class="varname">VacuumLimit</code> are exceeded.
-      </p></div><div class="refsect2"><a name="idm140250114794416"></a><h3>VacuumLimit</h3><p>Default: 5000</p><p>
-        During vacuuming, if the number of deleted records are more
-        than <code class="varname">VacuumLimit</code>, then databases are
-        repacked to avoid fragmentation.
-      </p><p>
-        Databases are repacked only if both
-        <code class="varname">RepackLimit</code> and
-        <code class="varname">VacuumLimit</code> are exceeded.
-      </p></div><div class="refsect2"><a name="idm140250113734000"></a><h3>VacuumFastPathCount</h3><p>Default: 60</p><p>
-        When a record is deleted, it is marked for deletion during
-        vacuuming.  Vacuuming process usually processes this list to purge
-        the records from the database.  If the number of records marked
-        for deletion are more than VacuumFastPathCount, then vacuuming
-       process will scan the complete database for empty records instead
-       of using the list of records marked for deletion.
-      </p></div><div class="refsect2"><a name="idm140250114795824"></a><h3>DeferredAttachTO</h3><p>Default: 120</p><p>
-       When databases are frozen we do not allow clients to attach to the
-       databases. Instead of returning an error immediately to the application
-       the attach request from the client is deferred until the database
-       becomes available again at which stage we respond to the client.
-      </p><p>
-       This timeout controls how long we will defer the request from the client
-       before timing it out and returning an error to the client.
-      </p></div><div class="refsect2"><a name="idm140250112807120"></a><h3>HopcountMakeSticky</h3><p>Default: 50</p><p>
-       If the database is set to 'STICKY' mode, using the 'ctdb setdbsticky' 
-       command, any record that is seen as very hot and migrating so fast that
-       hopcount surpasses 50 is set to become a STICKY record for StickyDuration
-       seconds. This means that after each migration the record will be kept on
-       the node and prevented from being migrated off the node.
+      </p></div><div class="refsect2"><a name="idm138"></a><h3>NoIPTakeover</h3><p>Default: 0</p><p>
+       When set to 1, ctdb will not allow IP addresses to be failed
+       over onto this node. Any IP addresses that the node currently
+       hosts will remain on the node but no new IP addresses can be
+       failed over to the node.
+      </p></div><div class="refsect2"><a name="idm142"></a><h3>PullDBPreallocation</h3><p>Default: 10*1024*1024</p><p>
+       This is the size of a record buffer to pre-allocate for sending
+       reply to PULLDB control. Usually record buffer starts with size
+       of the first record and gets reallocated every time a new record
+       is added to the record buffer. For a large number of records,
+       this can be very inefficient to grow the record buffer one record
+       at a time.
+      </p></div><div class="refsect2"><a name="idm146"></a><h3>QueueBufferSize</h3><p>Default: 1024</p><p>
+       This is the maximum amount of data (in bytes) ctdb will read
+       from a socket at a time.
       </p><p>
-       This setting allows one to try to identify such records and stop them from
-       migrating across the cluster so fast. This will improve performance for
-       certain workloads, such as locking.tdb if many clients are opening/closing
-       the same file concurrently.
-      </p></div><div class="refsect2"><a name="idm140250113465456"></a><h3>StickyDuration</h3><p>Default: 600</p><p>
-       Once a record has been found to be fetch-lock hot and has been flagged to
-       become STICKY, this is for how long, in seconds, the record will be 
-       flagged as a STICKY record.
-      </p></div><div class="refsect2"><a name="idm140250111515504"></a><h3>StickyPindown</h3><p>Default: 200</p><p>
-       Once a STICKY record has been migrated onto a node, it will be pinned down
-       on that node for this number of ms. Any request from other nodes to migrate
-       the record off the node will be deferred until the pindown timer expires.
-      </p></div><div class="refsect2"><a name="idm140250111919552"></a><h3>StatHistoryInterval</h3><p>Default: 1</p><p>
-       Granularity of the statistics collected in the statistics history.
-      </p></div><div class="refsect2"><a name="idm140250113801408"></a><h3>AllowClientDBAttach</h3><p>Default: 1</p><p>
-       When set to 0, clients are not allowed to attach to any databases.
-       This can be used to temporarily block any new processes from attaching
-       to and accessing the databases.
-      </p></div><div class="refsect2"><a name="idm140250111550352"></a><h3>RecoverPDBBySeqNum</h3><p>Default: 1</p><p>
-       When set to zero, database recovery for persistent databases
-       is record-by-record and recovery process simply collects the
-       most recent version of every individual record.
+       For a busy setup, if ctdb is not able to process the TCP sockets
+       fast enough (large amount of data in Recv-Q for tcp sockets),
+       then this tunable value should be increased.  However, large
+       values can keep ctdb busy processing packets and prevent ctdb
+       from handling other events.
+      </p></div><div class="refsect2"><a name="idm151"></a><h3>RecBufferSizeLimit</h3><p>Default: 1000000</p><p>
+        This is the limit on the size of the record buffer to be sent
+        in various controls.  This limit is used by new controls used
+        for recovery and controls used in vacuuming.
+      </p></div><div class="refsect2"><a name="idm155"></a><h3>RecdFailCount</h3><p>Default: 10</p><p>
+       If the recovery daemon has failed to ping the main dameon for
+       this many consecutive intervals, the main daemon will consider
+       the recovery daemon as hung and will try to restart it to recover.
+      </p></div><div class="refsect2"><a name="idm159"></a><h3>RecdPingTimeout</h3><p>Default: 60</p><p>
+       If the main dameon has not heard a "ping" from the recovery dameon
+       for this many seconds, the main dameon will log a message that
+       the recovery daemon is potentially hung.  This also increments a
+       counter which is checked against <code class="varname">RecdFailCount</code>
+       for detection of hung recovery daemon.
+      </p></div><div class="refsect2"><a name="idm164"></a><h3>RecLockLatencyMs</h3><p>Default: 1000</p><p>
+       When using a reclock file for split brain prevention, if set
+       to non-zero this tunable will make the recovery dameon log a
+       message if the fcntl() call to lock/testlock the recovery file
+       takes longer than this number of milliseconds.
+      </p></div><div class="refsect2"><a name="idm168"></a><h3>RecoverInterval</h3><p>Default: 1</p><p>
+       How frequently in seconds should the recovery daemon perform the
+       consistency checks to determine if it should perform a recovery.
+      </p></div><div class="refsect2"><a name="idm172"></a><h3>RecoverPDBBySeqNum</h3><p>Default: 1</p><p>
+       When set to zero, database recovery for persistent databases is
+       record-by-record and recovery process simply collects the most
+       recent version of every individual record.
       </p><p>
        When set to non-zero, persistent databases will instead be
        recovered as a whole db and not by individual records. The
        node that contains the highest value stored in the record
-       "__db_sequence_number__" is selected and the copy of that
-       nodes database is used as the recovered database.
+       "__db_sequence_number__" is selected and the copy of that nodes
+       database is used as the recovered database.
       </p><p>
        By default, recovery of persistent databses is done using
        __db_sequence_number__ record.
-      </p></div><div class="refsect2"><a name="idm140250112196048"></a><h3>FetchCollapse</h3><p>Default: 1</p><p>
-       When many clients across many nodes try to access the same record at the
-       same time this can lead to a fetch storm where the record becomes very
-       active and bounces between nodes very fast. This leads to high CPU
-       utilization of the ctdbd daemon, trying to bounce that record around
-       very fast, and poor performance.
+      </p></div><div class="refsect2"><a name="idm178"></a><h3>RecoverTimeout</h3><p>Default: 120</p><p>
+       This is the default setting for timeouts for controls when sent
+       from the recovery daemon. We allow longer control timeouts from
+       the recovery daemon than from normal use since the recovery
+       dameon often use controls that can take a lot longer than normal
+       controls.
+      </p></div><div class="refsect2"><a name="idm182"></a><h3>RecoveryBanPeriod</h3><p>Default: 300</p><p>
+       The duration in seconds for which a node is banned if the node
+       fails during recovery.  After this time has elapsed the node will
+       automatically get unbanned and will attempt to rejoin the cluster.
       </p><p>
-       This parameter is used to activate a fetch-collapse. A fetch-collapse
-       is when we track which records we have requests in flight so that we only
-       keep one request in flight from a certain node, even if multiple smbd
-       processes are attemtping to fetch the record at the same time. This 
-       can improve performance and reduce CPU utilization for certain
-       workloads.
+       A node usually gets banned due to real problems with the node.
+       Don't set this value too small.  Otherwise, a problematic node
+       will try to re-join cluster too soon causing unnecessary recoveries.
+      </p></div><div class="refsect2"><a name="idm187"></a><h3>RecoveryDropAllIPs</h3><p>Default: 120</p><p>
+       If a node is stuck in recovery, or stopped, or banned, for this
+       many seconds, then ctdb will release all public addresses on
+       that node.
+      </p></div><div class="refsect2"><a name="idm191"></a><h3>RecoveryGracePeriod</h3><p>Default: 120</p><p>
+       During recoveries, if a node has not caused recovery failures
+       during the last grace period in seconds, any records of
+       transgressions that the node has caused recovery failures will be
+       forgiven. This resets the ban-counter back to zero for that node.
+      </p></div><div class="refsect2"><a name="idm195"></a><h3>RepackLimit</h3><p>Default: 10000</p><p>
+        During vacuuming, if the number of freelist records are more than
+        <code class="varname">RepackLimit</code>, then the database is repacked
+        to get rid of the freelist records to avoid fragmentation.
       </p><p>
-       This timeout controls if we should collapse multiple fetch operations
-       of the same record into a single request and defer all duplicates or not.
-      </p></div><div class="refsect2"><a name="idm140250113381232"></a><h3>Samba3AvoidDeadlocks</h3><p>Default: 0</p><p>
-       Enable code that prevents deadlocks with Samba (only for Samba 3.x).
+        Databases are repacked only if both <code class="varname">RepackLimit</code>
+        and <code class="varname">VacuumLimit</code> are exceeded.
+      </p></div><div class="refsect2"><a name="idm203"></a><h3>RerecoveryTimeout</h3><p>Default: 10</p><p>
+       Once a recovery has completed, no additional recoveries are
+       permitted until this timeout in seconds has expired.
+      </p></div><div class="refsect2"><a name="idm207"></a><h3>SeqnumInterval</h3><p>Default: 1000</p><p>
+       Some databases have seqnum tracking enabled, so that samba will
+       be able to detect asynchronously when there has been updates
+       to the database.  Everytime a database is updated its sequence
+       number is increased.
       </p><p>
-       This should be set to 1 when using Samba version 3.x to enable special
-       code in CTDB to avoid deadlock with Samba version 3.x.  This code
-       is not required for Samba version 4.x and must not be enabled for
-       Samba 4.x.
-      </p></div></div><div class="refsect1"><a name="idm140250113309648"></a><h2>SEE ALSO</h2><p>
+       This tunable is used to specify in milliseconds how frequently
+       ctdb will send out updates to remote nodes to inform them that
+       the sequence number is increased.
+      </p></div><div class="refsect2"><a name="idm212"></a><h3>StatHistoryInterval</h3><p>Default: 1</p><p>
+       Granularity of the statistics collected in the statistics
+       history. This is reported by 'ctdb stats' command.
+      </p></div><div class="refsect2"><a name="idm216"></a><h3>StickyDuration</h3><p>Default: 600</p><p>
+       Once a record has been marked STICKY, this is the duration in
+       seconds, the record will be flagged as a STICKY record.
+      </p></div><div class="refsect2"><a name="idm220"></a><h3>StickyPindown</h3><p>Default: 200</p><p>
+       Once a STICKY record has been migrated onto a node, it will be
+       pinned down on that node for this number of milliseconds. Any
+       request from other nodes to migrate the record off the node will
+       be deferred.
+      </p></div><div class="refsect2"><a name="idm224"></a><h3>TakeoverTimeout</h3><p>Default: 9</p><p>
+       This is the duration in seconds in which ctdb tries to complete IP
+       failover.
+      </p></div><div class="refsect2"><a name="idm228"></a><h3>TDBMutexEnabled</h3><p>Default: 0</p><p>
+       This paramter enables TDB_MUTEX_LOCKING feature on volatile
+       databases if the robust mutexes are supported. This optimizes the
+       record locking using robust mutexes and is much more efficient
+       that using posix locks.
+      </p></div><div class="refsect2"><a name="idm232"></a><h3>TickleUpdateInterval</h3><p>Default: 20</p><p>
+       Every <code class="varname">TickleUpdateInterval</code> seconds, ctdb
+       synchronizes the client connection information across nodes.
+      </p></div><div class="refsect2"><a name="idm237"></a><h3>TraverseTimeout</h3><p>Default: 20</p><p>
+       This is the duration in seconds for which a database traverse
+       is allowed to run.  If the traverse does not complete during
+       this interval, ctdb will abort the traverse.
+      </p></div><div class="refsect2"><a name="idm241"></a><h3>VacuumFastPathCount</h3><p>Default: 60</p><p>
+       During a vacuuming run, ctdb usually processes only the records
+       marked for deletion also called the fast path vacuuming. After
+       finishing <code class="varname">VacuumFastPathCount</code> number of fast
+       path vacuuming runs, ctdb will trigger a scan of complete database
+       for any empty records that need to be deleted.
+      </p></div><div class="refsect2"><a name="idm246"></a><h3>VacuumInterval</h3><p>Default: 10</p><p>
+        Periodic interval in seconds when vacuuming is triggered for
+        volatile databases.
+      </p></div><div class="refsect2"><a name="idm250"></a><h3>VacuumLimit</h3><p>Default: 5000</p><p>
+        During vacuuming, if the number of deleted records are more than
+        <code class="varname">VacuumLimit</code>, then databases are repacked to
+        avoid fragmentation.
+      </p><p>
+        Databases are repacked only if both <code class="varname">RepackLimit</code>
+        and <code class="varname">VacuumLimit</code> are exceeded.
+      </p></div><div class="refsect2"><a name="idm258"></a><h3>VacuumMaxRunTime</h3><p>Default: 120</p><p>
+        The maximum time in seconds for which the vacuuming process is
+        allowed to run.  If vacuuming process takes longer than this
+        value, then the vacuuming process is terminated.
+      </p></div><div class="refsect2"><a name="idm262"></a><h3>VerboseMemoryNames</h3><p>Default: 0</p><p>
+       When set to non-zero, ctdb assigns verbose names for some of
+       the talloc allocated memory objects.  These names are visible
+       in the talloc memory report generated by 'ctdb dumpmemory'.
+      </p></div></div><div class="refsect1"><a name="idm266"></a><h2>SEE ALSO</h2><p>
       <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
 
       <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
index d0f2e4e..795570a 100644 (file)
@@ -1,4 +1,4 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdb.1"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb &#8212; CTDB management utility</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ctdb</code>  [<em class="replaceable"><code>OPTION</code></em>...] {<em class="replaceable"><code>COMMAND</code></em>} [<em class="replaceable"><code>COMMAND-ARGS</code></em>]</p></div></div><div class="refsect1"><a name="idm140001401982336"></a><h2>DESCRIPTION</h2><p>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb</title><meta name="generator" content="DocBook XSL Stylesheets V1.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 &#8212; 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
@@ -21,7 +21,7 @@
              A space separated list of at least one
              <em class="parameter"><code>DB</code></em>.
            </p></dd></dl></div><p>
-    </p></div><div class="refsect1"><a name="idm140001402008576"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-n <em class="parameter"><code>PNN-LIST</code></em></span></dt><dd><p>
+    </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-LIST</code></em></span></dt><dd><p>
          The nodes specified by PNN-LIST should be queried for the
          requested information.  Default is to query the daemon
          running on the local host.
          socket to use when connecting to the local CTDB
          daemon. The default is
          <code class="filename">/usr/local/var/run/ctdb/ctdbd.socket</code>.
-       </p></dd></dl></div></div><div class="refsect1"><a name="idm140001397612864"></a><h2>ADMINISTRATIVE COMMANDS</h2><p>
+       </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="idm140001397611712"></a><h3>pnn</h3><p>
+    </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="idm140001397610560"></a><h3>xpnn</h3><p>
-       This command displays the PNN of the current node without
-       contacting the CTDB daemon.  It parses the nodes file
-       directly, so can produce unexpected output if the nodes file
-       has been edited but has not been reloaded.
-      </p></div><div class="refsect2"><a name="idm140001397609136"></a><h3>status</h3><p>
+      </p></div><div class="refsect2"><a name="idm113"></a><h3>status</h3><p>
        This command shows the current status of all CTDB nodes based
        on information from the queried node.
       </p><p>
        Note: If the the queried node is INACTIVE then the status
        might not be current.
-      </p><div class="refsect3"><a name="idm140001402039168"></a><h4>Node status</h4><p>
+      </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="idm140001402036912"></a><h4>Generation</h4><p>
+       </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.
          All nodes start with generation "INVALID" and are not assigned a real
          generation id until they have successfully been merged with a cluster
          through a recovery.
-       </p></div><div class="refsect3"><a name="idm140001402033136"></a><h4>Virtual Node Number (VNN) map</h4><p>
+       </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.  Virtual
          nodes host CTDB databases.  Only nodes that are
          participating in the VNN map can become lmaster or dmaster
          for database records.
-       </p></div><div class="refsect3"><a name="idm140001402031664"></a><h4>Recovery mode</h4><p>
+       </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.
          databases have been recovered, the node mode will change into
          NORMAL mode and the databases will be "thawed", allowing samba
          to access the databases again.
-       </p></div><div class="refsect3"><a name="idm140001402027760"></a><h4>Recovery master</h4><p>
+       </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="idm140001402025760"></a><h4>Example</h4><pre class="screen">
+       </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)
@@ -146,7 +141,7 @@ hash:2 lmaster:2
 hash:3 lmaster:3
 Recovery mode:NORMAL (0)
 Recovery master:0
-       </pre></div></div><div class="refsect2"><a name="idm140001402023856"></a><h3>nodestatus [<span class="optional"><em class="parameter"><code>PNN-LIST</code></em></span>]</h3><p>
+       </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:
@@ -164,7 +159,7 @@ Recovery master:0
        A common invocation in scripts is <span class="command"><strong>ctdb nodestatus
        all</strong></span> to check whether all nodes in a cluster are
        healthy.
-      </p><div class="refsect3"><a name="idm140001396491728"></a><h4>Example</h4><pre class="screen">
+      </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)
 
@@ -172,50 +167,69 @@ pnn:0 10.0.0.30        OK (THIS NODE)
 Number of nodes:2
 pnn:0 10.0.0.30        OK (THIS NODE)
 pnn:1 10.0.0.31        OK
-       </pre></div></div><div class="refsect2"><a name="idm140001396490032"></a><h3>recmaster</h3><p>
+       </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="idm140001396488288"></a><h3>uptime</h3><p>
+      </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="idm140001396486976"></a><h4>Example</h4><pre class="screen">
+      </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="idm140001396485152"></a><h3>listnodes</h3><p>
+       </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="idm140001396484032"></a><h4>Example</h4><pre class="screen">
+      </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="idm140001396482416"></a><h3>natgwlist</h3><p>
-       Show the current NAT gateway master and the status of all
-       nodes in the current NAT gateway group.  See the
-       <em class="citetitle">NAT GATEWAY</em> section in
-       <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more details.
-      </p><div class="refsect3"><a name="idm140001396479984"></a><h4>Example</h4><pre class="screen">
-# ctdb natgwlist
-0 192.168.2.200
-Number of nodes:4
-pnn:0 192.168.2.200       OK (THIS NODE)
+       </pre></div></div><div class="refsect2"><a name="idm180"></a><h3>natgw {master|list|status}</h3><p>
+       This command shows different aspects of NAT gateway status.
+       For an overview of CTDB's NAT gateway functionality please see
+       the <em class="citetitle">NAT GATEWAY</em> section in
+       <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
+      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">master</span></dt><dd><p>
+             Show the PNN and private IP address of the current NAT
+             gateway master node.
+           </p><p>
+             Example output:
+           </p><pre class="screen">
+1 192.168.2.201
+           </pre></dd><dt><span class="term">list</span></dt><dd><p>
+             List the private IP addresses of nodes in the current
+             NAT gateway group, annotating the master node.
+           </p><p>
+             Example output:
+           </p><pre class="screen">
+192.168.2.200
+192.168.2.201  MASTER
+192.168.2.202
+192.168.2.203
+           </pre></dd><dt><span class="term">status</span></dt><dd><p>
+             List the nodes in the current NAT gateway group and
+             their status.
+           </p><p>
+             Example output:
+           </p><pre class="screen">
+pnn:0 192.168.2.200       UNHEALTHY (THIS NODE)
 pnn:1 192.168.2.201       OK
 pnn:2 192.168.2.202       OK
 pnn:3 192.168.2.203       OK
-       </pre></div></div><div class="refsect2"><a name="idm140001396478272"></a><h3>ping</h3><p>
+           </pre></dd></dl></div></div><div class="refsect2"><a name="idm206"></a><h3>ping</h3><p>
        This command will "ping" specified CTDB nodes in the cluster
        to verify that they are running.
-      </p><div class="refsect3"><a name="idm140001396477136"></a><h4>Example</h4><pre class="screen">
+      </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="idm140001396475616"></a><h3>ifaces</h3><p>
+       </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="idm140001396474448"></a><h4>Example</h4><pre class="screen">
+      </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
@@ -229,9 +243,9 @@ name:eth2 link:up references:1
 |eth4|0|0|
 |eth3|1|1|
 |eth2|1|1|
-       </pre></div></div><div class="refsect2"><a name="idm140001396472656"></a><h3>ip</h3><p>
+       </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="idm140001396471280"></a><h4>Example</h4><pre class="screen">
+      </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]
@@ -253,9 +267,9 @@ Public IPs on node 0
 |172.31.92.83|0|eth5|eth5|eth4,eth5|
 |172.31.92.84|1||eth5|eth4,eth5|
 |172.31.92.85|0|eth5|eth5|eth4,eth5|
-       </pre></div></div><div class="refsect2"><a name="idm140001396467728"></a><h3>ipinfo <em class="parameter"><code>IP</code></em></h3><p>
+       </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="idm140001396466112"></a><h4>Example</h4><pre class="screen">
+      </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
@@ -263,9 +277,9 @@ CurrentNode:0
 NumInterfaces:2
 Interface[1]: Name:eth4 Link:down References:0
 Interface[2]: Name:eth5 Link:up References:2 (active)
-       </pre></div></div><div class="refsect2"><a name="idm140001396464368"></a><h3>scriptstatus</h3><p>
+       </pre></div></div><div class="refsect2"><a name="idm231"></a><h3>scriptstatus</h3><p>
        This command displays which scripts where run in the previous monitoring cycle and the result of each script. If a script failed with an error, causing the node to become unhealthy, the output from that script is also shown.
-      </p><div class="refsect3"><a name="idm140001396463088"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm234"></a><h4>Example</h4><pre class="screen">
 # ctdb scriptstatus
 7 scripts were executed last monitoring cycle
 00.ctdb              Status:OK    Duration:0.056 Tue Mar 24 18:56:57 2009
@@ -277,34 +291,33 @@ Interface[2]: Name:eth5 Link:up References:2 (active)
 41.httpd             Status:OK    Duration:0.039 Tue Mar 24 18:56:57 2009
 50.samba             Status:ERROR    Duration:0.082 Tue Mar 24 18:56:57 2009
 OUTPUT:ERROR: Samba tcp port 445 is not responding
-      </pre></div></div><div class="refsect2"><a name="idm140001396460864"></a><h3>disablescript <em class="parameter"><code>SCRIPT</code></em></h3><p>
+      </pre></div></div><div class="refsect2"><a name="idm237"></a><h3>disablescript <em class="parameter"><code>SCRIPT</code></em></h3><p>
        This command is used to disable an eventscript.
       </p><p>
        This will take effect the next time the eventscripts are being executed so it can take a short while until this is reflected in 'scriptstatus'.
-      </p></div><div class="refsect2"><a name="idm140001396458656"></a><h3>enablescript <em class="parameter"><code>SCRIPT</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm242"></a><h3>enablescript <em class="parameter"><code>SCRIPT</code></em></h3><p>
        This command is used to enable an eventscript.
       </p><p>
        This will take effect the next time the eventscripts are being executed so it can take a short while until this is reflected in 'scriptstatus'.
-      </p></div><div class="refsect2"><a name="idm140001396456448"></a><h3>listvars</h3><p>
+      </p></div><div class="refsect2"><a name="idm247"></a><h3>listvars</h3><p>
        List all tuneable variables, except the values of the obsolete tunables
        like VacuumMinInterval. The obsolete tunables can be retrieved only
        explicitly with the "ctdb getvar" command.
-      </p><div class="refsect3"><a name="idm140001396455216"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm250"></a><h4>Example</h4><pre class="screen">
 # ctdb listvars
-MaxRedirectCount        = 3
 SeqnumInterval          = 1000
 ControlTimeout          = 60
 TraverseTimeout         = 20
 KeepaliveInterval       = 5
 KeepaliveLimit          = 5
-RecoverTimeout          = 20
+RecoverTimeout          = 120
 RecoverInterval         = 1
 ElectionTimeout         = 3
 TakeoverTimeout         = 9
 MonitorInterval         = 15
 TickleUpdateInterval    = 20
 EventScriptTimeout      = 30
-MonitorTimeoutCount     = 1
+MonitorTimeoutCount     = 20
 RecoveryGracePeriod     = 120
 RecoveryBanPeriod       = 300
 DatabaseHashSize        = 100001
@@ -313,7 +326,6 @@ RerecoveryTimeout       = 10
 EnableBans              = 1
 DeterministicIPs        = 0
 LCP2PublicIPs           = 1
-ReclockPingPeriod       = 60
 NoIPFailback            = 0
 DisableIPFailover       = 0
 VerboseMemoryNames      = 0
@@ -323,53 +335,67 @@ LogLatencyMs            = 0
 RecLockLatencyMs        = 1000
 RecoveryDropAllIPs      = 120
 VacuumInterval          = 10
-VacuumMaxRunTime        = 30
+VacuumMaxRunTime        = 120
 RepackLimit             = 10000
 VacuumLimit             = 5000
 VacuumFastPathCount     = 60
 MaxQueueDropMsg         = 1000000
-UseStatusEvents         = 0
 AllowUnhealthyDBRead    = 0
 StatHistoryInterval     = 1
 DeferredAttachTO        = 120
 AllowClientDBAttach     = 1
-RecoverPDBBySeqNum      = 0
-       </pre></div></div><div class="refsect2"><a name="idm140001396451152"></a><h3>getvar <em class="parameter"><code>NAME</code></em></h3><p>
+RecoverPDBBySeqNum      = 1
+DeferredRebalanceOnNodeAdd = 300
+FetchCollapse           = 1
+HopcountMakeSticky      = 50
+StickyDuration          = 600
+StickyPindown           = 200
+NoIPTakeover            = 0
+DBRecordCountWarn       = 100000
+DBRecordSizeWarn        = 10000000
+DBSizeWarn              = 100000000
+PullDBPreallocation     = 10485760
+NoIPHostOnAllDisabled   = 0
+Samba3AvoidDeadlocks    = 0
+TDBMutexEnabled         = 0
+LockProcessesPerDB      = 200
+       </pre></div></div><div class="refsect2"><a name="idm253"></a><h3>getvar <em class="parameter"><code>NAME</code></em></h3><p>
        Get the runtime value of a tuneable variable.
-      </p><div class="refsect3"><a name="idm140001396449632"></a><h4>Example</h4><pre class="screen">
-# ctdb getvar MaxRedirectCount
-MaxRedirectCount    = 3
-       </pre></div></div><div class="refsect2"><a name="idm140001396448112"></a><h3>setvar <em class="parameter"><code>NAME</code></em> <em class="parameter"><code>VALUE</code></em></h3><p>
+      </p><div class="refsect3"><a name="idm257"></a><h4>Example</h4><pre class="screen">
+# ctdb getvar MonitorInterval
+MonitorInterval         = 15
+       </pre></div></div><div class="refsect2"><a name="idm260"></a><h3>setvar <em class="parameter"><code>NAME</code></em> <em class="parameter"><code>VALUE</code></em></h3><p>
        Set the runtime value of a tuneable variable.
-      </p><p>
-       Example: ctdb setvar MaxRedirectCount 5
-      </p></div><div class="refsect2"><a name="idm140001396445456"></a><h3>lvsmaster</h3><p>
-       This command shows which node is currently the LVSMASTER. The
-       LVSMASTER is the node in the cluster which drives the LVS system and
-       which receives all incoming traffic from clients.
-      </p><p>
-       LVS is the mode where the entire CTDB/Samba cluster uses a single
-       ip address for the entire cluster. In this mode all clients connect to
-       one specific node which will then multiplex/loadbalance the clients
-       evenly onto the other nodes in the cluster. This is an alternative to using
-       public ip addresses. See the manpage for ctdbd for more information
-       about LVS.
-      </p></div><div class="refsect2"><a name="idm140001396443328"></a><h3>lvs</h3><p>
-       This command shows which nodes in the cluster are currently active in the
-       LVS configuration. I.e. which nodes we are currently loadbalancing
-       the single ip address across.
-      </p><p>
-       LVS will by default only loadbalance across those nodes that are both
-       LVS capable and also HEALTHY. Except if all nodes are UNHEALTHY in which
-       case LVS will loadbalance across all UNHEALTHY nodes as well.
-       LVS will never use nodes that are DISCONNECTED, STOPPED, BANNED or
-       DISABLED.
-      </p><p>
+      </p><div class="refsect3"><a name="idm265"></a><h4>Example</h4><pre class="screen">
+# ctdb setvar MonitorInterval 20
+       </pre></div></div><div class="refsect2"><a name="idm268"></a><h3>lvs {master|list|status}</h3><p>
+       This command shows different aspects of LVS status.  For an
+       overview of CTDB's LVS functionality please see the
+       <em class="citetitle">LVS</em> section in
+       <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
+      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">master</span></dt><dd><p>
+             Shows the PNN of the current LVS master node.
+           </p><p>
+       Example output:
+      </p><pre class="screen">
+2
+      </pre></dd><dt><span class="term">list</span></dt><dd><p>
+             Lists the currently usable LVS nodes.
+           </p><p>
+       Example output:
+      </p><pre class="screen">
+2 10.0.0.13
+3 10.0.0.14
+      </pre></dd><dt><span class="term">status</span></dt><dd><p>
+             List the nodes in the current LVS group and their status.
+           </p><p>
        Example output:
       </p><pre class="screen">
-2:10.0.0.13
-3:10.0.0.14
-      </pre></div><div class="refsect2"><a name="idm140001396440288"></a><h3>getcapabilities</h3><p>
+pnn:0 10.0.0.11        UNHEALTHY (THIS NODE)
+pnn:1 10.0.0.12        UNHEALTHY
+pnn:2 10.0.0.13        OK
+pnn:3 10.0.0.14        OK
+      </pre></dd></dl></div></div><div class="refsect2"><a name="idm294"></a><h3>getcapabilities</h3><p>
        This command shows the capabilities of the current node.  See
        the <em class="citetitle">CAPABILITIES</em> section in
        <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more details.
@@ -378,58 +404,72 @@ MaxRedirectCount    = 3
       </p><pre class="screen">
 RECMASTER: YES
 LMASTER: YES
-LVS: NO
-      </pre></div><div class="refsect2"><a name="idm140001396436848"></a><h3>statistics</h3><p>
+      </pre></div><div class="refsect2"><a name="idm303"></a><h3>statistics</h3><p>
         Collect statistics from the CTDB daemon about
         how many calls it has served.  Information about
         various fields in statistics can be found in
        <span class="citerefentry"><span class="refentrytitle">ctdb-statistics</span>(7)</span>.
-      </p><div class="refsect3"><a name="idm140001396434752"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm309"></a><h4>Example</h4><pre class="screen">
 # ctdb statistics
 CTDB version 1
-num_clients                        3
-frozen                             0
-recovering                         0
-client_packets_sent           360489
-client_packets_recv           360466
-node_packets_sent             480931
-node_packets_recv             240120
-keepalive_packets_sent             4
-keepalive_packets_recv             3
-node
-req_call                       2
-reply_call                     2
-req_dmaster                    0
-reply_dmaster                  0
-reply_error                    0
-req_message                   42
-req_control               120408
-reply_control             360439
-client
-req_call                       2
-req_message                   24
-req_control               360440
-timeouts
-call                           0
-control                        0
-traverse                       0
-total_calls                        2
-pending_calls                      0
-lockwait_calls                     0
-pending_lockwait_calls             0
-memory_used                     5040
-max_hop_count                      0
-max_call_latency                   4.948321 sec
-max_lockwait_latency               0.000000 sec
-       </pre></div></div><div class="refsect2"><a name="idm140001396430880"></a><h3>statisticsreset</h3><p>
+Current time of statistics  :                Tue Mar  8 15:18:51 2016
+Statistics collected since  : (003 21:31:32) Fri Mar  4 17:47:19 2016
+ num_clients                        9
+ frozen                             0
+ recovering                         0
+ num_recoveries                     2
+ client_packets_sent          8170534
+ client_packets_recv          7166132
+ node_packets_sent           16549998
+ node_packets_recv            5244418
+ keepalive_packets_sent        201969
+ keepalive_packets_recv        201969
+ node
+     req_call                      26
+     reply_call                     0
+     req_dmaster                    9
+     reply_dmaster                 12
+     reply_error                    0
+     req_message              1339231
+     req_control              8177506
+     reply_control            6831284
+ client
+     req_call                      15
+     req_message               334809
+     req_control              6831308
+ timeouts
+     call                           0
+     control                        0
+     traverse                       0
+ locks
+     num_calls                      8
+     num_current                    0
+     num_pending                    0
+     num_failed                     0
+ total_calls                       15
+ pending_calls                      0
+ childwrite_calls                   0
+ pending_childwrite_calls             0
+ memory_used                   394879
+ max_hop_count                      1
+ total_ro_delegations               0
+ total_ro_revokes                   0
+ hop_count_buckets: 8 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0
+ lock_buckets: 0 0 8 0 0 0 0 0 0 0 0 0 0 0 0 0
+ locks_latency      MIN/AVG/MAX     0.010005/0.010418/0.011010 sec out of 8
+ reclock_ctdbd      MIN/AVG/MAX     0.002538/0.002538/0.002538 sec out of 1
+ reclock_recd       MIN/AVG/MAX     0.000000/0.000000/0.000000 sec out of 0
+ call_latency       MIN/AVG/MAX     0.000044/0.002142/0.011702 sec out of 15
+ childwrite_latency MIN/AVG/MAX     0.000000/0.000000/0.000000 sec out of 0
+       </pre></div></div><div class="refsect2"><a name="idm312"></a><h3>statisticsreset</h3><p>
        This command is used to clear all statistics counters in a node.
       </p><p>
        Example: ctdb statisticsreset
-      </p></div><div class="refsect2"><a name="idm140001396429248"></a><h3>dbstatistics <em class="parameter"><code>DB</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm316"></a><h3>dbstatistics <em class="parameter"><code>DB</code></em></h3><p>
        Display statistics about the database DB.  Information
        about various fields in dbstatistics can be found in
        <span class="citerefentry"><span class="refentrytitle">ctdb-statistics</span>(7)</span>.
-      </p><div class="refsect3"><a name="idm140001396426704"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm323"></a><h4>Example</h4><pre class="screen">
 # ctdb dbstatistics locking.tdb
 DB Statistics: locking.tdb
  ro_delegations                     0
@@ -442,37 +482,16 @@ DB Statistics: locking.tdb
  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="idm140001396424592"></a><h3>getreclock</h3><p>
-       Show the name of the recovery lock file, if any.
+       </pre></div></div><div class="refsect2"><a name="idm326"></a><h3>getreclock</h3><p>
+       Show details of the recovery lock, if any.
       </p><p>
        Example output:
       </p><pre class="screen">
-       Reclock file:/clusterfs/.ctdb/recovery.lock
-      </pre></div><div class="refsect2"><a name="idm140001396422432"></a><h3>
-       setreclock [<span class="optional"><em class="parameter"><code>FILE</code></em></span>]
-      </h3><p>
-       FILE specifies the name of the recovery lock file.  If the
-       recovery lock file is changed at run-time then this will cause
-       a recovery, which in turn causes the recovery lock to be
-       retaken.
-      </p><p>
-       If no FILE is specified then a recovery lock file will no
-       longer be used.
-      </p><p>
-       This command only affects the run-time setting of a single
-       CTDB node.  This setting <span class="emphasis"><em>must</em></span> be changed
-       on all nodes simultaneously.  For information about configuring
-       the recovery lock file please see the
-       <em class="citetitle">CTDB_RECOVERY_LOCK</em> entry in
-       <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> and the
-       <em class="citetitle">--reclock</em> entry in
-       <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>.  For information
-       about the recovery lock please see the <em class="citetitle">RECOVERY
-       LOCK</em> section in
-       <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
-      </p></div><div class="refsect2"><a name="idm140001396415008"></a><h3>getdebug</h3><p>
+       /clusterfs/.ctdb/recovery.lock
+      </pre></div><div class="refsect2"><a name="idm331"></a><h3>getdebug</h3><p>
        Get the current debug level for the node. the debug level controls what information is written to the log file.
       </p><p>
        The debug levels are mapped to the corresponding syslog levels.
@@ -481,43 +500,53 @@ DB Statistics: locking.tdb
       </p><p>
        The list of debug levels from highest to lowest are :
       </p><p>
-       ERR WARNING NOTICE INFO DEBUG
-      </p></div><div class="refsect2"><a name="idm140001396412368"></a><h3>setdebug <em class="parameter"><code>DEBUGLEVEL</code></em></h3><p>
+       ERROR WARNING NOTICE INFO DEBUG
+      </p></div><div class="refsect2"><a name="idm337"></a><h3>setdebug <em class="parameter"><code>DEBUGLEVEL</code></em></h3><p>
        Set the debug level of a node. This controls what information will be logged.
       </p><p>
-       The debuglevel is one of ERR WARNING NOTICE INFO DEBUG
-      </p></div><div class="refsect2"><a name="idm140001396410240"></a><h3>getpid</h3><p>
+       The debuglevel is one of ERROR WARNING NOTICE INFO DEBUG
+      </p></div><div class="refsect2"><a name="idm342"></a><h3>getpid</h3><p>
        This command will return the process id of the ctdb daemon.
-      </p></div><div class="refsect2"><a name="idm140001396409088"></a><h3>disable</h3><p>
+      </p></div><div class="refsect2"><a name="idm345"></a><h3>disable</h3><p>
        This command is used to administratively disable a node in the cluster.
        A disabled node will still participate in the cluster and host
        clustered TDB records but its public ip address has been taken over by
        a different node and it no longer hosts any services.
-      </p></div><div class="refsect2"><a name="idm140001396407648"></a><h3>enable</h3><p>
+      </p></div><div class="refsect2"><a name="idm348"></a><h3>enable</h3><p>
        Re-enable a node that has been administratively disabled.
-      </p></div><div class="refsect2"><a name="idm140001396406496"></a><h3>stop</h3><p>
+      </p></div><div class="refsect2"><a name="idm351"></a><h3>stop</h3><p>
        This command is used to administratively STOP a node in the cluster.
        A STOPPED node is connected to the cluster but will not host any
        public ip addresse, nor does it participate in the VNNMAP.
        The difference between a DISABLED node and a STOPPED node is that
        a STOPPED node does not host any parts of the database which means
        that a recovery is required to stop/continue nodes.
-      </p></div><div class="refsect2"><a name="idm140001396404944"></a><h3>continue</h3><p>
+      </p></div><div class="refsect2"><a name="idm354"></a><h3>continue</h3><p>
        Re-start a node that has been administratively stopped.
-      </p></div><div class="refsect2"><a name="idm140001396403792"></a><h3>addip <em class="parameter"><code>IPADDR</code></em>/<em class="parameter"><code>mask</code></em> <em class="parameter"><code>IFACE</code></em></h3><p>
-       This command is used to add a new public ip to a node during runtime.
-       This allows public addresses to be added to a cluster without having
-       to restart the ctdb daemons.
-      </p><p>
-       Note that this only updates the runtime instance of ctdb. Any changes will be lost next time ctdb is restarted and the public addresses file is re-read.
-       If you want this change to be permanent you must also update the public addresses file manually.
-      </p></div><div class="refsect2"><a name="idm140001396400048"></a><h3>delip <em class="parameter"><code>IPADDR</code></em></h3><p>
-       This command is used to remove a public ip from a node during runtime.
-       If this public ip is currently hosted by the node it being removed from, the ip will first be failed over to another node, if possible, before it is removed.
-      </p><p>
-       Note that this only updates the runtime instance of ctdb. Any changes will be lost next time ctdb is restarted and the public addresses file is re-read.
-       If you want this change to be permanent you must also update the public addresses file manually.
-      </p></div><div class="refsect2"><a name="idm140001396397488"></a><h3>moveip <em class="parameter"><code>IPADDR</code></em> <em class="parameter"><code>PNN</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm357"></a><h3>addip <em class="parameter"><code>IPADDR</code></em>/<em class="parameter"><code>mask</code></em> <em class="parameter"><code>IFACE</code></em></h3><p>
+       This command is used to add a new public ip to a node
+       during runtime.  It should be followed by a <span class="command"><strong>ctdb
+       ipreallocate</strong></span>.  This allows public addresses to be
+       added to a cluster without having to restart the ctdb daemons.
+      </p><p>
+       Note that this only updates the runtime instance of ctdb. Any
+       changes will be lost next time ctdb is restarted and the public
+       addresses file is re-read.  If you want this change to be
+       permanent you must also update the public addresses file manually.
+      </p></div><div class="refsect2"><a name="idm365"></a><h3>delip <em class="parameter"><code>IPADDR</code></em></h3><p>
+       This command flags IPADDR for deletion from a node at runtime.
+       It should be followed by a <span class="command"><strong>ctdb
+       ipreallocate</strong></span>.  If IPADDR is currently hosted by the
+       node it is being removed from, this ensures that the IP will
+       first be failed over to another node, if possible, and that it
+       is then actually removed.
+      </p><p>
+       Note that this only updates the runtime instance of CTDB.  Any
+       changes will be lost next time CTDB is restarted and the
+       public addresses file is re-read.  If you want this change to
+       be permanent you must also update the public addresses file
+       manually.
+      </p></div><div class="refsect2"><a name="idm371"></a><h3>moveip <em class="parameter"><code>IPADDR</code></em> <em class="parameter"><code>PNN</code></em></h3><p>
        This command can be used to manually fail a public ip address to a
        specific node.
       </p><p>
@@ -528,9 +557,9 @@ DB Statistics: locking.tdb
        DeterministicIPs = 0
       </p><p>
        NoIPFailback = 1
-      </p></div><div class="refsect2"><a name="idm140001396393728"></a><h3>shutdown</h3><p>
+      </p></div><div class="refsect2"><a name="idm379"></a><h3>shutdown</h3><p>
        This command will shutdown a specific CTDB daemon.
-      </p></div><div class="refsect2"><a name="idm140001396392576"></a><h3>setlmasterrole on|off</h3><p>
+      </p></div><div class="refsect2"><a name="idm382"></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.
@@ -538,13 +567,13 @@ DB Statistics: locking.tdb
        Once this setting has been enabled/disabled, you need to perform a recovery for it to take effect.
       </p><p>
        See also "ctdb getcapabilities"
-      </p></div><div class="refsect2"><a name="idm140001396389696"></a><h3>setrecmasterrole on|off</h3><p>
+      </p></div><div class="refsect2"><a name="idm388"></a><h3>setrecmasterrole on|off</h3><p>
        This command is used ot enable/disable the RECMASTER capability for a node at runtime. This capability determines whether or not a node can be used as an RECMASTER for the cluster. A node that does not have the RECMASTER capability can not win a recmaster election. A node that already is the recmaster for the cluster when the capability is stripped off the node will remain the recmaster until the next cluster election.
       </p><p>
        Nodes will by default have this capability, but it can be stripped off nodes by the setting in the sysconfig file or by using this command.
       </p><p>
        See also "ctdb getcapabilities"
-      </p></div><div class="refsect2"><a name="idm140001396387168"></a><h3>reloadnodes</h3><p>
+      </p></div><div class="refsect2"><a name="idm393"></a><h3>reloadnodes</h3><p>
        This command is used when adding new nodes, or removing
        existing nodes from an existing cluster.
       </p><p>
@@ -593,14 +622,20 @@ DB Statistics: locking.tdb
          </p></li><li class="listitem"><p>
            Use <span class="command"><strong>ctdb status</strong></span> on all nodes and verify
            that the deleted nodes are no longer listed.
-         </p></li></ol></div></div><div class="refsect2"><a name="idm140001396367344"></a><h3>
+         </p></li></ol></div></div><div class="refsect2"><a name="idm434"></a><h3>
        reloadips
        [<span class="optional"><em class="parameter"><code>PNN-LIST</code></em></span>]
       </h3><p>
        This command reloads the public addresses configuration file
        on the specified nodes.  When it completes addresses will be
        reconfigured and reassigned across the cluster as necessary.
-      </p></div><div class="refsect2"><a name="idm140001396365232"></a><h3>getdbmap</h3><p>
+      </p><p>
+       This command is currently unable to make changes to the
+       netmask or interfaces associated with existing addresses.
+       Such changes must be made in 2 steps by deleting addresses in
+       question and re-adding then.  Unfortunately this will disrupt
+       connections to the changed addresses.
+      </p></div><div class="refsect2"><a name="idm440"></a><h3>getdbmap</h3><p>
        This command lists all clustered TDB databases that the CTDB daemon has attached to. Some databases are flagged as PERSISTENT, this means that the database stores data persistently and the data will remain across reboots. One example of such a database is secrets.tdb where information about how the cluster was joined to the domain is stored.
       </p><p>
        If a PERSISTENT database is not in a healthy state the database is
@@ -614,7 +649,7 @@ DB Statistics: locking.tdb
        and (if samba or tdb-utils are installed) "tdbtool check".
       </p><p>
        Most databases are not persistent and only store the state information that the currently running samba daemons need. These databases are always wiped when ctdb/samba starts and when a node is rebooted.
-      </p><div class="refsect3"><a name="idm140001396361920"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm446"></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
@@ -635,7 +670,7 @@ dbid:0xb775fff6 name:secrets.tdb path:/usr/local/var/lib/ctdb/persistent/secrets
 # ctdb -X getdbmap
 |ID|Name|Path|Persistent|Unhealthy|
 |0x7bbbd26c|passdb.tdb|/usr/local/var/lib/ctdb/persistent/passdb.tdb.0|1|0|
-       </pre></div></div><div class="refsect2"><a name="idm140001396359168"></a><h3>
+       </pre></div></div><div class="refsect2"><a name="idm449"></a><h3>
        backupdb
        <em class="parameter"><code>DB</code></em>
        <em class="parameter"><code>FILE</code></em>
@@ -644,7 +679,7 @@ dbid:0xb775fff6 name:secrets.tdb path:/usr/local/var/lib/ctdb/persistent/secrets
        read back using <span class="command"><strong>restoredb</strong></span>.  This is mainly
        useful for backing up persistent databases such as
        <code class="filename">secrets.tdb</code> and similar.
-      </p></div><div class="refsect2"><a name="idm140001396355344"></a><h3>
+      </p></div><div class="refsect2"><a name="idm456"></a><h3>
        restoredb
        <em class="parameter"><code>FILE</code></em>
        [<span class="optional"><em class="parameter"><code>DB</code></em></span>]
@@ -654,57 +689,45 @@ dbid:0xb775fff6 name:secrets.tdb path:/usr/local/var/lib/ctdb/persistent/secrets
        be restored back into the same database as it was created
        from. By specifying dbname you can restore the data into a
        different database.
-      </p></div><div class="refsect2"><a name="idm140001396352528"></a><h3>setdbreadonly <em class="parameter"><code>DB</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm462"></a><h3>setdbreadonly <em class="parameter"><code>DB</code></em></h3><p>
        This command will enable the read-only record support for a
        database.  This is an experimental feature to improve
        performance for contended records primarily in locking.tdb and
        brlock.tdb.  When enabling this feature you must set it on all
        nodes in the cluster.
-      </p></div><div class="refsect2"><a name="idm140001396350592"></a><h3>setdbsticky <em class="parameter"><code>DB</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm466"></a><h3>setdbsticky <em class="parameter"><code>DB</code></em></h3><p>
        This command will enable the sticky record support for the
        specified database.  This is an experimental feature to
        improve performance for contended records primarily in
        locking.tdb and brlock.tdb.  When enabling this feature you
        must set it on all nodes in the cluster.
-      </p></div></div><div class="refsect1"><a name="idm140001396348512"></a><h2>INTERNAL COMMANDS</h2><p>
+      </p></div></div><div class="refsect1"><a name="idm470"></a><h2>INTERNAL COMMANDS</h2><p>
       Internal commands are used by CTDB's scripts and are not
       required for managing a CTDB cluster.  Their parameters and
       behaviour are subject to change.
-    </p><div class="refsect2"><a name="idm140001396347296"></a><h3>gettickles <em class="parameter"><code>IPADDR</code></em></h3><p>
+    </p><div class="refsect2"><a name="idm473"></a><h3>gettickles <em class="parameter"><code>IPADDR</code></em></h3><p>
        Show TCP connections that are registered with CTDB to be
        "tickled" if there is a failover.
-      </p></div><div class="refsect2"><a name="idm140001396345536"></a><h3>gratiousarp <em class="parameter"><code>IPADDR</code></em> <em class="parameter"><code>INTERFACE</code></em></h3><p>
-       Send out a gratious ARP for the specified interface through
+      </p></div><div class="refsect2"><a name="idm477"></a><h3>gratarp <em class="parameter"><code>IPADDR</code></em> <em class="parameter"><code>INTERFACE</code></em></h3><p>
+       Send out a gratuitous ARP for the specified interface through
        the specified interface. This command is mainly used by the
        ctdb eventscripts.
-      </p></div><div class="refsect2"><a name="idm140001396343104"></a><h3>killtcp</h3><p>
-       Read a list of TCP connections, one per line, from standard
-       input and terminate each connection.  A connection is
-       specified as:
-      </p><pre class="synopsis">
-       <em class="parameter"><code>SRC-IPADDR</code></em>:<em class="parameter"><code>SRC-PORT</code></em> <em class="parameter"><code>DST-IPADDR</code></em>:<em class="parameter"><code>DST-PORT</code></em>
-      </pre><p>
-       Each connection is terminated by issuing a TCP RST to the
-       SRC-IPADDR:SRC-PORT endpoint.
-      </p><p>
-       A single connection can be specified on the command-line
-       rather than on standard input.
-      </p></div><div class="refsect2"><a name="idm140001396337680"></a><h3>
+      </p></div><div class="refsect2"><a name="idm482"></a><h3>
        pdelete <em class="parameter"><code>DB</code></em> <em class="parameter"><code>KEY</code></em>
       </h3><p>
        Delete KEY from DB.
-      </p></div><div class="refsect2"><a name="idm140001396335280"></a><h3>
+      </p></div><div class="refsect2"><a name="idm487"></a><h3>
        pfetch <em class="parameter"><code>DB</code></em> <em class="parameter"><code>KEY</code></em>
       </h3><p>
        Print the value associated with KEY in DB.
-      </p></div><div class="refsect2"><a name="idm140001396332880"></a><h3>
+      </p></div><div class="refsect2"><a name="idm492"></a><h3>
        pstore
        <em class="parameter"><code>DB</code></em>
        <em class="parameter"><code>KEY</code></em>
        <em class="parameter"><code>FILE</code></em>
       </h3><p>
        Store KEY in DB with contents of FILE as the associated value.
-      </p></div><div class="refsect2"><a name="idm140001396329776"></a><h3>
+      </p></div><div class="refsect2"><a name="idm498"></a><h3>
        ptrans
        <em class="parameter"><code>DB</code></em>
        [<span class="optional"><em class="parameter"><code>FILE</code></em></span>]
@@ -716,7 +739,7 @@ dbid:0xb775fff6 name:secrets.tdb path:/usr/local/var/lib/ctdb/persistent/secrets
        The key and value should be separated by spaces or tabs. Each
        key/value should be a printable string enclosed in
        double-quotes.
-      </p></div><div class="refsect2"><a name="idm140001396326512"></a><h3>runstate [setup|first_recovery|startup|running]</h3><p>
+      </p></div><div class="refsect2"><a name="idm505"></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.
@@ -724,33 +747,41 @@ dbid:0xb775fff6 name:secrets.tdb path:/usr/local/var/lib/ctdb/persistent/secrets
        If one or more optional runstate arguments are specified then
        the node must be in one of these runstates for the command to
        succeed.
-      </p><div class="refsect3"><a name="idm140001396324784"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm509"></a><h4>Example</h4><pre class="screen">
 # ctdb runstate
 RUNNING
-       </pre></div></div><div class="refsect2"><a name="idm140001396323264"></a><h3>setifacelink <em class="parameter"><code>IFACE</code></em> up|down</h3><p>
+       </pre></div></div><div class="refsect2"><a name="idm512"></a><h3>setifacelink <em class="parameter"><code>IFACE</code></em> up|down</h3><p>
        Set the internal state of network interface IFACE.  This is
        typically used in the <code class="filename">10.interface</code> script
        in the "monitor" event.
       </p><p>
        Example: ctdb setifacelink eth0 up
-      </p></div><div class="refsect2"><a name="idm140001396320384"></a><h3>tickle <em class="parameter"><code>SRC-IPADDR</code></em>:<em class="parameter"><code>SRC-PORT</code></em> <em class="parameter"><code>DST-IPADDR</code></em>:<em class="parameter"><code>DST-PORT</code></em></h3><p>
-       Send a TCP tickle to the source host for the specified TCP
-       connection.  A TCP tickle is a TCP ACK packet with an invalid
-       sequence and acknowledge number and will when received by the
-       source host result in it sending an immediate correct ACK back
-       to the other end.
+      </p></div><div class="refsect2"><a name="idm518"></a><h3>tickle</h3><p>
+       Read a list of TCP connections, one per line, from standard
+       input and send a TCP tickle to the source host for each
+       connection.  A connection is specified as:
+      </p><pre class="synopsis">
+       <em class="parameter"><code>SRC-IPADDR</code></em>:<em class="parameter"><code>SRC-PORT</code></em> <em class="parameter"><code>DST-IPADDR</code></em>:<em class="parameter"><code>DST-PORT</code></em>
+      </pre><p>
+       A single connection can be specified on the command-line
+       rather than on standard input.
+      </p><p>
+       A TCP tickle is a TCP ACK packet with an invalid sequence and
+       acknowledge number and will when received by the source host
+       result in it sending an immediate correct ACK back to the
+       other end.
       </p><p>
        TCP tickles are useful to "tickle" clients after a IP failover has
        occured since this will make the client immediately recognize the
        TCP connection has been disrupted and that the client will need
        to reestablish. This greatly speeds up the time it takes for a client
        to detect and reestablish after an IP failover in the ctdb cluster.
-      </p></div><div class="refsect2"><a name="idm140001396315824"></a><h3>version</h3><p>
+      </p></div><div class="refsect2"><a name="idm529"></a><h3>version</h3><p>
        Display the CTDB version.
-      </p></div></div><div class="refsect1"><a name="idm140001396314544"></a><h2>DEBUGGING COMMANDS</h2><p>
+      </p></div></div><div class="refsect1"><a name="idm532"></a><h2>DEBUGGING COMMANDS</h2><p>
       These commands are primarily used for CTDB development and testing and
       should not be used for normal administration.
-    </p><div class="refsect2"><a name="idm140001396313376"></a><h3>OPTIONS</h3><div class="variablelist"><dl class="variablelist"><dt><span class="term">--print-emptyrecords</span></dt><dd><p>
+    </p><div class="refsect2"><a name="idm535"></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
@@ -768,11 +799,11 @@ RUNNING
            This lets catdb and dumpdbbackup print the
            record flags for each record. Note that cattdb always
            prints the flags.
-         </p></dd></dl></div></div><div class="refsect2"><a name="idm140001396304352"></a><h3>process-exists <em class="parameter"><code>PID</code></em></h3><p>
+         </p></dd></dl></div></div><div class="refsect2"><a name="idm558"></a><h3>process-exists <em class="parameter"><code>PID</code></em></h3><p>
        This command checks if a specific process exists on the CTDB host. This is mainly used by Samba to check if remote instances of samba are still running or not.
-      </p></div><div class="refsect2"><a name="idm140001396302512"></a><h3>getdbstatus <em class="parameter"><code>DB</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm562"></a><h3>getdbstatus <em class="parameter"><code>DB</code></em></h3><p>
        This command displays more details about a database.
-      </p><div class="refsect3"><a name="idm140001396300912"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm566"></a><h4>Example</h4><pre class="screen">
 # ctdb getdbstatus test.tdb.0
 dbid: 0x122224da
 name: test.tdb
@@ -786,32 +817,28 @@ name: registry.tdb
 path: /usr/local/var/lib/ctdb/persistent/registry.tdb.0
 PERSISTENT: yes
 HEALTH: NO-HEALTHY-NODES - ERROR - Backup of corrupted TDB in '/usr/local/var/lib/ctdb/persistent/registry.tdb.0.corrupted.20091208091949.0Z'
-       </pre></div></div><div class="refsect2"><a name="idm140001396298944"></a><h3>catdb <em class="parameter"><code>DB</code></em></h3><p>
+       </pre></div></div><div class="refsect2"><a name="idm569"></a><h3>catdb <em class="parameter"><code>DB</code></em></h3><p>
        Print a dump of the clustered TDB database DB.
-      </p></div><div class="refsect2"><a name="idm140001396297296"></a><h3>cattdb <em class="parameter"><code>DB</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm573"></a><h3>cattdb <em class="parameter"><code>DB</code></em></h3><p>
        Print a dump of the contents of the local TDB database DB.
-      </p></div><div class="refsect2"><a name="idm140001396295568"></a><h3>dumpdbbackup <em class="parameter"><code>FILE</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm577"></a><h3>dumpdbbackup <em class="parameter"><code>FILE</code></em></h3><p>
        Print a dump of the contents from database backup FILE,
        similar to <span class="command"><strong>catdb</strong></span>.
-      </p></div><div class="refsect2"><a name="idm140001396293216"></a><h3>wipedb <em class="parameter"><code>DB</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm582"></a><h3>wipedb <em class="parameter"><code>DB</code></em></h3><p>
        Remove all contents of database DB.
-      </p></div><div class="refsect2"><a name="idm140001396291568"></a><h3>recover</h3><p>
+      </p></div><div class="refsect2"><a name="idm586"></a><h3>recover</h3><p>
        This command will trigger the recovery daemon to do a cluster
        recovery.
-      </p></div><div class="refsect2"><a name="idm140001396290320"></a><h3>ipreallocate, sync</h3><p>
+      </p></div><div class="refsect2"><a name="idm589"></a><h3>ipreallocate, sync</h3><p>
        This command will force the recovery master to perform a full ip reallocation process and redistribute all ip addresses. This is useful to "reset" the allocations back to its default state if they have been changed using the "moveip" command. While a "recover" will also perform this reallocation, a recovery is much more hevyweight since it will also rebuild all the databases.
-      </p></div><div class="refsect2"><a name="idm140001396288768"></a><h3>getmonmode</h3><p>
-       This command returns the monutoring mode of a node. The monitoring mode is either ACTIVE or DISABLED. Normally a node will continuously monitor that all other nodes that are expected are in fact connected and that they respond to commands.
-      </p><p>
-       ACTIVE - This is the normal mode. The node is actively monitoring all other nodes, both that the transport is connected and also that the node responds to commands. If a node becomes unavailable, it will be marked as DISCONNECTED and a recovery is initiated to restore the cluster.
-      </p><p>
-       DISABLED - This node is not monitoring that other nodes are available. In this mode a node failure will not be detected and no recovery will be performed. This mode is useful when for debugging purposes one wants to attach GDB to a ctdb process but wants to prevent the rest of the cluster from marking this node as DISCONNECTED and do a recovery.
-      </p></div><div class="refsect2"><a name="idm140001396285904"></a><h3>setmonmode 0|1</h3><p>
-       This command can be used to explicitly disable/enable monitoring mode on a node. The main purpose is if one wants to attach GDB to a running ctdb daemon but wants to prevent the other nodes from marking it as DISCONNECTED and issuing a recovery. To do this, set monitoring mode to 0 on all nodes before attaching with GDB. Remember to set monitoring mode back to 1 afterwards.
-      </p></div><div class="refsect2"><a name="idm140001396284352"></a><h3>attach <em class="parameter"><code>DBNAME</code></em> [persistent]</h3><p>
+      </p></div><div class="refsect2"><a name="idm592"></a><h3>getmonmode</h3><p>
+       This command prints the monitoring mode of a node.  This
+       indicates when CTDB is monitoring services on the node. The
+       monitoring mode is either ENABLED or DISABLED.
+      </p></div><div class="refsect2"><a name="idm595"></a><h3>attach <em class="parameter"><code>DBNAME</code></em> [persistent]</h3><p>
        Create a new CTDB database called DBNAME and attach to it on
        all nodes.
-      </p></div><div class="refsect2"><a name="idm140001396282480"></a><h3>detach <em class="parameter"><code>DB-LIST</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm599"></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
@@ -819,18 +846,16 @@ HEALTH: NO-HEALTHY-NODES - ERROR - Backup of corrupted TDB in '/usr/local/var/li
       </p><p>
        All nodes should be active and tunable AllowClientDBAccess should
        be disabled on all nodes before detaching databases.
-      </p></div><div class="refsect2"><a name="idm140001396280048"></a><h3>dumpmemory</h3><p>
+      </p></div><div class="refsect2"><a name="idm604"></a><h3>dumpmemory</h3><p>
        This is a debugging command. This command will make the ctdb
        daemon to write a fill memory allocation map to standard output.
-      </p></div><div class="refsect2"><a name="idm140001396278752"></a><h3>rddumpmemory</h3><p>
+      </p></div><div class="refsect2"><a name="idm607"></a><h3>rddumpmemory</h3><p>
        This is a debugging command. This command will dump the talloc memory
        allocation tree for the recovery daemon to standard output.
-      </p></div><div class="refsect2"><a name="idm140001396277440"></a><h3>thaw</h3><p>
-       Thaw a previously frozen node.
-      </p></div><div class="refsect2"><a name="idm140001396276288"></a><h3>eventscript <em class="parameter"><code>ARGUMENTS</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm610"></a><h3>eventscript <em class="parameter"><code>ARGUMENTS</code></em></h3><p>
        This is a debugging command. This command can be used to manually
        invoke and run the eventscritps with arbitrary arguments.
-      </p></div><div class="refsect2"><a name="idm140001396274496"></a><h3>ban <em class="parameter"><code>BANTIME</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm614"></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>
@@ -844,29 +869,21 @@ HEALTH: NO-HEALTHY-NODES - ERROR - Backup of corrupted TDB in '/usr/local/var/li
       </p><p>
        To administratively exclude a node from a cluster use the
        <span class="command"><strong>stop</strong></span> command.
-      </p></div><div class="refsect2"><a name="idm140001396270512"></a><h3>unban</h3><p>
+      </p></div><div class="refsect2"><a name="idm622"></a><h3>unban</h3><p>
        This command is used to unban a node that has either been
        administratively banned using the ban command or has been
        automatically banned.
-      </p></div><div class="refsect2"><a name="idm140001396269200"></a><h3>
-       rebalancenode
-       [<span class="optional"><em class="parameter"><code>PNN-LIST</code></em></span>]
-      </h3><p>
-       This command marks the given nodes as rebalance targets in the
-       LCP2 IP allocation algorithm.  The
-       <span class="command"><strong>reloadips</strong></span> command will do this as necessary
-       so this command should not be needed.
-      </p></div><div class="refsect2"><a name="idm140001396266464"></a><h3>check_srvids <em class="parameter"><code>SRVID</code></em> ...</h3><p>
+      </p></div><div class="refsect2"><a name="idm625"></a><h3>check_srvids <em class="parameter"><code>SRVID</code></em> ...</h3><p>
        This command checks whether a set of srvid message ports are
        registered on the node or not. The command takes a list of
        values to check.
-      </p><div class="refsect3"><a name="idm140001396264656"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm629"></a><h4>Example</h4><pre class="screen">
 # ctdb check_srvids 1 2 3 14765
 Server id 0:1 does not exist
 Server id 0:2 does not exist
 Server id 0:3 does not exist
 Server id 0:14765 exists
-       </pre></div></div></div><div class="refsect1"><a name="idm140001396262720"></a><h2>SEE ALSO</h2><p>
+       </pre></div></div></div><div class="refsect1"><a name="idm632"></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>,
index 9321103..8b6a36a 100644 (file)
@@ -1,4 +1,4 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdb.7"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb &#8212; Clustered TDB</p></div><div class="refsect1"><a name="idm140441723018176"></a><h2>DESCRIPTION</h2><p>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb</title><meta name="generator" content="DocBook XSL Stylesheets V1.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 &#8212; 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>
@@ -16,7 +16,7 @@
     Combined with a cluster filesystem CTDB provides a full
     high-availablity (HA) environment for services such as clustered
     Samba, NFS and other services.
-  </p></div><div class="refsect1"><a name="idm140441723037264"></a><h2>ANATOMY OF A CTDB CLUSTER</h2><p>
+  </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
@@ -25,7 +25,7 @@
   </p><p>
     CTDB provides an "all active" cluster, where services are load
     balanced across all nodes.
-  </p></div><div class="refsect1"><a name="idm140441725338896"></a><h2>Recovery Lock</h2><p>
+  </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
       master</em></span>.  This node takes and holds the recovery lock
       to assert its privileged role in the cluster.
     </p><p>
-      The recovery lock is implemented using a file residing in shared
-      storage (usually) on a cluster filesystem.  To support a
-      recovery lock the cluster filesystem must support lock
-      coherence.  See
+      By default, the recovery lock is implemented using a file
+      (specified by <em class="parameter"><code>CTDB_RECOVERY_LOCK</code></em>)
+      residing in shared storage (usually) on a cluster filesystem.
+      To support a recovery lock the cluster filesystem must support
+      lock coherence.  See
       <span class="citerefentry"><span class="refentrytitle">ping_pong</span>(1)</span> for more details.
+    </p><p>
+      The recovery lock can also be implemented using an arbitrary
+      cluster mutex call-out by using an exclamation point ('!') as
+      the first character of
+      <em class="parameter"><code>CTDB_RECOVERY_LOCK</code></em>.  For example, a value
+      of <span class="command"><strong>!/usr/local/bin/myhelper recovery</strong></span> would
+      run the given helper with the specified arguments.  See the
+      source code relating to cluster mutexes for clues about writing
+      call-outs.
     </p><p>
       If a cluster becomes partitioned (for example, due to a
       communication failure) and a different recovery master is
@@ -62,7 +72,7 @@
     </p><p>
       CTDB can run without a recovery lock but this is not recommended
       as there will be no protection from split brains.
-    </p></div><div class="refsect1"><a name="idm140441722733568"></a><h2>Private vs Public addresses</h2><p>
+    </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:
 
@@ -73,7 +83,7 @@
            One or more public IP addresses that are used to provide
            NAS or other services.
          </p></li></ul></div><p>
-    </p><div class="refsect2"><a name="idm140441727493008"></a><h3>Private address</h3><p>
+    </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
       </p><p>
         It is strongly recommended that the private addresses are
         configured on a private network that is separate from client
-        networks.
+        networks.  This is because the CTDB protocol is both
+        unauthenticated and unencrypted.  If clients share the private
+        network then steps need to be taken to stop injection of
+        packets to relevant ports on the private addresses.  It is
+        also likely that CTDB protocol traffic between nodes could
+        leak sensitive information if it can be intercepted.
       </p><p>
        Example <code class="filename">/usr/local/etc/ctdb/nodes</code> for a four node
        cluster:
 192.168.1.2
 192.168.1.3
 192.168.1.4
-      </pre></div><div class="refsect2"><a name="idm140441727640272"></a><h3>Public addresses</h3><p>
+      </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
@@ -173,7 +188,7 @@ Node 3:/usr/local/etc/ctdb/public_addresses
       </p><p>
         The <span class="command"><strong>ctdb ip</strong></span> command can be used to view the
         current assignment of public addresses to physical nodes.
-      </p></div></div><div class="refsect1"><a name="idm140441727555008"></a><h2>Node status</h2><p>
+      </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>
@@ -218,7 +233,7 @@ Node 3:/usr/local/etc/ctdb/public_addresses
            like a healthy (OK) node.  Some interfaces to serve public
            addresses are down, but at least one interface is up.  See
            also <span class="command"><strong>ctdb ifaces</strong></span>.
-         </p></dd></dl></div></div><div class="refsect1"><a name="idm140441727667696"></a><h2>CAPABILITIES</h2><p>
+         </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>
@@ -233,19 +248,11 @@ Node 3:/usr/local/etc/ctdb/public_addresses
            has the latest copy of a record in a volatile database.
          </p><p>
            Default is YES.
-         </p></dd><dt><span class="term">LVS</span></dt><dd><p>
-           Indicates that a node is configued in Linux Virtual Server
-           (LVS) mode.  In this mode the entire CTDB cluster uses one
-           single public address for the entire cluster instead of
-           using multiple public addresses in failover mode.  This is
-           an alternative to using a load-balancing layer-4 switch.
-           See the <em class="citetitle">LVS</em> section for more
-           details.
          </p></dd></dl></div><p>
       The RECMASTER and LMASTER capabilities can be disabled when CTDB
       is used to create a cluster spanning across WAN links. In this
       case CTDB acts as a WAN accelerator.
-    </p></div><div class="refsect1"><a name="idm140441727658624"></a><h2>LVS</h2><p>
+    </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
@@ -254,23 +261,31 @@ Node 3:/usr/local/etc/ctdb/public_addresses
       This is similar to using a layer-4 loadbalancing switch but with
       some restrictions.
     </p><p>
-      In this mode the cluster selects a set of nodes in the cluster
-      and loadbalance all client access to the LVS address across this
-      set of nodes. This set of nodes are all LVS capable nodes that
-      are HEALTHY, or if no HEALTHY nodes exists all LVS capable nodes
-      regardless of health status.  LVS will however never loadbalance
-      traffic to nodes that are BANNED, STOPPED, DISABLED or
-      DISCONNECTED. The <span class="command"><strong>ctdb lvs</strong></span> command is used to
-      show which nodes are currently load-balanced across.
+      One extra LVS public address is assigned on the public network
+      to each LVS group.  Each LVS group is a set of nodes in the
+      cluster that presents the same LVS address public address to the
+      outside world.  Normally there would only be one LVS group
+      spanning an entire cluster, but in situations where one CTDB
+      cluster spans multiple physical sites it might be useful to have
+      one LVS group for each site.  There can be multiple LVS groups
+      in a cluster but each node can only be member of one LVS group.
+    </p><p>
+      Client access to the cluster is load-balanced across the HEALTHY
+      nodes in an LVS group.  If no HEALTHY nodes exists then all
+      nodes in the group are used, regardless of health status.  CTDB
+      will, however never load-balance LVS traffic to nodes that are
+      BANNED, STOPPED, DISABLED or DISCONNECTED.  The <span class="command"><strong>ctdb
+      lvs</strong></span> command is used to show which nodes are currently
+      load-balanced across.
     </p><p>
-      One of the these nodes are elected as the LVSMASTER. This node
-      receives all traffic from clients coming in to the LVS address
-      and multiplexes it across the internal network to one of the
-      nodes that LVS is using.  When responding to the client, that
-      node will send the data back directly to the client, bypassing
-      the LVSMASTER node.  The command <span class="command"><strong>ctdb
-      lvsmaster</strong></span> will show which node is the current
-      LVSMASTER.
+      In each LVS group, one of the nodes is selected by CTDB to be
+      the LVS master.  This node receives all traffic from clients
+      coming in to the LVS public address and multiplexes it across
+      the internal network to one of the nodes that LVS is using.
+      When responding to the client, that node will send the data back
+      directly to the client, bypassing the LVS master node.  The
+      command <span class="command"><strong>ctdb lvsmaster</strong></span> will show which node
+      is the current LVS master.
     </p><p>
       The path used for a client I/O is:
       </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
@@ -283,7 +298,7 @@ Node 3:/usr/local/etc/ctdb/public_addresses
          </p></li><li class="listitem"><p>
            Node responds back to client.
          </p></li></ol></div><p>
-    </p><p> 
+    </p><p>
       This means that all incoming traffic to the cluster will pass
       through one physical node, which limits scalability. You can
       send more data to the LVS address that one physical node can
@@ -311,19 +326,41 @@ Node 3:/usr/local/etc/ctdb/public_addresses
       reachable from a node <span class="emphasis"><em>before</em></span> you enable
       LVS.  Also ensure that outgoing traffic to these hosts is routed
       out through the configured public interface.
-    </p><div class="refsect2"><a name="idm140441722121984"></a><h3>Configuration</h3><p>
+    </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_PUBLIC_INTERFACE</code> and
-       <code class="varname">CTDB_LVS_PUBLIC_IP</code> configuration variables.
-       Setting the latter variable also enables the LVS capability on
-       the node at startup.
+       <code class="varname">CTDB_LVS_PUBLIC_IFACE</code>,
+       <code class="varname">CTDB_LVS_PUBLIC_IP</code> and
+       <code class="varname">CTDB_LVS_NODES</code> configuration variables.
+       <code class="varname">CTDB_LVS_NODES</code> specifies a file containing
+       the private address of all nodes in the current node's LVS
+       group.
       </p><p>
        Example:
        </p><pre class="screen">
-CTDB_PUBLIC_INTERFACE=eth1
+CTDB_LVS_PUBLIC_IFACE=eth1
 CTDB_LVS_PUBLIC_IP=10.1.1.237
+CTDB_LVS_NODES=/usr/local/etc/ctdb/lvs_nodes
        </pre><p>
-      </p></div></div><div class="refsect1"><a name="idm140441722118800"></a><h2>TRACKING AND RESETTING TCP CONNECTIONS</h2><p>
+      </p><p>
+       Example <code class="filename">/usr/local/etc/ctdb/lvs_nodes</code>:
+      </p><pre class="screen">
+192.168.1.2
+192.168.1.3
+192.168.1.4
+      </pre><p>
+       Normally any node in an LVS group can act as the LVS master.
+       Nodes that are highly loaded due to other demands maybe
+       flagged with the "slave-only" option in the
+       <code class="varname">CTDB_LVS_NODES</code> file to limit the LVS
+       functionality of those nodes.
+      </p><p>
+       LVS nodes file that excludes 192.168.1.4 from being
+       the LVS master node:
+      </p><pre class="screen">
+192.168.1.2
+192.168.1.3
+192.168.1.4 slave-only
+      </pre></div></div><div class="refsect1"><a name="idm183"></a><h2>TRACKING AND RESETTING TCP CONNECTIONS</h2><p>
       CTDB tracks TCP connections from clients to public IP addresses,
       on known ports.  When an IP address moves from one node to
       another, all existing TCP connections to that IP address are
@@ -336,7 +373,7 @@ CTDB_LVS_PUBLIC_IP=10.1.1.237
       a release and take of a public IP address on the same node.
       Such connections can get out of sync with sequence and ACK
       numbers, potentially causing a disruptive ACK storm.
-    </p></div><div class="refsect1"><a name="idm140441722116496"></a><h2>NAT GATEWAY</h2><p>
+    </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)
@@ -353,7 +390,7 @@ CTDB_LVS_PUBLIC_IP=10.1.1.237
       extra static IP address to a public interface on every node.
       This is simpler but it uses an extra IP address per node, while
       NAT gateway generally uses only one extra IP address.
-    </p><div class="refsect2"><a name="idm140441722113808"></a><h3>Operation</h3><p>
+    </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
@@ -374,7 +411,7 @@ CTDB_LVS_PUBLIC_IP=10.1.1.237
        public IP address and routes outgoing connections from
        slave nodes via this IP address.  It also establishes a
        fallback default route.
-      </p></div><div class="refsect2"><a name="idm140441722110800"></a><h3>Configuration</h3><p>
+      </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
@@ -393,7 +430,7 @@ CTDB_NATGW_DEFAULT_GATEWAY=10.0.0.1
        See the <em class="citetitle">NAT GATEWAY</em> section in
        <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> for more details of
        NATGW configuration.
-      </p></div><div class="refsect2"><a name="idm140441722106032"></a><h3>Implementation details</h3><p>
+      </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
@@ -428,7 +465,7 @@ CTDB_NATGW_DEFAULT_GATEWAY=10.0.0.1
        eventscript.  Please see the eventscript file and the
        <em class="citetitle">NAT GATEWAY</em> section in
        <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> for more details.
-      </p></div></div><div class="refsect1"><a name="idm140441722098208"></a><h2>POLICY ROUTING</h2><p>
+      </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
@@ -438,7 +475,7 @@ CTDB_NATGW_DEFAULT_GATEWAY=10.0.0.1
       This allows routing to be specified for packets sourced from
       each public address.  The routes are added and removed as CTDB
       moves public addresses between nodes.
-    </p><div class="refsect2"><a name="idm140441722095984"></a><h3>Configuration variables</h3><p>
+    </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>,
@@ -446,7 +483,7 @@ CTDB_NATGW_DEFAULT_GATEWAY=10.0.0.1
        <code class="varname">CTDB_PER_IP_ROUTING_TABLE_ID_HIGH</code>.  See the
        <em class="citetitle">POLICY ROUTING</em> section in
        <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> for more details.
-      </p></div><div class="refsect2"><a name="idm140441722092016"></a><h3>Configuration</h3><p>
+      </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">
@@ -508,7 +545,7 @@ CTDB_NATGW_DEFAULT_GATEWAY=10.0.0.1
       </p><pre class="screen">
   192.168.1.0/24 dev eth2 scope link 
   default via 192.168.1.1 dev eth2 
-      </pre></div><div class="refsect2"><a name="idm140441722076800"></a><h3>Sample configuration</h3><p>
+      </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:
@@ -528,7 +565,7 @@ CTDB_NATGW_DEFAULT_GATEWAY=10.0.0.1
        The routes local packets as expected, the default route is as
        previously discussed, but packets to 192.168.200.0/24 are
        routed via the alternate gateway 192.168.1.254.
-      </p></div></div><div class="refsect1"><a name="idm140441722073584"></a><h2>NOTIFICATION SCRIPT</h2><p>
+      </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
@@ -544,9 +581,9 @@ CTDB_NATGW_DEFAULT_GATEWAY=10.0.0.1
     </p><p>
       CTDB currently generates notifications after CTDB changes to
       these states:
-    </p><table border="0" summary="Simple list" class="simplelist"><tr><td>init</td></tr><tr><td>setup</td></tr><tr><td>startup</td></tr><tr><td>healthy</td></tr><tr><td>unhealthy</td></tr></table></div><div class="refsect1"><a name="idm140441722066640"></a><h2>DEBUG LEVELS</h2><p>
+    </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 (0)</td></tr><tr><td>WARNING (1)</td></tr><tr><td>NOTICE (2)</td></tr><tr><td>INFO (3)</td></tr><tr><td>DEBUG (4)</td></tr></table></div><div class="refsect1"><a name="idm140441722062944"></a><h2>REMOTE CLUSTER NODES</h2><p>
+    </p><table border="0" summary="Simple list" class="simplelist"><tr><td>ERR (0)</td></tr><tr><td>WARNING (1)</td></tr><tr><td>NOTICE (2)</td></tr><tr><td>INFO (3)</td></tr><tr><td>DEBUG (4)</td></tr></table></div><div class="refsect1"><a name="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.
@@ -575,13 +612,15 @@ CTDB_CAPABILITY_RECMASTER=no
     </p><p>
        Verify with the command "ctdb getcapabilities" that that node no longer
        has the recmaster or the lmaster capabilities.
-    </p></div><div class="refsect1"><a name="idm140441722058240"></a><h2>SEE ALSO</h2><p>
+    </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>,
diff --git a/web/manpages/ctdb_diagnostics.1.html b/web/manpages/ctdb_diagnostics.1.html
new file mode 100644 (file)
index 0000000..4831468
--- /dev/null
@@ -0,0 +1,19 @@
+<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 &#8212; 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 &lt;nodes&gt;</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>
index 8ded4ff..ca6d0b7 100644 (file)
@@ -1,11 +1,11 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdbd</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdbd.1"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdbd &#8212; The CTDB cluster daemon</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ctdbd</code>  [<em class="replaceable"><code>OPTION</code></em>...]</p></div></div><div class="refsect1"><a name="idm139840524087616"></a><h2>DESCRIPTION</h2><p>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdbd</title><meta name="generator" content="DocBook XSL Stylesheets V1.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 &#8212; 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="idm139840525514688"></a><h2>GENERAL OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-d, --debug=<em class="parameter"><code>DEBUGLEVEL</code></em></span></dt><dd><p>
+    </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.
                        format.  This method will log the correct
                        hostname but is not as widely implemented in
                        syslog daemons.
-                     </p></dd></dl></div></dd></dl></div></dd><dt><span class="term">--lvs</span></dt><dd><p>
-           This option is used to activate the LVS capability on a CTDB
-           node.  Please see the <em class="citetitle">LVS</em> section in
-           <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
-           information.
-         </p></dd><dt><span class="term">--max-persistent-check-errors=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
+                     </p></dd></dl></div></dd></dl></div></dd><dt><span class="term">--max-persistent-check-errors=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
            NUM specifies the maximum number of health check failures
            allowed for persistent databases during startup.
          </p><p>
            This is usually the file
            <code class="filename">/usr/local/etc/ctdb/public_addresses</code>
          </p></dd><dt><span class="term">--public-interface=<em class="parameter"><code>INTERFACE</code></em></span></dt><dd><p>
-           INTERFACE on which to attach public IP addresses or on which
-           to attach the single-public-ip when used.
+           Default INTERFACE on which to attach public IP addresses.
          </p><p>
            When using public IP addresses, this is only required if
            interfaces are not explicitly specified in the public
            addresses file.
-         </p></dd><dt><span class="term">--reclock=<em class="parameter"><code>FILE</code></em></span></dt><dd><p>
-           FILE is the name of the recovery lock file, stored in
-           <span class="emphasis"><em>shared storage</em></span>, that CTDB uses to
-           prevent split brains.
+         </p></dd><dt><span class="term">--reclock=<em class="parameter"><code>LOCK</code></em></span></dt><dd><p>
+           LOCK specifies the cluster-wide mutex used to detect and
+           prevent a partitioned cluster (or "split brain").
          </p><p>
            For information about the recovery lock please see the
            <em class="citetitle">RECOVERY LOCK</em> section in
            <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
-         </p></dd><dt><span class="term">--single-public-ip=<em class="parameter"><code>IPADDR</code></em></span></dt><dd><p>
-           IPADDR specifies the single IP that CTDB will use in
-           conjunction with LVS.
-         </p><p>
-           Please see the <em class="citetitle">LVS</em> section in
-           <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
-           information.
          </p></dd><dt><span class="term">--start-as-disabled</span></dt><dd><p>
            This makes ctdbd start in the DISABLED state.
          </p><p>
            The "infiniband" support is not regularly tested.
          </p></dd><dt><span class="term">-?, --help</span></dt><dd><p>
            Display a summary of options.
-         </p></dd></dl></div></div><div class="refsect1"><a name="idm139840521704176"></a><h2>DEBUGGING OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-i, --interactive</span></dt><dd><p>
+         </p></dd></dl></div></div><div class="refsect1"><a name="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
            This is a debugging option. This option is only used when
            debugging ctdbd.  This enables additional debugging
            capabilities and implies --nosetsched.
-         </p></dd></dl></div></div><div class="refsect1"><a name="idm139840521682688"></a><h2>SEE ALSO</h2><p>
+         </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>,
index c618d2b..458ef52 100644 (file)
@@ -1,4 +1,4 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdbd.conf</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdbd.conf.5"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdbd.conf &#8212; CTDB daemon configuration file</p></div><div class="refsect1"><a name="idm140222705806272"></a><h2>DESCRIPTION</h2><p>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdbd.conf</title><meta name="generator" content="DocBook XSL Stylesheets V1.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 &#8212; CTDB daemon configuration file</p></div><div class="refsect1"><a name="idm10"></a><h2>DESCRIPTION</h2><p>
       This file contains CTDB configuration variables that are affect
       the operation of CTDB.  The default location of this file is
       <code class="filename">/usr/local/etc/ctdb/ctdbd.conf</code>.
@@ -17,7 +17,7 @@
       A historical alternative is
       <code class="filename">/usr/local/etc/ctdb/sysconfig/ctdb</code> - this is
       deprecated.
-    </p></div><div class="refsect1"><a name="idm140222708394512"></a><h2>
+    </p></div><div class="refsect1"><a name="idm23"></a><h2>
       INITSCRIPT CONFIGURATION
     </h2><p>
       Some options must be available to the initscript so they need to
          </p><p>
            Default is <code class="filename">/usr/local/var/run/ctdb/ctdbd.pid</code>.
            Corresponds to <code class="option">--pidfile</code>.
-         </p></dd></dl></div></div><div class="refsect1"><a name="idm140222705452464"></a><h2>
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm40"></a><h2>
       GLOBAL CONFIGURATION
     </h2><p>
       These options may be used in the initscripts, daemon and
       scripts.
     </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_BASE=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
            DIRECTORY containing CTDB scripts and configuration files.
-         </p></dd></dl></div></div><div class="refsect1"><a name="idm140222710281056"></a><h2>
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm49"></a><h2>
       DAEMON CONFIGURATION
     </h2><p>
       Variables in this section are processed by
                        format.  This method will log the correct
                        hostname but is not as widely implemented in
                        syslog daemons.
-                     </p></dd></dl></div></dd></dl></div></dd><dt><span class="term">CTDB_LVS_PUBLIC_IP=<em class="parameter"><code>IPADDR</code></em></span></dt><dd><p>
-           No default.  Corresponds to "<code class="option">--lvs</code>
-           <code class="option">--single-public-ip IPADDR"</code>.
-         </p></dd><dt><span class="term">CTDB_NODES=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+                     </p></dd></dl></div></dd></dl></div></dd><dt><span class="term">CTDB_NODES=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
            Default is <code class="varname">CTDB_BASE</code>/nodes, so usually
            <code class="filename">/usr/local/etc/ctdb/nodes</code>.  Corresponds to
            <code class="option">--nlist</code>.
+         </p></dd><dt><span class="term">CTDB_NOSETSCHED=yes|no</span></dt><dd><p>
+           Defaults to no.  Corresponds to <code class="option">--nosetsched</code>.
+         </p><p>
+           Usually CTDB runs with real-time priority.  If you are running
+           CTDB on a platform that does not support real-time priority,
+           you can set this.
          </p></dd><dt><span class="term">CTDB_NOTIFY_SCRIPT=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
            No default, usually
            <code class="filename">/usr/local/etc/ctdb/notify.sh</code>.  Corresponds to
          </p></dd><dt><span class="term">CTDB_PUBLIC_INTERFACE=<em class="parameter"><code>INTERFACE</code></em></span></dt><dd><p>
            No default.  Corresponds to
            <code class="option">--public-interface</code>.
-         </p></dd><dt><span class="term">CTDB_RECOVERY_LOCK=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
-           Defaults to
+         </p></dd><dt><span class="term">CTDB_RECOVERY_LOCK=<em class="parameter"><code>LOCK</code></em></span></dt><dd><p>
+           LOCK specifies the cluster-wide mutex used to detect and
+           prevent a partitioned cluster (or "split brain").
+         </p><p>
+           No default, but the default configuration file specifies
            <code class="filename">/some/place/on/shared/storage</code>, which
            should be change to a useful value.  Corresponds to
            <code class="option">--reclock</code>.
            "setup" event before this timeout then it is killed.
          </p><p>
            Defaults is 10.
-         </p></dd></dl></div></div><div class="refsect1"><a name="idm140222704871744"></a><h2>NETWORK CONFIGURATION</h2><div class="refsect2"><a name="idm140222704871104"></a><h3>NAT GATEWAY</h3><p>
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm277"></a><h2>NETWORK CONFIGURATION</h2><div class="refsect2"><a name="idm279"></a><h3>NAT GATEWAY</h3><p>
        NAT gateway is used to configure fallback routing for nodes
        when they do not host any public IP addresses.  For example,
        it allows unhealthy nodes to reliably communicate with
              route to avoid this.
            </p><p>
              No default.
-           </p></dd></dl></div><div class="refsect3"><a name="idm140222704844880"></a><h4>Example</h4><pre class="screen">
+           </p></dd></dl></div><div class="refsect3"><a name="idm337"></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
@@ -311,7 +317,7 @@ CTDB_NATGW_STATIC_ROUTES=10.0.0.0/24
        </pre><p>
          Note that <code class="varname">CTDB_NATGW_DEFAULT_GATEWAY</code> is
          not specified.
-       </p></div></div><div class="refsect2"><a name="idm140222704840976"></a><h3>POLICY ROUTING</h3><p>
+       </p></div></div><div class="refsect2"><a name="idm344"></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
@@ -375,12 +381,43 @@ CTDB_NATGW_STATIC_ROUTES=10.0.0.0/24
              manipulate).
            </p><p>
              No default, usually 1000 and 9000.
-           </p></dd></dl></div><div class="refsect3"><a name="idm140222704819040"></a><h4>Example</h4><pre class="screen">
+           </p></dd></dl></div><div class="refsect3"><a name="idm393"></a><h4>Example</h4><pre class="screen">
 CTDB_PER_IP_ROUTING_CONF=/usr/local/etc/ctdb/policy_routing
 CTDB_PER_IP_ROUTING_RULE_PREF=100
 CTDB_PER_IP_ROUTING_TABLE_ID_LOW=1000
 CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000
-       </pre></div></div><div class="refsect2"><a name="idm140222704817328"></a><h3>MISCELLANEOUS NETWORK CONFIGURATION</h3><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_PARTIALLY_ONLINE_INTERFACES=yes|no</span></dt><dd><p>
+       </pre></div></div><div class="refsect2"><a name="idm396"></a><h3>LVS</h3><p>
+       For a general description see the <em class="citetitle">LVS</em>
+       section in <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
+      </p><div class="refsect3"><a name="idm403"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">91.lvs</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_LVS_NODES=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+             FILENAME contains the list of nodes that belong to the
+             same LVS group.
+           </p><p>
+             File format:
+             </p><pre class="screen">
+<em class="parameter"><code>IPADDR</code></em> [<span class="optional">slave-only</span>]
+             </pre><p>
+           </p><p>
+             IPADDR is the private IP address of each node in the LVS
+             group.
+           </p><p>
+             If "slave-only" is specified then the corresponding node
+             can not be the LVS master node.  In this case
+             <code class="varname">CTDB_LVS_PUBLIC_IFACE</code> and
+             <code class="varname">CTDB_LVS_PUBLIC_IP</code> are optional and
+             unused.
+           </p><p>
+             No default, usually
+             <code class="filename">/usr/local/etc/ctdb/lvs_nodes</code> when enabled.
+           </p></dd><dt><span class="term">CTDB_LVS_PUBLIC_IFACE=<em class="parameter"><code>INTERFACE</code></em></span></dt><dd><p>
+             INTERFACE is the network interface that clients will use
+             to connection to <code class="varname">CTDB_LVS_PUBLIC_IP</code>.
+             This is optional for slave-only nodes.
+             No default.
+           </p></dd><dt><span class="term">CTDB_LVS_PUBLIC_IP=<em class="parameter"><code>IPADDR</code></em></span></dt><dd><p>
+             CTDB_LVS_PUBLIC_IP is the LVS public address.  No
+             default.
+         </p></dd></dl></div></div><div class="refsect2"><a name="idm435"></a><h3>MISCELLANEOUS NETWORK CONFIGURATION</h3><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_PARTIALLY_ONLINE_INTERFACES=yes|no</span></dt><dd><p>
              Whether one or more offline interfaces should cause a
              monitor event to fail if there are other interfaces that
              are up.  If this is "yes" and a node has some interfaces
@@ -393,7 +430,7 @@ CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000
              to be up.
            </p><p>
              Default is "no".
-           </p></dd></dl></div></div></div><div class="refsect1"><a name="idm140222704812656"></a><h2>SERVICE CONFIGURATION</h2><p>
+           </p></dd></dl></div></div></div><div class="refsect1"><a name="idm445"></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>
@@ -402,7 +439,7 @@ CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000
       monitor the service and CTDB will do any required
       reconfiguration of the service when public IP addresses are
       failed over.
-    </p><div class="refsect2"><a name="idm140222704810800"></a><h3>SAMBA</h3><div class="refsect3"><a name="idm140222704810160"></a><h4>Eventscripts</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">49.winbind</code></td></tr><tr><td><code class="filename">50.samba</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_SAMBA=yes|no</span></dt><dd><p>
+    </p><div class="refsect2"><a name="idm449"></a><h3>SAMBA</h3><div class="refsect3"><a name="idm451"></a><h4>Eventscripts</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">49.winbind</code></td></tr><tr><td><code class="filename">50.samba</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_SAMBA=yes|no</span></dt><dd><p>
              Should CTDB manage Samba?
            </p><p>
              Default is no.
@@ -434,16 +471,11 @@ CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000
              Distribution specific SERVICE for managing winbindd.
            </p><p>
              Default is "winbind".
-           </p></dd></dl></div></div><div class="refsect2"><a name="idm140222704790816"></a><h3>NFS</h3><p>
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm498"></a><h3>NFS</h3><p>
        This includes parameters for the kernel NFS server.
        Alternative NFS subsystems (such as <a class="ulink" href="https://github.com/nfs-ganesha/nfs-ganesha/wiki" target="_top">NFS-Ganesha</a>)
        can be integrated using <code class="varname">CTDB_NFS_CALLOUT</code>.
-      </p><div class="refsect3"><a name="idm140222704788672"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">60.nfs</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_CLUSTER_FILESYSTEM_TYPE=gpfs</span></dt><dd><p>
-             The type of cluster filesystem to use with NFS-ganesha.
-             Currently only "gpfs" is supported.
-           </p><p>
-             Default is "gpfs".
-           </p></dd><dt><span class="term">CTDB_MANAGES_NFS=yes|no</span></dt><dd><p>
+      </p><div class="refsect3"><a name="idm503"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">60.nfs</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_NFS=yes|no</span></dt><dd><p>
              Should CTDB manage NFS?
            </p><p>
              Default is no.
@@ -477,16 +509,22 @@ CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000
              overheads.
            </p><p>
              Default is "::1".
-           </p></dd></dl></div></div><div class="refsect2"><a name="idm140222704767600"></a><h3>APACHE HTTPD</h3><p>
+           </p></dd><dt><span class="term">CTDB_NFS_STATE_FS_TYPE=<em class="parameter"><code>TYPE</code></em></span></dt><dd><p>
+             The type of filesystem used for a clustered NFS' shared
+             state. No default.
+           </p></dd><dt><span class="term">CTDB_NFS_STATE_MNT=<em class="parameter"><code>DIR</code></em></span></dt><dd><p>
+             The directory where a clustered NFS' shared state will be
+             located. No default.
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm554"></a><h3>APACHE HTTPD</h3><p>
        CTDB can manage the Apache web server.
-      </p><div class="refsect3"><a name="idm140222704766576"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">41.httpd</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_HTTPD=yes|no</span></dt><dd><p>
+      </p><div class="refsect3"><a name="idm557"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">41.httpd</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_HTTPD=yes|no</span></dt><dd><p>
              Should CTDB manage the Apache web server?
            </p><p>
              Default is no.
-           </p></dd></dl></div></div><div class="refsect2"><a name="idm140222704762000"></a><h3>CLAMAV</h3><p>
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm568"></a><h3>CLAMAV</h3><p>
        CTDB has support to manage the popular anti-virus daemon
        ClamAV.
-      </p><div class="refsect3"><a name="idm140222704760880"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">31.clamd</code></td></tr></table><p>
+      </p><div class="refsect3"><a name="idm571"></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>
@@ -497,9 +535,9 @@ CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000
              FILENAME is the socket to monitor ClamAV.
            </p><p>
              No default.
-           </p></dd></dl></div></div><div class="refsect2"><a name="idm140222704752800"></a><h3>ISCSI</h3><p>
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm590"></a><h3>ISCSI</h3><p>
        CTDB has support for managing the Linux iSCSI tgtd service.
-      </p><div class="refsect3"><a name="idm140222704751696"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">70.iscsi</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_ISCSI=yes|no</span></dt><dd><p>
+      </p><div class="refsect3"><a name="idm593"></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.
@@ -508,23 +546,23 @@ CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000
              tgtd for each public IP address.
            </p><p>
              No default.
-           </p></dd></dl></div></div><div class="refsect2"><a name="idm140222704744576"></a><h3>MULTIPATHD</h3><p>
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm610"></a><h3>MULTIPATHD</h3><p>
        CTDB can monitor multipath devices to ensure that active paths
        are available.
-      </p><div class="refsect3"><a name="idm140222704743456"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">20.multipathd</code></td></tr></table><p>
+      </p><div class="refsect3"><a name="idm613"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">20.multipathd</code></td></tr></table><p>
          This eventscript is not enabled by default.  Use
          <span class="command"><strong>ctdb enablescript</strong></span> to enable it.
        </p></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MONITOR_MPDEVICES=<em class="parameter"><code>MP-DEVICE-LIST</code></em></span></dt><dd><p>
              MP-DEVICE-LIST is a list of multipath devices for CTDB to monitor?
            </p><p>
              No default.
-           </p></dd></dl></div></div><div class="refsect2"><a name="idm140222704737200"></a><h3>VSFTPD</h3><p>
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm627"></a><h3>VSFTPD</h3><p>
        CTDB can manage the vsftpd FTP server.
-      </p><div class="refsect3"><a name="idm140222704736176"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">40.vsftpd</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_VSFTPD=yes|no</span></dt><dd><p>
+      </p><div class="refsect3"><a name="idm630"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">40.vsftpd</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_VSFTPD=yes|no</span></dt><dd><p>
              Should CTDB manage the vsftpd FTP server?
            </p><p>
              Default is no.
-           </p></dd></dl></div></div><div class="refsect2"><a name="idm140222704731600"></a><h3>
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm641"></a><h3>
        SYSTEM RESOURCE MONITORING CONFIGURATION
       </h3><p>
        CTDB can experience seemingly random (performance and other)
@@ -537,7 +575,7 @@ CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000
        Some checks are enabled by default.  It is recommended that
        these checks remain enabled or are augmented by extra checks.
        There is no supported way of completely disabling the checks.
-      </p><div class="refsect3"><a name="idm140222704729616"></a><h4>Eventscripts</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">05.system</code></td></tr></table><p>
+      </p><div class="refsect3"><a name="idm645"></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>
@@ -576,7 +614,7 @@ CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000
            </p><p>
              Default is 25, so warnings will be logged when swap
              usage reaches 25%.
-           </p></dd></dl></div></div><div class="refsect2"><a name="idm140222704711456"></a><h3>MISCELLANEOUS SERVICE-RELATED CONFIGURATION</h3><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGED_SERVICES=<em class="parameter"><code>SERVICE-LIST</code></em></span></dt><dd><p>
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm684"></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
@@ -589,7 +627,7 @@ CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000
              managed or unmanaged.
            </p><p>
              Default is no.
-           </p></dd></dl></div></div></div><div class="refsect1"><a name="idm140222704704928"></a><h2>
+           </p></dd></dl></div></div></div><div class="refsect1"><a name="idm700"></a><h2>
       TUNABLES CONFIGURATION
     </h2><p>
       CTDB tunables (see
@@ -605,7 +643,7 @@ CTDB_SET_<em class="replaceable"><code>TUNABLE</code></em>=<em class="replaceabl
       </p><pre class="screen">
 CTDB_SET_MonitorInterval=20
       </pre><p>
-    </p></div><div class="refsect1"><a name="idm140222704700144"></a><h2>
+    </p></div><div class="refsect1"><a name="idm711"></a><h2>
       DEBUG AND TEST
     </h2><p>
       Variable in this section are for debugging and testing CTDB.
@@ -712,7 +750,7 @@ CTDB_SET_MonitorInterval=20
            runtime.
          </p><p>
            Defaults to <code class="filename">/usr/local/var/lib/ctdb</code>.
-         </p></dd></dl></div></div><div class="refsect1"><a name="idm140222704651408"></a><h2>FILES</h2><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">/usr/local/etc/ctdb/ctdbd.conf</code></td></tr><tr><td><code class="filename">/etc/sysconfig/ctdb</code></td></tr><tr><td><code class="filename">/etc/default/ctdb</code></td></tr><tr><td><code class="filename">/usr/local/etc/ctdb/sysconfig/ctdb</code></td></tr></table></div><div class="refsect1"><a name="idm140222704647008"></a><h2>SEE ALSO</h2><p>
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm822"></a><h2>FILES</h2><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">/usr/local/etc/ctdb/ctdbd.conf</code></td></tr><tr><td><code class="filename">/etc/sysconfig/ctdb</code></td></tr><tr><td><code class="filename">/etc/default/ctdb</code></td></tr><tr><td><code class="filename">/usr/local/etc/ctdb/sysconfig/ctdb</code></td></tr></table></div><div class="refsect1"><a name="idm833"></a><h2>SEE ALSO</h2><p>
       <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
 
       <span class="citerefentry"><span class="refentrytitle">ctdbd_wrapper</span>(1)</span>,
index 4be7f39..45d9629 100644 (file)
@@ -1,4 +1,4 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdbd_wrapper</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdbd_wrapper.1"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdbd_wrapper &#8212; Wrapper for ctdbd</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ctdbd_wrapper</code>  {<em class="replaceable"><code>PIDFILE</code></em>} { start  |   stop }</p></div></div><div class="refsect1"><a name="idm140621592027056"></a><h2>DESCRIPTION</h2><p>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdbd_wrapper</title><meta name="generator" content="DocBook XSL Stylesheets V1.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 &#8212; Wrapper for ctdbd</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ctdbd_wrapper</code>  {<em class="replaceable"><code>PIDFILE</code></em>} { start  |   stop }</p></div></div><div class="refsect1"><a name="idm46088121867040"></a><h2>DESCRIPTION</h2><p>
       ctdbd_wrapper is used to start or stop the main CTDB daemon.
     </p><p>
       <em class="replaceable"><code>PIDFILE</code></em> specifies the location of the
@@ -9,7 +9,7 @@
       <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>.
     </p><p>
       See <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for an overview of CTDB.
-    </p></div><div class="refsect1"><a name="idm140621591846720"></a><h2>SEE ALSO</h2><p>
+    </p></div><div class="refsect1"><a name="idm46088123065984"></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>,
index 8031b49..9b2262e 100644 (file)
@@ -1,4 +1,4 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ltdbtool</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ltdbtool.1"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ltdbtool &#8212; manipulate CTDB's local TDB files</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ltdbtool</code>  [<em class="replaceable"><code>OPTION</code></em>...] {<em class="replaceable"><code>COMMAND</code></em>} [<em class="replaceable"><code>COMMAND-ARGS</code></em>]</p></div></div><div class="refsect1"><a name="idm139640830330400"></a><h2>DESCRIPTION</h2><p>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ltdbtool</title><meta name="generator" content="DocBook XSL Stylesheets V1.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 &#8212; manipulate CTDB's local TDB files</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ltdbtool</code>  [<em class="replaceable"><code>OPTION</code></em>...] {<em class="replaceable"><code>COMMAND</code></em>} [<em class="replaceable"><code>COMMAND-ARGS</code></em>]</p></div></div><div class="refsect1"><a name="idm46526557164304"></a><h2>DESCRIPTION</h2><p>
       ltdbtool is a utility to manipulate CTDB's local TDB databases
       (LTDBs) without connecting to a CTDB daemon.
     </p><p>
@@ -11,7 +11,7 @@
          by adding or removing CTDB headers and
        </p></li><li class="listitem"><p>convert between 64 and 32 bit LTDBs where the CTDB record
          headers differ by 4 bytes of padding.
-         </p></li></ul></div></div><div class="refsect1"><a name="idm139640829958096"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-e</span></dt><dd><p>
+         </p></li></ul></div></div><div class="refsect1"><a name="idm46526557607696"></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".
@@ -37,7 +37,7 @@
            output database in bytes.
          </p></dd><dt><span class="term">-h</span></dt><dd><p>
             Print help text.
-         </p></dd></dl></div></div><div class="refsect1"><a name="idm139640833162512"></a><h2>COMMANDS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">help</span></dt><dd><p>
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm46526561410160"></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
@@ -47,7 +47,7 @@
        </span></dt><dd><p>
            Copy an LTDB input file IDB to output file ODB, optionally
            adding or removing CTDB headers.
-         </p></dd></dl></div></div><div class="refsect1"><a name="idm139640833154640"></a><h2>EXAMPLES</h2><p>
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm46526561595136"></a><h2>EXAMPLES</h2><p>
       Print a local tdb in "tdbdump" style:
     </p><pre class="screen">
       ltdbtool dump idmap2.tdb.0
@@ -75,7 +75,7 @@
       Add a default header:
     </p><pre class="screen">
       ltdbtool convert -s0 idmap.tdb idmap2.tdb.0
-    </pre></div><div class="refsect1"><a name="idm139640833333616"></a><h2>SEE ALSO</h2><p>
+    </pre></div><div class="refsect1"><a name="idm46526561586960"></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>,
index 055b538..9bb6590 100644 (file)
@@ -1,4 +1,4 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>onnode</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="onnode.1"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>onnode &#8212; run commands on CTDB cluster nodes</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">onnode</code>  [<em class="replaceable"><code>OPTION</code></em>...] {<em class="replaceable"><code>NODES</code></em>} {<em class="replaceable"><code>COMMAND</code></em>}</p></div></div><div class="refsect1"><a name="idm139965911351184"></a><h2>DESCRIPTION</h2><p>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>onnode</title><meta name="generator" content="DocBook XSL Stylesheets V1.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 &#8212; 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>
@@ -9,7 +9,7 @@
       <em class="replaceable"><code>COMMAND</code></em> can be any shell command. The
       onnode utility uses ssh or rsh to connect to the remote nodes
       and run the command.
-    </p></div><div class="refsect1"><a name="idm139965910891312"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-c</span></dt><dd><p>
+    </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>
@@ -49,7 +49,7 @@
             more than one node is specified.
          </p></dd><dt><span class="term">-h, --help</span></dt><dd><p>
             Show a short usage guide.
-         </p></dd></dl></div></div><div class="refsect1"><a name="idm139965914755584"></a><h2>NODES SPECIFICATION</h2><p>
+         </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,
             unhealthy.
          </p></dd><dt><span class="term">con | connected</span></dt><dd><p>
             All nodes that are not disconnected.
-         </p></dd><dt><span class="term">lvs | lvsmaster</span></dt><dd><p>
-            The current LVS master.
-         </p></dd><dt><span class="term">natgw | natgwlist</span></dt><dd><p>
-            The current NAT gateway.
-         </p></dd><dt><span class="term">rm | recmaster</span></dt><dd><p>
-            The current recovery master.
-         </p></dd></dl></div></div><div class="refsect1"><a name="idm139965914612928"></a><h2>EXAMPLES</h2><p>
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm98"></a><h2>EXAMPLES</h2><p>
       The following command would show the process ID of ctdbd on all nodes
     </p><pre class="screen">
       onnode all ctdb getpid
       directory, in parallel, on nodes 0, 2, 3 and 4.
     </p><pre class="screen">
       onnode -c -p 0,2-4 ./foo
-    </pre></div><div class="refsect1"><a name="idm139965914607472"></a><h2>ENVIRONMENT</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="envar">CTDB_BASE</code></span></dt><dd><p>
+    </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="idm139965914789184"></a><h2>FILES</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="filename">/usr/local/etc/ctdb/nodes</code></span></dt><dd><p>
+         </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>
             <code class="envar">SSH</code> to something other than "ssh".  In this
             case the -t option is ignored.  For example, the
             administrator may choose to use use rsh instead of ssh.
-         </p></dd></dl></div></div><div class="refsect1"><a name="idm139965914777120"></a><h2>SEE ALSO</h2><p>
+         </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>
index e3113ad..06bba9b 100644 (file)
@@ -1,4 +1,4 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ping_pong</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ping_pong.1"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ping_pong &#8212; measures the ping-pong byte range lock latency</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ping_pong</code>  { -r  |   -w  |   -rw } [-m] [-c] {<em class="replaceable"><code>FILENAME</code></em>} {<em class="replaceable"><code>NUM-LOCKS</code></em>}</p></div></div><div class="refsect1"><a name="idm140370556517440"></a><h2>DESCRIPTION</h2><p>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ping_pong</title><meta name="generator" content="DocBook XSL Stylesheets V1.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 &#8212; measures the ping-pong byte range lock latency</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ping_pong</code>  { -r  |   -w  |   -rw } [-m] [-c] {<em class="replaceable"><code>FILENAME</code></em>} {<em class="replaceable"><code>NUM-LOCKS</code></em>}</p></div></div><div class="refsect1"><a name="idm45847900673440"></a><h2>DESCRIPTION</h2><p>
       ping_pong measures the byte range lock latency. It is especially
       useful on a cluster of nodes sharing a common lock manager as it
       will give some indication of the lock manager's performance
@@ -9,7 +9,7 @@
     </p><p>
       NUM-LOCKS is the number of byte range locks, so needs to be
       (strictly) greater than the number of nodes in the cluster.
-    </p></div><div class="refsect1"><a name="idm140370557909952"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-r</span></dt><dd><p>
+    </p></div><div class="refsect1"><a name="idm45847899428656"></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
@@ -17,7 +17,7 @@
            use mmap
          </p></dd><dt><span class="term">-c</span></dt><dd><p>
            validate the locks
-         </p></dd></dl></div></div><div class="refsect1"><a name="idm140370560882016"></a><h2>EXAMPLES</h2><p>
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm45847903379600"></a><h2>EXAMPLES</h2><p>
       Testing lock coherence
     </p><pre class="screen">
       ping_pong test.dat N
@@ -29,7 +29,7 @@
       Testing IO coherence
     </p><pre class="screen">
       ping_pong -rw test.dat N
-    </pre></div><div class="refsect1"><a name="idm140370561032480"></a><h2>SEE ALSO</h2><p>
+    </pre></div><div class="refsect1"><a name="idm45847903438176"></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>