manpages: Update to 4.9 (and 4.8) master
authorMartin Schwenke <>
Mon, 17 Sep 2018 04:48:41 +0000 (14:48 +1000)
committerAmitay Isaacs <>
Thu, 20 Sep 2018 01:47:25 +0000 (11:47 +1000)
Signed-off-by: Martin Schwenke <>
29 files changed:
web/manpages/4.8/ctdb-etcd.7.html [new file with mode: 0644]
web/manpages/4.8/ctdb-statistics.7.html [new file with mode: 0644]
web/manpages/4.8/ctdb-tunables.7.html [new file with mode: 0644]
web/manpages/4.8/ctdb.1.html [new file with mode: 0644]
web/manpages/4.8/ctdb.7.html [new file with mode: 0644]
web/manpages/4.8/ctdb_diagnostics.1.html [new file with mode: 0644]
web/manpages/4.8/ctdb_mutex_ceph_rados_helper.7.html [new file with mode: 0644]
web/manpages/4.8/ctdbd.1.html [new file with mode: 0644]
web/manpages/4.8/ctdbd.conf.5.html [moved from web/manpages/ctdbd.conf.5.html with 92% similarity]
web/manpages/4.8/ctdbd_wrapper.1.html [new file with mode: 0644]
web/manpages/4.8/ltdbtool.1.html [new file with mode: 0644]
web/manpages/4.8/onnode.1.html [new file with mode: 0644]
web/manpages/4.8/ping_pong.1.html [new file with mode: 0644]
web/manpages/ctdb-script.options.5.html [new file with mode: 0644]
web/manpages/ctdb.conf.5.html [new file with mode: 0644]
web/manpages/ctdb.sysconfig.5.html [new file with mode: 0644]

index b19ed67..6f69cfc 100644 (file)
-<p>Man pages:</p>
+<p>Man pages for CTDB in latest Samba release:</p>
 <li><a href="/manpages/ctdb.1.html">ctdb (1)</a>
 <li><a href="/manpages/ctdb_diagnostics.1.html">ctdb_diagnostics (1)</a>
 <li><a href="/manpages/ctdbd.1.html">ctdbd (1)</a>
 <li><a href="/manpages/ctdbd_wrapper.1.html">ctdbd_wrapper (1)</a>
-<li><a href="/manpages/ctdbd.conf.5.html">ctdbd.conf (5)</a>
+<li><a href="/manpages/ctdb.conf.5.html">ctdb.conf (5)</a>
+<li><a href="/manpages/ctdb-script.options.5.html">ctdb-script.options (5)</a>
+<li><a href="/manpages/ctdb.sysconfig.5.html">ctdb.sysconfig.conf (5)</a>
 <li><a href="/manpages/ctdb.7.html">ctdb (7)</a>
 <li><a href="/manpages/ctdb-etcd.7.html">ctdb-etcd (7)</a>
 <li><a href="/manpages/ctdb_mutex_ceph_rados_helper.7.html">ctdb_mutex_ceph_rados_helper (7)</a>
 <li><a href="/manpages/ping_pong.1.html">ping_pong (1)</a>
+<p>Man pages for CTDB in Samba 4.8:</p>
+<li><a href="/manpages/4.8/ctdb.1.html">ctdb (1)</a>
+<li><a href="/manpages/4.8/ctdb_diagnostics.1.html">ctdb_diagnostics (1)</a>
+<li><a href="/manpages/4.8/ctdbd.1.html">ctdbd (1)</a>
+<li><a href="/manpages/4.8/ctdbd_wrapper.1.html">ctdbd_wrapper (1)</a>
+<li><a href="/manpages/4.8/ctdbd.conf.5.html">ctdbd.conf (5)</a>
+<li><a href="/manpages/4.8/ctdb.7.html">ctdb (7)</a>
+<li><a href="/manpages/4.8/ctdb-etcd.7.html">ctdb-etcd (7)</a>
+<li><a href="/manpages/4.8/ctdb_mutex_ceph_rados_helper.7.html">ctdb_mutex_ceph_rados_helper (7)</a>
+<li><a href="/manpages/4.8/ctdb-statistics.7.html">ctdb-statistics (7)</a>
+<li><a href="/manpages/4.8/ctdb-tunables.7.html">ctdb-tunables (7)</a>
+<li><a href="/manpages/4.8/onnode.1.html">onnode (1)</a>
+<li><a href="/manpages/4.8/ltdbtool.1.html">ltdbtool (1)</a>
+<li><a href="/manpages/4.8/ping_pong.1.html">ping_pong (1)</a>
   Additional documentation that might not yet be fully migrated to the
diff --git a/web/manpages/4.8/ctdb-etcd.7.html b/web/manpages/4.8/ctdb-etcd.7.html
new file mode 100644 (file)
index 0000000..181721b
--- /dev/null
@@ -0,0 +1,40 @@
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb-etcd</title><meta name="generator" content="DocBook XSL Stylesheets V1.79.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdb-etcd.7"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb-etcd &#8212; CTDB etcd integration</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ctdb_etcd_lock</code> </p></div></div><div class="refsect1"><a name="idm24"></a><h2>DESCRIPTION</h2><p>
+      ctdb_etcd_lock is intended to be run as a mutex helper for CTDB. It
+      will try to connect to an existing etcd cluster and grab a lock in that
+      cluster to function as CTDB's recovery lock. Please see
+      <span class="emphasis"><em>ctdb/doc/cluster_mutex_helper.txt</em></span> for details on
+      the mutex helper API. To use this, include the following line in your
+      CTDB config file:
+    </p><pre class="screen">
+    </pre><p>
+      You can also pass "-v", "-vv", or "-vvv" to include verbose output in
+      the CTDB log. Additional "v"s indicate increases in verbosity.
+    </p><p>
+      This mutex helper expects the system Python interpreter to have access
+      to the etcd Python module. It also expects an etcd cluster to be
+      configured and running. To integrate with this, there is an optional
+      config file of the following format:
+    </p><pre class="screen">
+key = value
+    </pre><p>
+      The following configuration parameters (and their defaults) are defined
+      for use by ctdb_etcd_lock:
+    </p><pre class="screen">
+port      = 2379   # connecting port for the etcd cluster
+lock_ttl  = 9      # seconds for TTL
+refresh   = 2      # seconds between attempts to maintain lock
+locks_dir = _ctdb  # where to store CTDB locks in etcd
+                   # The final etcd directory for any given lock looks like:
+                   #   /_locks/{locks_dir}/{netbios name}/
+    </pre><p>
+      In addition, any keyword parameter that can be used to configure an
+      etcd client may be specified and modified here. For more documentation
+      on these parameters, see here:
+    </p></div><div class="refsect1"><a name="idm35"></a><h2>SEE ALSO</h2><p>
+      <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
+      <a class="ulink" href="" target="_top"></a>
+    </p></div></div></body></html>
diff --git a/web/manpages/4.8/ctdb-statistics.7.html b/web/manpages/4.8/ctdb-statistics.7.html
new file mode 100644 (file)
index 0000000..5add6c3
--- /dev/null
@@ -0,0 +1,268 @@
+<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="idm10"></a><h2>OVERALL STATISTICS</h2><p>
+      CTDB maintains information about various messages communicated
+      and some of the important operations per node.  See the
+      <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span> commands
+      <span class="command"><strong>statistics</strong></span> and <span class="command"><strong>statisticsreset</strong></span>
+      for displaying statistics.
+    </p><div class="refsect2"><a name="idm18"></a><h3>Example: ctdb statistics</h3><pre class="screen">
+CTDB version 1
+Current time of statistics  :                Fri Sep 12 13:32:32 2014
+Statistics collected since  : (000 01:49:20) Fri Sep 12 11:43:12 2014
+ num_clients                        6
+ frozen                             0
+ recovering                         0
+ num_recoveries                     2
+ client_packets_sent           281293
+ client_packets_recv           296317
+ node_packets_sent             452387
+ node_packets_recv             182394
+ keepalive_packets_sent          3927
+ keepalive_packets_recv          3928
+ node
+     req_call                   48605
+     reply_call                     1
+     req_dmaster                23404
+     reply_dmaster              24917
+     reply_error                    0
+     req_message                  958
+     req_control               197513
+     reply_control             153705
+ client
+     req_call                  130866
+     req_message                  770
+     req_control               168921
+ timeouts
+     call                           0
+     control                        0
+     traverse                       0
+ locks
+     num_calls                    220
+     num_current                    0
+     num_pending                    0
+     num_failed                     0
+ total_calls                   130866
+ pending_calls                      0
+ childwrite_calls                   1
+ pending_childwrite_calls             0
+ memory_used                   334490
+ max_hop_count                     18
+ total_ro_delegations               2
+ total_ro_revokes                   2
+ hop_count_buckets: 42816 5464 26 1 0 0 0 0 0 0 0 0 0 0 0 0
+ lock_buckets: 9 165 14 15 7 2 2 0 0 0 0 0 0 0 0 0
+ locks_latency      MIN/AVG/MAX     0.000685/0.160302/6.369342 sec out of 214
+ reclock_ctdbd      MIN/AVG/MAX     0.004940/0.004969/0.004998 sec out of 2
+ reclock_recd       MIN/AVG/MAX     0.000000/0.000000/0.000000 sec out of 0
+ call_latency       MIN/AVG/MAX     0.000006/0.000719/4.562991 sec out of 126626
+ childwrite_latency MIN/AVG/MAX     0.014527/0.014527/0.014527 sec out of 1
+       </pre></div><div class="refsect2"><a name="idm21"></a><h3>CTDB version</h3><p>
+        Version of the ctdb protocol used by the node.
+      </p></div><div class="refsect2"><a name="idm24"></a><h3>Current time of statistics</h3><p>
+        Time when the statistics are generated.
+      </p><p>
+        This is useful when collecting statistics output periodically
+        for post-processing.
+      </p></div><div class="refsect2"><a name="idm28"></a><h3>Statistics collected since</h3><p>
+       Time when ctdb was started or the last time statistics was reset.
+       The output shows the duration and the timestamp.
+      </p></div><div class="refsect2"><a name="idm31"></a><h3>num_clients</h3><p>
+        Number of processes currently connected to CTDB's unix socket.
+        This includes recovery daemon, ctdb tool and samba processes
+        (smbd, winbindd).
+      </p></div><div class="refsect2"><a name="idm34"></a><h3>frozen</h3><p>
+       1 if the the databases are currently frozen, 0 otherwise.
+      </p></div><div class="refsect2"><a name="idm37"></a><h3>recovering</h3><p>
+       1 if recovery is active, 0 otherwise.
+      </p></div><div class="refsect2"><a name="idm40"></a><h3>num_recoveries</h3><p>
+       Number of recoveries since the start of ctdb or since the last
+       statistics reset.
+      </p></div><div class="refsect2"><a name="idm43"></a><h3>client_packets_sent</h3><p>
+       Number of packets sent to client processes via unix domain socket.
+      </p></div><div class="refsect2"><a name="idm46"></a><h3>client_packets_recv</h3><p>
+       Number of packets received from client processes via unix domain socket.
+      </p></div><div class="refsect2"><a name="idm49"></a><h3>node_packets_sent</h3><p>
+       Number of packets sent to the other nodes in the cluster via TCP.
+      </p></div><div class="refsect2"><a name="idm52"></a><h3>node_packets_recv</h3><p>
+       Number of packets received from the other nodes in the cluster via TCP.
+      </p></div><div class="refsect2"><a name="idm55"></a><h3>keepalive_packets_sent</h3><p>
+       Number of keepalive messages sent to other nodes.
+      </p><p>
+       CTDB periodically sends keepalive messages to other nodes.
+       See <em class="citetitle">KeepaliveInterval</em> tunable in
+       <span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span> for more details.
+      </p></div><div class="refsect2"><a name="idm63"></a><h3>keepalive_packets_recv</h3><p>
+       Number of keepalive messages received from other nodes.
+      </p></div><div class="refsect2"><a name="idm66"></a><h3>node</h3><p>
+       This section lists various types of messages processed which
+       originated from other nodes via TCP.
+      </p><div class="refsect3"><a name="idm69"></a><h4>req_call</h4><p>
+        Number of REQ_CALL messages from the other nodes.
+      </p></div><div class="refsect3"><a name="idm72"></a><h4>reply_call</h4><p>
+        Number of REPLY_CALL messages from the other nodes.
+      </p></div><div class="refsect3"><a name="idm75"></a><h4>req_dmaster</h4><p>
+        Number of REQ_DMASTER messages from the other nodes.
+      </p></div><div class="refsect3"><a name="idm78"></a><h4>reply_dmaster</h4><p>
+        Number of REPLY_DMASTER messages from the other nodes.
+      </p></div><div class="refsect3"><a name="idm81"></a><h4>reply_error</h4><p>
+        Number of REPLY_ERROR messages from the other nodes.
+      </p></div><div class="refsect3"><a name="idm84"></a><h4>req_message</h4><p>
+        Number of REQ_MESSAGE messages from the other nodes.
+      </p></div><div class="refsect3"><a name="idm87"></a><h4>req_control</h4><p>
+        Number of REQ_CONTROL messages from the other nodes.
+      </p></div><div class="refsect3"><a name="idm90"></a><h4>reply_control</h4><p>
+        Number of REPLY_CONTROL messages from the other nodes.
+      </p></div><div class="refsect3"><a name="idm93"></a><h4>req_tunnel</h4><p>
+        Number of REQ_TUNNEL messages from the other nodes.
+      </p></div></div><div class="refsect2"><a name="idm96"></a><h3>client</h3><p>
+       This section lists various types of messages processed which
+       originated from clients via unix domain socket.
+      </p><div class="refsect3"><a name="idm99"></a><h4>req_call</h4><p>
+        Number of REQ_CALL messages from the clients.
+      </p></div><div class="refsect3"><a name="idm102"></a><h4>req_message</h4><p>
+        Number of REQ_MESSAGE messages from the clients.
+      </p></div><div class="refsect3"><a name="idm105"></a><h4>req_control</h4><p>
+        Number of REQ_CONTROL messages from the clients.
+      </p></div><div class="refsect3"><a name="idm108"></a><h4>req_tunnel</h4><p>
+        Number of REQ_TUNNEL messages from the clients.
+      </p></div></div><div class="refsect2"><a name="idm111"></a><h3>timeouts</h3><p>
+       This section lists timeouts occurred when sending various messages.
+      </p><div class="refsect3"><a name="idm114"></a><h4>call</h4><p>
+        Number of timeouts for REQ_CALL messages.
+      </p></div><div class="refsect3"><a name="idm117"></a><h4>control</h4><p>
+        Number of timeouts for REQ_CONTROL messages.
+      </p></div><div class="refsect3"><a name="idm120"></a><h4>traverse</h4><p>
+        Number of timeouts for database traverse operations.
+      </p></div></div><div class="refsect2"><a name="idm123"></a><h3>locks</h3><p>
+       This section lists locking statistics.
+      </p><div class="refsect3"><a name="idm126"></a><h4>num_calls</h4><p>
+        Number of completed lock calls.  This includes database locks
+        and record locks.
+      </p></div><div class="refsect3"><a name="idm129"></a><h4>num_current</h4><p>
+        Number of scheduled lock calls.  This includes database locks
+        and record locks.
+      </p></div><div class="refsect3"><a name="idm132"></a><h4>num_pending</h4><p>
+        Number of queued lock calls.  This includes database locks and
+        record locks.
+      </p></div><div class="refsect3"><a name="idm135"></a><h4>num_failed</h4><p>
+        Number of failed lock calls.  This includes database locks and
+        record locks.
+      </p></div></div><div class="refsect2"><a name="idm138"></a><h3>total_calls</h3><p>
+       Number of req_call messages processed from clients.  This number
+       should be same as client --&gt; req_call.
+      </p></div><div class="refsect2"><a name="idm141"></a><h3>pending_calls</h3><p>
+       Number of req_call messages which are currenly being processed.
+       This number indicates the number of record migrations in flight.
+      </p></div><div class="refsect2"><a name="idm144"></a><h3>childwrite_calls</h3><p>
+       Number of record update calls.  Record update calls are used to
+       update a record under a transaction.
+      </p></div><div class="refsect2"><a name="idm147"></a><h3>pending_childwrite_calls</h3><p>
+       Number of record update calls currently active.
+      </p></div><div class="refsect2"><a name="idm150"></a><h3>memory_used</h3><p>
+       The amount of memory in bytes currently used by CTDB using
+       talloc.  This includes all the memory used for CTDB's internal
+       data structures.  This does not include the memory mapped TDB
+       databases.
+      </p></div><div class="refsect2"><a name="idm153"></a><h3>max_hop_count</h3><p>
+       The maximum number of hops required for a record migration request
+       to obtain the record.  High numbers indicate record contention.
+      </p></div><div class="refsect2"><a name="idm156"></a><h3>total_ro_delegations</h3><p>
+       Number of readonly delegations created.
+      </p></div><div class="refsect2"><a name="idm159"></a><h3>total_ro_revokes</h3><p>
+       Number of readonly delegations that were revoked.  The difference
+       between total_ro_revokes and total_ro_delegations gives the
+       number of currently active readonly delegations.
+      </p></div><div class="refsect2"><a name="idm162"></a><h3>hop_count_buckets</h3><p>
+       Distribution of migration requests based on hop counts values.
+       Buckets are 1, &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="idm165"></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="idm168"></a><h3>locks_latency</h3><p>
+       The minimum, the average and the maximum time (in seconds)
+       required to obtain record locks.
+      </p></div><div class="refsect2"><a name="idm171"></a><h3>reclock_ctdbd</h3><p>
+       The minimum, the average and the maximum time (in seconds)
+       required to check if recovery lock is still held by recovery
+       daemon when recovery mode is changed.  This check is done in ctdb daemon.
+      </p></div><div class="refsect2"><a name="idm174"></a><h3>reclock_recd</h3><p>
+        The minimum, the average and the maximum time (in seconds)
+        required to check if recovery lock is still held by recovery
+        daemon during recovery.  This check is done in recovery daemon.
+      </p></div><div class="refsect2"><a name="idm177"></a><h3>call_latency</h3><p>
+       The minimum, the average and the maximum time (in seconds) required
+       to process a REQ_CALL message from client.  This includes the time
+       required to migrate a record from remote node, if the record is
+       not available on the local node.
+      </p></div><div class="refsect2"><a name="idm180"></a><h3>childwrite_latency</h3><p>Default: 0</p><p>
+       The minimum, the average and the maximum time (in seconds)
+       required to update records under a transaction.
+      </p></div></div><div class="refsect1"><a name="idm184"></a><h2>DATABASE STATISTICS</h2><p>
+      CTDB maintains per database statistics about important operations.
+      See the <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span> command
+      <span class="command"><strong>dbstatistics</strong></span> for displaying database statistics.
+    </p><div class="refsect2"><a name="idm191"></a><h3>Example: ctdb dbstatistics notify_index.tdb</h3><pre class="screen">
+DB Statistics: notify_index.tdb
+ ro_delegations                     0
+ ro_revokes                         0
+ locks
+     total                        131
+     failed                         0
+     current                        0
+     pending                        0
+ hop_count_buckets: 9890 5454 26 1 0 0 0 0 0 0 0 0 0 0 0 0
+ lock_buckets: 4 117 10 0 0 0 0 0 0 0 0 0 0 0 0 0
+ locks_latency      MIN/AVG/MAX     0.000683/0.004198/0.014730 sec out of 131
+ Num Hot Keys:     3
+     Count:7 Key:2f636c75737465726673
+     Count:18 Key:2f636c757374657266732f64617461
+     Count:7 Key:2f636c757374657266732f646174612f636c69656e7473
+       </pre></div><div class="refsect2"><a name="idm194"></a><h3>DB Statistics</h3><p>
+       Name of the database.
+      </p></div><div class="refsect2"><a name="idm197"></a><h3>ro_delegations</h3><p>
+       Number of readonly delegations created in the database.
+      </p></div><div class="refsect2"><a name="idm200"></a><h3>ro_revokes</h3><p>
+       Number of readonly delegations revoked.  The difference in
+       ro_delegations and ro_revokes indicates the currently active
+       readonly delegations.
+      </p></div><div class="refsect2"><a name="idm203"></a><h3>locks</h3><p>
+       This section lists locking statistics.
+      </p><div class="refsect3"><a name="idm206"></a><h4>total</h4><p>
+        Number of completed lock calls.  This includes database locks
+        and record locks.
+      </p></div><div class="refsect3"><a name="idm209"></a><h4>failed</h4><p>
+        Number of failed lock calls.  This includes database locks and
+        record locks.
+      </p></div><div class="refsect3"><a name="idm212"></a><h4>current</h4><p>
+        Number of scheduled lock calls.  This includes database locks
+        and record locks.
+      </p></div><div class="refsect3"><a name="idm215"></a><h4>pending</h4><p>
+        Number of queued lock calls.  This includes database locks and
+        record locks.
+      </p></div></div><div class="refsect2"><a name="idm218"></a><h3>hop_count_buckets</h3><p>
+       Distribution of migration requests based on hop counts values.
+       Buckets are 1, &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="idm221"></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="idm224"></a><h3>locks_latency</h3><p>
+       The minimum, the average and the maximum time (in seconds)
+       required to obtain record locks.
+      </p></div><div class="refsect2"><a name="idm227"></a><h3>Num Hot Keys</h3><p>
+        Number of contended records determined by hop count.  CTDB keeps
+        track of top 10 hot records and the output shows hex encoded
+        keys for the hot records.
+      </p></div></div><div class="refsect1"><a name="idm230"></a><h2>SEE ALSO</h2><p>
+      <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span>,
+      <a class="ulink" href="" target="_top"></a>
+    </p></div></div></body></html>
diff --git a/web/manpages/4.8/ctdb-tunables.7.html b/web/manpages/4.8/ctdb-tunables.7.html
new file mode 100644 (file)
index 0000000..e8092db
--- /dev/null
@@ -0,0 +1,367 @@
+<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><p>
+      Unless otherwise stated, tunables should be set to the same
+      value on all nodes.  Setting tunables to different values across
+      nodes may produce unexpected results.  Future releases may set
+      (some or most) tunables globally across the cluster but doing so
+      is currently a manual process.
+    </p><p>
+      The tunable variables are listed alphabetically.
+    </p><div class="refsect2"><a name="idm21"></a><h3>AllowClientDBAttach</h3><p>Default: 1</p><p>
+       When set to 0, clients are not allowed to attach to any databases.
+       This can be used to temporarily block any new processes from
+       attaching to and accessing the databases.  This is mainly used
+       for detaching a volatile database using 'ctdb detach'.
+      </p></div><div class="refsect2"><a name="idm25"></a><h3>AllowMixedVersions</h3><p>Default: 0</p><p>
+       CTDB will not allow incompatible versions to co-exist in
+       a cluster.  If a version mismatch is found, then losing CTDB
+       will shutdown.  To disable the incompatible version check,
+       set this tunable to 1.
+      </p><p>
+       For version checking, CTDB uses major and minor version.
+       For example, CTDB 4.6.1 and CTDB CTDB 4.6.2 are matching versions;
+       CTDB 4.5.x and CTDB 4.6.y do not match.
+      </p><p>
+       CTDB with version check support will lose to CTDB without
+       version check support.  Between two different CTDB versions with
+       version check support, one running for less time will lose.
+       If the running time for both CTDB versions with version check
+       support is equal (to seconds), then the older version will lose.
+       The losing CTDB daemon will shutdown.
+      </p></div><div class="refsect2"><a name="idm31"></a><h3>AllowUnhealthyDBRead</h3><p>Default: 0</p><p>
+       When set to 1, ctdb allows database traverses to read unhealthy
+       databases.  By default, ctdb does not allow reading records from
+       unhealthy databases.
+      </p></div><div class="refsect2"><a name="idm35"></a><h3>ControlTimeout</h3><p>Default: 60</p><p>
+       This is the default setting for timeout for when sending a
+       control message to either the local or a remote ctdb daemon.
+      </p></div><div class="refsect2"><a name="idm39"></a><h3>DatabaseHashSize</h3><p>Default: 100001</p><p>
+       Number of the hash chains for the local store of the tdbs that
+       ctdb manages.
+      </p></div><div class="refsect2"><a name="idm43"></a><h3>DatabaseMaxDead</h3><p>Default: 5</p><p>
+       Maximum number of dead records per hash chain for the tdb databses
+       managed by ctdb.
+      </p></div><div class="refsect2"><a name="idm47"></a><h3>DBRecordCountWarn</h3><p>Default: 100000</p><p>
+       When set to non-zero, ctdb will log a warning during recovery if
+       a database has more than this many records. This will produce a
+       warning if a database grows uncontrollably with orphaned records.
+      </p></div><div class="refsect2"><a name="idm51"></a><h3>DBRecordSizeWarn</h3><p>Default: 10000000</p><p>
+       When set to non-zero, ctdb will log a warning during recovery
+       if a single record is bigger than this size. This will produce
+       a warning if a database record grows uncontrollably.
+      </p></div><div class="refsect2"><a name="idm55"></a><h3>DBSizeWarn</h3><p>Default: 1000000000</p><p>
+       When set to non-zero, ctdb will log a warning during recovery if
+       a database size is bigger than this. This will produce a warning
+       if a database grows uncontrollably.
+      </p></div><div class="refsect2"><a name="idm59"></a><h3>DeferredAttachTO</h3><p>Default: 120</p><p>
+       When databases are frozen we do not allow clients to attach to
+       the databases. Instead of returning an error immediately to the
+       client, the attach request from the client is deferred until
+       the database becomes available again at which stage we respond
+       to the client.
+      </p><p>
+       This timeout controls how long we will defer the request from the
+       client before timing it out and returning an error to the client.
+      </p></div><div class="refsect2"><a name="idm64"></a><h3>DisableIPFailover</h3><p>Default: 0</p><p>
+       When set to non-zero, ctdb will not perform failover or
+       failback. Even if a node fails while holding public IPs, ctdb
+       will not recover the IPs or assign them to another node.
+      </p><p>
+       When this tunable is enabled, ctdb will no longer attempt
+       to recover the cluster by failing IP addresses over to other
+       nodes. This leads to a service outage until the administrator
+       has manually performed IP failover to replacement nodes using the
+       'ctdb moveip' command.
+      </p></div><div class="refsect2"><a name="idm69"></a><h3>ElectionTimeout</h3><p>Default: 3</p><p>
+       The number of seconds to wait for the election of recovery
+       master to complete. If the election is not completed during this
+       interval, then that round of election fails and ctdb starts a
+       new election.
+      </p></div><div class="refsect2"><a name="idm73"></a><h3>EnableBans</h3><p>Default: 1</p><p>
+       This parameter allows ctdb to ban a node if the node is misbehaving.
+      </p><p>
+       When set to 0, this disables banning completely in the cluster
+       and thus nodes can not get banned, even it they break. Don't
+       set to 0 unless you know what you are doing.
+      </p></div><div class="refsect2"><a name="idm78"></a><h3>EventScriptTimeout</h3><p>Default: 30</p><p>
+       Maximum time in seconds to allow an event to run before timing
+       out.  This is the total time for all enabled scripts that are
+       run for an event, not just a single event script.
+      </p><p>
+       Note that timeouts are ignored for some events ("takeip",
+       "releaseip", "startrecovery", "recovered") and converted to
+       success.  The logic here is that the callers of these events
+       implement their own additional timeout.
+      </p></div><div class="refsect2"><a name="idm83"></a><h3>FetchCollapse</h3><p>Default: 1</p><p>
+       This parameter is used to avoid multiple migration requests for
+       the same record from a single node. All the record requests for
+       the same record are queued up and processed when the record is
+       migrated to the current node.
+      </p><p>
+       When many clients across many nodes try to access the same record
+       at the same time this can lead to a fetch storm where the record
+       becomes very active and bounces between nodes very fast. This
+       leads to high CPU utilization of the ctdbd daemon, trying to
+       bounce that record around very fast, and poor performance.
+       This can improve performance and reduce CPU utilization for
+       certain workloads.
+      </p></div><div class="refsect2"><a name="idm88"></a><h3>HopcountMakeSticky</h3><p>Default: 50</p><p>
+       For database(s) marked STICKY (using 'ctdb setdbsticky'),
+       any record that is migrating so fast that hopcount
+       exceeds this limit is marked as STICKY record for
+       <code class="varname">StickyDuration</code> seconds. This means that
+       after each migration the sticky record will be kept on the node
+       <code class="varname">StickyPindown</code>milliseconds and prevented from
+       being migrated off the node.
+       </p><p>
+       This will improve performance for certain workloads, such as
+       locking.tdb if many clients are opening/closing the same file
+       concurrently.
+      </p></div><div class="refsect2"><a name="idm95"></a><h3>IPAllocAlgorithm</h3><p>Default: 2</p><p>
+       Selects the algorithm that CTDB should use when doing public
+       IP address allocation.  Meaningful values are:
+      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">0</span></dt><dd><p>
+             Deterministic IP address allocation.
+           </p><p>
+             This is a simple and fast option.  However, it can cause
+             unnecessary address movement during fail-over because
+             each address has a "home" node.  Works badly when some
+             nodes do not have any addresses defined.  Should be used
+             with care when addresses are defined across multiple
+             networks.
+           </p></dd><dt><span class="term">1</span></dt><dd><p>
+             Non-deterministic IP address allocation.
+           </p><p>
+             This is a relatively fast option that attempts to do a
+             minimise unnecessary address movements.  Addresses do
+             not have a "home" node.  Rebalancing is limited but it
+             usually adequate.  Works badly when addresses are
+             defined across multiple networks.
+           </p></dd><dt><span class="term">2</span></dt><dd><p>
+             LCP2 IP address allocation.
+           </p><p>
+             Uses a heuristic to assign addresses defined across
+             multiple networks, usually balancing addresses on each
+             network evenly across nodes.  Addresses do not have a
+             "home" node.  Minimises unnecessary address movements.
+             The algorithm is complex, so is slower than other
+             choices for a large number of addresses.  However, it
+             can calculate an optimal assignment of 900 addresses in
+             under 10 seconds on modern hardware.
+           </p></dd></dl></div><p>
+       If the specified value is not one of these then the default
+       will be used.
+      </p></div><div class="refsect2"><a name="idm116"></a><h3>KeepaliveInterval</h3><p>Default: 5</p><p>
+       How often in seconds should the nodes send keep-alive packets to
+       each other.
+      </p></div><div class="refsect2"><a name="idm120"></a><h3>KeepaliveLimit</h3><p>Default: 5</p><p>
+       After how many keepalive intervals without any traffic should
+       a node wait until marking the peer as DISCONNECTED.
+       </p><p>
+       If a node has hung, it can take
+       <code class="varname">KeepaliveInterval</code> *
+       (<code class="varname">KeepaliveLimit</code> + 1) seconds before
+       ctdb determines that the node is DISCONNECTED and performs
+       a recovery. This limit should not be set too high to enable
+       early detection and avoid any application timeouts (e.g. SMB1)
+       to kick in before the fail over is completed.
+      </p></div><div class="refsect2"><a name="idm127"></a><h3>LockProcessesPerDB</h3><p>Default: 200</p><p>
+       This is the maximum number of lock helper processes ctdb will
+       create for obtaining record locks.  When ctdb cannot get a record
+       lock without blocking, it creates a helper process that waits
+       for the lock to be obtained.
+      </p></div><div class="refsect2"><a name="idm131"></a><h3>LogLatencyMs</h3><p>Default: 0</p><p>
+       When set to non-zero, ctdb will log if certains operations
+       take longer than this value, in milliseconds, to complete.
+       These operations include "process a record request from client",
+       "take a record or database lock", "update a persistent database
+       record" and "vaccum a database".
+      </p></div><div class="refsect2"><a name="idm135"></a><h3>MaxQueueDropMsg</h3><p>Default: 1000000</p><p>
+       This is the maximum number of messages to be queued up for
+       a client before ctdb will treat the client as hung and will
+       terminate the client connection.
+      </p></div><div class="refsect2"><a name="idm139"></a><h3>MonitorInterval</h3><p>Default: 15</p><p>
+       How often should ctdb run the 'monitor' event in seconds to check
+       for a node's health.
+      </p></div><div class="refsect2"><a name="idm143"></a><h3>MonitorTimeoutCount</h3><p>Default: 20</p><p>
+       How many 'monitor' events in a row need to timeout before a node
+       is flagged as UNHEALTHY.  This setting is useful if scripts can
+       not be written so that they do not hang for benign reasons.
+      </p></div><div class="refsect2"><a name="idm147"></a><h3>NoIPFailback</h3><p>Default: 0</p><p>
+       When set to 1, ctdb will not perform failback of IP addresses
+       when a node becomes healthy. When a node becomes UNHEALTHY,
+       ctdb WILL perform failover of public IP addresses, but when the
+       node becomes HEALTHY again, ctdb will not fail the addresses back.
+      </p><p>
+       Use with caution! Normally when a node becomes available to the
+       cluster ctdb will try to reassign public IP addresses onto the
+       new node as a way to distribute the workload evenly across the
+       clusternode. Ctdb tries to make sure that all running nodes have
+       approximately the same number of public addresses it hosts.
+      </p><p>
+       When you enable this tunable, ctdb will no longer attempt to
+       rebalance the cluster by failing IP addresses back to the new
+       nodes. An unbalanced cluster will therefore remain unbalanced
+       until there is manual intervention from the administrator. When
+       this parameter is set, you can manually fail public IP addresses
+       over to the new node(s) using the 'ctdb moveip' command.
+      </p></div><div class="refsect2"><a name="idm153"></a><h3>NoIPHostOnAllDisabled</h3><p>Default: 0</p><p>
+       If no nodes are HEALTHY then by default ctdb will happily host
+       public IPs on disabled (unhealthy or administratively disabled)
+       nodes.  This can cause problems, for example if the underlying
+       cluster filesystem is not mounted.  When set to 1 and a node
+       is disabled, any IPs hosted by this node will be released and
+       the node will not takeover any IPs until it is no longer disabled.
+      </p></div><div class="refsect2"><a name="idm157"></a><h3>NoIPTakeover</h3><p>Default: 0</p><p>
+       When set to 1, ctdb will not allow IP addresses to be failed
+       over to other nodes.  Any IP addresses already hosted on
+       healthy nodes will remain.  Usually IP addresses hosted on
+       unhealthy nodes will also remain, if NoIPHostOnAllDisabled is
+       0.  However, if NoIPHostOnAllDisabled is 1 then IP addresses
+       will be released by unhealthy nodes and will become un-hosted.
+      </p></div><div class="refsect2"><a name="idm161"></a><h3>PullDBPreallocation</h3><p>Default: 10*1024*1024</p><p>
+       This is the size of a record buffer to pre-allocate for sending
+       reply to PULLDB control. Usually record buffer starts with size
+       of the first record and gets reallocated every time a new record
+       is added to the record buffer. For a large number of records,
+       this can be very inefficient to grow the record buffer one record
+       at a time.
+      </p></div><div class="refsect2"><a name="idm165"></a><h3>QueueBufferSize</h3><p>Default: 1024</p><p>
+       This is the maximum amount of data (in bytes) ctdb will read
+       from a socket at a time.
+      </p><p>
+       For a busy setup, if ctdb is not able to process the TCP sockets
+       fast enough (large amount of data in Recv-Q for tcp sockets),
+       then this tunable value should be increased.  However, large
+       values can keep ctdb busy processing packets and prevent ctdb
+       from handling other events.
+      </p></div><div class="refsect2"><a name="idm170"></a><h3>RecBufferSizeLimit</h3><p>Default: 1000000</p><p>
+        This is the limit on the size of the record buffer to be sent
+        in various controls.  This limit is used by new controls used
+        for recovery and controls used in vacuuming.
+      </p></div><div class="refsect2"><a name="idm174"></a><h3>RecdFailCount</h3><p>Default: 10</p><p>
+       If the recovery daemon has failed to ping the main dameon for
+       this many consecutive intervals, the main daemon will consider
+       the recovery daemon as hung and will try to restart it to recover.
+      </p></div><div class="refsect2"><a name="idm178"></a><h3>RecdPingTimeout</h3><p>Default: 60</p><p>
+       If the main dameon has not heard a "ping" from the recovery dameon
+       for this many seconds, the main dameon will log a message that
+       the recovery daemon is potentially hung.  This also increments a
+       counter which is checked against <code class="varname">RecdFailCount</code>
+       for detection of hung recovery daemon.
+      </p></div><div class="refsect2"><a name="idm183"></a><h3>RecLockLatencyMs</h3><p>Default: 1000</p><p>
+       When using a reclock file for split brain prevention, if set
+       to non-zero this tunable will make the recovery dameon log a
+       message if the fcntl() call to lock/testlock the recovery file
+       takes longer than this number of milliseconds.
+      </p></div><div class="refsect2"><a name="idm187"></a><h3>RecoverInterval</h3><p>Default: 1</p><p>
+       How frequently in seconds should the recovery daemon perform the
+       consistency checks to determine if it should perform a recovery.
+      </p></div><div class="refsect2"><a name="idm191"></a><h3>RecoverTimeout</h3><p>Default: 120</p><p>
+       This is the default setting for timeouts for controls when sent
+       from the recovery daemon. We allow longer control timeouts from
+       the recovery daemon than from normal use since the recovery
+       dameon often use controls that can take a lot longer than normal
+       controls.
+      </p></div><div class="refsect2"><a name="idm195"></a><h3>RecoveryBanPeriod</h3><p>Default: 300</p><p>
+       The duration in seconds for which a node is banned if the node
+       fails during recovery.  After this time has elapsed the node will
+       automatically get unbanned and will attempt to rejoin the cluster.
+      </p><p>
+       A node usually gets banned due to real problems with the node.
+       Don't set this value too small.  Otherwise, a problematic node
+       will try to re-join cluster too soon causing unnecessary recoveries.
+      </p></div><div class="refsect2"><a name="idm200"></a><h3>RecoveryDropAllIPs</h3><p>Default: 120</p><p>
+       If a node is stuck in recovery, or stopped, or banned, for this
+       many seconds, then ctdb will release all public addresses on
+       that node.
+      </p></div><div class="refsect2"><a name="idm204"></a><h3>RecoveryGracePeriod</h3><p>Default: 120</p><p>
+       During recoveries, if a node has not caused recovery failures
+       during the last grace period in seconds, any records of
+       transgressions that the node has caused recovery failures will be
+       forgiven. This resets the ban-counter back to zero for that node.
+      </p></div><div class="refsect2"><a name="idm208"></a><h3>RepackLimit</h3><p>Default: 10000</p><p>
+        During vacuuming, if the number of freelist records are more than
+        <code class="varname">RepackLimit</code>, then the database is repacked
+        to get rid of the freelist records to avoid fragmentation.
+      </p><p>
+        Databases are repacked only if both <code class="varname">RepackLimit</code>
+        and <code class="varname">VacuumLimit</code> are exceeded.
+      </p></div><div class="refsect2"><a name="idm216"></a><h3>RerecoveryTimeout</h3><p>Default: 10</p><p>
+       Once a recovery has completed, no additional recoveries are
+       permitted until this timeout in seconds has expired.
+      </p></div><div class="refsect2"><a name="idm220"></a><h3>SeqnumInterval</h3><p>Default: 1000</p><p>
+       Some databases have seqnum tracking enabled, so that samba will
+       be able to detect asynchronously when there has been updates
+       to the database.  Everytime a database is updated its sequence
+       number is increased.
+      </p><p>
+       This tunable is used to specify in milliseconds how frequently
+       ctdb will send out updates to remote nodes to inform them that
+       the sequence number is increased.
+      </p></div><div class="refsect2"><a name="idm225"></a><h3>StatHistoryInterval</h3><p>Default: 1</p><p>
+       Granularity of the statistics collected in the statistics
+       history. This is reported by 'ctdb stats' command.
+      </p></div><div class="refsect2"><a name="idm229"></a><h3>StickyDuration</h3><p>Default: 600</p><p>
+       Once a record has been marked STICKY, this is the duration in
+       seconds, the record will be flagged as a STICKY record.
+      </p></div><div class="refsect2"><a name="idm233"></a><h3>StickyPindown</h3><p>Default: 200</p><p>
+       Once a STICKY record has been migrated onto a node, it will be
+       pinned down on that node for this number of milliseconds. Any
+       request from other nodes to migrate the record off the node will
+       be deferred.
+      </p></div><div class="refsect2"><a name="idm237"></a><h3>TakeoverTimeout</h3><p>Default: 9</p><p>
+       This is the duration in seconds in which ctdb tries to complete IP
+       failover.
+      </p></div><div class="refsect2"><a name="idm241"></a><h3>TDBMutexEnabled</h3><p>Default: 1</p><p>
+       This parameter enables TDB_MUTEX_LOCKING feature on volatile
+       databases if the robust mutexes are supported. This optimizes the
+       record locking using robust mutexes and is much more efficient
+       that using posix locks.
+      </p></div><div class="refsect2"><a name="idm245"></a><h3>TickleUpdateInterval</h3><p>Default: 20</p><p>
+       Every <code class="varname">TickleUpdateInterval</code> seconds, ctdb
+       synchronizes the client connection information across nodes.
+      </p></div><div class="refsect2"><a name="idm250"></a><h3>TraverseTimeout</h3><p>Default: 20</p><p>
+       This is the duration in seconds for which a database traverse
+       is allowed to run.  If the traverse does not complete during
+       this interval, ctdb will abort the traverse.
+      </p></div><div class="refsect2"><a name="idm254"></a><h3>VacuumFastPathCount</h3><p>Default: 60</p><p>
+       During a vacuuming run, ctdb usually processes only the records
+       marked for deletion also called the fast path vacuuming. After
+       finishing <code class="varname">VacuumFastPathCount</code> number of fast
+       path vacuuming runs, ctdb will trigger a scan of complete database
+       for any empty records that need to be deleted.
+      </p></div><div class="refsect2"><a name="idm259"></a><h3>VacuumInterval</h3><p>Default: 10</p><p>
+        Periodic interval in seconds when vacuuming is triggered for
+        volatile databases.
+      </p></div><div class="refsect2"><a name="idm263"></a><h3>VacuumLimit</h3><p>Default: 5000</p><p>
+        During vacuuming, if the number of deleted records are more than
+        <code class="varname">VacuumLimit</code>, then databases are repacked to
+        avoid fragmentation.
+      </p><p>
+        Databases are repacked only if both <code class="varname">RepackLimit</code>
+        and <code class="varname">VacuumLimit</code> are exceeded.
+      </p></div><div class="refsect2"><a name="idm271"></a><h3>VacuumMaxRunTime</h3><p>Default: 120</p><p>
+        The maximum time in seconds for which the vacuuming process is
+        allowed to run.  If vacuuming process takes longer than this
+        value, then the vacuuming process is terminated.
+      </p></div><div class="refsect2"><a name="idm275"></a><h3>VerboseMemoryNames</h3><p>Default: 0</p><p>
+       When set to non-zero, ctdb assigns verbose names for some of
+       the talloc allocated memory objects.  These names are visible
+       in the talloc memory report generated by 'ctdb dumpmemory'.
+      </p></div></div><div class="refsect1"><a name="idm279"></a><h2>SEE ALSO</h2><p>
+      <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+      <a class="ulink" href="" target="_top"></a>
+    </p></div></div></body></html>
diff --git a/web/manpages/4.8/ctdb.1.html b/web/manpages/4.8/ctdb.1.html
new file mode 100644 (file)
index 0000000..5d672e3
--- /dev/null
@@ -0,0 +1,983 @@
+<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
+      cluster:
+      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">PNN</span></dt><dd><p>
+             Physical Node Number.  The physical node number is an
+             integer that describes the node in the cluster. The
+             first node has physical node number 0.  in a cluster.
+           </p></dd><dt><span class="term">PNN-LIST</span></dt><dd><p>
+             This is either a single PNN, a comma-separate list of PNNs
+             or "all".
+           </p></dd></dl></div><p>
+    </p><p>
+      Commands that reference a database use the following terms:
+      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">DB</span></dt><dd><p>
+             This is either a database name, such as
+             <code class="filename">locking.tdb</code> or a database ID such
+             as "0x42fe72c5".
+           </p></dd><dt><span class="term">DB-LIST</span></dt><dd><p>
+             A space separated list of at least one
+             <em class="parameter"><code>DB</code></em>.
+           </p></dd></dl></div><p>
+    </p></div><div class="refsect1"><a name="idm56"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-n <em class="parameter"><code>PNN</code></em></span></dt><dd><p>
+         The node specified by PNN should be queried for the
+         requested information.  Default is to query the daemon
+         running on the local host.
+       </p></dd><dt><span class="term">-Y</span></dt><dd><p>
+         Produce output in machine readable form for easier parsing
+         by scripts. This uses a field delimiter of ':'.  Not all
+         commands support this option.
+       </p></dd><dt><span class="term">-x <em class="parameter"><code>SEPARATOR</code></em></span></dt><dd><p>
+         Use SEPARATOR to delimit fields in machine readable output.
+         This implies -Y.
+       </p></dd><dt><span class="term">-X</span></dt><dd><p>
+         Produce output in machine readable form for easier parsing
+         by scripts. This uses a field delimiter of '|'.  Not all
+         commands support this option.
+       </p><p>
+         This is equivalent to "-x|" and avoids some shell quoting
+         issues.
+       </p></dd><dt><span class="term">-t <em class="parameter"><code>TIMEOUT</code></em></span></dt><dd><p>
+         Indicates that ctdb should wait up to TIMEOUT seconds for
+         a response to most commands sent to the CTDB daemon.  The
+         default is 10 seconds.
+       </p></dd><dt><span class="term">-T <em class="parameter"><code>TIMELIMIT</code></em></span></dt><dd><p>
+         Indicates that TIMELIMIT is the maximum run time (in
+         seconds) for the ctdb command.  When TIMELIMIT is exceeded
+         the ctdb command will terminate with an error.  The default
+         is 120 seconds.
+       </p></dd><dt><span class="term">-? --help</span></dt><dd><p>
+         Print some help text to the screen.
+       </p></dd><dt><span class="term">--usage</span></dt><dd><p>
+         Print useage information to the screen.
+       </p></dd><dt><span class="term">-d --debug=<em class="parameter"><code>DEBUGLEVEL</code></em></span></dt><dd><p>
+         Change the debug level for the command. Default is NOTICE.
+       </p></dd><dt><span class="term">--socket=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+         Specify that FILENAME is the name of the Unix domain
+         socket to use when connecting to the local CTDB
+         daemon. The default is
+         <code class="filename">/usr/local/var/run/ctdb/ctdbd.socket</code>.
+       </p></dd></dl></div></div><div class="refsect1"><a name="idm107"></a><h2>ADMINISTRATIVE COMMANDS</h2><p>
+      These are commands used to monitor and administer a CTDB cluster.
+    </p><div class="refsect2"><a name="idm110"></a><h3>pnn</h3><p>
+       This command displays the PNN of the current node.
+      </p></div><div class="refsect2"><a name="idm113"></a><h3>status</h3><p>
+       This command shows the current status of all CTDB nodes based
+       on information from the queried node.
+      </p><p>
+       Note: If the the queried node is INACTIVE then the status
+       might not be current.
+      </p><div class="refsect3"><a name="idm117"></a><h4>Node status</h4><p>
+         This includes the number of physical nodes and the status of
+         each node.  See <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for information
+         about node states.
+       </p></div><div class="refsect3"><a name="idm123"></a><h4>Generation</h4><p>
+         The generation id is a number that indicates the current generation 
+         of a cluster instance. Each time a cluster goes through a 
+         reconfiguration or a recovery its generation id will be changed.
+       </p><p>
+         This number does not have any particular meaning other than
+         to keep track of when a cluster has gone through a
+         recovery. It is a random number that represents the current
+         instance of a ctdb cluster and its databases.  The CTDB
+         daemon uses this number internally to be able to tell when
+         commands to operate on the cluster and the databases was
+         issued in a different generation of the cluster, to ensure
+         that commands that operate on the databases will not survive
+         across a cluster database recovery.  After a recovery, all
+         old outstanding commands will automatically become invalid.
+       </p><p>
+         Sometimes this number will be shown as "INVALID". This only means that
+         the ctdbd daemon has started but it has not yet merged with the cluster through a recovery.
+         All nodes start with generation "INVALID" and are not assigned a real
+         generation id until they have successfully been merged with a cluster
+         through a recovery.
+       </p></div><div class="refsect3"><a name="idm128"></a><h4>Virtual Node Number (VNN) map</h4><p>
+         Consists of the number of virtual nodes and mapping from
+         virtual node numbers to physical node numbers.  Only nodes
+         that are participating in the VNN map can become lmaster for
+         database records.
+       </p></div><div class="refsect3"><a name="idm131"></a><h4>Recovery mode</h4><p>
+         This is the current recovery mode of the cluster. There are two possible modes:
+       </p><p>
+         NORMAL - The cluster is fully operational.
+       </p><p>
+         RECOVERY - The cluster databases have all been frozen, pausing all services while the cluster awaits a recovery process to complete. A recovery process should finish within seconds. If a cluster is stuck in the RECOVERY state this would indicate a cluster malfunction which needs to be investigated.
+       </p><p>
+         Once the recovery master detects an inconsistency, for example a node 
+         becomes disconnected/connected, the recovery daemon will trigger a 
+         cluster recovery process, where all databases are remerged across the
+         cluster. When this process starts, the recovery master will first
+         "freeze" all databases to prevent applications such as samba from 
+         accessing the databases and it will also mark the recovery mode as
+         RECOVERY.
+       </p><p>
+         When the CTDB daemon starts up, it will start in RECOVERY
+         mode.  Once the node has been merged into a cluster and all
+         databases have been recovered, the node mode will change into
+         NORMAL mode and the databases will be "thawed", allowing samba
+         to access the databases again.
+       </p></div><div class="refsect3"><a name="idm138"></a><h4>Recovery master</h4><p>
+         This is the cluster node that is currently designated as the recovery master. This node is responsible of monitoring the consistency of the cluster and to perform the actual recovery process when reqired.
+       </p><p>
+         Only one node at a time can be the designated recovery master. Which
+         node is designated the recovery master is decided by an election
+         process in the recovery daemons running on each node.
+       </p></div><div class="refsect3"><a name="idm142"></a><h4>Example</h4><pre class="screen">
+# ctdb status
+Number of nodes:4
+pnn:0       OK (THIS NODE)
+pnn:1       OK
+pnn:2       OK
+pnn:3       OK
+hash:0 lmaster:0
+hash:1 lmaster:1
+hash:2 lmaster:2
+hash:3 lmaster:3
+Recovery mode:NORMAL (0)
+Recovery master:0
+       </pre></div></div><div class="refsect2"><a name="idm145"></a><h3>nodestatus [<span class="optional"><em class="parameter"><code>PNN-LIST</code></em></span>]</h3><p>
+       This command is similar to the <span class="command"><strong>status</strong></span>
+       command.  It displays the "node status" subset of output.  The
+       main differences are:
+      </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
+           The exit code is the bitwise-OR of the flags for each
+           specified node, while <span class="command"><strong>ctdb status</strong></span> exits
+           with 0 if it was able to retrieve status for all nodes.
+         </p></li><li class="listitem"><p>
+           <span class="command"><strong>ctdb status</strong></span> provides status information
+           for all nodes.  <span class="command"><strong>ctdb nodestatus</strong></span>
+           defaults to providing status for only the current node.
+           If PNN-LIST is provided then status is given for
+           the indicated node(s).
+         </p></li></ul></div><p>
+       A common invocation in scripts is <span class="command"><strong>ctdb nodestatus
+       all</strong></span> to check whether all nodes in a cluster are
+       healthy.
+      </p><div class="refsect3"><a name="idm161"></a><h4>Example</h4><pre class="screen">
+# ctdb nodestatus
+pnn:0        OK (THIS NODE)
+# ctdb nodestatus all
+Number of nodes:2
+pnn:0        OK (THIS NODE)
+pnn:1        OK
+       </pre></div></div><div class="refsect2"><a name="idm164"></a><h3>recmaster</h3><p>
+       This command shows the pnn of the node which is currently the recmaster.
+      </p><p>
+       Note: If the the queried node is INACTIVE then the status
+       might not be current.
+      </p></div><div class="refsect2"><a name="idm168"></a><h3>uptime</h3><p>
+       This command shows the uptime for the ctdb daemon. When the last recovery or ip-failover completed and how long it took. If the "duration" is shown as a negative number, this indicates that there is a recovery/failover in progress and it started that many seconds ago.
+      </p><div class="refsect3"><a name="idm171"></a><h4>Example</h4><pre class="screen">
+# ctdb uptime
+Current time of node          :                Thu Oct 29 10:38:54 2009
+Ctdbd start time              : (000 16:54:28) Wed Oct 28 17:44:26 2009
+Time of last recovery/failover: (000 16:53:31) Wed Oct 28 17:45:23 2009
+Duration of last recovery/failover: 2.248552 seconds
+       </pre></div></div><div class="refsect2"><a name="idm174"></a><h3>listnodes</h3><p>
+       This command shows lists the ip addresses of all the nodes in the cluster.
+      </p><div class="refsect3"><a name="idm177"></a><h4>Example</h4><pre class="screen">
+# ctdb listnodes
+       </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">
+           </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">
+           </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       UNHEALTHY (THIS NODE)
+pnn:1       OK
+pnn:2       OK
+pnn:3       OK
+           </pre></dd></dl></div></div><div class="refsect2"><a name="idm206"></a><h3>ping</h3><p>
+       This command will "ping" specified CTDB nodes in the cluster
+       to verify that they are running.
+      </p><div class="refsect3"><a name="idm209"></a><h4>Example</h4><pre class="screen">
+# ctdb ping
+response from 0 time=0.000054 sec  (3 clients)
+       </pre></div></div><div class="refsect2"><a name="idm212"></a><h3>ifaces</h3><p>
+       This command will display the list of network interfaces, which could
+       host public addresses, along with their status.
+      </p><div class="refsect3"><a name="idm215"></a><h4>Example</h4><pre class="screen">
+# ctdb ifaces
+Interfaces on node 0
+name:eth5 link:up references:2
+name:eth4 link:down references:0
+name:eth3 link:up references:1
+name:eth2 link:up references:1
+# ctdb -X ifaces
+       </pre></div></div><div class="refsect2"><a name="idm218"></a><h3>ip</h3><p>
+       This command will display the list of public addresses that are provided by the cluster and which physical node is currently serving this ip. By default this command will ONLY show those public addresses that are known to the node itself. To see the full list of all public ips across the cluster you must use "ctdb ip all".
+      </p><div class="refsect3"><a name="idm221"></a><h4>Example</h4><pre class="screen">
+# ctdb ip -v
+Public IPs on node 0
+ node[1] active[] available[eth2,eth3] configured[eth2,eth3]
+ node[0] active[eth3] available[eth2,eth3] configured[eth2,eth3]
+ node[1] active[] available[eth2,eth3] configured[eth2,eth3]
+ node[0] active[eth2] available[eth2,eth3] configured[eth2,eth3]
+ node[1] active[] available[eth5] configured[eth4,eth5]
+ node[0] active[eth5] available[eth5] configured[eth4,eth5]
+ node[1] active[] available[eth5] configured[eth4,eth5]
+ node[0] active[eth5] available[eth5] configured[eth4,eth5]
+# ctdb -X ip -v
+|Public IP|Node|ActiveInterface|AvailableInterfaces|ConfiguredInterfaces|
+       </pre></div></div><div class="refsect2"><a name="idm224"></a><h3>ipinfo <em class="parameter"><code>IP</code></em></h3><p>
+       This command will display details about the specified public addresses.
+      </p><div class="refsect3"><a name="idm228"></a><h4>Example</h4><pre class="screen">
+# ctdb ipinfo
+Public IP[] info on node 0
+Interface[1]: Name:eth4 Link:down References:0
+Interface[2]: Name:eth5 Link:up References:2 (active)
+       </pre></div></div><div class="refsect2"><a name="idm231"></a><h3>event run|status|script list|script enable|script disable</h3><p>
+       This command is used to control event daemon and to inspect
+       status of various events.
+      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">run <em class="parameter"><code>EVENT</code></em> <em class="parameter"><code>TIMEOUT</code></em> [<span class="optional"><em class="parameter"><code>ARGUMENTS</code></em></span>] </span></dt><dd><p>
+            This command can be used to manually run specified EVENT
+            with optional ARGUMENTS.  The event will be allowed to run
+            a maximum of TIMEOUT seconds.  If TIMEOUT is 0, then there
+            is no time limit for running the event.
+           </p></dd><dt><span class="term">status [<span class="optional"><em class="parameter"><code>EVENT</code></em></span>] [<span class="optional">lastrun|lastpass|lastfail</span>]</span></dt><dd><p>
+             This command displays the last execution status of the
+             specified EVENT.  If no event is specified, then the status
+             of last executed monitor event will be displayed.
+           </p><p>
+             To see the last successful execution of the event, lastpass
+             can be specified. Similarly lastfail can be specified
+             to see the last unsuccessful execution of the event.
+             The optional lastrun can be specified to query the last
+             execution of the event.
+           </p><p>
+             The command will terminate with the exit status
+             corresponding to the overall status of event that is
+             displayed.  If lastpass is specified, then the command will
+             always terminate with 0.  If lastfail is specified then the
+             command will always terminate with non-zero exit status.
+             If lastrun is specified, then the command will terminate
+             with 0 or not depending on if the last execution of the
+             event was successful or not.
+           </p><p>
+             The output is the list of event scripts executed.
+             Each line shows the name, status, duration and start time
+             for each script.
+           </p><p>
+             Example output:
+           </p><pre class="screen">
+00.ctdb              OK         0.014 Sat Dec 17 19:39:11 2016
+01.reclock           OK         0.013 Sat Dec 17 19:39:11 2016
+05.system            OK         0.029 Sat Dec 17 19:39:11 2016
+06.nfs               OK         0.014 Sat Dec 17 19:39:11 2016
+10.external          DISABLED  
+10.interface         OK         0.037 Sat Dec 17 19:39:11 2016
+11.natgw             OK         0.011 Sat Dec 17 19:39:11 2016
+11.routing           OK         0.007 Sat Dec 17 19:39:11 2016
+13.per_ip_routing    OK         0.007 Sat Dec 17 19:39:11 2016
+20.multipathd        OK         0.007 Sat Dec 17 19:39:11 2016
+31.clamd             OK         0.007 Sat Dec 17 19:39:11 2016
+40.vsftpd            OK         0.013 Sat Dec 17 19:39:11 2016
+41.httpd             OK         0.018 Sat Dec 17 19:39:11 2016
+49.winbind           OK         0.023 Sat Dec 17 19:39:11 2016
+50.samba             OK         0.100 Sat Dec 17 19:39:12 2016
+60.nfs               OK         0.376 Sat Dec 17 19:39:12 2016
+70.iscsi             OK         0.009 Sat Dec 17 19:39:12 2016
+91.lvs               OK         0.007 Sat Dec 17 19:39:12 2016
+99.timeout           OK         0.007 Sat Dec 17 19:39:12 2016
+           </pre></dd><dt><span class="term">script list</span></dt><dd><p>
+             List the available event scripts.
+           </p><p>
+             Example output:
+           </p><pre class="screen">
+10.external          DISABLED
+           </pre></dd><dt><span class="term">script enable <em class="parameter"><code>SCRIPT</code></em></span></dt><dd><p>
+             Enable the specified event SCRIPT.  Only enabled scripts will be
+             executed when running any event.
+           </p></dd><dt><span class="term">script disable <em class="parameter"><code>SCRIPT</code></em></span></dt><dd><p>
+             Disable the specified event SCRIPT.  This will prevent the script
+             from executing when running any event.
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm271"></a><h3>scriptstatus</h3><p>
+       This command displays which event scripts where run in the previous
+       monitoring cycle and the result of each script. If a script
+       failed with an error, causing the node to become unhealthy,
+       the output from that script is also shown.
+      </p><p>
+       This command is deprecated.  It's provided for backward
+       compatibility.  In place of <span class="command"><strong>ctdb scriptstatus</strong></span>,
+       use <span class="command"><strong>ctdb event status</strong></span>.
+      </p><div class="refsect3"><a name="idm277"></a><h4>Example</h4><pre class="screen">
+# ctdb scriptstatus
+00.ctdb              OK         0.011 Sat Dec 17 19:40:46 2016
+01.reclock           OK         0.010 Sat Dec 17 19:40:46 2016
+05.system            OK         0.030 Sat Dec 17 19:40:46 2016
+06.nfs               OK         0.014 Sat Dec 17 19:40:46 2016
+10.external          DISABLED  
+10.interface         OK         0.041 Sat Dec 17 19:40:46 2016
+11.natgw             OK         0.008 Sat Dec 17 19:40:46 2016
+11.routing           OK         0.007 Sat Dec 17 19:40:46 2016
+13.per_ip_routing    OK         0.007 Sat Dec 17 19:40:46 2016
+20.multipathd        OK         0.007 Sat Dec 17 19:40:46 2016
+31.clamd             OK         0.007 Sat Dec 17 19:40:46 2016
+40.vsftpd            OK         0.013 Sat Dec 17 19:40:46 2016
+41.httpd             OK         0.015 Sat Dec 17 19:40:46 2016
+49.winbind           OK         0.022 Sat Dec 17 19:40:46 2016
+50.samba             ERROR      0.077 Sat Dec 17 19:40:46 2016
+  OUTPUT: ERROR: samba tcp port 445 is not responding
+      </pre></div></div><div class="refsect2"><a name="idm280"></a><h3>listvars</h3><p>
+       List all tuneable variables, except the values of the obsolete tunables
+       like VacuumMinInterval. The obsolete tunables can be retrieved only
+       explicitly with the "ctdb getvar" command.
+      </p><div class="refsect3"><a name="idm283"></a><h4>Example</h4><pre class="screen">
+# ctdb listvars
+SeqnumInterval          = 1000
+ControlTimeout          = 60
+TraverseTimeout         = 20
+KeepaliveInterval       = 5
+KeepaliveLimit          = 5
+RecoverTimeout          = 120
+RecoverInterval         = 1
+ElectionTimeout         = 3
+TakeoverTimeout         = 9
+MonitorInterval         = 15
+TickleUpdateInterval    = 20
+EventScriptTimeout      = 30
+MonitorTimeoutCount     = 20
+RecoveryGracePeriod     = 120
+RecoveryBanPeriod       = 300
+DatabaseHashSize        = 100001
+DatabaseMaxDead         = 5
+RerecoveryTimeout       = 10
+EnableBans              = 1
+NoIPFailback            = 0
+DisableIPFailover       = 0
+VerboseMemoryNames      = 0
+RecdPingTimeout         = 60
+RecdFailCount           = 10
+LogLatencyMs            = 0
+RecLockLatencyMs        = 1000
+RecoveryDropAllIPs      = 120
+VacuumInterval          = 10
+VacuumMaxRunTime        = 120
+RepackLimit             = 10000
+VacuumLimit             = 5000
+VacuumFastPathCount     = 60
+MaxQueueDropMsg         = 1000000
+AllowUnhealthyDBRead    = 0
+StatHistoryInterval     = 1
+DeferredAttachTO        = 120
+AllowClientDBAttach     = 1
+RecoverPDBBySeqNum      = 1
+DeferredRebalanceOnNodeAdd = 300
+FetchCollapse           = 1
+HopcountMakeSticky      = 50
+StickyDuration          = 600
+StickyPindown           = 200
+NoIPTakeover            = 0
+DBRecordCountWarn       = 100000
+DBRecordSizeWarn        = 10000000
+DBSizeWarn              = 100000000
+PullDBPreallocation     = 10485760
+NoIPHostOnAllDisabled   = 0
+TDBMutexEnabled         = 1
+LockProcessesPerDB      = 200
+RecBufferSizeLimit      = 1000000
+QueueBufferSize         = 1024
+IPAllocAlgorithm        = 2
+       </pre></div></div><div class="refsect2"><a name="idm286"></a><h3>getvar <em class="parameter"><code>NAME</code></em></h3><p>
+       Get the runtime value of a tuneable variable.
+      </p><div class="refsect3"><a name="idm290"></a><h4>Example</h4><pre class="screen">
+# ctdb getvar MonitorInterval
+MonitorInterval         = 15
+       </pre></div></div><div class="refsect2"><a name="idm293"></a><h3>setvar <em class="parameter"><code>NAME</code></em> <em class="parameter"><code>VALUE</code></em></h3><p>
+       Set the runtime value of a tuneable variable.
+      </p><div class="refsect3"><a name="idm298"></a><h4>Example</h4><pre class="screen">
+# ctdb setvar MonitorInterval 20
+       </pre></div></div><div class="refsect2"><a name="idm301"></a><h3>lvs {master|list|status}</h3><p>
+       This command shows different aspects of LVS status.  For an
+       overview of CTDB's LVS functionality please see the
+       <em class="citetitle">LVS</em> section in
+       <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
+      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">master</span></dt><dd><p>
+             Shows the PNN of the current LVS master node.
+           </p><p>
+       Example output:
+      </p><pre class="screen">
+      </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">
+      </pre></dd><dt><span class="term">status</span></dt><dd><p>
+             List the nodes in the current LVS group and their status.
+           </p><p>
+       Example output:
+      </p><pre class="screen">
+pnn:0        UNHEALTHY (THIS NODE)
+pnn:1        UNHEALTHY
+pnn:2        OK
+pnn:3        OK
+      </pre></dd></dl></div></div><div class="refsect2"><a name="idm327"></a><h3>getcapabilities</h3><p>
+       This command shows the capabilities of the current node.  See
+       the <em class="citetitle">CAPABILITIES</em> section in
+       <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more details.
+      </p><p>
+       Example output:
+      </p><pre class="screen">
+      </pre></div><div class="refsect2"><a name="idm336"></a><h3>statistics</h3><p>
+        Collect statistics from the CTDB daemon about
+        how many calls it has served.  Information about
+        various fields in statistics can be found in
+       <span class="citerefentry"><span class="refentrytitle">ctdb-statistics</span>(7)</span>.
+      </p><div class="refsect3"><a name="idm342"></a><h4>Example</h4><pre class="screen">
+# ctdb statistics
+CTDB version 1
+Current time of statistics  :                Tue Mar  8 15:18:51 2016
+Statistics collected since  : (003 21:31:32) Fri Mar  4 17:47:19 2016
+ num_clients                        9
+ frozen                             0
+ recovering                         0
+ num_recoveries                     2
+ client_packets_sent          8170534
+ client_packets_recv          7166132
+ node_packets_sent           16549998
+ node_packets_recv            5244418
+ keepalive_packets_sent        201969
+ keepalive_packets_recv        201969
+ node
+     req_call                      26
+     reply_call                     0
+     req_dmaster                    9
+     reply_dmaster                 12
+     reply_error                    0
+     req_message              1339231
+     req_control              8177506
+     reply_control            6831284
+ client
+     req_call                      15
+     req_message               334809
+     req_control              6831308
+ timeouts
+     call                           0
+     control                        0
+     traverse                       0
+ locks
+     num_calls                      8
+     num_current                    0
+     num_pending                    0
+     num_failed                     0
+ total_calls                       15
+ pending_calls                      0
+ childwrite_calls                   0
+ pending_childwrite_calls             0
+ memory_used                   394879
+ max_hop_count                      1
+ total_ro_delegations               0
+ total_ro_revokes                   0
+ hop_count_buckets: 8 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0
+ lock_buckets: 0 0 8 0 0 0 0 0 0 0 0 0 0 0 0 0
+ locks_latency      MIN/AVG/MAX     0.010005/0.010418/0.011010 sec out of 8
+ reclock_ctdbd      MIN/AVG/MAX     0.002538/0.002538/0.002538 sec out of 1
+ reclock_recd       MIN/AVG/MAX     0.000000/0.000000/0.000000 sec out of 0
+ call_latency       MIN/AVG/MAX     0.000044/0.002142/0.011702 sec out of 15
+ childwrite_latency MIN/AVG/MAX     0.000000/0.000000/0.000000 sec out of 0
+       </pre></div></div><div class="refsect2"><a name="idm345"></a><h3>statisticsreset</h3><p>
+       This command is used to clear all statistics counters in a node.
+      </p><p>
+       Example: ctdb statisticsreset
+      </p></div><div class="refsect2"><a name="idm349"></a><h3>dbstatistics <em class="parameter"><code>DB</code></em></h3><p>
+       Display statistics about the database DB.  Information
+       about various fields in dbstatistics can be found in
+       <span class="citerefentry"><span class="refentrytitle">ctdb-statistics</span>(7)</span>.
+      </p><div class="refsect3"><a name="idm356"></a><h4>Example</h4><pre class="screen">
+# ctdb dbstatistics locking.tdb
+DB Statistics: locking.tdb
+ ro_delegations                     0
+ ro_revokes                         0
+ locks
+     total                      14356
+     failed                         0
+     current                        0
+     pending                        0
+ hop_count_buckets: 28087 2 1 0 0 0 0 0 0 0 0 0 0 0 0 0
+ lock_buckets: 0 14188 38 76 32 19 3 0 0 0 0 0 0 0 0 0
+ locks_latency      MIN/AVG/MAX     0.001066/0.012686/4.202292 sec out of 14356
+ vacuum_latency     MIN/AVG/MAX     0.000472/0.002207/15.243570 sec out of 224530
+ Num Hot Keys:     1
+     Count:8 Key:ff5bd7cb3ee3822edc1f0000000000000000000000000000
+       </pre></div></div><div class="refsect2"><a name="idm359"></a><h3>getreclock</h3><p>
+       Show details of the recovery lock, if any.
+      </p><p>
+       Example output:
+      </p><pre class="screen">
+       /clusterfs/.ctdb/recovery.lock
+      </pre></div><div class="refsect2"><a name="idm364"></a><h3>getdebug</h3><p>
+       Get the current debug level for the node. the debug level controls what information is written to the log file.
+      </p><p>
+       The debug levels are mapped to the corresponding syslog levels.
+       When a debug level is set, only those messages at that level and higher
+       levels will be printed.
+      </p><p>
+       The list of debug levels from highest to lowest are :
+      </p><p>
+      </p></div><div class="refsect2"><a name="idm370"></a><h3>setdebug <em class="parameter"><code>DEBUGLEVEL</code></em></h3><p>
+       Set the debug level of a node. This controls what information will be logged.
+      </p><p>
+       The debuglevel is one of ERROR WARNING NOTICE INFO DEBUG
+      </p></div><div class="refsect2"><a name="idm375"></a><h3>getpid</h3><p>
+       This command will return the process id of the ctdb daemon.
+      </p></div><div class="refsect2"><a name="idm378"></a><h3>disable</h3><p>
+       This command is used to administratively disable a node in the cluster.
+       A disabled node will still participate in the cluster and host
+       clustered TDB records but its public ip address has been taken over by
+       a different node and it no longer hosts any services.
+      </p></div><div class="refsect2"><a name="idm381"></a><h3>enable</h3><p>
+       Re-enable a node that has been administratively disabled.
+      </p></div><div class="refsect2"><a name="idm384"></a><h3>stop</h3><p>
+       This command is used to administratively STOP a node in the cluster.
+       A STOPPED node is connected to the cluster but will not host any
+       public ip addresse, nor does it participate in the VNNMAP.
+       The difference between a DISABLED node and a STOPPED node is that
+       a STOPPED node does not host any parts of the database which means
+       that a recovery is required to stop/continue nodes.
+      </p></div><div class="refsect2"><a name="idm387"></a><h3>continue</h3><p>
+       Re-start a node that has been administratively stopped.
+      </p></div><div class="refsect2"><a name="idm390"></a><h3>addip <em class="parameter"><code>IPADDR</code></em>/<em class="parameter"><code>mask</code></em> <em class="parameter"><code>IFACE</code></em></h3><p>
+       This command is used to add a new public ip to a node
+       during runtime.  It should be followed by a <span class="command"><strong>ctdb
+       ipreallocate</strong></span>.  This allows public addresses to be
+       added to a cluster without having to restart the ctdb daemons.
+      </p><p>
+       Note that this only updates the runtime instance of ctdb. Any
+       changes will be lost next time ctdb is restarted and the public
+       addresses file is re-read.  If you want this change to be
+       permanent you must also update the public addresses file manually.
+      </p></div><div class="refsect2"><a name="idm398"></a><h3>delip <em class="parameter"><code>IPADDR</code></em></h3><p>
+       This command flags IPADDR for deletion from a node at runtime.
+       It should be followed by a <span class="command"><strong>ctdb
+       ipreallocate</strong></span>.  If IPADDR is currently hosted by the
+       node it is being removed from, this ensures that the IP will
+       first be failed over to another node, if possible, and that it
+       is then actually removed.
+      </p><p>
+       Note that this only updates the runtime instance of CTDB.  Any
+       changes will be lost next time CTDB is restarted and the
+       public addresses file is re-read.  If you want this change to
+       be permanent you must also update the public addresses file
+       manually.
+      </p></div><div class="refsect2"><a name="idm404"></a><h3>moveip <em class="parameter"><code>IPADDR</code></em> <em class="parameter"><code>PNN</code></em></h3><p>
+       This command can be used to manually fail a public ip address to a
+       specific node.
+      </p><p>
+       In order to manually override the "automatic" distribution of public 
+       ip addresses that ctdb normally provides, this command only works
+       when you have changed the tunables for the daemon to:
+      </p><p>
+       IPAllocAlgorithm != 0
+      </p><p>
+       NoIPFailback = 1
+      </p></div><div class="refsect2"><a name="idm412"></a><h3>shutdown</h3><p>
+       This command will shutdown a specific CTDB daemon.
+      </p></div><div class="refsect2"><a name="idm415"></a><h3>setlmasterrole on|off</h3><p>
+       This command is used ot enable/disable the LMASTER capability for a node at runtime. This capability determines whether or not a node can be used as an LMASTER for records in the database. A node that does not have the LMASTER capability will not show up in the vnnmap.
+      </p><p>
+       Nodes will by default have this capability, but it can be stripped off nodes by the setting in the sysconfig file or by using this command.
+      </p><p>
+       Once this setting has been enabled/disabled, you need to perform a recovery for it to take effect.
+      </p><p>
+       See also "ctdb getcapabilities"
+      </p></div><div class="refsect2"><a name="idm421"></a><h3>setrecmasterrole on|off</h3><p>
+       This command is used ot enable/disable the RECMASTER capability for a node at runtime. This capability determines whether or not a node can be used as an RECMASTER for the cluster. A node that does not have the RECMASTER capability can not win a recmaster election. A node that already is the recmaster for the cluster when the capability is stripped off the node will remain the recmaster until the next cluster election.
+      </p><p>
+       Nodes will by default have this capability, but it can be stripped off nodes by the setting in the sysconfig file or by using this command.
+      </p><p>
+       See also "ctdb getcapabilities"
+      </p></div><div class="refsect2"><a name="idm426"></a><h3>reloadnodes</h3><p>
+       This command is used when adding new nodes, or removing
+       existing nodes from an existing cluster.
+      </p><p>
+       Procedure to add nodes:
+      </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
+            To expand an existing cluster, first ensure with
+            <span class="command"><strong>ctdb status</strong></span> that all nodes are up and
+            running and that they are all healthy.  Do not try to
+            expand a cluster unless it is completely healthy!
+         </p></li><li class="listitem"><p>
+           On all nodes, edit <code class="filename">/usr/local/etc/ctdb/nodes</code>
+           and <span class="emphasis"><em>add the new nodes at the end of this
+           file</em></span>.
+         </p></li><li class="listitem"><p>
+           Verify that all the nodes have identical
+           <code class="filename">/usr/local/etc/ctdb/nodes</code> files after adding
+           the new nodes.
+         </p></li><li class="listitem"><p>
+           Run <span class="command"><strong>ctdb reloadnodes</strong></span> to force all nodes
+           to reload the nodes file.
+         </p></li><li class="listitem"><p>
+           Use <span class="command"><strong>ctdb status</strong></span> on all nodes and verify
+           that they now show the additional nodes.
+         </p></li><li class="listitem"><p>
+           Install and configure the new node and bring it online.
+         </p></li></ol></div><p>
+       Procedure to remove nodes:
+      </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
+           To remove nodes from an existing cluster, first ensure
+           with <span class="command"><strong>ctdb status</strong></span> that all nodes, except
+           the node to be deleted, are up and running and that they
+           are all healthy.  Do not try to remove nodes from a
+           cluster unless the cluster is completely healthy!
+         </p></li><li class="listitem"><p>
+           Shutdown and power off the node to be removed.
+         </p></li><li class="listitem"><p>
+           On all other nodes, edit the
+           <code class="filename">/usr/local/etc/ctdb/nodes</code> file and
+           <span class="emphasis"><em>comment out</em></span> the nodes to be removed.
+           <span class="emphasis"><em>Do not delete the lines for the deleted
+           nodes</em></span>, just comment them out by adding a '#' at
+           the beginning of the lines.
+         </p></li><li class="listitem"><p>
+           Run <span class="command"><strong>ctdb reloadnodes</strong></span> to force all nodes
+           to reload the nodes file.
+         </p></li><li class="listitem"><p>
+           Use <span class="command"><strong>ctdb status</strong></span> on all nodes and verify
+           that the deleted nodes are no longer listed.
+         </p></li></ol></div></div><div class="refsect2"><a name="idm467"></a><h3>
+       reloadips
+       [<span class="optional"><em class="parameter"><code>PNN-LIST</code></em></span>]
+      </h3><p>
+       This command reloads the public addresses configuration file
+       on the specified nodes.  When it completes addresses will be
+       reconfigured and reassigned across the cluster as necessary.
+      </p><p>
+       This command is currently unable to make changes to the
+       netmask or interfaces associated with existing addresses.
+       Such changes must be made in 2 steps by deleting addresses in
+       question and re-adding then.  Unfortunately this will disrupt
+       connections to the changed addresses.
+      </p></div><div class="refsect2"><a name="idm473"></a><h3>getdbmap</h3><p>
+       This command lists all clustered TDB databases that the CTDB
+       daemon has attached to. Some databases are flagged as PERSISTENT,
+       this means that the database stores data persistently and the
+       data will remain across reboots. One example of such a database
+       is secrets.tdb where information about how the cluster was joined
+       to the domain is stored.  Some database are flagged as REPLICATED,
+       this means that the data in that database is replicated across all
+       the nodes.  But the data will not remain across reboots.  This
+       type of database is used by CTDB to store it's internal state.
+      </p><p>
+       If a PERSISTENT database is not in a healthy state the database
+       is flagged as UNHEALTHY. If there's at least one completely
+       healthy node running in the cluster, it's possible that the
+       content is restored by a recovery run automaticly. Otherwise an
+       administrator needs to analyze the problem.
+      </p><p>
+       See also "ctdb getdbstatus", "ctdb backupdb", "ctdb restoredb",
+       "ctdb dumpbackup", "ctdb wipedb", "ctdb setvar AllowUnhealthyDBRead 1"
+       and (if samba or tdb-utils are installed) "tdbtool check".
+      </p><p>
+       Most databases are not persistent and only store the state
+       information that the currently running samba daemons need. These
+       databases are always wiped when ctdb/samba starts and when a
+       node is rebooted.
+      </p><div class="refsect3"><a name="idm479"></a><h4>Example</h4><pre class="screen">
+# ctdb getdbmap
+Number of databases:10
+dbid:0x435d3410 name:notify.tdb path:/usr/local/var/lib/ctdb/notify.tdb.0
+dbid:0x42fe72c5 name:locking.tdb path:/usr/local/var/lib/ctdb/locking.tdb.0
+dbid:0x1421fb78 name:brlock.tdb path:/usr/local/var/lib/ctdb/brlock.tdb.0
+dbid:0x17055d90 name:connections.tdb path:/usr/local/var/lib/ctdb/connections.tdb.0
+dbid:0xc0bdde6a name:sessionid.tdb path:/usr/local/var/lib/ctdb/sessionid.tdb.0
+dbid:0x122224da name:test.tdb path:/usr/local/var/lib/ctdb/test.tdb.0
+dbid:0x2672a57f name:idmap2.tdb path:/usr/local/var/lib/ctdb/persistent/idmap2.tdb.0 PERSISTENT
+dbid:0xb775fff6 name:secrets.tdb path:/usr/local/var/lib/ctdb/persistent/secrets.tdb.0 PERSISTENT
+dbid:0xe98e08b6 name:group_mapping.tdb path:/usr/local/var/lib/ctdb/persistent/group_mapping.tdb.0 PERSISTENT
+dbid:0x7bbbd26c name:passdb.tdb path:/usr/local/var/lib/ctdb/persistent/passdb.tdb.0 PERSISTENT
+# ctdb getdbmap  # example for unhealthy database
+Number of databases:1
+dbid:0xb775fff6 name:secrets.tdb path:/usr/local/var/lib/ctdb/persistent/secrets.tdb.0 PERSISTENT UNHEALTHY
+# ctdb -X getdbmap
+       </pre></div></div><div class="refsect2"><a name="idm482"></a><h3>
+       backupdb
+       <em class="parameter"><code>DB</code></em>
+       <em class="parameter"><code>FILE</code></em>
+      </h3><p>
+       Copy the contents of database DB to FILE.  FILE can later be
+       read back using <span class="command"><strong>restoredb</strong></span>.  This is mainly
+       useful for backing up persistent databases such as
+       <code class="filename">secrets.tdb</code> and similar.
+      </p></div><div class="refsect2"><a name="idm489"></a><h3>
+       restoredb
+       <em class="parameter"><code>FILE</code></em>
+       [<span class="optional"><em class="parameter"><code>DB</code></em></span>]
+      </h3><p>
+       This command restores a persistent database that was
+       previously backed up using backupdb.  By default the data will
+       be restored back into the same database as it was created
+       from. By specifying dbname you can restore the data into a
+       different database.
+      </p></div><div class="refsect2"><a name="idm495"></a><h3>setdbreadonly <em class="parameter"><code>DB</code></em></h3><p>
+       This command will enable the read-only record support for a
+       database.  This is an experimental feature to improve
+       performance for contended records primarily in locking.tdb and
+       brlock.tdb.  When enabling this feature you must set it on all
+       nodes in the cluster.
+      </p></div><div class="refsect2"><a name="idm499"></a><h3>setdbsticky <em class="parameter"><code>DB</code></em></h3><p>
+       This command will enable the sticky record support for the
+       specified database.  This is an experimental feature to
+       improve performance for contended records primarily in
+       locking.tdb and brlock.tdb.  When enabling this feature you
+       must set it on all nodes in the cluster.
+      </p></div></div><div class="refsect1"><a name="idm503"></a><h2>INTERNAL COMMANDS</h2><p>
+      Internal commands are used by CTDB's scripts and are not
+      required for managing a CTDB cluster.  Their parameters and
+      behaviour are subject to change.
+    </p><div class="refsect2"><a name="idm506"></a><h3>gettickles <em class="parameter"><code>IPADDR</code></em></h3><p>
+       Show TCP connections that are registered with CTDB to be
+       "tickled" if there is a failover.
+      </p></div><div class="refsect2"><a name="idm510"></a><h3>gratarp <em class="parameter"><code>IPADDR</code></em> <em class="parameter"><code>INTERFACE</code></em></h3><p>
+       Send out a gratuitous ARP for the specified interface through
+       the specified interface. This command is mainly used by the
+       ctdb eventscripts.
+      </p></div><div class="refsect2"><a name="idm515"></a><h3>
+       pdelete <em class="parameter"><code>DB</code></em> <em class="parameter"><code>KEY</code></em>
+      </h3><p>
+       Delete KEY from DB.
+      </p></div><div class="refsect2"><a name="idm520"></a><h3>
+       pfetch <em class="parameter"><code>DB</code></em> <em class="parameter"><code>KEY</code></em>
+      </h3><p>
+       Print the value associated with KEY in DB.
+      </p></div><div class="refsect2"><a name="idm525"></a><h3>
+       pstore
+       <em class="parameter"><code>DB</code></em>
+       <em class="parameter"><code>KEY</code></em>
+       <em class="parameter"><code>FILE</code></em>
+      </h3><p>
+       Store KEY in DB with contents of FILE as the associated value.
+      </p></div><div class="refsect2"><a name="idm531"></a><h3>
+       ptrans
+       <em class="parameter"><code>DB</code></em>
+       [<span class="optional"><em class="parameter"><code>FILE</code></em></span>]
+      </h3><p>
+       Read a list of key-value pairs, one per line from FILE, and
+       store them in DB using a single transaction.  An empty value
+       is equivalent to deleting the given key.
+      </p><p>
+       The key and value should be separated by spaces or tabs. Each
+       key/value should be a printable string enclosed in
+       double-quotes.
+      </p></div><div class="refsect2"><a name="idm538"></a><h3>runstate [setup|first_recovery|startup|running]</h3><p>
+       Print the runstate of the specified node.  Runstates are used
+       to serialise important state transitions in CTDB, particularly
+       during startup.
+      </p><p>
+       If one or more optional runstate arguments are specified then
+       the node must be in one of these runstates for the command to
+       succeed.
+      </p><div class="refsect3"><a name="idm542"></a><h4>Example</h4><pre class="screen">
+# ctdb runstate
+       </pre></div></div><div class="refsect2"><a name="idm545"></a><h3>setifacelink <em class="parameter"><code>IFACE</code></em> up|down</h3><p>
+       Set the internal state of network interface IFACE.  This is
+       typically used in the <code class="filename">10.interface</code> script
+       in the "monitor" event.
+      </p><p>
+       Example: ctdb setifacelink eth0 up
+      </p></div><div class="refsect2"><a name="idm551"></a><h3>tickle</h3><p>
+       Read a list of TCP connections, one per line, from standard
+       input and send a TCP tickle to the source host for each
+       connection.  A connection is specified as:
+      </p><pre class="synopsis">
+       <em class="parameter"><code>SRC-IPADDR</code></em>:<em class="parameter"><code>SRC-PORT</code></em> <em class="parameter"><code>DST-IPADDR</code></em>:<em class="parameter"><code>DST-PORT</code></em>
+      </pre><p>
+       A single connection can be specified on the command-line
+       rather than on standard input.
+      </p><p>
+       A TCP tickle is a TCP ACK packet with an invalid sequence and
+       acknowledge number and will when received by the source host
+       result in it sending an immediate correct ACK back to the
+       other end.
+      </p><p>
+       TCP tickles are useful to "tickle" clients after a IP failover has
+       occurred since this will make the client immediately recognize the
+       TCP connection has been disrupted and that the client will need
+       to reestablish. This greatly speeds up the time it takes for a client
+       to detect and reestablish after an IP failover in the ctdb cluster.
+      </p></div><div class="refsect2"><a name="idm562"></a><h3>version</h3><p>
+       Display the CTDB version.
+      </p></div></div><div class="refsect1"><a name="idm565"></a><h2>DEBUGGING COMMANDS</h2><p>
+      These commands are primarily used for CTDB development and testing and
+      should not be used for normal administration.
+    </p><div class="refsect2"><a name="idm568"></a><h3>OPTIONS</h3><div class="variablelist"><dl class="variablelist"><dt><span class="term">--print-emptyrecords</span></dt><dd><p>
+           This enables printing of empty records when dumping databases
+           with the catdb, cattbd and dumpdbbackup commands. Records with
+           empty data segment are considered deleted by ctdb and cleaned
+           by the vacuuming mechanism, so this switch can come in handy for
+           debugging the vacuuming behaviour.
+         </p></dd><dt><span class="term">--print-datasize</span></dt><dd><p>
+           This lets database dumps (catdb, cattdb, dumpdbbackup) print the
+           size of the record data instead of dumping the data contents.
+         </p></dd><dt><span class="term">--print-lmaster</span></dt><dd><p>
+           This lets catdb print the lmaster for each record.
+         </p></dd><dt><span class="term">--print-hash</span></dt><dd><p>
+           This lets database dumps (catdb, cattdb, dumpdbbackup) print the
+           hash for each record.
+         </p></dd><dt><span class="term">--print-recordflags</span></dt><dd><p>
+           This lets catdb and dumpdbbackup print the
+           record flags for each record. Note that cattdb always
+           prints the flags.
+         </p></dd></dl></div></div><div class="refsect2"><a name="idm591"></a><h3>process-exists <em class="parameter"><code>PID</code></em> <em class="parameter"><code>[SRVID]</code></em></h3><p>
+       This command checks if a specific process exists on the CTDB
+       host. This is mainly used by Samba to check if remote instances
+       of samba are still running or not.  When the optional SRVID
+       argument is specified, the command check if a specific process
+       exists on the CTDB host and has registered for specified SRVID.
+      </p></div><div class="refsect2"><a name="idm596"></a><h3>getdbstatus <em class="parameter"><code>DB</code></em></h3><p>
+       This command displays more details about a database.
+      </p><div class="refsect3"><a name="idm600"></a><h4>Example</h4><pre class="screen">
+# ctdb getdbstatus test.tdb.0
+dbid: 0x122224da
+name: test.tdb
+path: /usr/local/var/lib/ctdb/test.tdb.0
+# ctdb getdbstatus registry.tdb  # with a corrupted TDB
+dbid: 0xf2a58948
+name: registry.tdb
+path: /usr/local/var/lib/ctdb/persistent/registry.tdb.0
+HEALTH: NO-HEALTHY-NODES - ERROR - Backup of corrupted TDB in '/usr/local/var/lib/ctdb/persistent/registry.tdb.0.corrupted.20091208091949.0Z'
+       </pre></div></div><div class="refsect2"><a name="idm603"></a><h3>catdb <em class="parameter"><code>DB</code></em></h3><p>
+       Print a dump of the clustered TDB database DB.
+      </p></div><div class="refsect2"><a name="idm607"></a><h3>cattdb <em class="parameter"><code>DB</code></em></h3><p>
+       Print a dump of the contents of the local TDB database DB.
+      </p></div><div class="refsect2"><a name="idm611"></a><h3>dumpdbbackup <em class="parameter"><code>FILE</code></em></h3><p>
+       Print a dump of the contents from database backup FILE,
+       similar to <span class="command"><strong>catdb</strong></span>.
+      </p></div><div class="refsect2"><a name="idm616"></a><h3>wipedb <em class="parameter"><code>DB</code></em></h3><p>
+       Remove all contents of database DB.
+      </p></div><div class="refsect2"><a name="idm620"></a><h3>recover</h3><p>
+       This command will trigger the recovery daemon to do a cluster
+       recovery.
+      </p></div><div class="refsect2"><a name="idm623"></a><h3>ipreallocate, sync</h3><p>
+       This command will force the recovery master to perform a full ip reallocation process and redistribute all ip addresses. This is useful to "reset" the allocations back to its default state if they have been changed using the "moveip" command. While a "recover" will also perform this reallocation, a recovery is much more hevyweight since it will also rebuild all the databases.
+      </p></div><div class="refsect2"><a name="idm626"></a><h3>attach <em class="parameter"><code>DBNAME</code></em> [persistent|replicated]</h3><p>
+       Create a new CTDB database called DBNAME and attach to it on
+       all nodes.
+      </p></div><div class="refsect2"><a name="idm630"></a><h3>detach <em class="parameter"><code>DB-LIST</code></em></h3><p>
+       Detach specified non-persistent database(s) from the cluster. This
+       command will disconnect specified database(s) on all nodes in
+       the cluster.  This command should only be used when none of the
+       specified database(s) are in use.
+      </p><p>
+       All nodes should be active and tunable AllowClientDBAccess should
+       be disabled on all nodes before detaching databases.
+      </p></div><div class="refsect2"><a name="idm635"></a><h3>dumpmemory</h3><p>
+       This is a debugging command. This command will make the ctdb
+       daemon to write a fill memory allocation map to standard output.
+      </p></div><div class="refsect2"><a name="idm638"></a><h3>rddumpmemory</h3><p>
+       This is a debugging command. This command will dump the talloc memory
+       allocation tree for the recovery daemon to standard output.
+      </p></div><div class="refsect2"><a name="idm641"></a><h3>ban <em class="parameter"><code>BANTIME</code></em></h3><p>
+       Administratively ban a node for BANTIME seconds.  The node
+       will be unbanned after BANTIME seconds have elapsed.
+      </p><p>
+       A banned node does not participate in the cluster.  It does
+       not host any records for the clustered TDB and does not host
+       any public IP addresses.
+      </p><p>
+       Nodes are automatically banned if they misbehave.  For
+       example, a node may be banned if it causes too many cluster
+       recoveries.
+      </p><p>
+       To administratively exclude a node from a cluster use the
+       <span class="command"><strong>stop</strong></span> command.
+      </p></div><div class="refsect2"><a name="idm649"></a><h3>unban</h3><p>
+       This command is used to unban a node that has either been
+       administratively banned using the ban command or has been
+       automatically banned.
+      </p></div></div><div class="refsect1"><a name="idm652"></a><h2>SEE ALSO</h2><p>
+      <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">onnode</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdb-statistics</span>(7)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span>,
+      <a class="ulink" href="" target="_top"></a>
+    </p></div></div></body></html>
diff --git a/web/manpages/4.8/ctdb.7.html b/web/manpages/4.8/ctdb.7.html
new file mode 100644 (file)
index 0000000..bbacaab
--- /dev/null
@@ -0,0 +1,637 @@
+<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>
+    The main functions of CTDB are:
+  </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
+       Provide a clustered version of the TDB database with automatic
+       rebuild/recovery of the databases upon node failures.
+      </p></li><li class="listitem"><p>
+      Monitor nodes in the cluster and services running on each node.
+      </p></li><li class="listitem"><p>
+       Manage a pool of public IP addresses that are used to provide
+       services to clients.  Alternatively, CTDB can be used with
+       LVS.
+      </p></li></ul></div><p>
+    Combined with a cluster filesystem CTDB provides a full
+    high-availablity (HA) environment for services such as clustered
+    Samba, NFS and other services.
+  </p></div><div class="refsect1"><a name="idm22"></a><h2>ANATOMY OF A CTDB CLUSTER</h2><p>
+    A CTDB cluster is a collection of nodes with 2 or more network
+    interfaces.  All nodes provide network (usually file/NAS) services
+    to clients.  Data served by file services is stored on shared
+    storage (usually a cluster filesystem) that is accessible by all
+    nodes.
+  </p><p>
+    CTDB provides an "all active" cluster, where services are load
+    balanced across all nodes.
+  </p></div><div class="refsect1"><a name="idm26"></a><h2>Recovery Lock</h2><p>
+      CTDB uses a <span class="emphasis"><em>recovery lock</em></span> to avoid a
+      <span class="emphasis"><em>split brain</em></span>, where a cluster becomes
+      partitioned and each partition attempts to operate
+      independently.  Issues that can result from a split brain
+      include file data corruption, because file locking metadata may
+      not be tracked correctly.
+    </p><p>
+      CTDB uses a <span class="emphasis"><em>cluster leader and follower</em></span>
+      model of cluster management.  All nodes in a cluster elect one
+      node to be the leader.  The leader node coordinates privileged
+      operations such as database recovery and IP address failover.
+      CTDB refers to the leader node as the <span class="emphasis"><em>recovery
+      master</em></span>.  This node takes and holds the recovery lock
+      to assert its privileged role in the cluster.
+    </p><p>
+      By default, the recovery lock is implemented using a file
+      (specified by <em class="parameter"><code>CTDB_RECOVERY_LOCK</code></em>)
+      residing in shared storage (usually) on a cluster filesystem.
+      To support a recovery lock the cluster filesystem must support
+      lock coherence.  See
+      <span class="citerefentry"><span class="refentrytitle">ping_pong</span>(1)</span> for more details.
+    </p><p>
+      The recovery lock can also be implemented using an arbitrary
+      cluster mutex call-out by using an exclamation point ('!') as
+      the first character of
+      <em class="parameter"><code>CTDB_RECOVERY_LOCK</code></em>.  For example, a value
+      of <span class="command"><strong>!/usr/local/bin/myhelper recovery</strong></span> would
+      run the given helper with the specified arguments.  See the
+      source code relating to cluster mutexes for clues about writing
+      call-outs.
+    </p><p>
+      If a cluster becomes partitioned (for example, due to a
+      communication failure) and a different recovery master is
+      elected by the nodes in each partition, then only one of these
+      recovery masters will be able to take the recovery lock.  The
+      recovery master in the "losing" partition will not be able to
+      take the recovery lock and will be excluded from the cluster.
+      The nodes in the "losing" partition will elect each node in turn
+      as their recovery master so eventually all the nodes in that
+      partition will be excluded.
+    </p><p>
+      CTDB does sanity checks to ensure that the recovery lock is held
+      as expected.
+    </p><p>
+      CTDB can run without a recovery lock but this is not recommended
+      as there will be no protection from split brains.
+    </p></div><div class="refsect1"><a name="idm45"></a><h2>Private vs Public addresses</h2><p>
+      Each node in a CTDB cluster has multiple IP addresses assigned
+      to it:
+      </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
+           A single private IP address that is used for communication
+           between nodes.
+         </p></li><li class="listitem"><p>
+           One or more public IP addresses that are used to provide
+           NAS or other services.
+         </p></li></ul></div><p>
+    </p><div class="refsect2"><a name="idm53"></a><h3>Private address</h3><p>
+        Each node is configured with a unique, permanently assigned
+        private address.  This address is configured by the operating
+        system.  This address uniquely identifies a physical node in
+        the cluster and is the address that CTDB daemons will use to
+        communicate with the CTDB daemons on other nodes.
+      </p><p>
+        Private addresses are listed in the file specified by the
+        <code class="varname">CTDB_NODES</code> configuration variable (see
+        <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>, default
+        <code class="filename">/usr/local/etc/ctdb/nodes</code>).  This file contains the
+        list of private addresses for all nodes in the cluster, one
+        per line. This file must be the same on all nodes in the
+        cluster.
+      </p><p>
+       Private addresses should not be used by clients to connect to
+       services provided by the cluster.
+      </p><p>
+        It is strongly recommended that the private addresses are
+        configured on a private network that is separate from client
+        networks.  This is because the CTDB protocol is both
+        unauthenticated and unencrypted.  If clients share the private
+        network then steps need to be taken to stop injection of
+        packets to relevant ports on the private addresses.  It is
+        also likely that CTDB protocol traffic between nodes could
+        leak sensitive information if it can be intercepted.
+      </p><p>
+       Example <code class="filename">/usr/local/etc/ctdb/nodes</code> for a four node
+       cluster:
+      </p><pre class="screen">
+      </pre></div><div class="refsect2"><a name="idm67"></a><h3>Public addresses</h3><p>
+       Public addresses are used to provide services to clients.
+       Public addresses are not configured at the operating system
+       level and are not permanently associated with a particular
+       node.  Instead, they are managed by CTDB and are assigned to
+       interfaces on physical nodes at runtime.
+      </p><p>
+        The CTDB cluster will assign/reassign these public addresses
+        across the available healthy nodes in the cluster. When one
+        node fails, its public addresses will be taken over by one or
+        more other nodes in the cluster.  This ensures that services
+        provided by all public addresses are always available to
+        clients, as long as there are nodes available capable of
+        hosting this address.
+      </p><p>
+       The public address configuration is stored in a file on each
+       node specified by the <code class="varname">CTDB_PUBLIC_ADDRESSES</code>
+       configuration variable (see
+       <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>, recommended
+       <code class="filename">/usr/local/etc/ctdb/public_addresses</code>).  This file
+       contains a list of the public addresses that the node is
+       capable of hosting, one per line.  Each entry also contains
+       the netmask and the interface to which the address should be
+       assigned.
+      </p><p>
+       Example <code class="filename">/usr/local/etc/ctdb/public_addresses</code> for a
+       node that can host 4 public addresses, on 2 different
+       interfaces:
+      </p><pre class="screen">
+ eth1
+ eth1
+ eth2
+ eth2
+      </pre><p>
+       In many cases the public addresses file will be the same on
+       all nodes.  However, it is possible to use different public
+       address configurations on different nodes.
+      </p><p>
+       Example: 4 nodes partitioned into two subgroups:
+      </p><pre class="screen">
+Node 0:/usr/local/etc/ctdb/public_addresses
+ eth1
+ eth1
+Node 1:/usr/local/etc/ctdb/public_addresses
+ eth1
+ eth1
+Node 2:/usr/local/etc/ctdb/public_addresses
+ eth2
+ eth2
+Node 3:/usr/local/etc/ctdb/public_addresses
+ eth2
+ eth2
+      </pre><p>
+       In this example nodes 0 and 1 host two public addresses on the
+       10.1.1.x network while nodes 2 and 3 host two public addresses
+       for the 10.1.2.x network.
+      </p><p>
+       Public address can be hosted by either of nodes 0 or
+       1 and will be available to clients as long as at least one of
+       these two nodes are available.
+      </p><p>
+       If both nodes 0 and 1 become unavailable then public address
+ also becomes unavailable. can not be failed
+       over to nodes 2 or 3 since these nodes do not have this public
+       address configured.
+      </p><p>
+        The <span class="command"><strong>ctdb ip</strong></span> command can be used to view the
+        current assignment of public addresses to physical nodes.
+      </p></div></div><div class="refsect1"><a name="idm88"></a><h2>Node status</h2><p>
+      The current status of each node in the cluster can be viewed by the 
+      <span class="command"><strong>ctdb status</strong></span> command.
+    </p><p>
+      A node can be in one of the following states:
+    </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">OK</span></dt><dd><p>
+           This node is healthy and fully functional.  It hosts public
+           addresses to provide services.
+         </p></dd><dt><span class="term">DISCONNECTED</span></dt><dd><p>
+           This node is not reachable by other nodes via the private
+           network.  It is not currently participating in the cluster.
+           It <span class="emphasis"><em>does not</em></span> host public addresses to
+           provide services.  It might be shut down.
+         </p></dd><dt><span class="term">DISABLED</span></dt><dd><p>
+           This node has been administratively disabled. This node is
+           partially functional and participates in the cluster.
+           However, it <span class="emphasis"><em>does not</em></span> host public
+           addresses to provide services.
+         </p></dd><dt><span class="term">UNHEALTHY</span></dt><dd><p>
+           A service provided by this node has failed a health check
+           and should be investigated.  This node is partially
+           functional and participates in the cluster.  However, it
+           <span class="emphasis"><em>does not</em></span> host public addresses to
+           provide services.  Unhealthy nodes should be investigated
+           and may require an administrative action to rectify.
+         </p></dd><dt><span class="term">BANNED</span></dt><dd><p>
+           CTDB is not behaving as designed on this node.  For example,
+           it may have failed too many recovery attempts.  Such nodes
+           are banned from participating in the cluster for a
+           configurable time period before they attempt to rejoin the
+           cluster.  A banned node <span class="emphasis"><em>does not</em></span> host
+           public addresses to provide services.  All banned nodes
+           should be investigated and may require an administrative
+           action to rectify.
+         </p></dd><dt><span class="term">STOPPED</span></dt><dd><p>
+           This node has been administratively exclude from the
+           cluster.  A stopped node does no participate in the cluster
+           and <span class="emphasis"><em>does not</em></span> host public addresses to
+           provide services.  This state can be used while performing
+           maintenance on a node.
+         </p></dd><dt><span class="term">PARTIALLYONLINE</span></dt><dd><p>
+           A node that is partially online participates in a cluster
+           like a healthy (OK) node.  Some interfaces to serve public
+           addresses are down, but at least one interface is up.  See
+           also <span class="command"><strong>ctdb ifaces</strong></span>.
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm128"></a><h2>CAPABILITIES</h2><p>
+      Cluster nodes can have several different capabilities enabled.
+      These are listed below.
+    </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">RECMASTER</span></dt><dd><p>
+           Indicates that a node can become the CTDB cluster recovery
+           master.  The current recovery master is decided via an
+           election held by all active nodes with this capability.
+         </p><p>
+           Default is YES.
+         </p></dd><dt><span class="term">LMASTER</span></dt><dd><p>
+           Indicates that a node can be the location master (LMASTER)
+           for database records.  The LMASTER always knows which node
+           has the latest copy of a record in a volatile database.
+         </p><p>
+           Default is YES.
+         </p></dd></dl></div><p>
+      The RECMASTER and LMASTER capabilities can be disabled when CTDB
+      is used to create a cluster spanning across WAN links. In this
+      case CTDB acts as a WAN accelerator.
+    </p></div><div class="refsect1"><a name="idm143"></a><h2>LVS</h2><p>
+      LVS is a mode where CTDB presents one single IP address for the
+      entire cluster. This is an alternative to using public IP
+      addresses and round-robin DNS to loadbalance clients across the
+      cluster.
+    </p><p>
+      This is similar to using a layer-4 loadbalancing switch but with
+      some restrictions.
+    </p><p>
+      One extra LVS public address is assigned on the public network
+      to each LVS group.  Each LVS group is a set of nodes in the
+      cluster that presents the same LVS address public address to the
+      outside world.  Normally there would only be one LVS group
+      spanning an entire cluster, but in situations where one CTDB
+      cluster spans multiple physical sites it might be useful to have
+      one LVS group for each site.  There can be multiple LVS groups
+      in a cluster but each node can only be member of one LVS group.
+    </p><p>
+      Client access to the cluster is load-balanced across the HEALTHY
+      nodes in an LVS group.  If no HEALTHY nodes exists then all
+      nodes in the group are used, regardless of health status.  CTDB
+      will, however never load-balance LVS traffic to nodes that are
+      BANNED, STOPPED, DISABLED or DISCONNECTED.  The <span class="command"><strong>ctdb
+      lvs</strong></span> command is used to show which nodes are currently
+      load-balanced across.
+    </p><p>
+      In each LVS group, one of the nodes is selected by CTDB to be
+      the LVS master.  This node receives all traffic from clients
+      coming in to the LVS public address and multiplexes it across
+      the internal network to one of the nodes that LVS is using.
+      When responding to the client, that node will send the data back
+      directly to the client, bypassing the LVS master node.  The
+      command <span class="command"><strong>ctdb lvs master</strong></span> will show which node
+      is the current LVS master.
+    </p><p>
+      The path used for a client I/O is:
+      </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
+           Client sends request packet to LVSMASTER.
+         </p></li><li class="listitem"><p>
+           LVSMASTER passes the request on to one node across the
+           internal network.
+         </p></li><li class="listitem"><p>
+           Selected node processes the request.
+         </p></li><li class="listitem"><p>
+           Node responds back to client.
+         </p></li></ol></div><p>
+    </p><p>
+      This means that all incoming traffic to the cluster will pass
+      through one physical node, which limits scalability. You can
+      send more data to the LVS address that one physical node can
+      multiplex. This means that you should not use LVS if your I/O
+      pattern is write-intensive since you will be limited in the
+      available network bandwidth that node can handle.  LVS does work
+      very well for read-intensive workloads where only smallish READ
+      requests are going through the LVSMASTER bottleneck and the
+      majority of the traffic volume (the data in the read replies)
+      goes straight from the processing node back to the clients. For
+      read-intensive i/o patterns you can achieve very high throughput
+      rates in this mode.
+    </p><p>
+      Note: you can use LVS and public addresses at the same time.
+    </p><p>
+      If you use LVS, you must have a permanent address configured for
+      the public interface on each node. This address must be routable
+      and the cluster nodes must be configured so that all traffic
+      back to client hosts are routed through this interface. This is
+      also required in order to allow samba/winbind on the node to
+      talk to the domain controller.  This LVS IP address can not be
+      used to initiate outgoing traffic.
+    </p><p>
+      Make sure that the domain controller and the clients are
+      reachable from a node <span class="emphasis"><em>before</em></span> you enable
+      LVS.  Also ensure that outgoing traffic to these hosts is routed
+      out through the configured public interface.
+    </p><div class="refsect2"><a name="idm167"></a><h3>Configuration</h3><p>
+       To activate LVS on a CTDB node you must specify the
+       <code class="varname">CTDB_LVS_PUBLIC_IFACE</code>,
+       <code class="varname">CTDB_LVS_PUBLIC_IP</code> and
+       <code class="varname">CTDB_LVS_NODES</code> configuration variables.
+       <code class="varname">CTDB_LVS_NODES</code> specifies a file containing
+       the private address of all nodes in the current node's LVS
+       group.
+      </p><p>
+       Example:
+       </p><pre class="screen">
+       </pre><p>
+      </p><p>
+       Example <code class="filename">/usr/local/etc/ctdb/lvs_nodes</code>:
+      </p><pre class="screen">
+      </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 from being
+       the LVS master node:
+      </p><pre class="screen">
+ slave-only
+      </pre></div></div><div class="refsect1"><a name="idm183"></a><h2>TRACKING AND RESETTING TCP CONNECTIONS</h2><p>
+      CTDB tracks TCP connections from clients to public IP addresses,
+      on known ports.  When an IP address moves from one node to
+      another, all existing TCP connections to that IP address are
+      reset.  The node taking over this IP address will also send
+      gratuitous ARPs (for IPv4, or neighbour advertisement, for
+      IPv6).  This allows clients to reconnect quickly, rather than
+      waiting for TCP timeouts, which can be very long.
+    </p><p>
+      It is important that established TCP connections do not survive
+      a release and take of a public IP address on the same node.
+      Such connections can get out of sync with sequence and ACK
+      numbers, potentially causing a disruptive ACK storm.
+    </p></div><div class="refsect1"><a name="idm187"></a><h2>NAT GATEWAY</h2><p>
+      NAT gateway (NATGW) is an optional feature that is used to
+      configure fallback routing for nodes.  This allows cluster nodes
+      to connect to external services (e.g. DNS, AD, NIS and LDAP)
+      when they do not host any public addresses (e.g. when they are
+      unhealthy).
+    </p><p>
+      This also applies to node startup because CTDB marks nodes as
+      UNHEALTHY until they have passed a "monitor" event.  In this
+      context, NAT gateway helps to avoid a "chicken and egg"
+      situation where a node needs to access an external service to
+      become healthy.
+    </p><p>
+      Another way of solving this type of problem is to assign an
+      extra static IP address to a public interface on every node.
+      This is simpler but it uses an extra IP address per node, while
+      NAT gateway generally uses only one extra IP address.
+    </p><div class="refsect2"><a name="idm192"></a><h3>Operation</h3><p>
+       One extra NATGW public address is assigned on the public
+       network to each NATGW group.  Each NATGW group is a set of
+       nodes in the cluster that shares the same NATGW address to
+       talk to the outside world.  Normally there would only be one
+       NATGW group spanning an entire cluster, but in situations
+       where one CTDB cluster spans multiple physical sites it might
+       be useful to have one NATGW group for each site.
+      </p><p>
+       There can be multiple NATGW groups in a cluster but each node
+       can only be member of one NATGW group.
+      </p><p>
+       In each NATGW group, one of the nodes is selected by CTDB to
+       be the NATGW master and the other nodes are consider to be
+       NATGW slaves.  NATGW slaves establish a fallback default route
+       to the NATGW master via the private network.  When a NATGW
+       slave hosts no public IP addresses then it will use this route
+       for outbound connections.  The NATGW master hosts the NATGW
+       public IP address and routes outgoing connections from
+       slave nodes via this IP address.  It also establishes a
+       fallback default route.
+      </p></div><div class="refsect2"><a name="idm197"></a><h3>Configuration</h3><p>
+       NATGW is usually configured similar to the following example configuration:
+      </p><pre class="screen">
+      </pre><p>
+       Normally any node in a NATGW group can act as the NATGW
+       master.  Some configurations may have special nodes that lack
+       connectivity to a public network.  In such cases, those nodes
+       can be flagged with the "slave-only" option in the
+       <code class="varname">CTDB_NATGW_NODES</code> file to limit the NATGW
+       functionality of those nodes.
+      </p><p>
+       See the <em class="citetitle">NAT GATEWAY</em> section in
+       <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> for more details of
+       NATGW configuration.
+      </p></div><div class="refsect2"><a name="idm208"></a><h3>Implementation details</h3><p>
+       When the NATGW functionality is used, one of the nodes is
+       selected to act as a NAT gateway for all the other nodes in
+       the group when they need to communicate with the external
+       services.  The NATGW master is selected to be a node that is
+       most likely to have usable networks.
+      </p><p>
+       The NATGW master hosts the NATGW public IP address
+       <code class="varname">CTDB_NATGW_PUBLIC_IP</code> on the configured public
+       interfaces <code class="varname">CTDB_NATGW_PUBLIC_IFACE</code> and acts as
+       a router, masquerading outgoing connections from slave nodes
+       via this IP address.  If
+       <code class="varname">CTDB_NATGW_DEFAULT_GATEWAY</code> is set then it
+       also establishes a fallback default route to the configured
+       this gateway with a metric of 10.  A metric 10 route is used
+       so it can co-exist with other default routes that may be
+       available.
+      </p><p>
+       A NATGW slave establishes its fallback default route to the
+       NATGW master via the private network
+       <code class="varname">CTDB_NATGW_PRIVATE_NETWORK</code>with a metric of 10.
+       This route is used for outbound connections when no other
+       default route is available because the node hosts no public
+       addresses.  A metric 10 routes is used so that it can co-exist
+       with other default routes that may be available when the node
+       is hosting public addresses.
+      </p><p>
+       <code class="varname">CTDB_NATGW_STATIC_ROUTES</code> can be used to
+       have NATGW create more specific routes instead of just default
+       routes.
+      </p><p>
+       This is implemented in the <code class="filename">11.natgw</code>
+       eventscript.  Please see the eventscript file and the
+       <em class="citetitle">NAT GATEWAY</em> section in
+       <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> for more details.
+      </p></div></div><div class="refsect1"><a name="idm225"></a><h2>POLICY ROUTING</h2><p>
+      Policy routing is an optional CTDB feature to support complex
+      network topologies.  Public addresses may be spread across
+      several different networks (or VLANs) and it may not be possible
+      to route packets from these public addresses via the system's
+      default route.  Therefore, CTDB has support for policy routing
+      via the <code class="filename">13.per_ip_routing</code> eventscript.
+      This allows routing to be specified for packets sourced from
+      each public address.  The routes are added and removed as CTDB
+      moves public addresses between nodes.
+    </p><div class="refsect2"><a name="idm229"></a><h3>Configuration variables</h3><p>
+       There are 4 configuration variables related to policy routing:
+       <code class="varname">CTDB_PER_IP_ROUTING_CONF</code>,
+       <code class="varname">CTDB_PER_IP_ROUTING_RULE_PREF</code>,
+       <code class="varname">CTDB_PER_IP_ROUTING_TABLE_ID_LOW</code>,
+       <code class="varname">CTDB_PER_IP_ROUTING_TABLE_ID_HIGH</code>.  See the
+       <em class="citetitle">POLICY ROUTING</em> section in
+       <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> for more details.
+      </p></div><div class="refsect2"><a name="idm240"></a><h3>Configuration</h3><p>
+       The format of each line of
+       <code class="varname">CTDB_PER_IP_ROUTING_CONF</code> is:
+      </p><pre class="screen">
+&lt;public_address&gt; &lt;network&gt; [ &lt;gateway&gt; ]
+      </pre><p>
+       Leading whitespace is ignored and arbitrary whitespace may be
+       used as a separator.  Lines that have a "public address" item
+       that doesn't match an actual public address are ignored.  This
+       means that comment lines can be added using a leading
+       character such as '#', since this will never match an IP
+       address.
+      </p><p>
+       A line without a gateway indicates a link local route.
+      </p><p>
+       For example, consider the configuration line:
+      </p><pre class="screen">
+      </pre><p>
+       If the corresponding public_addresses line is:
+      </p><pre class="screen">
+     eth2,eth3
+      </pre><p>
+       <code class="varname">CTDB_PER_IP_ROUTING_RULE_PREF</code> is 100, and
+       CTDB adds the address to eth2 then the following routing
+       information is added:
+      </p><pre class="screen">
+  ip rule add from pref 100 table ctdb.
+  ip route add dev eth2 table ctdb.
+      </pre><p>  
+       This causes traffic from to go via
+       eth2.
+      </p><p>
+       The <span class="command"><strong>ip rule</strong></span> command will show (something
+       like - depending on other public addresses and other routes on
+       the system):
+      </p><pre class="screen">
+  0:           from all lookup local 
+  100:         from lookup ctdb.
+  32766:       from all lookup main 
+  32767:       from all lookup default 
+      </pre><p>
+       <span class="command"><strong>ip route show table ctdb.</strong></span> will show:
+      </p><pre class="screen">
+ dev eth2 scope link
+      </pre><p>
+       The usual use for a line containing a gateway is to add a
+       default route corresponding to a particular source address.
+       Consider this line of configuration:
+      </p><pre class="screen">
+      </pre><p>
+       In the situation described above this will cause an extra
+       routing command to be executed:
+      </p><pre class="screen">
+  ip route add via dev eth2 table ctdb.
+      </pre><p>
+       With both configuration lines, <span class="command"><strong>ip route show table
+       ctdb.</strong></span> will show:
+      </p><pre class="screen">
+ dev eth2 scope link 
+  default via dev eth2 
+      </pre></div><div class="refsect2"><a name="idm268"></a><h3>Sample configuration</h3><p>
+       Here is a more complete example configuration.
+      </p><pre class="screen">
+ eth2,eth3
+ eth2,eth3
+      </pre><p>
+       The routes local packets as expected, the default route is as
+       previously discussed, but packets to are
+       routed via the alternate gateway
+      </p></div></div><div class="refsect1"><a name="idm273"></a><h2>NOTIFICATION SCRIPT</h2><p>
+      When certain state changes occur in CTDB, it can be configured
+      to perform arbitrary actions via a notification script.  For
+      example, sending SNMP traps or emails when a node becomes
+      unhealthy or similar.
+    </p><p>
+      This is activated by setting the
+      <code class="varname">CTDB_NOTIFY_SCRIPT</code> configuration variable.
+      The specified script must be executable.  
+    </p><p>
+      Use of the provided <code class="filename">/usr/local/etc/ctdb/</code>
+      script is recommended.  It executes files in
+      <code class="filename">/usr/local/etc/ctdb/notify.d/</code>.
+    </p><p>
+      CTDB currently generates notifications after CTDB changes to
+      these states:
+    </p><table border="0" summary="Simple list" class="simplelist"><tr><td>init</td></tr><tr><td>setup</td></tr><tr><td>startup</td></tr><tr><td>healthy</td></tr><tr><td>unhealthy</td></tr></table></div><div class="refsect1"><a name="idm288"></a><h2>DEBUG LEVELS</h2><p>
+      Valid values for DEBUGLEVEL are:
+    </p><table border="0" summary="Simple list" class="simplelist"><tr><td>ERR</td></tr><tr><td>WARNING</td></tr><tr><td>NOTICE</td></tr><tr><td>INFO</td></tr><tr><td>DEBUG</td></tr></table></div><div class="refsect1"><a name="idm297"></a><h2>REMOTE CLUSTER NODES</h2><p>
+It is possible to have a CTDB cluster that spans across a WAN link. 
+For example where you have a CTDB cluster in your datacentre but you also
+want to have one additional CTDB node located at a remote branch site.
+This is similar to how a WAN accelerator works but with the difference 
+that while a WAN-accelerator often acts as a Proxy or a MitM, in 
+the ctdb remote cluster node configuration the Samba instance at the remote site
+IS the genuine server, not a proxy and not a MitM, and thus provides 100%
+correct CIFS semantics to clients.
+    </p><p>
+       See the cluster as one single multihomed samba server where one of
+       the NICs (the remote node) is very far away.
+    </p><p>
+       NOTE: This does require that the cluster filesystem you use can cope
+       with WAN-link latencies. Not all cluster filesystems can handle
+       WAN-link latencies! Whether this will provide very good WAN-accelerator
+       performance or it will perform very poorly depends entirely
+       on how optimized your cluster filesystem is in handling high latency
+       for data and metadata operations.
+    </p><p>
+       To activate a node as being a remote cluster node you need to set
+       the following two parameters in /etc/sysconfig/ctdb  for the remote node:
+        </p><pre class="screen">
+       </pre><p>
+    </p><p>
+       Verify with the command "ctdb getcapabilities" that that node no longer
+       has the recmaster or the lmaster capabilities.
+    </p></div><div class="refsect1"><a name="idm305"></a><h2>SEE ALSO</h2><p>
+      <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdbd_wrapper</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdb_diagnostics</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ltdbtool</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">onnode</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ping_pong</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdb-statistics</span>(7)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span>,
+      <a class="ulink" href="" target="_top"></a>
+    </p></div></div></body></html>
diff --git a/web/manpages/4.8/ctdb_diagnostics.1.html b/web/manpages/4.8/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="" target="_top"></a>
+    </p></div></div></body></html>
diff --git a/web/manpages/4.8/ctdb_mutex_ceph_rados_helper.7.html b/web/manpages/4.8/ctdb_mutex_ceph_rados_helper.7.html
new file mode 100644 (file)
index 0000000..d8cc910
--- /dev/null
@@ -0,0 +1,26 @@
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Ceph RADOS Mutex</title><meta name="generator" content="DocBook XSL Stylesheets V1.79.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdb_mutex_ceph_rados_helper.7"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb_mutex_ceph_rados_helper &#8212; Ceph RADOS cluster mutex helper</p></div><div class="refsect1"><a name="idm10"></a><h2>DESCRIPTION</h2><p>
+      ctdb_mutex_ceph_rados_helper can be used as a recovery lock provider
+      for CTDB.  When configured, split brain avoidance during CTDB recovery
+      will be handled using locks against an object located in a Ceph RADOS
+      pool.
+      To enable this functionality, include the following line in your CTDB
+      config file:
+    </p><pre class="screen">
+CTDB_RECOVERY_LOCK="!ctdb_mutex_ceph_rados_helper [Cluster] [User] [Pool] [Object]"
+Cluster: Ceph cluster name (e.g. ceph)
+User: Ceph cluster user name (e.g. client.admin)
+Pool: Ceph RADOS pool name
+Object: Ceph RADOS object name
+    </pre><p>
+      The Ceph cluster <em class="parameter"><code>Cluster</code></em> must be up and running,
+      with a configuration, and keyring file for <em class="parameter"><code>User</code></em>
+      located in a librados default search path (e.g. /etc/ceph/).
+      <em class="parameter"><code>Pool</code></em> must already exist.
+    </p></div><div class="refsect1"><a name="idm18"></a><h2>SEE ALSO</h2><p>
+      <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
+      <a class="ulink" href="" target="_top"></a>
+    </p></div></div></body></html>
diff --git a/web/manpages/4.8/ctdbd.1.html b/web/manpages/4.8/ctdbd.1.html
new file mode 100644 (file)
index 0000000..82b1cfb
--- /dev/null
@@ -0,0 +1,265 @@
+<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="idm26"></a><h2>GENERAL OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-d, --debug=<em class="parameter"><code>DEBUGLEVEL</code></em></span></dt><dd><p>
+           This option sets the debug level to DEBUGLEVEL, which
+           controls what will be written by the logging
+           subsystem.  The default is 2.
+         </p><p>
+           See the <em class="citetitle">DEBUG LEVELS</em> section in
+           <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
+           information.
+         </p></dd><dt><span class="term">--dbdir=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
+           DIRECTORY on local storage where ctdbd keeps a local copy of
+           TDB databases.  This directory is local for each node and
+           should not be stored on the shared cluster filesystem.
+         </p><p>
+           Defaults to <code class="filename">/usr/local/var/lib/ctdb</code>.
+         </p></dd><dt><span class="term">--dbdir-persistent=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
+           DIRECTORY on local storage where ctdbd keeps a local copy of
+           persistent TDB databases.  This directory is local for each
+           node and should not be stored on the shared cluster
+           filesystem.
+         </p><p>
+           Defaults to <code class="filename">/usr/local/var/lib/ctdb/persistent</code>.
+         </p></dd><dt><span class="term">--dbdir-state=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
+           DIRECTORY on local storage where ctdbd keep internal state
+           TDB files.  This directory is local for each node and
+           should not be stored on the shared cluster filesystem.
+         </p><p>
+           Defaults to <code class="filename">/usr/local/var/lib/ctdb/state</code>.
+         </p></dd><dt><span class="term">--event-script-dir=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
+           DIRECTORY where the CTDB event scripts are stored.  See the
+           <em class="citetitle">EVENT SCRIPTS</em> section in
+           <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more information.
+         </p><p>
+           Default is <code class="envar">CTDB_BASE</code>/events.d, so usually
+           <code class="filename">/usr/local/etc/ctdb/events.d</code>, which is part of
+           the CTDB installation.
+         </p></dd><dt><span class="term">--listen=<em class="parameter"><code>IPADDR</code></em></span></dt><dd><p>
+           IPADDR is the private IP address that ctdbd will bind to.
+         </p><p>
+           By default ctdbd will select the first address from the
+           nodes list that in can bind to.  See also
+           <em class="citetitle">--nlist</em>.
+         </p><p>
+           This option is only required when automatic address
+           detection can not be used.  This can be the case when
+           running multiple ctdbd daemons/nodes on the same physical
+           host (usually for testing), using InfiniBand for the
+           private network or on Linux when sysctl
+           net.ipv4.ip_nonlocal_bind=1.
+         </p></dd><dt><span class="term">--logging=<em class="parameter"><code>STRING</code></em></span></dt><dd><p>
+           STRING specifies where ctdbd will write its log. The
+           default is
+           file:<code class="filename">/usr/local/var/log/log.ctdb</code>.
+         </p><p>
+           Valid values are:
+         </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">file:<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+                 FILENAME where ctdbd will write its log. This is usually
+                 <code class="filename">/usr/local/var/log/log.ctdb</code>.
+               </p></dd><dt><span class="term">syslog[<span class="optional">:<em class="parameter"><code>METHOD</code></em></span>]</span></dt><dd><p>
+                 CTDB will log to syslog.  By default this will use
+                 the syslog(3) API.
+                </p><p>
+                 Under heavy loads syslog(3) can block if the syslog
+                 daemon processes messages too slowly.  This can
+                 cause CTDB to block when logging.
+               </p><p>
+                 If METHOD is specified then it specifies an
+                 extension that causes logging to be done in a
+                 non-blocking mode.  Note that <span class="emphasis"><em>this may
+                 cause messages to be dropped</em></span>.  METHOD
+                 must be one of:
+               </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">nonblocking</span></dt><dd><p>
+                       CTDB will log to syslog via
+                       <code class="filename">/dev/log</code> in non-blocking
+                       mode.
+                     </p></dd><dt><span class="term">udp</span></dt><dd><p>
+                       CTDB will log to syslog via UDP to
+                       localhost:514.  The syslog daemon must be
+                       configured to listen on (at least)
+                       localhost:514.  Most syslog daemons will log
+                       the messages with hostname "localhost" - this
+                       is a limitation of the implementation, for
+                       compatibility with more syslog daemons.
+                     </p></dd><dt><span class="term">udp-rfc5424</span></dt><dd><p>
+                       As with "udp" but messages are sent in RFC5424
+                       format.  This method will log the correct
+                       hostname but is not as widely implemented in
+                       syslog daemons.
+                     </p></dd></dl></div></dd></dl></div></dd><dt><span class="term">--max-persistent-check-errors=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
+           NUM specifies the maximum number of health check failures
+           allowed for persistent databases during startup.
+         </p><p>
+           The default value is 0.  Setting this to non-zero allows a
+           node with unhealthy persistent databases to startup and
+           join the cluster as long as there is another node with
+           healthy persistent databases.
+         </p></dd><dt><span class="term">--nlist=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+           FILENAME containing a list of the private IP addresses, one
+           per line, for each node in the cluster.  This file
+           <span class="emphasis"><em>must be the same on each node</em></span> in the
+           cluster.
+         </p><p>
+           Default is <code class="envar">CTDB_BASE</code>/nodes, so usually
+           <code class="filename">/usr/local/etc/ctdb/nodes</code>.
+         </p></dd><dt><span class="term">--no-lmaster</span></dt><dd><p>
+           This argument specifies that this node can NOT become an lmaster
+           for records in the database. This means that it will never show up
+           in the vnnmap. This feature is primarily used for making a cluster
+           span across a WAN link and use CTDB as a WAN-accelerator.
+         </p><p>
+           Please see the <em class="citetitle">REMOTE CLUSTER NODES</em>
+           section in <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
+           information.
+         </p></dd><dt><span class="term">--no-recmaster</span></dt><dd><p>
+           This argument specifies that this node can NOT become a recmaster
+           for the database. This feature is primarily used for making a cluster
+           span across a WAN link and use CTDB as a WAN-accelerator.
+         </p><p>
+           Please see the <em class="citetitle">REMOTE CLUSTER NODES</em>
+           section in <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
+           information.
+         </p></dd><dt><span class="term">--notification-script=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+           FILENAME specifying a script to be invoked by ctdbd when
+           certain state changes occur.
+         </p><p>
+           This file is usually
+           <code class="filename">/usr/local/etc/ctdb/</code>.
+         </p><p>
+           Please see the <em class="citetitle">NOTIFICATION SCRIPT</em>
+           section in <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
+           information.
+         </p></dd><dt><span class="term">--pidfile=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+           FILENAME for file containing process ID of main CTDB
+           daemon.  This file is automatically created and removed by
+           CTDB.
+         </p><p>
+           The default is to not create a PID file.
+         </p></dd><dt><span class="term">--public_addresses=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+           FILENAME specifying a file containing the public IP
+           addresses to use on the cluster when CTDB should use IP
+           takeover. This file contains a list of IP addresses,
+           netmasks and interfaces.  CTDB will distribute these public
+           IP addresses appropriately across the available nodes.
+         </p><p>
+           The IP addresses specified in this file can differ across
+           nodes.
+         </p><p>
+           This is usually the file
+           <code class="filename">/usr/local/etc/ctdb/public_addresses</code>
+         </p></dd><dt><span class="term">--public-interface=<em class="parameter"><code>INTERFACE</code></em></span></dt><dd><p>
+           Default INTERFACE on which to attach public IP addresses.
+         </p><p>
+           When using public IP addresses, this is only required if
+           interfaces are not explicitly specified in the public
+           addresses file.
+         </p></dd><dt><span class="term">--reclock=<em class="parameter"><code>LOCK</code></em></span></dt><dd><p>
+           LOCK specifies the cluster-wide mutex used to detect and
+           prevent a partitioned cluster (or "split brain").
+         </p><p>
+           For information about the recovery lock please see the
+           <em class="citetitle">RECOVERY LOCK</em> section in
+           <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
+         </p></dd><dt><span class="term">--start-as-disabled</span></dt><dd><p>
+           This makes ctdbd start in the DISABLED state.
+         </p><p>
+           To allow the node to host public IP addresses and
+           services, it must be manually enabled using the
+           <span class="command"><strong>ctdb enable</strong></span> command.
+         </p><p>
+           Please see the <em class="citetitle">NODE STATES</em> section
+           in <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
+           information about the DISABLED state.
+         </p></dd><dt><span class="term">--start-as-stopped</span></dt><dd><p>
+           This makes ctdbd start in the STOPPED state.
+         </p><p>
+           To allow the node to take part in the cluster it must be
+           manually continued with the the <span class="command"><strong>ctdb
+           enable</strong></span> command.
+         </p><p>
+           Please see the <em class="citetitle">NODE STATES</em> section
+           in <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
+           information about the STOPPED state.
+         </p></dd><dt><span class="term">--transport=tcp|infiniband</span></dt><dd><p>
+           This option specifies which transport to use for ctdbd
+           internode communications. The default is "tcp".
+         </p><p>
+           The "infiniband" support is not regularly tested.
+         </p></dd><dt><span class="term">-?, --help</span></dt><dd><p>
+           Display a summary of options.
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm223"></a><h2>DEBUGGING OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-i, --interactive</span></dt><dd><p>
+           Enable interactive mode.  This will make ctdbd run in the
+           foreground and not detach from the terminal.  By default
+           ctdbd will detach itself and run in the background as a
+           daemon.
+         </p></dd><dt><span class="term">--nopublicipcheck</span></dt><dd><p>
+           This option is used when testing with multiple local
+           daemons on a single machine.  It disables checks related
+           to public IP addresses.
+         </p></dd><dt><span class="term">--nosetsched</span></dt><dd><p>
+           This is a debugging option. This option is only used when
+           debugging ctdbd.
+         </p><p>
+           Normally ctdbd will change its scheduler to run as a
+           real-time process. This is the default mode for a normal
+           ctdbd operation to gurarantee that ctdbd always gets the CPU
+           cycles that it needs.
+         </p><p>
+           This option is used to tell ctdbd to
+           <span class="emphasis"><em>not</em></span> run as a real-time process and
+           instead run ctdbd as a normal userspace process.  This is
+           useful for debugging and when you want to run ctdbd under
+           valgrind or gdb. (You don't want to attach valgrind or gdb
+           to a real-time process.)
+         </p></dd><dt><span class="term">--socket=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+           FILENAME specifies the name of the Unix domain socket that
+           ctdbd will create. This socket is used by local clients to
+           communicate with ctdbd.
+         </p><p>
+           The default is <code class="filename">/usr/local/var/run/ctdb/ctdbd.socket</code>.
+           You only need to use this option if you plan to run
+           multiple ctdbd daemons on the same physical host, usually
+           for testing.
+         </p></dd><dt><span class="term">--script-log-level=<em class="parameter"><code>DEBUGLEVEL</code></em></span></dt><dd><p>
+           This option sets the debug level of event script output to
+           DEBUGLEVEL.  The default is ERR.
+         </p><p>
+           See the <em class="citetitle">DEBUG LEVELS</em> section in
+           <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for more
+           information.
+         </p></dd><dt><span class="term">--sloppy-start</span></dt><dd><p>
+           This is debugging option.  This speeds up the initial
+           recovery during startup at the expense of some consistency
+           checking.  <span class="emphasis"><em>Don't use this option in
+           production</em></span>.
+         </p></dd><dt><span class="term">--torture</span></dt><dd><p>
+           This option is only used for development and testing of
+           CTDB.  It adds artificial errors and failures to the
+           common codepaths in ctdbd to verify that ctdbd can recover
+           correctly from failures.
+         </p><p>
+           <span class="emphasis"><em>Do not use this option</em></span> unless you are
+           developing and testing new functionality in CTDB.
+         </p></dd><dt><span class="term">--valgrinding</span></dt><dd><p>
+           This is a debugging option. This option is only used when
+           debugging ctdbd.  This enables additional debugging
+           capabilities and implies --nosetsched.
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm273"></a><h2>SEE ALSO</h2><p>
+      <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdbd_wrapper</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">onnode</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span>,
+      <a class="ulink" href="" target="_top"></a>
+    </p></div></div></body></html>
similarity index 92%
rename from web/manpages/ctdbd.conf.5.html
rename to web/manpages/4.8/ctdbd.conf.5.html
index e9e7c02..e249fb6 100644 (file)
@@ -65,7 +65,7 @@
            OPTIONS is a comma-separated list of any permissible
            options to the tmpfs filesystem.  The only pre-specified
            default is <code class="option">mode=700</code>, which can
-           overriden by specifying <code class="option">mode</code> in
+           overridden by specifying <code class="option">mode</code> in
            OPTIONS.  It probably makes sense to specify a maximum
            <code class="option">size</code>.
@@ -486,6 +486,24 @@ CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000
              Default is the included
              <span class="command"><strong>nfs-linux-kernel-callout</strong></span>.
+           </p></dd><dt><span class="term">CTDB_NFS_CHECKS_DIR=<em class="parameter"><code>DIRECTORY</code></em></span></dt><dd><p>
+             Specifies the path to a DIRECTORY containing files that
+             describe how to monitor the responsiveness of NFS RPC
+             services.  See the README file for this directory for an
+             explanation of the contents of these "check" files.
+           </p><p>
+             CTDB_NFS_CHECKS_DIR can be used to point to different
+             sets of checks for different NFS servers.
+           </p><p>
+             One way of using this is to have it point to, say,
+             <code class="filename">/usr/local/etc/ctdb/nfs-checks-enabled.d</code>
+             and populate it with symbolic links to the desired check
+             files.  This avoids duplication and is upgrade-safe.
+           </p><p>
+             Default is
+             <code class="filename">/usr/local/etc/ctdb/nfs-checks.d</code>,
+             which contains NFS RPC checks suitable for Linux kernel
+             NFS.
            </p></dd><dt><span class="term">CTDB_NFS_SKIP_SHARE_CHECK=yes|no</span></dt><dd><p>
              As part of monitoring, should CTDB skip the check for
              the existence of each directory exported via NFS.  This
@@ -515,16 +533,16 @@ CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000
            </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="idm140600394743504"></a><h3>APACHE HTTPD</h3><p>
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm564"></a><h3>APACHE HTTPD</h3><p>
        CTDB can manage the Apache web server.
-      </p><div class="refsect3"><a name="idm140600394742480"></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="idm567"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">41.httpd</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_HTTPD=yes|no</span></dt><dd><p>
              Should CTDB manage the Apache web server?
              Default is no.
-           </p></dd></dl></div></div><div class="refsect2"><a name="idm140600394737904"></a><h3>CLAMAV</h3><p>
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm578"></a><h3>CLAMAV</h3><p>
        CTDB has support to manage the popular anti-virus daemon
-      </p><div class="refsect3"><a name="idm140600394736784"></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="idm581"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">31.clamd</code></td></tr></table><p>
          This eventscript is not enabled by default.  Use
          <span class="command"><strong>ctdb enablescript</strong></span> to enable it.
        </p></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_CLAMD=yes|no</span></dt><dd><p>
@@ -535,9 +553,9 @@ CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000
              FILENAME is the socket to monitor ClamAV.
              No default.
-           </p></dd></dl></div></div><div class="refsect2"><a name="idm140600394728704"></a><h3>ISCSI</h3><p>
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm600"></a><h3>ISCSI</h3><p>
        CTDB has support for managing the Linux iSCSI tgtd service.
-      </p><div class="refsect3"><a name="idm140600394727600"></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="idm603"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">70.iscsi</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_ISCSI=yes|no</span></dt><dd><p>
              Should CTDB manage iSCSI tgtd?
              Default is no.
@@ -546,23 +564,23 @@ CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000
              tgtd for each public IP address.
              No default.
-           </p></dd></dl></div></div><div class="refsect2"><a name="idm140600394720480"></a><h3>MULTIPATHD</h3><p>
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm620"></a><h3>MULTIPATHD</h3><p>
        CTDB can monitor multipath devices to ensure that active paths
        are available.
-      </p><div class="refsect3"><a name="idm140600394719360"></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="idm623"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">20.multipathd</code></td></tr></table><p>
          This eventscript is not enabled by default.  Use
          <span class="command"><strong>ctdb enablescript</strong></span> to enable it.
        </p></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MONITOR_MPDEVICES=<em class="parameter"><code>MP-DEVICE-LIST</code></em></span></dt><dd><p>
              MP-DEVICE-LIST is a list of multipath devices for CTDB to monitor?
              No default.
-           </p></dd></dl></div></div><div class="refsect2"><a name="idm140600394713104"></a><h3>VSFTPD</h3><p>
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm637"></a><h3>VSFTPD</h3><p>
        CTDB can manage the vsftpd FTP server.
-      </p><div class="refsect3"><a name="idm140600394712080"></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="idm640"></a><h4>Eventscript</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">40.vsftpd</code></td></tr></table></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGES_VSFTPD=yes|no</span></dt><dd><p>
              Should CTDB manage the vsftpd FTP server?
              Default is no.
-           </p></dd></dl></div></div><div class="refsect2"><a name="idm140600394707504"></a><h3>
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm651"></a><h3>
        CTDB can experience seemingly random (performance and other)
@@ -575,7 +593,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="idm140600394705520"></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="idm655"></a><h4>Eventscripts</h4><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">05.system</code></td></tr></table><p>
          Filesystem and memory usage monitoring is in
          <code class="filename">05.system</code>.
        </p></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MONITOR_FILESYSTEM_USAGE=<em class="parameter"><code>FS-LIMIT-LIST</code></em></span></dt><dd><p>
@@ -614,7 +632,7 @@ CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000
              Default is 25, so warnings will be logged when swap
              usage reaches 25%.
-           </p></dd></dl></div></div><div class="refsect2"><a name="idm140600394687360"></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="idm694"></a><h3>MISCELLANEOUS SERVICE-RELATED CONFIGURATION</h3><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MANAGED_SERVICES=<em class="parameter"><code>SERVICE-LIST</code></em></span></dt><dd><p>
              SERVICE-LIST is a space-separated list of SERVICEs that
              CTDB should manage.  This can be used as an alternative
              to the
@@ -622,12 +640,7 @@ CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000
              No default.
-           </p></dd><dt><span class="term">CTDB_SERVICE_AUTOSTARTSTOP=yes|no</span></dt><dd><p>
-             When CTDB should start and stop services if they become
-             managed or unmanaged.
-           </p><p>
-             Default is no.
-           </p></dd></dl></div></div></div><div class="refsect1"><a name="idm140600394680832"></a><h2>
+           </p></dd></dl></div></div></div><div class="refsect1"><a name="idm705"></a><h2>
       CTDB tunables (see
@@ -643,7 +656,7 @@ CTDB_SET_<em class="replaceable"><code>TUNABLE</code></em>=<em class="replaceabl
       </p><pre class="screen">
-    </p></div><div class="refsect1"><a name="idm140600394676048"></a><h2>
+    </p></div><div class="refsect1"><a name="idm716"></a><h2>
       Variable in this section are for debugging and testing CTDB.
@@ -722,12 +735,6 @@ CTDB_SET_MonitorInterval=20
            This uses the <code class="filename">99.timeout</code> eventscript.
            Default is no.
-         </p></dd><dt><span class="term">CTDB_SCRIPT_DEBUGLEVEL=<em class="parameter"><code>DEBUGLEVEL</code></em></span></dt><dd><p>
-           DEBUGLEVEL is the level debugging messages printed by CTDB
-           scripts.  Setting this to a higher level (e.g. DEBUG) will
-           cause some scripts to log more messages.
-         </p><p>
-           Default is NOTICE.
          </p></dd><dt><span class="term">CTDB_SUPPRESS_COREFILE=yes|no</span></dt><dd><p>
            Whether CTDB core files should be suppressed.
@@ -750,7 +757,7 @@ CTDB_SET_MonitorInterval=20
            Defaults to <code class="filename">/usr/local/var/lib/ctdb</code>.
-         </p></dd></dl></div></div><div class="refsect1"><a name="idm140600394627632"></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="idm140600394623232"></a><h2>SEE ALSO</h2><p>
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm821"></a><h2>FILES</h2><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">/usr/local/etc/ctdb/ctdbd.conf</code></td></tr><tr><td><code class="filename">/etc/sysconfig/ctdb</code></td></tr><tr><td><code class="filename">/etc/default/ctdb</code></td></tr><tr><td><code class="filename">/usr/local/etc/ctdb/sysconfig/ctdb</code></td></tr></table></div><div class="refsect1"><a name="idm832"></a><h2>SEE ALSO</h2><p>
       <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
       <span class="citerefentry"><span class="refentrytitle">ctdbd_wrapper</span>(1)</span>,
diff --git a/web/manpages/4.8/ctdbd_wrapper.1.html b/web/manpages/4.8/ctdbd_wrapper.1.html
new file mode 100644 (file)
index 0000000..e0e3563
--- /dev/null
@@ -0,0 +1,20 @@
+<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="idm18"></a><h2>DESCRIPTION</h2><p>
+      ctdbd_wrapper is used to start or stop the main CTDB daemon.
+    </p><p>
+      <em class="replaceable"><code>PIDFILE</code></em> specifies the location of the
+      file containing the PID of the main CTDB daemon.
+    </p><p>
+      ctdbd_wrapper constructs command-line options for ctdbd from
+      configuration variables specified in
+      <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>.
+    </p><p>
+      See <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span> for an overview of CTDB.
+    </p></div><div class="refsect1"><a name="idm31"></a><h2>SEE ALSO</h2><p>
+      <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+      <a class="ulink" href="" target="_top"></a>
+    </p></div></div></body></html>
diff --git a/web/manpages/4.8/ltdbtool.1.html b/web/manpages/4.8/ltdbtool.1.html
new file mode 100644 (file)
index 0000000..a3959a7
--- /dev/null
@@ -0,0 +1,88 @@
+<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="idm19"></a><h2>DESCRIPTION</h2><p>
+      ltdbtool is a utility to manipulate CTDB's local TDB databases
+      (LTDBs) without connecting to a CTDB daemon.
+    </p><p>
+      It can be used to:
+    </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
+         dump the contents of a LTDB, optionally printing the CTDB
+           record header information,
+       </p></li><li class="listitem"><p>
+         convert between an LTDB and a non-clustered tdb
+         by adding or removing CTDB headers and
+       </p></li><li class="listitem"><p>convert between 64 and 32 bit LTDBs where the CTDB record
+         headers differ by 4 bytes of padding.
+         </p></li></ul></div></div><div class="refsect1"><a name="idm30"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-e</span></dt><dd><p>
+           Dump empty records.  These are normally excluded.
+         </p></dd><dt><span class="term">-p</span></dt><dd><p>
+           Dump with header information, similar to "ctdb catdb".
+         </p></dd><dt><span class="term">
+         -s
+         { 0  |   32  |   64 }
+       </span></dt><dd><p>
+           Specify how to determine the CTDB record header size
+           for the input database:
+           </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">0</span></dt><dd><p>no CTDB header</p></dd><dt><span class="term">32</span></dt><dd><p>CTDB header size of a 32 bit system (20 bytes)</p></dd><dt><span class="term">64</span></dt><dd><p>CTDB header size of a 64 bit system (24 bytes)</p></dd></dl></div><p>
+           The default is 32 or 64 depending on the system architecture.
+         </p></dd><dt><span class="term">
+         -o
+         { 0  |   32  |   64 }
+       </span></dt><dd><p>
+           Specify how to determine the CTDB record header size
+           for the output database, see -s.
+         </p></dd><dt><span class="term">-S <em class="parameter"><code>SIZE</code></em></span></dt><dd><p>
+           Explicitly specify the CTDB record header SIZE of the
+           input database in bytes.
+         </p></dd><dt><span class="term">-O <em class="parameter"><code>SIZE</code></em></span></dt><dd><p>
+           Explicitly specify the CTDB record header SIZE for the
+           output database in bytes.
+         </p></dd><dt><span class="term">-h</span></dt><dd><p>
+            Print help text.
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm84"></a><h2>COMMANDS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">help</span></dt><dd><p>
+           Print help text.
+         </p></dd><dt><span class="term">dump <em class="parameter"><code>IDB</code></em></span></dt><dd><p>
+           Dump the contents of an LTDB input file IDB to standard
+           output in a human-readable format.
+         </p></dd><dt><span class="term">
+         convert <em class="parameter"><code>IDB</code></em> <em class="parameter"><code>ODB</code></em>
+       </span></dt><dd><p>
+           Copy an LTDB input file IDB to output file ODB, optionally
+           adding or removing CTDB headers.
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm102"></a><h2>EXAMPLES</h2><p>
+      Print a local tdb in "tdbdump" style:
+    </p><pre class="screen">
+      ltdbtool dump idmap2.tdb.0
+    </pre><p>
+      Print a local tdb with header information similar to "ctdb catdb":
+    </p><pre class="screen">
+      ltdbtool dump -p idmap2.tdb.0
+    </pre><p>
+      Strip the CTDB headers from records:
+    </p><pre class="screen">
+      ltdbtool convert -o0 idmap2.tdb.0 idmap.tdb
+    </pre><p>
+      Strip 64 bit CTDB headers from records, running on i386:
+    </p><pre class="screen">
+      ltdbtool convert -s64 -o0 idmap2.tdb.0 idmap.tdb
+    </pre><p>
+      Strip the CTDB headers from records by piping through tdbrestore:
+    </p><pre class="screen">
+      ltdbtool dump idmap2.tdb.0 | tdbrestore idmap.tdb
+    </pre><p>
+      Convert a local tdb from a 64 bit system for usage on a 32 bit system:
+    </p><pre class="screen">
+      ltdbtool convert -s64 -o32 idmap2.tdb.0 idmap2.tdb.1
+    </pre><p>
+      Add a default header:
+    </p><pre class="screen">
+      ltdbtool convert -s0 idmap.tdb idmap2.tdb.0
+    </pre></div><div class="refsect1"><a name="idm118"></a><h2>SEE ALSO</h2><p>
+      <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">tdbdump</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">tdbrestore</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+      <a class="ulink" href="" target="_top"></a>
+    </p></div></div></body></html>
diff --git a/web/manpages/4.8/onnode.1.html b/web/manpages/4.8/onnode.1.html
new file mode 100644 (file)
index 0000000..9bb6590
--- /dev/null
@@ -0,0 +1,126 @@
+<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>
+      <em class="replaceable"><code>NODES</code></em> specifies which node(s) to run
+      a command on.  See section <em class="citetitle">NODES
+      SPECIFICATION</em> for details.
+    </p><p>
+      <em class="replaceable"><code>COMMAND</code></em> can be any shell command. The
+      onnode utility uses ssh or rsh to connect to the remote nodes
+      and run the command.
+    </p></div><div class="refsect1"><a name="idm27"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-c</span></dt><dd><p>
+            Execute COMMAND in the current working directory on the
+            specified nodes.
+         </p></dd><dt><span class="term">-f <em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+            Specify an alternative nodes FILENAME to use instead of
+            the default.  This option overrides the CTDB_NODES_FILE
+            and CTDB_NODES variables.  See the discussion of
+            <code class="filename">/usr/local/etc/ctdb/nodes</code> in the FILES section
+            for more details.
+         </p></dd><dt><span class="term">-i</span></dt><dd><p>
+           Keep standard input open, allowing data to be piped to
+           onnode.  Normally onnode closes stdin to avoid surprises
+           when scripting.  Note that this option is ignored when
+           using <code class="option">-p</code> or if <code class="envar">SSH</code> is set
+           to anything other than "ssh".
+         </p></dd><dt><span class="term">-n</span></dt><dd><p>
+            Allow nodes to be specified by name rather than node
+            numbers.  These nodes don't need to be listed in the nodes
+            file.  You can avoid the nodes file entirely by combining
+            this with <code class="code">-f /dev/null</code>.
+         </p></dd><dt><span class="term">-o <em class="parameter"><code>PREFIX</code></em></span></dt><dd><p>
+           Causes standard output from each node to be saved into a
+           file with name PREFIX.<em class="replaceable"><code>IP</code></em>.
+         </p></dd><dt><span class="term">-p</span></dt><dd><p>
+            Run COMMAND in parallel on the specified nodes.  The
+            default is to run COMMAND sequentially on each node.
+         </p></dd><dt><span class="term">-P</span></dt><dd><p>
+            Push files to nodes.  Names of files to push are specified
+            rather than the usual command.  Quoting is fragile/broken
+            - filenames with whitespace in them are not supported.
+         </p></dd><dt><span class="term">-q</span></dt><dd><p>
+            Do not print node addresses.  Normally, onnode prints
+            informational node addresses if more than one node is
+            specified.  This overrides -v.
+         </p></dd><dt><span class="term">-v</span></dt><dd><p>
+            Print node addresses even if only one node is specified.
+            Normally, onnode prints informational node addresses when
+            more than one node is specified.
+         </p></dd><dt><span class="term">-h, --help</span></dt><dd><p>
+            Show a short usage guide.
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm77"></a><h2>NODES SPECIFICATION</h2><p>
+      Nodes can be specified via numeric node numbers (from 0 to N-1)
+      or mnemonics.  Multiple nodes are specified using lists of
+      nodes, separated by commas, and ranges of numeric node numbers,
+      separated by dashes.  If nodes are specified multiple times then
+      the command will be executed multiple times on those nodes.  The
+      order of nodes is significant.
+    </p><p>
+      The following mnemonics are available:
+    </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">all</span></dt><dd><p>
+            All nodes.
+         </p></dd><dt><span class="term">any</span></dt><dd><p>
+             A node where ctdbd is running.  This semi-random but
+             there is a bias towards choosing a low numbered node.
+         </p></dd><dt><span class="term">ok | healthy</span></dt><dd><p>
+            All nodes that are not disconnected, banned, disabled or
+            unhealthy.
+         </p></dd><dt><span class="term">con | connected</span></dt><dd><p>
+            All nodes that are not disconnected.
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm98"></a><h2>EXAMPLES</h2><p>
+      The following command would show the process ID of ctdbd on all nodes
+    </p><pre class="screen">
+      onnode all ctdb getpid
+    </pre><p>
+      The following command would show the last 5 lines of log on each
+      node, preceded by the node's hostname
+    </p><pre class="screen">
+      onnode all "hostname; tail -5 /usr/local/var/log/log.ctdb"
+    </pre><p>
+      The following command would restart the ctdb service on all
+      nodes, in parallel.
+    </p><pre class="screen">
+      onnode -p all service ctdb restart
+    </pre><p>
+      The following command would run ./foo in the current working
+      directory, in parallel, on nodes 0, 2, 3 and 4.
+    </p><pre class="screen">
+      onnode -c -p 0,2-4 ./foo
+    </pre></div><div class="refsect1"><a name="idm108"></a><h2>ENVIRONMENT</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="envar">CTDB_BASE</code></span></dt><dd><p>
+           Directory containing CTDB configuration files.  The
+           default is <code class="filename">/usr/local/etc/ctdb</code>.
+         </p></dd><dt><span class="term"><code class="envar">CTDB_NODES_FILE</code></span></dt><dd><p>
+           Name of alternative nodes file to use instead of the
+           default.  See the <em class="citetitle">FILES</em> section for
+           more details.
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm123"></a><h2>FILES</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="filename">/usr/local/etc/ctdb/nodes</code></span></dt><dd><p>
+            Default file containing a list of each node's IP address
+            or hostname.
+         </p><p>
+           As above, a file specified via the <code class="option">-f</code> or
+           <code class="envar">CTDB_NODES_FILE</code> is given precedence.  If a
+           relative path is specified and no corresponding file
+           exists relative to the current directory then the file is
+           also searched for in the <code class="filename">$CTDB_BASE</code>
+           directory.
+         </p><p>
+           If <code class="envar">CTDB_NODES_FILE</code> is not set and
+           <code class="envar">CTDB_NODES</code> is set in configuration then the
+           file pointed to by <code class="envar">CTDB_NODES</code> is used.
+         </p><p>
+           Otherwise the default is
+           <code class="filename">$CTDB_BASE/nodes</code>, where
+           <code class="envar">CTDB_BASE</code> defaults to
+           <code class="filename">/usr/local/etc/ctdb</code>.
+          </p></dd><dt><span class="term"><code class="filename">/usr/local/etc/ctdb/onnode.conf</code></span></dt><dd><p>
+            If this file exists it is sourced by onnode.  The main
+            purpose is to allow the administrator to set
+            <code class="envar">SSH</code> to something other than "ssh".  In this
+            case the -t option is ignored.  For example, the
+            administrator may choose to use use rsh instead of ssh.
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm149"></a><h2>SEE ALSO</h2><p>
+      <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+      <a class="ulink" href="" target="_top"></a>
+    </p></div></div></body></html>
diff --git a/web/manpages/4.8/ping_pong.1.html b/web/manpages/4.8/ping_pong.1.html
new file mode 100644 (file)
index 0000000..79c0763
--- /dev/null
@@ -0,0 +1,37 @@
+<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="idm23"></a><h2>DESCRIPTION</h2><p>
+      ping_pong measures the byte range lock latency. It is especially
+      useful on a cluster of nodes sharing a common lock manager as it
+      will give some indication of the lock manager's performance
+      under stress.
+    </p><p>
+      FILENAME is a file on shared storage to use for byte range
+      locking tests.
+    </p><p>
+      NUM-LOCKS is the number of byte range locks, so needs to be
+      (strictly) greater than the number of nodes in the cluster.
+    </p></div><div class="refsect1"><a name="idm28"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-r</span></dt><dd><p>
+           test read performance
+         </p></dd><dt><span class="term">-w</span></dt><dd><p>
+           test write performance
+         </p></dd><dt><span class="term">-m</span></dt><dd><p>
+           use mmap
+         </p></dd><dt><span class="term">-c</span></dt><dd><p>
+           validate the locks
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm47"></a><h2>EXAMPLES</h2><p>
+      Testing lock coherence
+    </p><pre class="screen">
+      ping_pong test.dat N
+    </pre><p>
+      Testing lock coherence with lock validation
+    </p><pre class="screen">
+      ping_pong -c test.dat N
+    </pre><p>
+      Testing IO coherence
+    </p><pre class="screen">
+      ping_pong -rw test.dat N
+    </pre></div><div class="refsect1"><a name="idm55"></a><h2>SEE ALSO</h2><p>
+      <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+      <a class="ulink" href="" target="_top"></a>
+    </p></div></div></body></html>
index f5c9ff0..6a8806c 100644 (file)
@@ -1,12 +1,13 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb-etcd</title><meta name="generator" content="DocBook XSL Stylesheets V1.79.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdb-etcd.7"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb-etcd &#8212; CTDB etcd integration</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ctdb_etcd_lock</code> </p></div></div><div class="refsect1"><a name="idm139667986750976"></a><h2>DESCRIPTION</h2><p>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb-etcd</title><meta name="generator" content="DocBook XSL Stylesheets V1.79.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdb-etcd.7"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb-etcd &#8212; CTDB etcd integration</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ctdb_etcd_lock</code> </p></div></div><div class="refsect1"><a name="idm24"></a><h2>DESCRIPTION</h2><p>
       ctdb_etcd_lock is intended to be run as a mutex helper for CTDB. It
       will try to connect to an existing etcd cluster and grab a lock in that
       cluster to function as CTDB's recovery lock. Please see
       <span class="emphasis"><em>ctdb/doc/cluster_mutex_helper.txt</em></span> for details on
-      the mutex helper API. To use this, include the following line in your
-      CTDB config file:
+      the mutex helper API. To use this, include the following line in
+      the <code class="literal">[cluster]</code> section of
+      <span class="citerefentry"><span class="refentrytitle">ctdb.conf</span>(5)</span>:
     </p><pre class="screen">
+recovery lock = !/usr/local/usr/libexec/ctdb/ctdb_etcd_lock
       You can also pass "-v", "-vv", or "-vvv" to include verbose output in
       the CTDB log. Additional "v"s indicate increases in verbosity.
@@ -31,7 +32,7 @@ locks_dir = _ctdb  # where to store CTDB locks in etcd
       In addition, any keyword parameter that can be used to configure an
       etcd client may be specified and modified here. For more documentation
       on these parameters, see here:
-    </p></div><div class="refsect1"><a name="idm139667989962512"></a><h2>SEE ALSO</h2><p>
+    </p></div><div class="refsect1"><a name="idm39"></a><h2>SEE ALSO</h2><p>
       <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
       <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
diff --git a/web/manpages/ctdb-script.options.5.html b/web/manpages/ctdb-script.options.5.html
new file mode 100644 (file)
index 0000000..1305422
--- /dev/null
@@ -0,0 +1,504 @@
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb-script.options</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-script.options.5"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb-script.options &#8212; CTDB scripts configuration files</p></div><div class="refsect1"><a name="idm10"></a><h2>DESCRIPTION</h2><p>
+      Each CTDB script has 2 possible locations for its configuration options:
+    </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">
+         <code class="filename">/usr/local/etc/ctdb/script.options</code>
+       </span></dt><dd><p>
+           This is a catch-all global file for general purpose
+           scripts and for options that are used in multiple event
+           scripts.
+         </p></dd><dt><span class="term">
+         <em class="parameter"><code>SCRIPT</code></em>.options
+       </span></dt><dd><p>
+           That is, options for
+           <code class="filename"><em class="parameter"><code>SCRIPT</code></em></code> are
+           placed in a file alongside the script, with a ".script"
+           suffix added.  This style is usually recommended for event
+           scripts.
+         </p><p>
+           Options in this script-specific file override those in
+           the global file.
+         </p></dd></dl></div><p>
+      These files should include simple shell-style variable
+      assignments and shell-style comments.
+    </p></div><div class="refsect1"><a name="idm28"></a><h2>NETWORK CONFIGURATION</h2><div class="refsect2"><a name="idm30"></a><h3>10.interface</h3><p>
+       This event script handles monitoring of interfaces using by
+       public IP addresses.
+      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">
+         </span></dt><dd><p>
+             Whether one or more offline interfaces should cause a
+             monitor event to fail if there are other interfaces that
+             are up.  If this is "yes" and a node has some interfaces
+             that are down then <span class="command"><strong>ctdb status</strong></span> will
+             display the node as "PARTIALLYONLINE".
+           </p><p>
+             Note that CTDB_PARTIALLY_ONLINE_INTERFACES=yes is not
+             generally compatible with NAT gateway or LVS.  NAT
+             gateway relies on the interface configured by
+             CTDB_NATGW_PUBLIC_IFACE to be up and LVS replies on
+             CTDB_LVS_PUBLIC_IFACE to be up.  CTDB does not check if
+             these options are set in an incompatible way so care is
+             needed to understand the interaction.
+           </p><p>
+             Default is "no".
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm41"></a><h3>11.natgw</h3><p>
+       Provides CTDB's NAT gateway functionality.
+      </p><p>
+       NAT gateway is used to configure fallback routing for nodes
+       when they do not host any public IP addresses.  For example,
+       it allows unhealthy nodes to reliably communicate with
+       external infrastructure.  One node in a NAT gateway group will
+       be designated as the NAT gateway master node and other (slave)
+       nodes will be configured with fallback routes via the NAT
+       gateway master node.  For more information, see the
+       <em class="citetitle">NAT GATEWAY</em> section in
+       <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
+      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_NATGW_DEFAULT_GATEWAY=<em class="parameter"><code>IPADDR</code></em></span></dt><dd><p>
+             IPADDR is an alternate network gateway to use on the NAT
+             gateway master node.  If set, a fallback default route
+             is added via this network gateway.
+           </p><p>
+             No default.  Setting this variable is optional - if not
+             set that no route is created on the NAT gateway master
+             node.
+           </p></dd><dt><span class="term">CTDB_NATGW_NODES=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+             FILENAME contains the list of nodes that belong to the
+             same NAT gateway group.
+           </p><p>
+             File format:
+             </p><pre class="screen">
+<em class="parameter"><code>IPADDR</code></em> [<span class="optional">slave-only</span>]
+             </pre><p>
+           </p><p>
+             IPADDR is the private IP address of each node in the NAT
+             gateway group.
+           </p><p>
+             If "slave-only" is specified then the corresponding node
+             can not be the NAT gateway master node.  In this case
+             <code class="varname">CTDB_NATGW_PUBLIC_IFACE</code> and
+             <code class="varname">CTDB_NATGW_PUBLIC_IP</code> are optional and
+             unused.
+           </p><p>
+             No default, usually
+             <code class="filename">/usr/local/etc/ctdb/natgw_nodes</code> when enabled.
+           </p></dd><dt><span class="term">CTDB_NATGW_PRIVATE_NETWORK=<em class="parameter"><code>IPADDR/MASK</code></em></span></dt><dd><p>
+             IPADDR/MASK is the private sub-network that is
+             internally routed via the NAT gateway master node.  This
+             is usually the private network that is used for node
+             addresses.
+           </p><p>
+             No default.
+           </p></dd><dt><span class="term">CTDB_NATGW_PUBLIC_IFACE=<em class="parameter"><code>IFACE</code></em></span></dt><dd><p>
+             IFACE is the network interface on which the
+             CTDB_NATGW_PUBLIC_IP will be configured.
+           </p><p>
+             No default.
+           </p></dd><dt><span class="term">CTDB_NATGW_PUBLIC_IP=<em class="parameter"><code>IPADDR/MASK</code></em></span></dt><dd><p>
+             IPADDR/MASK indicates the IP address that is used for
+             outgoing traffic (originating from
+             CTDB_NATGW_PRIVATE_NETWORK) on the NAT gateway master
+             node.  This <span class="emphasis"><em>must not</em></span> be a
+             configured public IP address.
+           </p><p>
+             No default.
+           </p></dd><dt><span class="term">CTDB_NATGW_STATIC_ROUTES=<em class="parameter"><code>IPADDR/MASK[@GATEWAY]</code></em> ...</span></dt><dd><p>
+             Each IPADDR/MASK identifies a network or host to which
+             NATGW should create a fallback route, instead of
+             creating a single default route.  This can be used when
+             there is already a default route, via an interface that
+             can not reach required infrastructure, that overrides
+             the NAT gateway default route.
+           </p><p>
+             If GATEWAY is specified then the corresponding route on
+             the NATGW master node will be via GATEWAY.  Such routes
+             are created even if
+             <code class="varname">CTDB_NATGW_DEFAULT_GATEWAY</code> is not
+             specified.  If GATEWAY is not specified for some
+             networks then routes are only created on the NATGW
+             master node for those networks if
+             <code class="varname">CTDB_NATGW_DEFAULT_GATEWAY</code> is
+             specified.
+           </p><p>
+             This should be used with care to avoid causing traffic
+             to unnecessarily double-hop through the NAT gateway
+             master, even when a node is hosting public IP addresses.
+             Each specified network or host should probably have a
+             corresponding automatically created link route or static
+             route to avoid this.
+           </p><p>
+             No default.
+           </p></dd></dl></div><div class="refsect3"><a name="idm100"></a><h4>Example</h4><pre class="screen">
+       </pre><p>
+         A variation that ensures that infrastructure (ADS, DNS, ...)
+         directly attached to the public network ( is
+         always reachable would look like this:
+       </p><pre class="screen">
+       </pre><p>
+         Note that <code class="varname">CTDB_NATGW_DEFAULT_GATEWAY</code> is
+         not specified.
+       </p></div></div><div class="refsect2"><a name="idm107"></a><h3>13.per_ip_routing</h3><p>
+       Provides CTDB's policy routing functionality.
+      </p><p>
+       A node running CTDB may be a component of a complex network
+       topology.  In particular, public addresses may be spread
+       across several different networks (or VLANs) and it may not be
+       possible to route packets from these public addresses via the
+       system's default route.  Therefore, CTDB has support for
+       policy routing via the <code class="filename">13.per_ip_routing</code>
+       eventscript.  This allows routing to be specified for packets
+       sourced from each public address.  The routes are added and
+       removed as CTDB moves public addresses between nodes.
+      </p><p>
+       For more information, see the <em class="citetitle">POLICY
+       ROUTING</em> section in
+       <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>.
+      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_PER_IP_ROUTING_CONF=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
+             FILENAME contains elements for constructing the desired
+             routes for each source address.
+           </p><p>
+             The special FILENAME value
+             <code class="constant">__auto_link_local__</code> indicates that no
+             configuration file is provided and that CTDB should
+             generate reasonable link-local routes for each public IP
+             address.
+           </p><p>
+             File format:
+             </p><pre class="screen">
+               <em class="parameter"><code>IPADDR</code></em> <em class="parameter"><code>DEST-IPADDR/MASK</code></em> [<span class="optional"><em class="parameter"><code>GATEWAY-IPADDR</code></em></span>]
+             </pre><p>
+           </p><p>
+             No default, usually
+             <code class="filename">/usr/local/etc/ctdb/policy_routing</code>
+             when enabled.
+           </p></dd><dt><span class="term">
+           CTDB_PER_IP_ROUTING_RULE_PREF=<em class="parameter"><code>NUM</code></em>
+         </span></dt><dd><p>
+           NUM sets the priority (or preference) for the routing
+           rules that are added by CTDB.
+         </p><p>
+           This should be (strictly) greater than 0 and (strictly)
+           less than 32766.  A priority of 100 is recommended, unless
+           this conflicts with a priority already in use on the
+           system.  See
+           <span class="citerefentry"><span class="refentrytitle">ip</span>(8)</span>, for more details.
+         </p></dd><dt><span class="term">
+           CTDB_PER_IP_ROUTING_TABLE_ID_LOW=<em class="parameter"><code>LOW-NUM</code></em>,
+           CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=<em class="parameter"><code>HIGH-NUM</code></em>
+         </span></dt><dd><p>
+             CTDB determines a unique routing table number to use for
+             the routing related to each public address.  LOW-NUM and
+             HIGH-NUM indicate the minimum and maximum routing table
+             numbers that are used.
+           </p><p>
+             <span class="citerefentry"><span class="refentrytitle">ip</span>(8)</span> uses some
+             reserved routing table numbers below 255.  Therefore,
+             CTDB_PER_IP_ROUTING_TABLE_ID_LOW should be (strictly)
+             greater than 255.
+           </p><p>
+             CTDB uses the standard file
+             <code class="filename">/etc/iproute2/rt_tables</code> to maintain
+             a mapping between the routing table numbers and labels.
+             The label for a public address
+             <em class="replaceable"><code>ADDR</code></em> will look like
+             ctdb.<em class="replaceable"><code>addr</code></em>.  This means that
+             the associated rules and routes are easy to read (and
+             manipulate).
+           </p><p>
+             No default, usually 1000 and 9000.
+           </p></dd></dl></div><div class="refsect3"><a name="idm157"></a><h4>Example</h4><pre class="screen">
+       </pre></div></div><div class="refsect2"><a name="idm160"></a><h3>91.lvs</h3><p>
+       Provides CTDB's LVS functionality.
+      </p><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="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><div class="refsect1"><a name="idm195"></a><h2>SERVICE CONFIGURATION</h2><p>
+      CTDB can be configured to manage and/or monitor various NAS (and
+      other) services via its eventscripts.
+    </p><p>
+      In the simplest case CTDB will manage a service.  This means the
+      service will be started and stopped along with CTDB, CTDB will
+      monitor the service and CTDB will do any required
+      reconfiguration of the service when public IP addresses are
+      failed over.
+    </p><div class="refsect2"><a name="idm199"></a><h3>20.multipathd</h3><p>
+       Provides CTDB's Linux multipathd service management.
+      </p><p>
+       It can monitor multipath devices to ensure that active paths
+       are available.
+      </p><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="idm210"></a><h3>31.clamd</h3><p>
+       This event script provide CTDB's ClamAV anti-virus service
+       management.
+      </p><p>
+       This eventscript is not enabled by default.  Use <span class="command"><strong>ctdb
+       enablescript</strong></span> to enable it.
+      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">
+           CTDB_CLAMD_SOCKET=<em class="parameter"><code>FILENAME</code></em>
+         </span></dt><dd><p>
+             FILENAME is the socket to monitor ClamAV.
+           </p><p>
+             No default.
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm222"></a><h3>49.winbind</h3><p>
+       Provides CTDB's Samba winbind service management.
+      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">
+           CTDB_SERVICE_WINBIND=<em class="parameter"><code>SERVICE</code></em>
+         </span></dt><dd><p>
+             Distribution specific SERVICE for managing winbindd.
+           </p><p>
+             Default is "winbind".
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm232"></a><h3>50.samba</h3><p>
+       Provides the core of CTDB's Samba file service management.
+      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">
+           CTDB_SAMBA_CHECK_PORTS=<em class="parameter"><code>PORT-LIST</code></em>
+         </span></dt><dd><p>
+             When monitoring Samba, check TCP ports in
+             space-separated PORT-LIST.
+           </p><p>
+             Default is to monitor ports that Samba is configured to listen on.
+           </p></dd><dt><span class="term">
+           CTDB_SAMBA_SKIP_SHARE_CHECK=yes|no
+         </span></dt><dd><p>
+             As part of monitoring, should CTDB skip the check for
+             the existence of each directory configured as share in
+             Samba.  This may be desirable if there is a large number
+             of shares.
+           </p><p>
+             Default is no.
+           </p></dd><dt><span class="term">
+           CTDB_SERVICE_NMB=<em class="parameter"><code>SERVICE</code></em>
+         </span></dt><dd><p>
+             Distribution specific SERVICE for managing nmbd.
+           </p><p>
+             Default is distribution-dependant.
+           </p></dd><dt><span class="term">
+           CTDB_SERVICE_SMB=<em class="parameter"><code>SERVICE</code></em>
+         </span></dt><dd><p>
+             Distribution specific SERVICE for managing smbd.
+           </p><p>
+             Default is distribution-dependant.
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm259"></a><h3>60.nfs</h3><p>
+       This event script (along with 06.nfs) provides CTDB's NFS
+       service management.
+      </p><p>
+       This includes parameters for the kernel NFS server.
+       Alternative NFS subsystems (such as <a class="ulink" href="" target="_top">NFS-Ganesha</a>)
+       can be integrated using <code class="varname">CTDB_NFS_CALLOUT</code>.
+      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">
+           CTDB_NFS_CALLOUT=<em class="parameter"><code>COMMAND</code></em>
+         </span></dt><dd><p>
+             COMMAND specifies the path to a callout to handle
+             interactions with the configured NFS system, including
+             startup, shutdown, monitoring.
+           </p><p>
+             Default is the included
+             <span class="command"><strong>nfs-linux-kernel-callout</strong></span>.
+           </p></dd><dt><span class="term">
+           CTDB_NFS_CHECKS_DIR=<em class="parameter"><code>DIRECTORY</code></em>
+         </span></dt><dd><p>
+             Specifies the path to a DIRECTORY containing files that
+             describe how to monitor the responsiveness of NFS RPC
+             services.  See the README file for this directory for an
+             explanation of the contents of these "check" files.
+           </p><p>
+             CTDB_NFS_CHECKS_DIR can be used to point to different
+             sets of checks for different NFS servers.
+           </p><p>
+             One way of using this is to have it point to, say,
+             <code class="filename">/usr/local/etc/ctdb/nfs-checks-enabled.d</code>
+             and populate it with symbolic links to the desired check
+             files.  This avoids duplication and is upgrade-safe.
+           </p><p>
+             Default is
+             <code class="filename">/usr/local/etc/ctdb/nfs-checks.d</code>,
+             which contains NFS RPC checks suitable for Linux kernel
+             NFS.
+           </p></dd><dt><span class="term">
+           CTDB_NFS_SKIP_SHARE_CHECK=yes|no
+         </span></dt><dd><p>
+             As part of monitoring, should CTDB skip the check for
+             the existence of each directory exported via NFS.  This
+             may be desirable if there is a large number of exports.
+           </p><p>
+             Default is no.
+           </p></dd><dt><span class="term">
+           CTDB_RPCINFO_LOCALHOST=<em class="parameter"><code>IPADDR</code></em>|<em class="parameter"><code>HOSTNAME</code></em>
+         </span></dt><dd><p>
+             IPADDR or HOSTNAME indicates the address that
+             <span class="command"><strong>rpcinfo</strong></span> should connect to when doing
+             <span class="command"><strong>rpcinfo</strong></span> check on IPv4 RPC service during
+             monitoring.  Optimally this would be "localhost".
+             However, this can add some performance overheads.
+           </p><p>
+             Default is "".
+           </p></dd><dt><span class="term">
+           CTDB_RPCINFO_LOCALHOST6=<em class="parameter"><code>IPADDR</code></em>|<em class="parameter"><code>HOSTNAME</code></em>
+         </span></dt><dd><p>
+             IPADDR or HOSTNAME indicates the address that
+             <span class="command"><strong>rpcinfo</strong></span> should connect to when doing
+             <span class="command"><strong>rpcinfo</strong></span> check on IPv6 RPC service
+             during monitoring.  Optimally this would be "localhost6"
+             (or similar).  However, this can add some performance
+             overheads.
+           </p><p>
+             Default is "::1".
+           </p></dd><dt><span class="term">
+           CTDB_NFS_STATE_FS_TYPE=<em class="parameter"><code>TYPE</code></em>
+         </span></dt><dd><p>
+             The type of filesystem used for a clustered NFS' shared
+             state. No default.
+           </p></dd><dt><span class="term">
+           CTDB_NFS_STATE_MNT=<em class="parameter"><code>DIR</code></em>
+         </span></dt><dd><p>
+             The directory where a clustered NFS' shared state will be
+             located. No default.
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm316"></a><h3>70.iscsi</h3><p>
+       Provides CTDB's Linux iSCSI tgtd service management.
+      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">
+           CTDB_START_ISCSI_SCRIPTS=<em class="parameter"><code>DIRECTORY</code></em>
+         </span></dt><dd><p>
+             DIRECTORY on shared storage containing scripts to start
+             tgtd for each public IP address.
+           </p><p>
+             No default.
+           </p></dd></dl></div></div></div><div class="refsect1"><a name="idm326"></a><h2>
+      </h2><p>
+       CTDB checks the consistency of databases during startup.
+      </p><div class="refsect2"><a name="idm329"></a><h3>00.ctdb</h3><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_MAX_CORRUPT_DB_BACKUPS=<em class="parameter"><code>NUM</code></em></span></dt><dd><p>
+               NUM is the maximum number of volatile TDB database
+               backups to be kept (for each database) when a corrupt
+               database is found during startup.  Volatile TDBs are
+               zeroed during startup so backups are needed to debug
+               any corruption that occurs before a restart.
+             </p><p>
+               Default is 10.
+             </p></dd></dl></div></div></div><div class="refsect1"><a name="idm338"></a><h2>SYSTEM RESOURCE MONITORING</h2><div class="refsect2"><a name="idm340"></a><h3>
+       05.system
+      </h3><p>
+       Provides CTDB's filesystem and memory usage monitoring.
+      </p><p>
+       CTDB can experience seemingly random (performance and other)
+       issues if system resources become too constrained.  Options in
+       this section can be enabled to allow certain system resources
+       to be checked.  They allows warnings to be logged and nodes to
+       be marked unhealthy when system resource usage reaches the
+       configured thresholds.
+      </p><p>
+       Some checks are enabled by default.  It is recommended that
+       these checks remain enabled or are augmented by extra checks.
+       There is no supported way of completely disabling the checks.
+      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">
+           CTDB_MONITOR_FILESYSTEM_USAGE=<em class="parameter"><code>FS-LIMIT-LIST</code></em>
+         </span></dt><dd><p>
+             FS-LIMIT-LIST is a space-separated list of
+             <em class="parameter"><code>FILESYSTEM</code></em>:<em class="parameter"><code>WARN_LIMIT</code></em>[<span class="optional">:<em class="parameter"><code>UNHEALTHY_LIMIT</code></em></span>]
+             triples indicating that warnings should be logged if the
+             space used on FILESYSTEM reaches WARN_LIMIT%.  If usage
+             reaches UNHEALTHY_LIMIT then the node should be flagged
+             unhealthy.  Either WARN_LIMIT or UNHEALTHY_LIMIT may be
+             left blank, meaning that check will be omitted.
+           </p><p>
+             Default is to warn for each filesystem containing a
+             database directory
+             (<code class="literal">volatile database directory</code>,
+             <code class="literal">persistent database directory</code>,
+             <code class="literal">state database directory</code>)
+             with a threshold of 90%.
+           </p></dd><dt><span class="term">
+           CTDB_MONITOR_MEMORY_USAGE=<em class="parameter"><code>MEM-LIMITS</code></em>
+         </span></dt><dd><p>
+             MEM-LIMITS takes the form
+             <em class="parameter"><code>WARN_LIMIT</code></em>[<span class="optional">:<em class="parameter"><code>UNHEALTHY_LIMIT</code></em></span>]
+             indicating that warnings should be logged if memory
+             usage reaches WARN_LIMIT%.  If usage reaches
+             UNHEALTHY_LIMIT then the node should be flagged
+             unhealthy.  Either WARN_LIMIT or UNHEALTHY_LIMIT may be
+             left blank, meaning that check will be omitted.
+           </p><p>
+             Default is 80, so warnings will be logged when memory
+             usage reaches 80%.
+           </p></dd><dt><span class="term">
+           CTDB_MONITOR_SWAP_USAGE=<em class="parameter"><code>SWAP-LIMITS</code></em>
+         </span></dt><dd><p>
+             SWAP-LIMITS takes the form
+             <em class="parameter"><code>WARN_LIMIT</code></em>[<span class="optional">:<em class="parameter"><code>UNHEALTHY_LIMIT</code></em></span>]
+              indicating that warnings should be logged if
+             swap usage reaches WARN_LIMIT%.  If usage reaches
+             UNHEALTHY_LIMIT then the node should be flagged
+             unhealthy.  Either WARN_LIMIT or UNHEALTHY_LIMIT may be
+             left blank, meaning that check will be omitted.
+           </p><p>
+             Default is 25, so warnings will be logged when swap
+             usage reaches 25%.
+           </p></dd></dl></div></div></div><div class="refsect1"><a name="idm377"></a><h2>EVENT SCRIPT DEBUGGING</h2><div class="refsect2"><a name="idm379"></a><h3>
+      </h3><div class="variablelist"><dl class="variablelist"><dt><span class="term">CTDB_DEBUG_HUNG_SCRIPT_STACKPAT=<em class="parameter"><code>REGEXP</code></em></span></dt><dd><p>
+             REGEXP specifies interesting processes for which stack
+             traces should be logged when debugging hung eventscripts
+             and those processes are matched in pstree output.
+             REGEXP is an extended regexp so choices are separated by
+             pipes ('|').  However, REGEXP should not contain
+             parentheses.  See also the <span class="citerefentry"><span class="refentrytitle">ctdb.conf</span>(5)</span>
+             [event] "debug script" option.
+           </p><p>
+             Default is "exportfs|rpcinfo".
+           </p></dd></dl></div></div></div><div class="refsect1"><a name="idm391"></a><h2>FILES</h2><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">/usr/local/etc/ctdb/script.options</code></td></tr></table></div><div class="refsect1"><a name="idm396"></a><h2>SEE ALSO</h2><p>
+      <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
+      <a class="ulink" href="" target="_top"></a>
+    </p></div></div></body></html>
index 9eeda66..5add6c3 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.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="idm140621985748688"></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="idm10"></a><h2>OVERALL STATISTICS</h2><p>
       CTDB maintains information about various messages communicated
       and some of the important operations per node.  See the
       <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span> commands
       <span class="command"><strong>statistics</strong></span> and <span class="command"><strong>statisticsreset</strong></span>
       for displaying statistics.
-    </p><div class="refsect2"><a name="idm140621984041088"></a><h3>Example: ctdb statistics</h3><pre class="screen">
+    </p><div class="refsect2"><a name="idm18"></a><h3>Example: ctdb statistics</h3><pre class="screen">
 CTDB version 1
 Current time of statistics  :                Fri Sep 12 13:32:32 2014
 Statistics collected since  : (000 01:49:20) Fri Sep 12 11:43:12 2014
@@ -55,151 +55,155 @@ 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="idm140621983581632"></a><h3>CTDB version</h3><p>
+       </pre></div><div class="refsect2"><a name="idm21"></a><h3>CTDB version</h3><p>
         Version of the ctdb protocol used by the node.
-      </p></div><div class="refsect2"><a name="idm140621984462224"></a><h3>Current time of statistics</h3><p>
+      </p></div><div class="refsect2"><a name="idm24"></a><h3>Current time of statistics</h3><p>
         Time when the statistics are generated.
         This is useful when collecting statistics output periodically
         for post-processing.
-      </p></div><div class="refsect2"><a name="idm140621985684512"></a><h3>Statistics collected since</h3><p>
+      </p></div><div class="refsect2"><a name="idm28"></a><h3>Statistics collected since</h3><p>
        Time when ctdb was started or the last time statistics was reset.
        The output shows the duration and the timestamp.
-      </p></div><div class="refsect2"><a name="idm140621986778784"></a><h3>num_clients</h3><p>
+      </p></div><div class="refsect2"><a name="idm31"></a><h3>num_clients</h3><p>
         Number of processes currently connected to CTDB's unix socket.
         This includes recovery daemon, ctdb tool and samba processes
         (smbd, winbindd).
-      </p></div><div class="refsect2"><a name="idm140621984947376"></a><h3>frozen</h3><p>
+      </p></div><div class="refsect2"><a name="idm34"></a><h3>frozen</h3><p>
        1 if the the databases are currently frozen, 0 otherwise.
-      </p></div><div class="refsect2"><a name="idm140621983990928"></a><h3>recovering</h3><p>
+      </p></div><div class="refsect2"><a name="idm37"></a><h3>recovering</h3><p>
        1 if recovery is active, 0 otherwise.
-      </p></div><div class="refsect2"><a name="idm140621983338032"></a><h3>num_recoveries</h3><p>
+      </p></div><div class="refsect2"><a name="idm40"></a><h3>num_recoveries</h3><p>
        Number of recoveries since the start of ctdb or since the last
        statistics reset.
-      </p></div><div class="refsect2"><a name="idm140621983522336"></a><h3>client_packets_sent</h3><p>
+      </p></div><div class="refsect2"><a name="idm43"></a><h3>client_packets_sent</h3><p>
        Number of packets sent to client processes via unix domain socket.
-      </p></div><div class="refsect2"><a name="idm140621985407040"></a><h3>client_packets_recv</h3><p>
+      </p></div><div class="refsect2"><a name="idm46"></a><h3>client_packets_recv</h3><p>
        Number of packets received from client processes via unix domain socket.
-      </p></div><div class="refsect2"><a name="idm140621987381056"></a><h3>node_packets_sent</h3><p>
+      </p></div><div class="refsect2"><a name="idm49"></a><h3>node_packets_sent</h3><p>
        Number of packets sent to the other nodes in the cluster via TCP.
-      </p></div><div class="refsect2"><a name="idm140621987379872"></a><h3>node_packets_recv</h3><p>
+      </p></div><div class="refsect2"><a name="idm52"></a><h3>node_packets_recv</h3><p>
        Number of packets received from the other nodes in the cluster via TCP.
-      </p></div><div class="refsect2"><a name="idm140621987378592"></a><h3>keepalive_packets_sent</h3><p>
+      </p></div><div class="refsect2"><a name="idm55"></a><h3>keepalive_packets_sent</h3><p>
        Number of keepalive messages sent to other nodes.
        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="idm140621987863744"></a><h3>keepalive_packets_recv</h3><p>
+      </p></div><div class="refsect2"><a name="idm63"></a><h3>keepalive_packets_recv</h3><p>
        Number of keepalive messages received from other nodes.
-      </p></div><div class="refsect2"><a name="idm140621987862560"></a><h3>node</h3><p>
+      </p></div><div class="refsect2"><a name="idm66"></a><h3>node</h3><p>
        This section lists various types of messages processed which
        originated from other nodes via TCP.
-      </p><div class="refsect3"><a name="idm140621987861376"></a><h4>req_call</h4><p>
+      </p><div class="refsect3"><a name="idm69"></a><h4>req_call</h4><p>
         Number of REQ_CALL messages from the other nodes.
-      </p></div><div class="refsect3"><a name="idm140621987860192"></a><h4>reply_call</h4><p>
+      </p></div><div class="refsect3"><a name="idm72"></a><h4>reply_call</h4><p>
         Number of REPLY_CALL messages from the other nodes.
-      </p></div><div class="refsect3"><a name="idm140621987859008"></a><h4>req_dmaster</h4><p>
+      </p></div><div class="refsect3"><a name="idm75"></a><h4>req_dmaster</h4><p>
         Number of REQ_DMASTER messages from the other nodes.
-      </p></div><div class="refsect3"><a name="idm140621987857824"></a><h4>reply_dmaster</h4><p>
+      </p></div><div class="refsect3"><a name="idm78"></a><h4>reply_dmaster</h4><p>
         Number of REPLY_DMASTER messages from the other nodes.
-      </p></div><div class="refsect3"><a name="idm140621987856640"></a><h4>reply_error</h4><p>
+      </p></div><div class="refsect3"><a name="idm81"></a><h4>reply_error</h4><p>
         Number of REPLY_ERROR messages from the other nodes.
-      </p></div><div class="refsect3"><a name="idm140621987855456"></a><h4>req_message</h4><p>
+      </p></div><div class="refsect3"><a name="idm84"></a><h4>req_message</h4><p>
         Number of REQ_MESSAGE messages from the other nodes.
-      </p></div><div class="refsect3"><a name="idm140621987854272"></a><h4>req_control</h4><p>
+      </p></div><div class="refsect3"><a name="idm87"></a><h4>req_control</h4><p>
         Number of REQ_CONTROL messages from the other nodes.
-      </p></div><div class="refsect3"><a name="idm140621987853008"></a><h4>reply_control</h4><p>
+      </p></div><div class="refsect3"><a name="idm90"></a><h4>reply_control</h4><p>
         Number of REPLY_CONTROL messages from the other nodes.
-      </p></div></div><div class="refsect2"><a name="idm140621987851616"></a><h3>client</h3><p>
+      </p></div><div class="refsect3"><a name="idm93"></a><h4>req_tunnel</h4><p>
+        Number of REQ_TUNNEL messages from the other nodes.
+      </p></div></div><div class="refsect2"><a name="idm96"></a><h3>client</h3><p>
        This section lists various types of messages processed which
        originated from clients via unix domain socket.
-      </p><div class="refsect3"><a name="idm140621987850432"></a><h4>req_call</h4><p>
+      </p><div class="refsect3"><a name="idm99"></a><h4>req_call</h4><p>
         Number of REQ_CALL messages from the clients.
-      </p></div><div class="refsect3"><a name="idm140621987849168"></a><h4>req_message</h4><p>
+      </p></div><div class="refsect3"><a name="idm102"></a><h4>req_message</h4><p>
         Number of REQ_MESSAGE messages from the clients.
-      </p></div><div class="refsect3"><a name="idm140621987986720"></a><h4>req_control</h4><p>
+      </p></div><div class="refsect3"><a name="idm105"></a><h4>req_control</h4><p>
         Number of REQ_CONTROL messages from the clients.
-      </p></div></div><div class="refsect2"><a name="idm140621987985328"></a><h3>timeouts</h3><p>
+      </p></div><div class="refsect3"><a name="idm108"></a><h4>req_tunnel</h4><p>
+        Number of REQ_TUNNEL messages from the clients.
+      </p></div></div><div class="refsect2"><a name="idm111"></a><h3>timeouts</h3><p>
        This section lists timeouts occurred when sending various messages.
-      </p><div class="refsect3"><a name="idm140621987984176"></a><h4>call</h4><p>
+      </p><div class="refsect3"><a name="idm114"></a><h4>call</h4><p>
         Number of timeouts for REQ_CALL messages.
-      </p></div><div class="refsect3"><a name="idm140621987982912"></a><h4>control</h4><p>
+      </p></div><div class="refsect3"><a name="idm117"></a><h4>control</h4><p>
         Number of timeouts for REQ_CONTROL messages.
-      </p></div><div class="refsect3"><a name="idm140621987981648"></a><h4>traverse</h4><p>
+      </p></div><div class="refsect3"><a name="idm120"></a><h4>traverse</h4><p>
         Number of timeouts for database traverse operations.
-      </p></div></div><div class="refsect2"><a name="idm140621987980256"></a><h3>locks</h3><p>
+      </p></div></div><div class="refsect2"><a name="idm123"></a><h3>locks</h3><p>
        This section lists locking statistics.
-      </p><div class="refsect3"><a name="idm140621987979200"></a><h4>num_calls</h4><p>
+      </p><div class="refsect3"><a name="idm126"></a><h4>num_calls</h4><p>
         Number of completed lock calls.  This includes database locks
         and record locks.
-      </p></div><div class="refsect3"><a name="idm140621987977904"></a><h4>num_current</h4><p>
+      </p></div><div class="refsect3"><a name="idm129"></a><h4>num_current</h4><p>
         Number of scheduled lock calls.  This includes database locks
         and record locks.
-      </p></div><div class="refsect3"><a name="idm140621987976608"></a><h4>num_pending</h4><p>
+      </p></div><div class="refsect3"><a name="idm132"></a><h4>num_pending</h4><p>
         Number of queued lock calls.  This includes database locks and
         record locks.
-      </p></div><div class="refsect3"><a name="idm140621987975312"></a><h4>num_failed</h4><p>
+      </p></div><div class="refsect3"><a name="idm135"></a><h4>num_failed</h4><p>
         Number of failed lock calls.  This includes database locks and
         record locks.
-      </p></div></div><div class="refsect2"><a name="idm140621987973888"></a><h3>total_calls</h3><p>
+      </p></div></div><div class="refsect2"><a name="idm138"></a><h3>total_calls</h3><p>
        Number of req_call messages processed from clients.  This number
        should be same as client --&gt; req_call.
-      </p></div><div class="refsect2"><a name="idm140621987972576"></a><h3>pending_calls</h3><p>
+      </p></div><div class="refsect2"><a name="idm141"></a><h3>pending_calls</h3><p>
        Number of req_call messages which are currenly being processed.
        This number indicates the number of record migrations in flight.
-      </p></div><div class="refsect2"><a name="idm140621987971232"></a><h3>childwrite_calls</h3><p>
+      </p></div><div class="refsect2"><a name="idm144"></a><h3>childwrite_calls</h3><p>
        Number of record update calls.  Record update calls are used to
        update a record under a transaction.
-      </p></div><div class="refsect2"><a name="idm140621987962288"></a><h3>pending_childwrite_calls</h3><p>
+      </p></div><div class="refsect2"><a name="idm147"></a><h3>pending_childwrite_calls</h3><p>
        Number of record update calls currently active.
-      </p></div><div class="refsect2"><a name="idm140621987961056"></a><h3>memory_used</h3><p>
+      </p></div><div class="refsect2"><a name="idm150"></a><h3>memory_used</h3><p>
        The amount of memory in bytes currently used by CTDB using
        talloc.  This includes all the memory used for CTDB's internal
        data structures.  This does not include the memory mapped TDB
-      </p></div><div class="refsect2"><a name="idm140621987959648"></a><h3>max_hop_count</h3><p>
+      </p></div><div class="refsect2"><a name="idm153"></a><h3>max_hop_count</h3><p>
        The maximum number of hops required for a record migration request
        to obtain the record.  High numbers indicate record contention.
-      </p></div><div class="refsect2"><a name="idm140621987958304"></a><h3>total_ro_delegations</h3><p>
+      </p></div><div class="refsect2"><a name="idm156"></a><h3>total_ro_delegations</h3><p>
        Number of readonly delegations created.
-      </p></div><div class="refsect2"><a name="idm140621987957120"></a><h3>total_ro_revokes</h3><p>
+      </p></div><div class="refsect2"><a name="idm159"></a><h3>total_ro_revokes</h3><p>
        Number of readonly delegations that were revoked.  The difference
        between total_ro_revokes and total_ro_delegations gives the
        number of currently active readonly delegations.
-      </p></div><div class="refsect2"><a name="idm140621987955728"></a><h3>hop_count_buckets</h3><p>
+      </p></div><div class="refsect2"><a name="idm162"></a><h3>hop_count_buckets</h3><p>
        Distribution of migration requests based on hop counts values.
        Buckets are 1, &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="idm140621987940288"></a><h3>lock_buckets</h3><p>
+      </p></div><div class="refsect2"><a name="idm165"></a><h3>lock_buckets</h3><p>
        Distribution of record lock requests based on time required to
        obtain locks.  Buckets are &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="idm140621987953456"></a><h3>locks_latency</h3><p>
+      </p></div><div class="refsect2"><a name="idm168"></a><h3>locks_latency</h3><p>
        The minimum, the average and the maximum time (in seconds)
        required to obtain record locks.
-      </p></div><div class="refsect2"><a name="idm140621987952304"></a><h3>reclock_ctdbd</h3><p>
+      </p></div><div class="refsect2"><a name="idm171"></a><h3>reclock_ctdbd</h3><p>
        The minimum, the average and the maximum time (in seconds)
        required to check if recovery lock is still held by recovery
        daemon when recovery mode is changed.  This check is done in ctdb daemon.
-      </p></div><div class="refsect2"><a name="idm140621987950928"></a><h3>reclock_recd</h3><p>
+      </p></div><div class="refsect2"><a name="idm174"></a><h3>reclock_recd</h3><p>
         The minimum, the average and the maximum time (in seconds)
         required to check if recovery lock is still held by recovery
         daemon during recovery.  This check is done in recovery daemon.
-      </p></div><div class="refsect2"><a name="idm140621987949552"></a><h3>call_latency</h3><p>
+      </p></div><div class="refsect2"><a name="idm177"></a><h3>call_latency</h3><p>
        The minimum, the average and the maximum time (in seconds) required
        to process a REQ_CALL message from client.  This includes the time
        required to migrate a record from remote node, if the record is
        not available on the local node.
-      </p></div><div class="refsect2"><a name="idm140621987947664"></a><h3>childwrite_latency</h3><p>Default: 0</p><p>
+      </p></div><div class="refsect2"><a name="idm180"></a><h3>childwrite_latency</h3><p>Default: 0</p><p>
        The minimum, the average and the maximum time (in seconds)
        required to update records under a transaction.
-      </p></div></div><div class="refsect1"><a name="idm140621987945808"></a><h2>DATABASE STATISTICS</h2><p>
+      </p></div></div><div class="refsect1"><a name="idm184"></a><h2>DATABASE STATISTICS</h2><p>
       CTDB maintains per database statistics about important operations.
       See the <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span> command
       <span class="command"><strong>dbstatistics</strong></span> for displaying database statistics.
-    </p><div class="refsect2"><a name="idm140621987942992"></a><h3>Example: ctdb dbstatistics notify_index.tdb</h3><pre class="screen">
+    </p><div class="refsect2"><a name="idm191"></a><h3>Example: ctdb dbstatistics notify_index.tdb</h3><pre class="screen">
 DB Statistics: notify_index.tdb
  ro_delegations                     0
  ro_revokes                         0
@@ -215,45 +219,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="idm140621987940928"></a><h3>DB Statistics</h3><p>
+       </pre></div><div class="refsect2"><a name="idm194"></a><h3>DB Statistics</h3><p>
        Name of the database.
-      </p></div><div class="refsect2"><a name="idm140621982442256"></a><h3>ro_delegations</h3><p>
+      </p></div><div class="refsect2"><a name="idm197"></a><h3>ro_delegations</h3><p>
        Number of readonly delegations created in the database.
-      </p></div><div class="refsect2"><a name="idm140621982441104"></a><h3>ro_revokes</h3><p>
+      </p></div><div class="refsect2"><a name="idm200"></a><h3>ro_revokes</h3><p>
        Number of readonly delegations revoked.  The difference in
        ro_delegations and ro_revokes indicates the currently active
        readonly delegations.
-      </p></div><div class="refsect2"><a name="idm140621982439776"></a><h3>locks</h3><p>
+      </p></div><div class="refsect2"><a name="idm203"></a><h3>locks</h3><p>
        This section lists locking statistics.
-      </p><div class="refsect3"><a name="idm140621982438752"></a><h4>total</h4><p>
+      </p><div class="refsect3"><a name="idm206"></a><h4>total</h4><p>
         Number of completed lock calls.  This includes database locks
         and record locks.
-      </p></div><div class="refsect3"><a name="idm140621982437488"></a><h4>failed</h4><p>
+      </p></div><div class="refsect3"><a name="idm209"></a><h4>failed</h4><p>
         Number of failed lock calls.  This includes database locks and
         record locks.
-      </p></div><div class="refsect3"><a name="idm140621982436224"></a><h4>current</h4><p>
+      </p></div><div class="refsect3"><a name="idm212"></a><h4>current</h4><p>
         Number of scheduled lock calls.  This includes database locks
         and record locks.
-      </p></div><div class="refsect3"><a name="idm140621982434960"></a><h4>pending</h4><p>
+      </p></div><div class="refsect3"><a name="idm215"></a><h4>pending</h4><p>
         Number of queued lock calls.  This includes database locks and
         record locks.
-      </p></div></div><div class="refsect2"><a name="idm140621982433568"></a><h3>hop_count_buckets</h3><p>
+      </p></div></div><div class="refsect2"><a name="idm218"></a><h3>hop_count_buckets</h3><p>
        Distribution of migration requests based on hop counts values.
        Buckets are 1, &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="idm140621982432208"></a><h3>lock_buckets</h3><p>
+      </p></div><div class="refsect2"><a name="idm221"></a><h3>lock_buckets</h3><p>
        Distribution of record lock requests based on time required to
        obtain locks.  Buckets are &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="idm140621982430784"></a><h3>locks_latency</h3><p>
+      </p></div><div class="refsect2"><a name="idm224"></a><h3>locks_latency</h3><p>
        The minimum, the average and the maximum time (in seconds)
        required to obtain record locks.
-      </p></div><div class="refsect2"><a name="idm140621982429520"></a><h3>Num Hot Keys</h3><p>
+      </p></div><div class="refsect2"><a name="idm227"></a><h3>Num Hot Keys</h3><p>
         Number of contended records determined by hop count.  CTDB keeps
         track of top 10 hot records and the output shows hex encoded
         keys for the hot records.
-      </p></div></div><div class="refsect1"><a name="idm140621982428048"></a><h2>SEE ALSO</h2><p>
+      </p></div></div><div class="refsect1"><a name="idm230"></a><h2>SEE ALSO</h2><p>
       <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
       <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
index 488de71..6772bbd 100644 (file)
@@ -1,4 +1,4 @@
-<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="idm140259278533088"></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>
       (some or most) tunables globally across the cluster but doing so
       is currently a manual process.
-      The tunable variables are listed alphabetically.
-    </p><div class="refsect2"><a name="idm140259278393728"></a><h3>AllowClientDBAttach</h3><p>Default: 1</p><p>
+      Tunables can be set at startup from the
+      <code class="filename">/usr/local/etc/ctdb/ctdb.tunables</code>
+      configuration file.
+      </p><div class="literallayout"><p><br>
+<em class="replaceable"><code>TUNABLE</code></em>=<em class="replaceable"><code>VALUE</code></em><br>
+      </p></div><p>
+    </p><p>
+      For example:
+      </p><pre class="screen">
+      </pre><p>
+    </p><p>
+      The available tunable variables are listed alphabetically below.
+    </p><div class="refsect2"><a name="idm28"></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="idm140259279350368"></a><h3>AllowUnhealthyDBRead</h3><p>Default: 0</p><p>
+      </p></div><div class="refsect2"><a name="idm32"></a><h3>AllowMixedVersions</h3><p>Default: 0</p><p>
+       CTDB will not allow incompatible versions to co-exist in
+       a cluster.  If a version mismatch is found, then losing CTDB
+       will shutdown.  To disable the incompatible version check,
+       set this tunable to 1.
+      </p><p>
+       For version checking, CTDB uses major and minor version.
+       For example, CTDB 4.6.1 and CTDB CTDB 4.6.2 are matching versions;
+       CTDB 4.5.x and CTDB 4.6.y do not match.
+      </p><p>
+       CTDB with version check support will lose to CTDB without
+       version check support.  Between two different CTDB versions with
+       version check support, one running for less time will lose.
+       If the running time for both CTDB versions with version check
+       support is equal (to seconds), then the older version will lose.
+       The losing CTDB daemon will shutdown.
+      </p></div><div class="refsect2"><a name="idm38"></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="idm140259280015280"></a><h3>ControlTimeout</h3><p>Default: 60</p><p>
+      </p></div><div class="refsect2"><a name="idm42"></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="idm140259280961360"></a><h3>DatabaseHashSize</h3><p>Default: 100001</p><p>
+      </p></div><div class="refsect2"><a name="idm46"></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="idm140259280959760"></a><h3>DatabaseMaxDead</h3><p>Default: 5</p><p>
+      </p></div><div class="refsect2"><a name="idm50"></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="idm140259281728576"></a><h3>DBRecordCountWarn</h3><p>Default: 100000</p><p>
+      </p></div><div class="refsect2"><a name="idm54"></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="idm140259281726752"></a><h3>DBRecordSizeWarn</h3><p>Default: 10000000</p><p>
+      </p></div><div class="refsect2"><a name="idm58"></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="idm140259281764192"></a><h3>DBSizeWarn</h3><p>Default: 1000000000</p><p>
+      </p></div><div class="refsect2"><a name="idm62"></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="idm140259281762400"></a><h3>DeferredAttachTO</h3><p>Default: 120</p><p>
+      </p></div><div class="refsect2"><a name="idm66"></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
        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="idm140259281759968"></a><h3>DisableIPFailover</h3><p>Default: 0</p><p>
-       When set to non-zero, ctdb will not perform failover or
-       failback. Even if a node fails while holding public IPs, ctdb
-       will not recover the IPs or assign them to another node.
-      </p><p>
-       When this tunable is enabled, ctdb will no longer attempt
-       to recover the cluster by failing IP addresses over to other
-       nodes. This leads to a service outage until the administrator
-       has manually performed IP failover to replacement nodes using the
-       'ctdb moveip' command.
-      </p></div><div class="refsect2"><a name="idm140259281757472"></a><h3>ElectionTimeout</h3><p>Default: 3</p><p>
+      </p></div><div class="refsect2"><a name="idm71"></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="idm140259281755648"></a><h3>EnableBans</h3><p>Default: 1</p><p>
+      </p></div><div class="refsect2"><a name="idm75"></a><h3>EnableBans</h3><p>Default: 1</p><p>
        This parameter allows ctdb to ban a node if the node is misbehaving.
        When set to 0, this disables banning completely in the cluster
        and thus nodes can not get banned, even it they break. Don't
        set to 0 unless you know what you are doing.
-      </p></div><div class="refsect2"><a name="idm140259281753472"></a><h3>EventScriptTimeout</h3><p>Default: 30</p><p>
+      </p></div><div class="refsect2"><a name="idm80"></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="idm140259281751040"></a><h3>FetchCollapse</h3><p>Default: 1</p><p>
+      </p></div><div class="refsect2"><a name="idm85"></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
        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="idm140259281887088"></a><h3>HopcountMakeSticky</h3><p>Default: 50</p><p>
+      </p></div><div class="refsect2"><a name="idm90"></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
        This will improve performance for certain workloads, such as
        locking.tdb if many clients are opening/closing the same file
-      </p></div><div class="refsect2"><a name="idm140259281883888"></a><h3>IPAllocAlgorithm</h3><p>Default: 2</p><p>
+      </p></div><div class="refsect2"><a name="idm97"></a><h3>IPAllocAlgorithm</h3><p>Default: 2</p><p>
        Selects the algorithm that CTDB should use when doing public
        IP address allocation.  Meaningful values are:
       </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">0</span></dt><dd><p>
        If the specified value is not one of these then the default
        will be used.
-      </p></div><div class="refsect2"><a name="idm140259281874384"></a><h3>KeepaliveInterval</h3><p>Default: 5</p><p>
+      </p></div><div class="refsect2"><a name="idm118"></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="idm140259281872784"></a><h3>KeepaliveLimit</h3><p>Default: 5</p><p>
+      </p></div><div class="refsect2"><a name="idm122"></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.
        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="idm140259281862080"></a><h3>LockProcessesPerDB</h3><p>Default: 200</p><p>
+      </p></div><div class="refsect2"><a name="idm129"></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="idm140259281860240"></a><h3>LogLatencyMs</h3><p>Default: 0</p><p>
+      </p></div><div class="refsect2"><a name="idm133"></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="idm140259281858336"></a><h3>MaxQueueDropMsg</h3><p>Default: 1000000</p><p>
+      </p></div><div class="refsect2"><a name="idm137"></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="idm140259281856560"></a><h3>MonitorInterval</h3><p>Default: 15</p><p>
+      </p></div><div class="refsect2"><a name="idm141"></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="idm140259281854848"></a><h3>MonitorTimeoutCount</h3><p>Default: 20</p><p>
+      </p></div><div class="refsect2"><a name="idm145"></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="idm140259281853040"></a><h3>NoIPFailback</h3><p>Default: 0</p><p>
+      </p></div><div class="refsect2"><a name="idm149"></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
        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="idm140259281849648"></a><h3>NoIPHostOnAllDisabled</h3><p>Default: 0</p><p>
-       If no nodes are HEALTHY then by default ctdb will happily host
-       public IPs on disabled (unhealthy or administratively disabled)
-       nodes.  This can cause problems, for example if the underlying
-       cluster filesystem is not mounted.  When set to 1 and a node
-       is disabled, any IPs hosted by this node will be released and
-       the node will not takeover any IPs until it is no longer disabled.
-      </p></div><div class="refsect2"><a name="idm140259281847632"></a><h3>NoIPTakeover</h3><p>Default: 0</p><p>
+      </p></div><div class="refsect2"><a name="idm155"></a><h3>NoIPTakeover</h3><p>Default: 0</p><p>
        When set to 1, ctdb will not allow IP addresses to be failed
        over to other nodes.  Any IP addresses already hosted on
-       healthy nodes will remain.  Usually IP addresses hosted on
-       unhealthy nodes will also remain, if NoIPHostOnAllDisabled is
-       0.  However, if NoIPHostOnAllDisabled is 1 then IP addresses
-       will be released by unhealthy nodes and will become un-hosted.
-      </p></div><div class="refsect2"><a name="idm140259281845632"></a><h3>PullDBPreallocation</h3><p>Default: 10*1024*1024</p><p>
+       healthy nodes will remain.  Any IP addresses hosted on
+       unhealthy nodes will be released by unhealthy nodes and will
+       become un-hosted.
+      </p></div><div class="refsect2"><a name="idm159"></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="idm140259281843664"></a><h3>QueueBufferSize</h3><p>Default: 1024</p><p>
+      </p></div><div class="refsect2"><a name="idm163"></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.
        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="idm140259281841264"></a><h3>RecBufferSizeLimit</h3><p>Default: 1000000</p><p>
+      </p></div><div class="refsect2"><a name="idm168"></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="idm140259276337632"></a><h3>RecdFailCount</h3><p>Default: 10</p><p>
+      </p></div><div class="refsect2"><a name="idm172"></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="idm140259276335872"></a><h3>RecdPingTimeout</h3><p>Default: 60</p><p>
+      </p></div><div class="refsect2"><a name="idm176"></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="idm140259276333696"></a><h3>RecLockLatencyMs</h3><p>Default: 1000</p><p>
+      </p></div><div class="refsect2"><a name="idm181"></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="idm140259276331904"></a><h3>RecoverInterval</h3><p>Default: 1</p><p>
+      </p></div><div class="refsect2"><a name="idm185"></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="idm140259276330208"></a><h3>RecoverTimeout</h3><p>Default: 120</p><p>
+      </p></div><div class="refsect2"><a name="idm189"></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
-      </p></div><div class="refsect2"><a name="idm140259276328384"></a><h3>RecoveryBanPeriod</h3><p>Default: 300</p><p>
+      </p></div><div class="refsect2"><a name="idm193"></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.
        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="idm140259276325984"></a><h3>RecoveryDropAllIPs</h3><p>Default: 120</p><p>
+      </p></div><div class="refsect2"><a name="idm198"></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="idm140259276324288"></a><h3>RecoveryGracePeriod</h3><p>Default: 120</p><p>
+      </p></div><div class="refsect2"><a name="idm202"></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="idm140259276322448"></a><h3>RepackLimit</h3><p>Default: 10000</p><p>
+      </p></div><div class="refsect2"><a name="idm206"></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.
         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="idm140259276319248"></a><h3>RerecoveryTimeout</h3><p>Default: 10</p><p>
+      </p></div><div class="refsect2"><a name="idm214"></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="idm140259276317568"></a><h3>SeqnumInterval</h3><p>Default: 1000</p><p>
+      </p></div><div class="refsect2"><a name="idm218"></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
+       to the database.  Every time a database is updated its sequence
        number is increased.
        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="idm140259276315216"></a><h3>StatHistoryInterval</h3><p>Default: 1</p><p>
+      </p></div><div class="refsect2"><a name="idm223"></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="idm140259276313552"></a><h3>StickyDuration</h3><p>Default: 600</p><p>
+      </p></div><div class="refsect2"><a name="idm227"></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="idm140259276311872"></a><h3>StickyPindown</h3><p>Default: 200</p><p>
+      </p></div><div class="refsect2"><a name="idm231"></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="idm140259276310112"></a><h3>TakeoverTimeout</h3><p>Default: 9</p><p>
+      </p></div><div class="refsect2"><a name="idm235"></a><h3>TakeoverTimeout</h3><p>Default: 9</p><p>
        This is the duration in seconds in which ctdb tries to complete IP
-      </p></div><div class="refsect2"><a name="idm140259276308480"></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="idm140259276306704"></a><h3>TickleUpdateInterval</h3><p>Default: 20</p><p>
+      </p></div><div class="refsect2"><a name="idm239"></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="idm140259276304688"></a><h3>TraverseTimeout</h3><p>Default: 20</p><p>
+      </p></div><div class="refsect2"><a name="idm244"></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="idm140259276302960"></a><h3>VacuumFastPathCount</h3><p>Default: 60</p><p>
+      </p></div><div class="refsect2"><a name="idm248"></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="idm140259276300704"></a><h3>VacuumInterval</h3><p>Default: 10</p><p>
+      </p></div><div class="refsect2"><a name="idm253"></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="idm140259276299040"></a><h3>VacuumLimit</h3><p>Default: 5000</p><p>
+      </p></div><div class="refsect2"><a name="idm257"></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.
         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="idm140259276295872"></a><h3>VacuumMaxRunTime</h3><p>Default: 120</p><p>
+      </p></div><div class="refsect2"><a name="idm265"></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="idm140259276294112"></a><h3>VerboseMemoryNames</h3><p>Default: 0</p><p>
+      </p></div><div class="refsect2"><a name="idm269"></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="idm140259276292240"></a><h2>SEE ALSO</h2><p>
+      </p></div></div><div class="refsect1"><a name="idm273"></a><h2>FILES&gt;</h2><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="filename">/usr/local/etc/ctdb/ctdb.tunables</code></td></tr></table></div><div class="refsect1"><a name="idm278"></a><h2>SEE ALSO</h2><p>
       <span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
       <span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
-      <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ctdb.conf</span>(5)</span>,
       <span class="citerefentry"><span class="refentrytitle">ctdb</span>(7)</span>,
index aaf29a7..301ce65 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.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="idm140317076399120"></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.
       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></div><div class="refsect1"><a name="idm140317080330816"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-n <em class="parameter"><code>PNN</code></em></span></dt><dd><p>
+    </p></div><div class="refsect1"><a name="idm56"></a><h2>OPTIONS</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term">-n <em class="parameter"><code>PNN</code></em></span></dt><dd><p>
          The node specified by PNN should be queried for the
          requested information.  Default is to query the daemon
          running on the local host.
          Print useage information to the screen.
        </p></dd><dt><span class="term">-d --debug=<em class="parameter"><code>DEBUGLEVEL</code></em></span></dt><dd><p>
          Change the debug level for the command. Default is NOTICE.
-       </p></dd><dt><span class="term">--socket=<em class="parameter"><code>FILENAME</code></em></span></dt><dd><p>
-         Specify that FILENAME is the name of the Unix domain
-         socket to use when connecting to the local CTDB
-         daemon. The default is
-         <code class="filename">/usr/local/var/run/ctdb/ctdbd.socket</code>.
-       </p></dd></dl></div></div><div class="refsect1"><a name="idm140317080470800"></a><h2>ADMINISTRATIVE COMMANDS</h2><p>
+       </p></dd></dl></div></div><div class="refsect1"><a name="idm101"></a><h2>ADMINISTRATIVE COMMANDS</h2><p>
       These are commands used to monitor and administer a CTDB cluster.
-    </p><div class="refsect2"><a name="idm140317080469648"></a><h3>pnn</h3><p>
+    </p><div class="refsect2"><a name="idm104"></a><h3>pnn</h3><p>
        This command displays the PNN of the current node.
-      </p></div><div class="refsect2"><a name="idm140317080468448"></a><h3>status</h3><p>
+      </p></div><div class="refsect2"><a name="idm107"></a><h3>status</h3><p>
        This command shows the current status of all CTDB nodes based
        on information from the queried node.
        Note: If the the queried node is INACTIVE then the status
        might not be current.
-      </p><div class="refsect3"><a name="idm140317080466768"></a><h4>Node status</h4><p>
+      </p><div class="refsect3"><a name="idm111"></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="idm140317080464560"></a><h4>Generation</h4><p>
+       </p></div><div class="refsect3"><a name="idm117"></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="idm140317080461056"></a><h4>Virtual Node Number (VNN) map</h4><p>
+       </p></div><div class="refsect3"><a name="idm122"></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="idm140317080452032"></a><h4>Recovery mode</h4><p>
+         virtual node numbers to physical node numbers.  Only nodes
+         that are participating in the VNN map can become lmaster for
+         database records.
+       </p></div><div class="refsect3"><a name="idm125"></a><h4>Recovery mode</h4><p>
          This is the current recovery mode of the cluster. There are two possible modes:
          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="idm140317080448128"></a><h4>Recovery master</h4><p>
+       </p></div><div class="refsect3"><a name="idm132"></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.
          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="idm140317080446128"></a><h4>Example</h4><pre class="screen">
+       </p></div><div class="refsect3"><a name="idm136"></a><h4>Example</h4><pre class="screen">
 # ctdb status
 Number of nodes:4
 pnn:0       OK (THIS NODE)
@@ -141,7 +135,7 @@ hash:2 lmaster:2
 hash:3 lmaster:3
 Recovery mode:NORMAL (0)
 Recovery master:0
-       </pre></div></div><div class="refsect2"><a name="idm140317080444224"></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="idm139"></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:
@@ -159,7 +153,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
-      </p><div class="refsect3"><a name="idm140317080436272"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm155"></a><h4>Example</h4><pre class="screen">
 # ctdb nodestatus
 pnn:0        OK (THIS NODE)
@@ -167,28 +161,28 @@ pnn:0        OK (THIS NODE)
 Number of nodes:2
 pnn:0        OK (THIS NODE)
 pnn:1        OK
-       </pre></div></div><div class="refsect2"><a name="idm140317080434512"></a><h3>recmaster</h3><p>
+       </pre></div></div><div class="refsect2"><a name="idm158"></a><h3>recmaster</h3><p>
        This command shows the pnn of the node which is currently the recmaster.
        Note: If the the queried node is INACTIVE then the status
        might not be current.
-      </p></div><div class="refsect2"><a name="idm140317080432736"></a><h3>uptime</h3><p>
+      </p></div><div class="refsect2"><a name="idm162"></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="idm140317080431392"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm165"></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="idm140317080429504"></a><h3>listnodes</h3><p>
+       </pre></div></div><div class="refsect2"><a name="idm168"></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="idm140317074930736"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm171"></a><h4>Example</h4><pre class="screen">
 # ctdb listnodes
-       </pre></div></div><div class="refsect2"><a name="idm140317074929120"></a><h3>natgw {master|list|status}</h3><p>
+       </pre></div></div><div class="refsect2"><a name="idm174"></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
@@ -220,16 +214,16 @@ pnn:0       UNHEALTHY (THIS NODE)
 pnn:1       OK
 pnn:2       OK
 pnn:3       OK
-           </pre></dd></dl></div></div><div class="refsect2"><a name="idm140317074918016"></a><h3>ping</h3><p>
+           </pre></dd></dl></div></div><div class="refsect2"><a name="idm200"></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="idm140317074916880"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm203"></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="idm140317074915360"></a><h3>ifaces</h3><p>
+       </pre></div></div><div class="refsect2"><a name="idm206"></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="idm140317074914192"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm209"></a><h4>Example</h4><pre class="screen">
 # ctdb ifaces
 Interfaces on node 0
 name:eth5 link:up references:2
@@ -243,9 +237,9 @@ name:eth2 link:up references:1
-       </pre></div></div><div class="refsect2"><a name="idm140317074912400"></a><h3>ip</h3><p>
+       </pre></div></div><div class="refsect2"><a name="idm212"></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="idm140317074911024"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm215"></a><h4>Example</h4><pre class="screen">
 # ctdb ip -v
 Public IPs on node 0 node[1] active[] available[eth2,eth3] configured[eth2,eth3]
@@ -267,9 +261,9 @@ Public IPs on node 0
-       </pre></div></div><div class="refsect2"><a name="idm140317074908480"></a><h3>ipinfo <em class="parameter"><code>IP</code></em></h3><p>
+       </pre></div></div><div class="refsect2"><a name="idm218"></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="idm140317074906864"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm222"></a><h4>Example</h4><pre class="screen">
 # ctdb ipinfo
 Public IP[] info on node 0
@@ -277,33 +271,25 @@ CurrentNode:0
 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="idm140317074905120"></a><h3>event run|status|script list|script enable|script disable</h3><p>
+       </pre></div></div><div class="refsect2"><a name="idm225"></a><h3>event run|status|script list|script enable|script disable</h3><p>
        This command is used to control event daemon and to inspect
        status of various events.
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">run <em class="parameter"><code>EVENT</code></em> <em class="parameter"><code>TIMEOUT</code></em> [<span class="optional"><em class="parameter"><code>ARGUMENTS</code></em></span>] </span></dt><dd><p>
+      </p><p>
+       The commands below require a component to be specified.  In
+       the current version the only valid component is
+       <code class="literal">legacy</code>.
+      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">run <em class="parameter"><code>TIMEOUT</code></em> <em class="parameter"><code>COMPONENT</code></em> <em class="parameter"><code>EVENT</code></em> [<span class="optional"><em class="parameter"><code>ARGUMENTS</code></em></span>] </span></dt><dd><p>
             This command can be used to manually run specified EVENT
-            with optional ARGUMENTS.  The event will be allowed to run
-            a maximum of TIMEOUT seconds.  If TIMEOUT is 0, then there
-            is no time limit for running the event.
-           </p></dd><dt><span class="term">status [<span class="optional"><em class="parameter"><code>EVENT</code></em></span>] [<span class="optional">lastrun|lastpass|lastfail</span>]</span></dt><dd><p>
+            in COMPONENT with optional ARGUMENTS.  The event will be
+            allowed to run a maximum of TIMEOUT seconds.  If TIMEOUT
+            is 0, then there is no time limit for running the event.
+           </p></dd><dt><span class="term">status <em class="parameter"><code>COMPONENT</code></em> <em class="parameter"><code>EVENT</code></em></span></dt><dd><p>
              This command displays the last execution status of the
-             specified EVENT.  If no event is specified, then the status
-             of last executed monitor event will be displayed.
-           </p><p>
-             To see the last successful execution of the event, lastpass
-             can be specified. Similarly lastfail can be specified
-             to see the last unsuccessful execution of the event.
-             The optional lastrun can be specified to query the last
-             execution of the event.
+             specified EVENT in COMPONENT.
              The command will terminate with the exit status
              corresponding to the overall status of event that is
-             displayed.  If lastpass is specified, then the command will
-             always terminate with 0.  If lastfail is specified then the
-             command will always terminate with non-zero exit status.
-             If lastrun is specified, then the command will terminate
-             with 0 or not depending on if the last execution of the
-             event was successful or not.
+             displayed.
              The output is the list of event scripts executed.
              Each line shows the name, status, duration and start time
@@ -315,7 +301,6 @@ Interface[2]: Name:eth5 Link:up References:2 (active)
 01.reclock           OK         0.013 Sat Dec 17 19:39:11 2016
 05.system            OK         0.029 Sat Dec 17 19:39:11 2016
 06.nfs               OK         0.014 Sat Dec 17 19:39:11 2016
-10.external          DISABLED  
 10.interface         OK         0.037 Sat Dec 17 19:39:11 2016
 11.natgw             OK         0.011 Sat Dec 17 19:39:11 2016
 11.routing           OK         0.007 Sat Dec 17 19:39:11 2016
@@ -329,38 +314,44 @@ Interface[2]: Name:eth5 Link:up References:2 (active)
 60.nfs               OK         0.376 Sat Dec 17 19:39:12 2016
 70.iscsi             OK         0.009 Sat Dec 17 19:39:12 2016
 91.lvs               OK         0.007 Sat Dec 17 19:39:12 2016
-99.timeout           OK         0.007 Sat Dec 17 19:39:12 2016
-           </pre></dd><dt><span class="term">script list</span></dt><dd><p>
-             List the available event scripts.
+           </pre></dd><dt><span class="term">script list <em class="parameter"><code>COMPONENT</code></em></span></dt><dd><p>
+             List the available event scripts in COMPONENT.  Enabled
+             scripts are flagged with a '*'.
+           </p><p>
+             Generally, event scripts are provided by CTDB.  However,
+             local or 3rd party event scripts may also be available.
+             These are shown in a separate section after those
+             provided by CTDB.
              Example output:
            </p><pre class="screen">
-10.external          DISABLED
-           </pre></dd><dt><span class="term">script enable <em class="parameter"><code>SCRIPT</code></em></span></dt><dd><p>
-             Enable the specified event SCRIPT.  Only enabled scripts will be
-             executed when running any event.
-           </p></dd><dt><span class="term">script disable <em class="parameter"><code>SCRIPT</code></em></span></dt><dd><p>
-             Disable the specified event SCRIPT.  This will prevent the script
-             from executing when running any event.
-           </p></dd></dl></div></div><div class="refsect2"><a name="idm140317074884112"></a><h3>scriptstatus</h3><p>
+* 00.ctdb             
+* 01.reclock          
+* 05.system           
+* 06.nfs              
+* 10.interface        
+  11.natgw            
+  11.routing          
+  13.per_ip_routing   
+  20.multipathd       
+  31.clamd            
+  40.vsftpd           
+  41.httpd            
+* 49.winbind          
+* 50.samba            
+* 60.nfs              
+  70.iscsi            
+  91.lvs              
+* 02.local            
+           </pre></dd><dt><span class="term">script enable <em class="parameter"><code>COMPONENT</code></em> <em class="parameter"><code>SCRIPT</code></em></span></dt><dd><p>
+             Enable the specified event SCRIPT in COMPONENT.  Only
+             enabled scripts will be executed when running any event.
+           </p></dd><dt><span class="term">script disable <em class="parameter"><code>COMPONENT</code></em> <em class="parameter"><code>SCRIPT</code></em></span></dt><dd><p>
+             Disable the specified event SCRIPT in COMPONENT.  This
+             will prevent the script from executing when running any
+             event.
+           </p></dd></dl></div></div><div class="refsect2"><a name="idm270"></a><h3>scriptstatus</h3><p>
        This command displays which event scripts where run in the previous
        monitoring cycle and the result of each script. If a script
        failed with an error, causing the node to become unhealthy,
@@ -369,13 +360,12 @@ Interface[2]: Name:eth5 Link:up References:2 (active)
        This command is deprecated.  It's provided for backward
        compatibility.  In place of <span class="command"><strong>ctdb scriptstatus</strong></span>,
        use <span class="command"><strong>ctdb event status</strong></span>.
-      </p><div class="refsect3"><a name="idm140317074881104"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm276"></a><h4>Example</h4><pre class="screen">
 # ctdb scriptstatus
 00.ctdb              OK         0.011 Sat Dec 17 19:40:46 2016
 01.reclock           OK         0.010 Sat Dec 17 19:40:46 2016
 05.system            OK         0.030 Sat Dec 17 19:40:46 2016
 06.nfs               OK         0.014 Sat Dec 17 19:40:46 2016
-10.external          DISABLED  
 10.interface         OK         0.041 Sat Dec 17 19:40:46 2016
 11.natgw             OK         0.008 Sat Dec 17 19:40:46 2016
 11.routing           OK         0.007 Sat Dec 17 19:40:46 2016
@@ -387,11 +377,11 @@ Interface[2]: Name:eth5 Link:up References:2 (active)
 49.winbind           OK         0.022 Sat Dec 17 19:40:46 2016
 50.samba             ERROR      0.077 Sat Dec 17 19:40:46 2016
   OUTPUT: ERROR: samba tcp port 445 is not responding
-      </pre></div></div><div class="refsect2"><a name="idm140317074878576"></a><h3>listvars</h3><p>
+      </pre></div></div><div class="refsect2"><a name="idm279"></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="idm140317074877344"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm282"></a><h4>Example</h4><pre class="screen">
 # ctdb listvars
 SeqnumInterval          = 1000
 ControlTimeout          = 60
@@ -413,7 +403,6 @@ DatabaseMaxDead         = 5
 RerecoveryTimeout       = 10
 EnableBans              = 1
 NoIPFailback            = 0
-DisableIPFailover       = 0
 VerboseMemoryNames      = 0
 RecdPingTimeout         = 60
 RecdFailCount           = 10
@@ -441,22 +430,20 @@ DBRecordCountWarn       = 100000
 DBRecordSizeWarn        = 10000000
 DBSizeWarn              = 100000000
 PullDBPreallocation     = 10485760
-NoIPHostOnAllDisabled   = 0
-TDBMutexEnabled         = 0
 LockProcessesPerDB      = 200
 RecBufferSizeLimit      = 1000000
 QueueBufferSize         = 1024
 IPAllocAlgorithm        = 2
-       </pre></div></div><div class="refsect2"><a name="idm140317074874176"></a><h3>getvar <em class="parameter"><code>NAME</code></em></h3><p>
+       </pre></div></div><div class="refsect2"><a name="idm285"></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="idm140317074872656"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm289"></a><h4>Example</h4><pre class="screen">
 # ctdb getvar MonitorInterval
 MonitorInterval         = 15
-       </pre></div></div><div class="refsect2"><a name="idm140317074871136"></a><h3>setvar <em class="parameter"><code>NAME</code></em> <em class="parameter"><code>VALUE</code></em></h3><p>
+       </pre></div></div><div class="refsect2"><a name="idm292"></a><h3>setvar <em class="parameter"><code>NAME</code></em> <em class="parameter"><code>VALUE</code></em></h3><p>
        Set the runtime value of a tuneable variable.
-      </p><div class="refsect3"><a name="idm140317074868992"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm297"></a><h4>Example</h4><pre class="screen">
 # ctdb setvar MonitorInterval 20
-       </pre></div></div><div class="refsect2"><a name="idm140317074867472"></a><h3>lvs {master|list|status}</h3><p>
+       </pre></div></div><div class="refsect2"><a name="idm300"></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
@@ -483,7 +470,7 @@ pnn:0        UNHEALTHY (THIS NODE)
 pnn:1        UNHEALTHY
 pnn:2        OK
 pnn:3        OK
-      </pre></dd></dl></div></div><div class="refsect2"><a name="idm140317074856736"></a><h3>getcapabilities</h3><p>
+      </pre></dd></dl></div></div><div class="refsect2"><a name="idm326"></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.
@@ -492,12 +479,12 @@ pnn:3        OK
       </p><pre class="screen">
-      </pre></div><div class="refsect2"><a name="idm140317074853216"></a><h3>statistics</h3><p>
+      </pre></div><div class="refsect2"><a name="idm335"></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="idm140317074851120"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm341"></a><h4>Example</h4><pre class="screen">
 # ctdb statistics
 CTDB version 1
 Current time of statistics  :                Tue Mar  8 15:18:51 2016
@@ -549,15 +536,15 @@ Statistics collected since  : (003 21:31:32) Fri Mar  4 17:47:19 2016
  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="idm140317074847520"></a><h3>statisticsreset</h3><p>
+       </pre></div></div><div class="refsect2"><a name="idm344"></a><h3>statisticsreset</h3><p>
        This command is used to clear all statistics counters in a node.
        Example: ctdb statisticsreset
-      </p></div><div class="refsect2"><a name="idm140317074845888"></a><h3>dbstatistics <em class="parameter"><code>DB</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm348"></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="idm140317074843344"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm355"></a><h4>Example</h4><pre class="screen">
 # ctdb dbstatistics locking.tdb
 DB Statistics: locking.tdb
  ro_delegations                     0
@@ -573,13 +560,13 @@ DB Statistics: locking.tdb
  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="idm140317074841152"></a><h3>getreclock</h3><p>
+       </pre></div></div><div class="refsect2"><a name="idm358"></a><h3>getreclock</h3><p>
        Show details of the recovery lock, if any.
        Example output:
       </p><pre class="screen">
-      </pre></div><div class="refsect2"><a name="idm140317074838992"></a><h3>getdebug</h3><p>
+      </pre></div><div class="refsect2"><a name="idm363"></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.
        The debug levels are mapped to the corresponding syslog levels.
@@ -589,29 +576,29 @@ DB Statistics: locking.tdb
        The list of debug levels from highest to lowest are :
-      </p></div><div class="refsect2"><a name="idm140317074836272"></a><h3>setdebug <em class="parameter"><code>DEBUGLEVEL</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm369"></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.
        The debuglevel is one of ERROR WARNING NOTICE INFO DEBUG
-      </p></div><div class="refsect2"><a name="idm140317074834064"></a><h3>getpid</h3><p>
+      </p></div><div class="refsect2"><a name="idm374"></a><h3>getpid</h3><p>
        This command will return the process id of the ctdb daemon.
-      </p></div><div class="refsect2"><a name="idm140317074832832"></a><h3>disable</h3><p>
+      </p></div><div class="refsect2"><a name="idm377"></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="idm140317074831392"></a><h3>enable</h3><p>
+      </p></div><div class="refsect2"><a name="idm380"></a><h3>enable</h3><p>
        Re-enable a node that has been administratively disabled.
-      </p></div><div class="refsect2"><a name="idm140317074830160"></a><h3>stop</h3><p>
+      </p></div><div class="refsect2"><a name="idm383"></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="idm140317074828608"></a><h3>continue</h3><p>
+      </p></div><div class="refsect2"><a name="idm386"></a><h3>continue</h3><p>
        Re-start a node that has been administratively stopped.
-      </p></div><div class="refsect2"><a name="idm140317074827376"></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>
+      </p></div><div class="refsect2"><a name="idm389"></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
@@ -621,7 +608,7 @@ DB Statistics: locking.tdb
        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="idm140317074822960"></a><h3>delip <em class="parameter"><code>IPADDR</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm397"></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
@@ -634,7 +621,7 @@ DB Statistics: locking.tdb
        public addresses file is re-read.  If you want this change to
        be permanent you must also update the public addresses file
-      </p></div><div class="refsect2"><a name="idm140317074819696"></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="idm403"></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.
@@ -645,9 +632,9 @@ DB Statistics: locking.tdb
        IPAllocAlgorithm != 0
        NoIPFailback = 1
-      </p></div><div class="refsect2"><a name="idm140317074815936"></a><h3>shutdown</h3><p>
+      </p></div><div class="refsect2"><a name="idm411"></a><h3>shutdown</h3><p>
        This command will shutdown a specific CTDB daemon.
-      </p></div><div class="refsect2"><a name="idm140317074814704"></a><h3>setlmasterrole on|off</h3><p>
+      </p></div><div class="refsect2"><a name="idm414"></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.
        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.
@@ -655,13 +642,13 @@ DB Statistics: locking.tdb
        Once this setting has been enabled/disabled, you need to perform a recovery for it to take effect.
        See also "ctdb getcapabilities"
-      </p></div><div class="refsect2"><a name="idm140317074811824"></a><h3>setrecmasterrole on|off</h3><p>
+      </p></div><div class="refsect2"><a name="idm420"></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.
        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.
        See also "ctdb getcapabilities"
-      </p></div><div class="refsect2"><a name="idm140317074809296"></a><h3>reloadnodes</h3><p>
+      </p></div><div class="refsect2"><a name="idm425"></a><h3>reloadnodes</h3><p>
        This command is used when adding new nodes, or removing
        existing nodes from an existing cluster.
@@ -710,7 +697,7 @@ 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="idm140317074789312"></a><h3>
+         </p></li></ol></div></div><div class="refsect2"><a name="idm466"></a><h3>
        [<span class="optional"><em class="parameter"><code>PNN-LIST</code></em></span>]
@@ -723,21 +710,32 @@ DB Statistics: locking.tdb
        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="idm140317074786512"></a><h3>getdbmap</h3><p>
-       This command lists all clustered TDB databases that the CTDB daemon has attached to. Some databases are flagged as PERSISTENT, this means that the database stores data persistently and the data will remain across reboots. One example of such a database is secrets.tdb where information about how the cluster was joined to the domain is stored.
-      </p><p>
-       If a PERSISTENT database is not in a healthy state the database is
-       flagged as UNHEALTHY. If there's at least one completely healthy node running in
-       the cluster, it's possible that the content is restored by a recovery
-       run automaticly. Otherwise an administrator needs to analyze the
-       problem.
+      </p></div><div class="refsect2"><a name="idm472"></a><h3>getdbmap</h3><p>
+       This command lists all clustered TDB databases that the CTDB
+       daemon has attached to. Some databases are flagged as PERSISTENT,
+       this means that the database stores data persistently and the
+       data will remain across reboots. One example of such a database
+       is secrets.tdb where information about how the cluster was joined
+       to the domain is stored.  Some database are flagged as REPLICATED,
+       this means that the data in that database is replicated across all
+       the nodes.  But the data will not remain across reboots.  This
+       type of database is used by CTDB to store it's internal state.
+      </p><p>
+       If a PERSISTENT database is not in a healthy state the database
+       is flagged as UNHEALTHY. If there's at least one completely
+       healthy node running in the cluster, it's possible that the
+       content is restored by a recovery run automaticly. Otherwise an
+       administrator needs to analyze the problem.
        See also "ctdb getdbstatus", "ctdb backupdb", "ctdb restoredb",
        "ctdb dumpbackup", "ctdb wipedb", "ctdb setvar AllowUnhealthyDBRead 1"
        and (if samba or tdb-utils are installed) "tdbtool check".
-       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="idm140317074783200"></a><h4>Example</h4><pre class="screen">
+       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="idm478"></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
@@ -758,7 +756,7 @@ dbid:0xb775fff6 name:secrets.tdb path:/usr/local/var/lib/ctdb/persistent/secrets
 # ctdb -X getdbmap
-       </pre></div></div><div class="refsect2"><a name="idm140317074780448"></a><h3>
+       </pre></div></div><div class="refsect2"><a name="idm481"></a><h3>
        <em class="parameter"><code>DB</code></em>
        <em class="parameter"><code>FILE</code></em>
@@ -767,7 +765,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="idm140317074776624"></a><h3>
+      </p></div><div class="refsect2"><a name="idm488"></a><h3>
        <em class="parameter"><code>FILE</code></em>
        [<span class="optional"><em class="parameter"><code>DB</code></em></span>]
@@ -777,45 +775,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="idm140317074773808"></a><h3>setdbreadonly <em class="parameter"><code>DB</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm494"></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="idm140317074771872"></a><h3>setdbsticky <em class="parameter"><code>DB</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm498"></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="idm140317074769792"></a><h2>INTERNAL COMMANDS</h2><p>
+      </p></div></div><div class="refsect1"><a name="idm502"></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="idm140317074768576"></a><h3>gettickles <em class="parameter"><code>IPADDR</code></em></h3><p>
+    </p><div class="refsect2"><a name="idm505"></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="idm140317074766816"></a><h3>gratarp <em class="parameter"><code>IPADDR</code></em> <em class="parameter"><code>INTERFACE</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm509"></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="idm140317074764384"></a><h3>
+      </p></div><div class="refsect2"><a name="idm514"></a><h3>
        pdelete <em class="parameter"><code>DB</code></em> <em class="parameter"><code>KEY</code></em>
        Delete KEY from DB.
-      </p></div><div class="refsect2"><a name="idm140317074761984"></a><h3>
+      </p></div><div class="refsect2"><a name="idm519"></a><h3>
        pfetch <em class="parameter"><code>DB</code></em> <em class="parameter"><code>KEY</code></em>
        Print the value associated with KEY in DB.
-      </p></div><div class="refsect2"><a name="idm140317074759584"></a><h3>
+      </p></div><div class="refsect2"><a name="idm524"></a><h3>
        <em class="parameter"><code>DB</code></em>
        <em class="parameter"><code>KEY</code></em>
        <em class="parameter"><code>FILE</code></em>
        Store KEY in DB with contents of FILE as the associated value.
-      </p></div><div class="refsect2"><a name="idm140317074756480"></a><h3>
+      </p></div><div class="refsect2"><a name="idm530"></a><h3>
        <em class="parameter"><code>DB</code></em>
        [<span class="optional"><em class="parameter"><code>FILE</code></em></span>]
@@ -827,7 +825,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
-      </p></div><div class="refsect2"><a name="idm140317074753216"></a><h3>runstate [setup|first_recovery|startup|running]</h3><p>
+      </p></div><div class="refsect2"><a name="idm537"></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.
@@ -835,16 +833,16 @@ 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
-      </p><div class="refsect3"><a name="idm140317074751488"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm541"></a><h4>Example</h4><pre class="screen">
 # ctdb runstate
-       </pre></div></div><div class="refsect2"><a name="idm140317074749968"></a><h3>setifacelink <em class="parameter"><code>IFACE</code></em> up|down</h3><p>
+       </pre></div></div><div class="refsect2"><a name="idm544"></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.
        Example: ctdb setifacelink eth0 up
-      </p></div><div class="refsect2"><a name="idm140317074747088"></a><h3>tickle</h3><p>
+      </p></div><div class="refsect2"><a name="idm550"></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:
@@ -860,16 +858,16 @@ RUNNING
        other end.
        TCP tickles are useful to "tickle" clients after a IP failover has
-       occured since this will make the client immediately recognize the
+       occurred since this will make the client immediately recognize the
        TCP connection has been disrupted and that the client will need
        to reestablish. This greatly speeds up the time it takes for a client
        to detect and reestablish after an IP failover in the ctdb cluster.
-      </p></div><div class="refsect2"><a name="idm140317074740768"></a><h3>version</h3><p>
+      </p></div><div class="refsect2"><a name="idm561"></a><h3>version</h3><p>
        Display the CTDB version.
-      </p></div></div><div class="refsect1"><a name="idm140317074739488"></a><h2>DEBUGGING COMMANDS</h2><p>
+      </p></div></div><div class="refsect1"><a name="idm564"></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="idm140317074738320"></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="idm567"></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
@@ -887,11 +885,15 @@ 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="idm140317074729296"></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="idm140317074727456"></a><h3>getdbstatus <em class="parameter"><code>DB</code></em></h3><p>
+         </p></dd></dl></div></div><div class="refsect2"><a name="idm590"></a><h3>process-exists <em class="parameter"><code>PID</code></em> <em class="parameter"><code>[SRVID]</code></em></h3><p>
+       This command checks if a specific process exists on the CTDB
+       host. This is mainly used by Samba to check if remote instances
+       of samba are still running or not.  When the optional SRVID
+       argument is specified, the command check if a specific process
+       exists on the CTDB host and has registered for specified SRVID.
+      </p></div><div class="refsect2"><a name="idm595"></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="idm140317074725856"></a><h4>Example</h4><pre class="screen">
+      </p><div class="refsect3"><a name="idm599"></a><h4>Example</h4><pre class="screen">
 # ctdb getdbstatus test.tdb.0
 dbid: 0x122224da
 name: test.tdb
@@ -905,28 +907,24 @@ name: registry.tdb
 path: /usr/local/var/lib/ctdb/persistent/registry.tdb.0
 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="idm140317074723888"></a><h3>catdb <em class="parameter"><code>DB</code></em></h3><p>
+       </pre></div></div><div class="refsect2"><a name="idm602"></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="idm140317074722240"></a><h3>cattdb <em class="parameter"><code>DB</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm606"></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="idm140317074720512"></a><h3>dumpdbbackup <em class="parameter"><code>FILE</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm610"></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="idm140317074718160"></a><h3>wipedb <em class="parameter"><code>DB</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm615"></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="idm140317074716512"></a><h3>recover</h3><p>
+      </p></div><div class="refsect2"><a name="idm619"></a><h3>recover</h3><p>
        This command will trigger the recovery daemon to do a cluster
-      </p></div><div class="refsect2"><a name="idm140317074715264"></a><h3>ipreallocate, sync</h3><p>
+      </p></div><div class="refsect2"><a name="idm622"></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="idm140317074713712"></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="idm140317074712368"></a><h3>attach <em class="parameter"><code>DBNAME</code></em> [persistent]</h3><p>
+      </p></div><div class="refsect2"><a name="idm625"></a><h3>attach <em class="parameter"><code>DBNAME</code></em> [persistent|replicated]</h3><p>
        Create a new CTDB database called DBNAME and attach to it on
        all nodes.
-      </p></div><div class="refsect2"><a name="idm140317074710496"></a><h3>detach <em class="parameter"><code>DB-LIST</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm629"></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
@@ -934,13 +932,13 @@ HEALTH: NO-HEALTHY-NODES - ERROR - Backup of corrupted TDB in '/usr/local/var/li
        All nodes should be active and tunable AllowClientDBAccess should
        be disabled on all nodes before detaching databases.
-      </p></div><div class="refsect2"><a name="idm140317074708064"></a><h3>dumpmemory</h3><p>
+      </p></div><div class="refsect2"><a name="idm634"></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="idm140317074706768"></a><h3>rddumpmemory</h3><p>
+      </p></div><div class="refsect2"><a name="idm637"></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="idm140317074705456"></a><h3>ban <em class="parameter"><code>BANTIME</code></em></h3><p>
+      </p></div><div class="refsect2"><a name="idm640"></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.
@@ -954,21 +952,11 @@ HEALTH: NO-HEALTHY-NODES - ERROR - Backup of corrupted TDB in '/usr/local/var/li
        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="idm140317074701472"></a><h3>unban</h3><p>
+      </p></div><div class="refsect2"><a name="idm648"></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="idm140317074700160"></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="idm140317074698352"></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="idm140317074695968"></a><h2>SEE ALSO</h2><p>
+      </p></div></div><div class="refsect1"><a name="idm651"></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 32c7d58..f59e7ea 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.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="idm139628772730512"></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.
@@ -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="idm139628772159680"></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 @@
     CTDB provides an "all active" cluster, where services are load
     balanced across all nodes.
-  </p></div><div class="refsect1"><a name="idm139628770890960"></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
       to assert its privileged role in the cluster.
       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
+      (specified by <em class="parameter"><code>recovery lock</code></em> in the
+      <code class="literal">[cluster]</code> section of
+      <span class="citerefentry"><span class="refentrytitle">ctdb.conf</span>(5)</span>) 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.
       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.
+      the first character of <em class="parameter"><code>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.
       If a cluster becomes partitioned (for example, due to a
       communication failure) and a different recovery master is
@@ -72,7 +73,7 @@
       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="idm139628773418304"></a><h2>Private vs Public addresses</h2><p>
+    </p></div><div class="refsect1"><a name="idm49"></a><h2>Private vs Public addresses</h2><p>
       Each node in a CTDB cluster has multiple IP addresses assigned
       to it:
            One or more public IP addresses that are used to provide
            NAS or other services.
-    </p><div class="refsect2"><a name="idm139628775259760"></a><h3>Private address</h3><p>
+    </p><div class="refsect2"><a name="idm57"></a><h3>Private address</h3><p>
         Each node is configured with a unique, permanently assigned
         private address.  This address is configured by the operating
         system.  This address uniquely identifies a physical node in
         the cluster and is the address that CTDB daemons will use to
         communicate with the CTDB daemons on other nodes.
-        Private addresses are listed in the file specified by the
-        <code class="varname">CTDB_NODES</code> configuration variable (see
-        <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>, default
-        <code class="filename">/usr/local/etc/ctdb/nodes</code>).  This file contains the
-        list of private addresses for all nodes in the cluster, one
-        per line. This file must be the same on all nodes in the
-        cluster.
+       Private addresses are listed in the file
+       <code class="filename">/usr/local/etc/ctdb/nodes</code>).  This file
+       contains the list of private addresses for all nodes in the
+       cluster, one per line. This file must be the same on all nodes
+       in the cluster.
+      </p><p>
+       Some users like to put this configuration file in their
+       cluster filesystem.  A symbolic link should be used in this
+       case.
        Private addresses should not be used by clients to connect to
        services provided by the cluster.
-      </pre></div><div class="refsect2"><a name="idm139628775740336"></a><h3>Public addresses</h3><p>
+      </pre></div><div class="refsect2"><a name="idm68"></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
         clients, as long as there are nodes available capable of
         hosting this address.
-       The public address configuration is stored in a file on each
-       node specified by the <code class="varname">CTDB_PUBLIC_ADDRESSES</code>
-       configuration variable (see
-       <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>, recommended
-       <code class="filename">/usr/local/etc/ctdb/public_addresses</code>).  This file
-       contains a list of the public addresses that the node is
-       capable of hosting, one per line.  Each entry also contains
-       the netmask and the interface to which the address should be
-       assigned.
+       The public address configuration is stored in
+       <code class="filename">/usr/local/etc/ctdb/public_addresses</code> on
+       each node.  This file contains a list of the public addresses
+       that the node is capable of hosting, one per line.  Each entry
+       also contains the netmask and the interface to which the
+       address should be assigned.  If this file is missing then no
+       public addresses are configured.
+      </p><p>
+       Some users who have the same public addresses on all nodes
+       like to put this configuration file in their cluster
+       filesystem.  A symbolic link should be used in this case.
        Example <code class="filename">/usr/local/etc/ctdb/public_addresses</code> for a
        node that can host 4 public addresses, on 2 different
@@ -188,7 +193,7 @@ Node 3:/usr/local/etc/ctdb/public_addresses
         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="idm139628775904560"></a><h2>Node status</h2><p>
+      </p></div></div><div class="refsect1"><a name="idm86"></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.
@@ -233,7 +238,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="idm139628775864032"></a><h2>CAPABILITIES</h2><p>
+         </p></dd></dl></div></div><div class="refsect1"><a name="idm126"></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>
@@ -252,7 +257,7 @@ Node 3:/usr/local/etc/ctdb/public_addresses
       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="idm139628775857328"></a><h2>LVS</h2><p>
+    </p></div><div class="refsect1"><a name="idm141"></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
@@ -284,7 +289,7 @@ Node 3:/usr/local/etc/ctdb/public_addresses
       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
+      command <span class="command"><strong>ctdb lvs master</strong></span> will show which node
       is the current LVS master.
       The path used for a client I/O is:
@@ -305,11 +310,11 @@ Node 3:/usr/local/etc/ctdb/public_addresses
       multiplex. This means that you should not use LVS if your I/O
       pattern is write-intensive since you will be limited in the
       available network bandwidth that node can handle.  LVS does work
-      wery well for read-intensive workloads where only smallish READ
+      very well for read-intensive workloads where only smallish READ
       requests are going through the LVSMASTER bottleneck and the
       majority of the traffic volume (the data in the read replies)
       goes straight from the processing node back to the clients. For
-      read-intensive i/o patterns you can acheive very high throughput
+      read-intensive i/o patterns you can achieve very high throughput
       rates in this mode.
       Note: you can use LVS and public addresses at the same time.
@@ -326,7 +331,7 @@ 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="idm139628775835584"></a><h3>Configuration</h3><p>
+    </p><div class="refsect2"><a name="idm165"></a><h3>Configuration</h3><p>
        To activate LVS on a CTDB node you must specify the
        <code class="varname">CTDB_LVS_PUBLIC_IFACE</code>,
        <code class="varname">CTDB_LVS_PUBLIC_IP</code> and
@@ -360,7 +365,7 @@ CTDB_LVS_NODES=/usr/local/etc/ctdb/lvs_nodes slave-only
-      </pre></div></div><div class="refsect1"><a name="idm139628775827248"></a><h2>TRACKING AND RESETTING TCP CONNECTIONS</h2><p>
+      </pre></div></div><div class="refsect1"><a name="idm181"></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
@@ -373,7 +378,7 @@ CTDB_LVS_NODES=/usr/local/etc/ctdb/lvs_nodes
       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="idm139628775824432"></a><h2>NAT GATEWAY</h2><p>
+    </p></div><div class="refsect1"><a name="idm185"></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)
@@ -390,7 +395,7 @@ CTDB_LVS_NODES=/usr/local/etc/ctdb/lvs_nodes
       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="idm139628770293920"></a><h3>Operation</h3><p>
+    </p><div class="refsect2"><a name="idm190"></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
@@ -411,7 +416,7 @@ CTDB_LVS_NODES=/usr/local/etc/ctdb/lvs_nodes
        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="idm139628770290912"></a><h3>Configuration</h3><p>
+      </p></div><div class="refsect2"><a name="idm195"></a><h3>Configuration</h3><p>
        NATGW is usually configured similar to the following example configuration:
       </p><pre class="screen">
@@ -428,9 +433,9 @@ CTDB_NATGW_DEFAULT_GATEWAY=
        functionality of those nodes.
        See the <em class="citetitle">NAT GATEWAY</em> section in
-       <span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> for more details of
+       <span class="citerefentry"><span class="refentrytitle">ctdb-script.options</span>(5)</span> for more details of
        NATGW configuration.
-      </p></div><div class="refsect2"><a name="idm139628770286144"></a><h3>Implementation details</h3><p>
+      </p></div><div class="refsect2"><a name="idm206"></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