<refmeta>
<refentrytitle>ctdbd</refentrytitle>
<manvolnum>1</manvolnum>
+ <refmiscinfo class="source">ctdb</refmiscinfo>
+ <refmiscinfo class="manual">CTDB - clustered TDB database</refmiscinfo>
</refmeta>
<arg choice="opt">--no-lmaster</arg>
<arg choice="opt">--no-recmaster</arg>
<arg choice="opt">--nosetsched</arg>
+ <arg choice="req">--notification-script=<filename></arg>
<arg choice="opt">--public-addresses=<filename></arg>
<arg choice="opt">--public-interface=<interface></arg>
<arg choice="req">--reclock=<filename></arg>
<arg choice="opt">--start-as-disabled</arg>
<arg choice="opt">--start-as-stopped</arg>
<arg choice="opt">--syslog</arg>
+ <arg choice="opt">--log-ringbuf-size=<num-entries></arg>
<arg choice="opt">--torture</arg>
<arg choice="opt">--transport=<STRING></arg>
<arg choice="opt">--usage</arg>
This option is used to tell ctdbd to NOT 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 dont want to attach valgrind or gdb to a
+ valgrind or gdb. (You don't want to attach valgrind or gdb to a
real-time process.)
</para>
</listitem>
</varlistentry>
+ <varlistentry><term>--notification-script=<filename></term>
+ <listitem>
+ <para>
+ This specifies a script which will be invoked by ctdb when certain
+ state changes occur in ctdbd and when you may want to trigger this
+ to run certain scripts.
+ </para>
+ <para>
+ This file is usually /etc/ctdb/notify.sh .
+ </para>
+ <para>
+ See the NOTIFICATION SCRIPT section below for more information.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry><term>--public_addresses=<filename></term>
<listitem>
<para>
</para>
<para>
This is only required when using public ip addresses and only when
- you dont specify the interface explicitly in /etc/ctdb/public_addresses or when you are using --single-public-ip.
+ you don't specify the interface explicitly in /etc/ctdb/public_addresses or when you are using --single-public-ip.
</para>
<para>
If you omit this argument when using public addresses or single public ip, ctdb will not be able to send out Gratious ARPs correctly or be able to kill tcp connections correctly which will lead to application failures.
</listitem>
</varlistentry>
+ <varlistentry><term>--log-ringbuf-size=<num-entries></term>
+ <listitem>
+ <para>
+ In addition to the normal loggign to a log file,
+ CTDBD also keeps a in-memory ringbuffer containing the most recent
+ log entries for all log levels (except DEBUG).
+ </para>
+ <para>
+ This is useful since it allows for keeping continous logs to a file
+ at a reasonable non-verbose level, but shortly after an incident has
+ occured, a much more detailed log can be pulled from memory. This
+ can allow you to avoid having to reproduce an issue due to the
+ on-disk logs being of insufficient detail.
+ </para>
+ <para>
+ This in-memory ringbuffer contains a fixed number of the most recent
+ entries. This is settable at startup either through the
+ --log-ringbuf-size argument, or preferably by using
+ CTDB_LOG_RINGBUF_SIZE in the sysconfig file.
+ </para>
+ <para>
+ Use the "ctdb getlog" command to access this log.
+ </para>
+ </listitem>
+ </varlistentry>
+
+
<varlistentry><term>--torture</term>
<listitem>
<para>
eventually become banned from the cluster.
This controls how long the culprit node will be banned from the cluster
before it is allowed to try to join the cluster again.
- Dont set to small. A node gets banned for a reason and it is usually due
+ Don't set to small. A node gets banned for a reason and it is usually due
to real problems with the node.
</para>
</refsect2>
<refsect2><title>EnableBans</title>
<para>Default: 1</para>
<para>
- When set to 0, this disables BANNING completely in the cluster and thus nodes can not get banned, even it they break. Dont set to 0.
+ 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.
</para>
</refsect2>
<refsect2><title>DeterministicIPs</title>
# CTDB_NATGW_DEFAULT_GATEWAY=10.0.0.1
# CTDB_NATGW_PRIVATE_NETWORK=10.1.1.0/24
# CTDB_NATGW_NODES=/etc/ctdb/natgw_nodes
+#
+# Normally any node in the natgw group can act as the natgw master.
+# In some configurations you may have special nodes that is a part of the
+# cluster/natgw group, but where the node lacks connectivity to the
+# public network.
+# For these cases, set this variable to make these nodes not able to
+# become natgw master.
+#
+# CTDB_NATGW_SLAVE_ONLY=yes
</screen>
</refsect2>
</refsect2>
+ <refsect2><title>Removing/Changing NATGW at runtime</title>
+ <para>
+ The following are the procedures to change/remove a NATGW configuration
+ at runtime, without having to restart ctdbd.
+ </para>
+
+ <para>
+ If you want to remove NATGW completely from a node, use these steps:
+ </para>
+ <screen format="linespecific">
+1, Run 'CTDB_BASE=/etc/ctdb /etc/ctdb/events.d/11.natgw removenatgw'
+2, Then remove the configuration from /etc/sysconfig/ctdb
+ </screen>
+
+ <para>
+ If you want to change the NATGW configuration on a node :
+ </para>
+ <screen format="linespecific">
+1, Run 'CTDB_BASE=/etc/ctdb /etc/ctdb/events.d/11.natgw removenatgw'
+2, Then change the configuration in /etc/sysconfig/ctdb
+3, Run 'CTDB_BASE=/etc/ctdb /etc/ctdb/events.d/11.natgw updatenatgw'
+ </screen>
+
+ </refsect2>
+
</refsect1>
+ <refsect1><title>NOTIFICATION SCRIPT</title>
+ <para>
+ Notification scripts are used with ctdb to have a call-out from ctdb
+ to a user-specified script when certain state changes occur in ctdb.
+ This is commonly to set up either sending SNMP traps or emails
+ when a node becomes unhealthy and similar.
+ </para>
+ <para>
+ This is activated by setting CTDB_NOTIFY_SCRIPT=<your script> in the
+ sysconfig file, or by adding --notification-script=<your script>.
+ </para>
+ <para>
+ See /etc/ctdb/notify.sh for an example script.
+ </para>
+ <para>
+ CTDB currently generates notifications on these state changes:
+ </para>
+
+ <refsect2><title>unhealthy</title>
+ <para>
+ This call-out is triggered when the node changes to UNHEALTHY state.
+ </para>
+ </refsect2>
+
+ <refsect2><title>healthy</title>
+ <para>
+ This call-out is triggered when the node changes to HEALTHY state.
+ </para>
+ </refsect2>
+
+ <refsect2><title>startup</title>
+ <para>
+ This call-out is triggered when ctdb has started up and all managed services are up and running.
+ </para>
+ </refsect2>
+
+ </refsect1>
<refsect1><title>ClamAV Daemon</title>
</screen>
<para>
-Second, activate the eventscript by making it executable:
+Second, activate the eventscript
</para>
<screen format="linespecific">
-chmod +x /etc/ctdb/events.d/31.clamd
+ctdb enablescript 31.clamd
</screen>
<para>
git.samba.org / sahlberg / ctdb.git / blobdiff