.\" Title: ctdb
.\" Author:
-.\" Generator: DocBook XSL Stylesheets v1.71.0 <http://docbook.sf.net/>
-.\" Date: 07/10/2008
+.\" Generator: DocBook XSL Stylesheets v1.73.2 <http://docbook.sf.net/>
+.\" Date: 09/15/2008
.\" Manual:
.\" Source:
.\"
-.TH "CTDB" "1" "07/10/2008" "" ""
+.TH "CTDB" "1" "09/15/2008" "" ""
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.SH "NAME"
-ctdb \- clustered tdb database management utility
+ctdb - clustered tdb database management utility
.SH "SYNOPSIS"
.HP 29
-\fBctdb [ OPTIONS ] COMMAND ...\fR
+\fBctdb [ OPTIONS ] COMMAND \.\.\.\fR
.HP 5
\fBctdb\fR [\-n\ <node>] [\-Y] [\-t\ <timeout>] [\-T\ <timelimit>] [\-?\ \-\-help] [\-\-usage] [\-d\ \-\-debug=<INTEGER>] [\-\-socket=<filename>]
.SH "DESCRIPTION"
.PP
-ctdb is a utility to view and manage a ctdb cluster.
+ctdb is a utility to view and manage a ctdb cluster\.
.SH "OPTIONS"
.PP
\-n <pnn>
-.RS 3n
-This specifies the physical node number on which to execute the command. Default is to run the command on the deamon running on the local host.
+.RS 4
+This specifies the physical node number on which to execute the command\. Default is to run the command on the deamon running on the local host\.
.sp
-The physical node number is an integer that describes the node in the cluster. The first node has physical node number 0.
+The physical node number is an integer that describes the node in the cluster\. The first node has physical node number 0\.
.RE
.PP
\-Y
-.RS 3n
-Produce output in machine readable form for easier parsing by scripts. Not all commands support this option.
+.RS 4
+Produce output in machine readable form for easier parsing by scripts\. Not all commands support this option\.
.RE
.PP
\-t <timeout>
-.RS 3n
-How long should ctdb wait for the local ctdb daemon to respond to a command before timing out. Default is 3 seconds.
+.RS 4
+How long should ctdb wait for the local ctdb daemon to respond to a command before timing out\. Default is 3 seconds\.
.RE
.PP
\-T <timelimit>
-.RS 3n
-A limit on how long the ctdb command will run for before it will be aborted. When this timelimit has been exceeded the ctdb command will terminate.
+.RS 4
+A limit on how long the ctdb command will run for before it will be aborted\. When this timelimit has been exceeded the ctdb command will terminate\.
.RE
.PP
\-? \-\-help
-.RS 3n
-Print some help text to the screen.
+.RS 4
+Print some help text to the screen\.
.RE
.PP
\-\-usage
-.RS 3n
-Print useage information to the screen.
+.RS 4
+Print useage information to the screen\.
.RE
.PP
\-d \-\-debug=<debuglevel>
-.RS 3n
-Change the debug level for the command. Default is 0.
+.RS 4
+Change the debug level for the command\. Default is 0\.
.RE
.PP
\-\-socket=<filename>
-.RS 3n
-Specify the socketname to use when connecting to the local ctdb daemon. The default is /tmp/ctdb.socket .
+.RS 4
+Specify the socketname to use when connecting to the local ctdb daemon\. The default is /tmp/ctdb\.socket \.
.sp
-You only need to specify this parameter if you run multiple ctdb daemons on the same physical host and thus can not use the default name for the domain socket.
+You only need to specify this parameter if you run multiple ctdb daemons on the same physical host and thus can not use the default name for the domain socket\.
.RE
.SH "ADMINISTRATIVE COMMANDS"
.PP
-These are commands used to monitor and administrate a CTDB cluster.
+These are commands used to monitor and administrate a CTDB cluster\.
.SS "pnn"
.PP
-This command displays the pnn of the current node.
+This command displays the pnn of the current node\.
.SS "status"
.PP
-This command shows the current status of the ctdb node.
+This command shows the current status of the ctdb node\.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
-\fBnode status\fR
+node status
.RS
.PP
-Node status reflects the current status of the node. There are four possible states:
+Node status reflects the current status of the node\. There are five possible states:
.PP
-OK \- This node is fully functional.
+OK \- This node is fully functional\.
.PP
-DISCONNECTED \- This node could not be connected through the network and is currently not participating in the cluster. If there is a public IP address associated with this node it should have been taken over by a different node. No services are running on this node.
+DISCONNECTED \- This node could not be connected through the network and is currently not participating in the cluster\. If there is a public IP address associated with this node it should have been taken over by a different node\. No services are running on this node\.
.PP
-DISABLED \- This node has been administratively disabled. This node is still functional and participates in the CTDB cluster but its IP addresses have been taken over by a different node and no services are currently being hosted.
+DISABLED \- This node has been administratively disabled\. This node is still functional and participates in the CTDB cluster but its IP addresses have been taken over by a different node and no services are currently being hosted\.
.PP
-UNHEALTHY \- A service provided by this node is malfunctioning and should be investigated. The CTDB daemon itself is operational and participates in the cluster. Its public IP address has been taken over by a different node and no services are currnetly being hosted. All unhealthy nodes should be investigated and require an administrative action to rectify.
+UNHEALTHY \- A service provided by this node is malfunctioning and should be investigated\. The CTDB daemon itself is operational and participates in the cluster\. Its public IP address has been taken over by a different node and no services are currnetly being hosted\. All unhealthy nodes should be investigated and require an administrative action to rectify\.
.PP
-BANNED \- This node failed too many recovery attempts and has been banned from participating in the cluster for a period of RecoveryBanPeriod seconds. Any public IP address has been taken over by other nodes. This node does not provide any services. All banned nodes should be investigated and require an administrative action to rectify. This node does not perticipate in the CTDB cluster but can still be communicated with. I.e. ctdb commands can be sent to it.
+BANNED \- This node failed too many recovery attempts and has been banned from participating in the cluster for a period of RecoveryBanPeriod seconds\. Any public IP address has been taken over by other nodes\. This node does not provide any services\. All banned nodes should be investigated and require an administrative action to rectify\. This node does not perticipate in the CTDB cluster but can still be communicated with\. I\.e\. ctdb commands can be sent to it\.
.RE
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
-\fBgeneration\fR
+generation
.RS
.PP
-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.
+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\.
.PP
-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. CTDBD 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.
+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\. CTDBD 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\.
.PP
-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.
+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\.
.RE
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
-\fBVNNMAP\fR
+VNNMAP
.RS
.PP
-The list of Virtual Node Numbers. This is a list of all nodes that actively participates in the cluster and that share the workload of hosting the Clustered TDB database records. Only nodes that are participating in the vnnmap can become lmaster or dmaster for a database record.
+The list of Virtual Node Numbers\. This is a list of all nodes that actively participates in the cluster and that share the workload of hosting the Clustered TDB database records\. Only nodes that are participating in the vnnmap can become lmaster or dmaster for a database record\.
.RE
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
-\fBRecovery mode\fR
+Recovery mode
.RS
.PP
-This is the current recovery mode of the cluster. There are two possible modes:
+This is the current recovery mode of the cluster\. There are two possible modes:
.PP
-NORMAL \- The cluster is fully operational.
+NORMAL \- The cluster is fully operational\.
.PP
-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.
+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\.
.PP
-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.
+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\.
.PP
-When CTDBD 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.
+When CTDBD 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\.
.RE
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
-\fBRecovery master\fR
+Recovery master
.RS
.PP
-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.
+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\.
.PP
-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.
+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\.
.RE
.PP
Example: ctdb status
.PP
Example output:
.sp
-.RS 3n
+.RS 4
.nf
Number of nodes:4
-pnn:0 11.1.2.200 OK (THIS NODE)
-pnn:1 11.1.2.201 OK
-pnn:2 11.1.2.202 OK
-pnn:3 11.1.2.203 OK
+pnn:0 11\.1\.2\.200 OK (THIS NODE)
+pnn:1 11\.1\.2\.201 OK
+pnn:2 11\.1\.2\.202 OK
+pnn:3 11\.1\.2\.203 OK
Generation:1362079228
Size:4
hash:0 lmaster:0
.RE
.SS "ping"
.PP
-This command will "ping" all CTDB daemons in the cluster to verify that they are processing commands correctly.
+This command will "ping" all CTDB daemons in the cluster to verify that they are processing commands correctly\.
.PP
Example: ctdb ping
.PP
Example output:
.sp
-.RS 3n
+.RS 4
.nf
-response from 0 time=0.000054 sec (3 clients)
-response from 1 time=0.000144 sec (2 clients)
-response from 2 time=0.000105 sec (2 clients)
-response from 3 time=0.000114 sec (2 clients)
+response from 0 time=0\.000054 sec (3 clients)
+response from 1 time=0\.000144 sec (2 clients)
+response from 2 time=0\.000105 sec (2 clients)
+response from 3 time=0\.000114 sec (2 clients)
.fi
.RE
.SS "ip"
.PP
-This command will display the list of public addresses that are provided by the cluster and which physical node is currently serving this ip.
+This command will display the list of public addresses that are provided by the cluster and which physical node is currently serving this ip\.
.PP
Example: ctdb ip
.PP
Example output:
.sp
-.RS 3n
+.RS 4
.nf
Number of addresses:4
-12.1.1.1 0
-12.1.1.2 1
-12.1.1.3 2
-12.1.1.4 3
+12\.1\.1\.1 0
+12\.1\.1\.2 1
+12\.1\.1\.3 2
+12\.1\.1\.4 3
.fi
.RE
.SS "getvar <name>"
.PP
-Get the runtime value of a tuneable variable.
+Get the runtime value of a tuneable variable\.
.PP
Example: ctdb getvar MaxRedirectCount
.PP
Example output:
.sp
-.RS 3n
+.RS 4
.nf
MaxRedirectCount = 3
.RE
.SS "setvar <name> <value>"
.PP
-Set the runtime value of a tuneable variable.
+Set the runtime value of a tuneable variable\.
.PP
Example: ctdb setvar MaxRedirectCount 5
.SS "listvars"
.PP
-List all tuneable variables.
+List all tuneable variables\.
.PP
Example: ctdb listvars
.PP
Example output:
.sp
-.RS 3n
+.RS 4
.nf
MaxRedirectCount = 5
SeqnumFrequency = 1
.RE
.SS "lvsmaster"
.PP
-This command shows which node is currently the LVSMASTER. The LVSMASTER is the node in the cluster which drives the LVS system and which receives all incoming traffic from clients.
+This command shows which node is currently the LVSMASTER\. The LVSMASTER is the node in the cluster which drives the LVS system and which receives all incoming traffic from clients\.
.PP
-LVS is the mode where the entire CTDB/Samba cluster uses a single ip address for the entire cluster. In this mode all clients connect to one specific node which will then multiplex/loadbalance the clients evenly onto the other nodes in the cluster. This is an alternative to using public ip addresses. See the manpage for ctdbd for more information about LVS.
+LVS is the mode where the entire CTDB/Samba cluster uses a single ip address for the entire cluster\. In this mode all clients connect to one specific node which will then multiplex/loadbalance the clients evenly onto the other nodes in the cluster\. This is an alternative to using public ip addresses\. See the manpage for ctdbd for more information about LVS\.
.SS "lvs"
.PP
-This command shows which nodes in the cluster are currently active in the LVS configuration. I.e. which nodes we are currently loadbalancing the single ip address across.
+This command shows which nodes in the cluster are currently active in the LVS configuration\. I\.e\. which nodes we are currently loadbalancing the single ip address across\.
.PP
-LVS will by default only loadbalance across those nodes that are both LVS capable and also HEALTHY. Except if all nodes are UNHEALTHY in which case LVS will loadbalance across all UNHEALTHY nodes as well. LVS will never use nodes that are DISCONNECTED, BANNED or DISABLED.
+LVS will by default only loadbalance across those nodes that are both LVS capable and also HEALTHY\. Except if all nodes are UNHEALTHY in which case LVS will loadbalance across all UNHEALTHY nodes as well\. LVS will never use nodes that are DISCONNECTED, BANNED or DISABLED\.
.PP
Example output:
.sp
-.RS 3n
+.RS 4
.nf
-2:10.0.0.13
-3:10.0.0.14
+2:10\.0\.0\.13
+3:10\.0\.0\.14
.fi
.RE
.SS "getcapabilities"
.PP
-This command shows the capabilities of the current node. Please see manpage for ctdbd for a full list of all capabilities and more detailed description.
+This command shows the capabilities of the current node\. Please see manpage for ctdbd for a full list of all capabilities and more detailed description\.
.PP
-RECMASTER and LMASTER capabilities are primarily used when CTDBD is used to create a cluster spanning across WAN links. In which case ctdbd acts as a WAN accelerator.
+RECMASTER and LMASTER capabilities are primarily used when CTDBD is used to create a cluster spanning across WAN links\. In which case ctdbd acts as a WAN accelerator\.
.PP
-LVS capabile means that the node is participating in LVS, a mode where the entire CTDB cluster uses one single ip address for the entire cluster instead of using public ip address failover. This is an alternative to using a loadbalancing layer\-4 switch.
+LVS capabile means that the node is participating in LVS, a mode where the entire CTDB cluster uses one single ip address for the entire cluster instead of using public ip address failover\. This is an alternative to using a loadbalancing layer\-4 switch\.
.PP
Example output:
.sp
-.RS 3n
+.RS 4
.nf
RECMASTER: YES
LMASTER: YES
.RE
.SS "statistics"
.PP
-Collect statistics from the CTDB daemon about how many calls it has served.
+Collect statistics from the CTDB daemon about how many calls it has served\.
.PP
Example: ctdb statistics
.PP
Example output:
.sp
-.RS 3n
+.RS 4
.nf
CTDB version 1
num_clients 3
pending_lockwait_calls 0
memory_used 5040
max_hop_count 0
- max_call_latency 4.948321 sec
- max_lockwait_latency 0.000000 sec
+ max_call_latency 4\.948321 sec
+ max_lockwait_latency 0\.000000 sec
.fi
.RE
.SS "statisticsreset"
.PP
-This command is used to clear all statistics counters in a node.
+This command is used to clear all statistics counters in a node\.
.PP
Example: ctdb statisticsreset
.SS "getdebug"
.PP
-Get the current debug level for the node. the debug level controls what information is written to the log file.
+Get the current debug level for the node\. the debug level controls what information is written to the log file\.
.PP
-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.
+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\.
.PP
The list of debug levels from highest to lowest are :
.PP
EMERG ALERT CRIT ERR WARNING NOTICE INFO DEBUG
.SS "setdebug <debuglevel>"
.PP
-Set the debug level of a node. This controls what information will be logged.
+Set the debug level of a node\. This controls what information will be logged\.
.PP
The debuglevel is one of EMERG ALERT CRIT ERR WARNING NOTICE INFO DEBUG
.SS "getpid"
.PP
-This command will return the process id of the ctdb daemon.
+This command will return the process id of the ctdb daemon\.
.SS "disable"
.PP
-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.
+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\.
.SS "enable"
.PP
-Re\-enable a node that has been administratively disabled.
+Re\-enable a node that has been administratively disabled\.
.SS "ban <bantime|0>"
.PP
-Administratively ban a node for bantime seconds. A bantime of 0 means that the node should be permanently banned.
+Administratively ban a node for bantime seconds\. A bantime of 0 means that the node should be permanently banned\.
.PP
-A banned node does not participate in the cluster and does not host any records for the clustered TDB. Its ip address has been taken over by an other node and no services are hosted.
+A banned node does not participate in the cluster and does not host any records for the clustered TDB\. Its ip address has been taken over by an other node and no services are hosted\.
.PP
-Nodes are automatically banned if they are the cause of too many cluster recoveries.
+Nodes are automatically banned if they are the cause of too many cluster recoveries\.
.SS "moveip <public_ip> <node>"
.PP
-This command can be used to manually fail a public ip address to a specific node.
+This command can be used to manually fail a public ip address to a specific node\.
.PP
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:
.PP
NoIPFailback = 1
.SS "unban"
.PP
-This command is used to unban a node that has either been administratively banned using the ban command or has been automatically banned by the recovery daemon.
+This command is used to unban a node that has either been administratively banned using the ban command or has been automatically banned by the recovery daemon\.
.SS "shutdown"
.PP
-This command will shutdown a specific CTDB daemon.
+This command will shutdown a specific CTDB daemon\.
.SS "recover"
.PP
-This command will trigger the recovery daemon to do a cluster recovery.
+This command will trigger the recovery daemon to do a cluster recovery\.
.SS "killtcp <srcip:port> <dstip:port>"
.PP
-This command will kill the specified TCP connection by issuing a TCP RST to the srcip:port endpoint.
+This command will kill the specified TCP connection by issuing a TCP RST to the srcip:port endpoint\.
.SS "reloadnodes"
.PP
-This command is used when adding new nodes to an existing cluster and to reduce the disruption of this operation. This command should never be used except when expanding an existing cluster. This can only be used to expand a cluster. To remove a node from the cluster you still need to shut down ctdb on all nodes, edit the nodes file and restart ctdb.
+This command is used when adding new nodes to an existing cluster and to reduce the disruption of this operation\. This command should never be used except when expanding an existing cluster\. This can only be used to expand a cluster\. To remove a node from the cluster you still need to shut down ctdb on all nodes, edit the nodes file and restart ctdb\.
.PP
Procedure:
.PP
-1, To expand an existing cluster, first ensure with 'ctdb status' 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!
+1, To expand an existing cluster, first ensure with \'ctdb status\' 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!
.PP
-2, On all nodes, edit /etc/ctdb/nodes and add the new node as the last entry to the file. The new node MUST be added to the end of this file!
+2, On all nodes, edit /etc/ctdb/nodes and add the new node as the last entry to the file\. The new node MUST be added to the end of this file!
.PP
3, Verify that all the nodes have identical /etc/ctdb/nodes files after you edited them and added the new node!
.PP
-4, Run 'ctdb reloadnodes' to force all nodes to reaload the nodesfile.
+4, Run \'ctdb reloadnodes\' to force all nodes to reaload the nodesfile\.
.PP
-5, Use 'ctdb status' on all nodes and verify that they now show the additional node.
+5, Use \'ctdb status\' on all nodes and verify that they now show the additional node\.
.PP
-6, Install and configure the new node and bring it online.
+6, Install and configure the new node and bring it online\.
.SS "tickle <srcip:port> <dstip:port>"
.PP
-This command will will send a TCP tickle to the source host for the specified TCP connection. A TCP tickle is a TCP ACK packet with an invalid sequence and acknowledge number and will when received by the source host result in it sending an immediate correct ACK back to the other end.
+This command will will send a TCP tickle to the source host for the specified TCP connection\. A TCP tickle is a TCP ACK packet with an invalid sequence and acknowledge number and will when received by the source host result in it sending an immediate correct ACK back to the other end\.
.PP
-TCP tickles are useful to "tickle" clients after a IP failover has occured since this will make the client immediately recognize the TCP connection has been disrupted and that the client will need to reestablish. This greatly speeds up the time it takes for a client to detect and reestablish after an IP failover in the ctdb cluster.
+TCP tickles are useful to "tickle" clients after a IP failover has occured since this will make the client immediately recognize the TCP connection has been disrupted and that the client will need to reestablish\. This greatly speeds up the time it takes for a client to detect and reestablish after an IP failover in the ctdb cluster\.
.SS "repack [max_freelist]"
.PP
-Over time, when records are created and deleted in a TDB, the TDB list of free space will become fragmented. This can lead to a slowdown in accessing TDB records. This command is used to defragment a TDB database and pruning the freelist.
+Over time, when records are created and deleted in a TDB, the TDB list of free space will become fragmented\. This can lead to a slowdown in accessing TDB records\. This command is used to defragment a TDB database and pruning the freelist\.
.PP
-If [max_freelist] is specified, then a database will only be repacked if it has more than this number of entries in the freelist.
+If [max_freelist] is specified, then a database will only be repacked if it has more than this number of entries in the freelist\.
.PP
-During repacking of the database, the entire TDB database will be locked to prevent writes. If samba tries to write to a record in the database during a repack operation, samba will block until the repacking has completed.
+During repacking of the database, the entire TDB database will be locked to prevent writes\. If samba tries to write to a record in the database during a repack operation, samba will block until the repacking has completed\.
.PP
-This command can be disruptive and can cause samba to block for the duration of the repack operation. In general, a repack operation will take less than one second to complete.
+This command can be disruptive and can cause samba to block for the duration of the repack operation\. In general, a repack operation will take less than one second to complete\.
.PP
-A repack operation will only defragment the local TDB copy of the CTDB database. You need to run this command on all of the nodes to repack a CTDB database completely.
+A repack operation will only defragment the local TDB copy of the CTDB database\. You need to run this command on all of the nodes to repack a CTDB database completely\.
.PP
Example: ctdb repack 1000
.PP
-By default, this operation is issued from the 00.ctdb event script every 5 minutes.
+By default, this operation is issued from the 00\.ctdb event script every 5 minutes\.
.SS "vacuum [max_records]"
.PP
-Over time CTDB databases will fill up with empty deleted records which will lead to a progressive slow down of CTDB database access. This command is used to prune all databases and delete all empty records from the cluster.
+Over time CTDB databases will fill up with empty deleted records which will lead to a progressive slow down of CTDB database access\. This command is used to prune all databases and delete all empty records from the cluster\.
.PP
-By default, vacuum will delete all empty records from all databases. If [max_records] is specified, the command will only delete the first [max_records] empty records for each database.
+By default, vacuum will delete all empty records from all databases\. If [max_records] is specified, the command will only delete the first [max_records] empty records for each database\.
.PP
-Vacuum only deletes records where the local node is the lmaster. To delete all records from the entire cluster you need to run a vacuum from each node. This command is not disruptive. Samba is unaffected and will still be able to read/write records normally while the database is being vacuumed.
+Vacuum only deletes records where the local node is the lmaster\. To delete all records from the entire cluster you need to run a vacuum from each node\. This command is not disruptive\. Samba is unaffected and will still be able to read/write records normally while the database is being vacuumed\.
.PP
Example: ctdb vacuum
.PP
-By default, this operation is issued from the 00.ctdb event script every 5 minutes.
+By default, this operation is issued from the 00\.ctdb event script every 5 minutes\.
.SH "DEBUGGING COMMANDS"
.PP
-These commands are primarily used for CTDB development and testing and should not be used for normal administration.
+These commands are primarily used for CTDB development and testing and should not be used for normal administration\.
.SS "process\-exists <pid>"
.PP
-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.
+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\.
.SS "getdbmap"
.PP
-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.
+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\.
.PP
-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.
+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\.
.PP
Example: ctdb getdbmap
.PP
Example output:
.sp
-.RS 3n
+.RS 4
.nf
Number of databases:10
-dbid:0x435d3410 name:notify.tdb path:/var/ctdb/notify.tdb.0
-dbid:0x42fe72c5 name:locking.tdb path:/var/ctdb/locking.tdb.0 dbid:0x1421fb78 name:brlock.tdb path:/var/ctdb/brlock.tdb.0
-dbid:0x17055d90 name:connections.tdb path:/var/ctdb/connections.tdb.0
-dbid:0xc0bdde6a name:sessionid.tdb path:/var/ctdb/sessionid.tdb.0
-dbid:0x122224da name:test.tdb path:/var/ctdb/test.tdb.0
-dbid:0x2672a57f name:idmap2.tdb path:/var/ctdb/persistent/idmap2.tdb.0 PERSISTENT
-dbid:0xb775fff6 name:secrets.tdb path:/var/ctdb/persistent/secrets.tdb.0 PERSISTENT
-dbid:0xe98e08b6 name:group_mapping.tdb path:/var/ctdb/persistent/group_mapping.tdb.0 PERSISTENT
-dbid:0x7bbbd26c name:passdb.tdb path:/var/ctdb/persistent/passdb.tdb.0 PERSISTENT
+dbid:0x435d3410 name:notify\.tdb path:/var/ctdb/notify\.tdb\.0
+dbid:0x42fe72c5 name:locking\.tdb path:/var/ctdb/locking\.tdb\.0 dbid:0x1421fb78 name:brlock\.tdb path:/var/ctdb/brlock\.tdb\.0
+dbid:0x17055d90 name:connections\.tdb path:/var/ctdb/connections\.tdb\.0
+dbid:0xc0bdde6a name:sessionid\.tdb path:/var/ctdb/sessionid\.tdb\.0
+dbid:0x122224da name:test\.tdb path:/var/ctdb/test\.tdb\.0
+dbid:0x2672a57f name:idmap2\.tdb path:/var/ctdb/persistent/idmap2\.tdb\.0 PERSISTENT
+dbid:0xb775fff6 name:secrets\.tdb path:/var/ctdb/persistent/secrets\.tdb\.0 PERSISTENT
+dbid:0xe98e08b6 name:group_mapping\.tdb path:/var/ctdb/persistent/group_mapping\.tdb\.0 PERSISTENT
+dbid:0x7bbbd26c name:passdb\.tdb path:/var/ctdb/persistent/passdb\.tdb\.0 PERSISTENT
.fi
.RE
.SS "catdb <dbname>"
.PP
-This command will dump a clustered TDB database to the screen. This is a debugging command.
+This command will dump a clustered TDB database to the screen\. This is a debugging command\.
.SS "getmonmode"
.PP
-This command returns the monutoring mode of a node. The monitoring mode is either ACTIVE or DISABLED. Normally a node will continously monitor that all other nodes that are expected are in fact connected and that they respond to commands.
+This command returns the monutoring mode of a node\. The monitoring mode is either ACTIVE or DISABLED\. Normally a node will continously monitor that all other nodes that are expected are in fact connected and that they respond to commands\.
.PP
-ACTIVE \- This is the normal mode. The node is actively monitoring all other nodes, both that the transport is connected and also that the node responds to commands. If a node becomes unavailable, it will be marked as DISCONNECTED and a recovery is initiated to restore the cluster.
+ACTIVE \- This is the normal mode\. The node is actively monitoring all other nodes, both that the transport is connected and also that the node responds to commands\. If a node becomes unavailable, it will be marked as DISCONNECTED and a recovery is initiated to restore the cluster\.
.PP
-DISABLED \- This node is not monitoring that other nodes are available. In this mode a node failure will not be detected and no recovery will be performed. This mode is useful when for debugging purposes one wants to attach GDB to a ctdb process but wants to prevent the rest of the cluster from marking this node as DISCONNECTED and do a recovery.
+DISABLED \- This node is not monitoring that other nodes are available\. In this mode a node failure will not be detected and no recovery will be performed\. This mode is useful when for debugging purposes one wants to attach GDB to a ctdb process but wants to prevent the rest of the cluster from marking this node as DISCONNECTED and do a recovery\.
.SS "setmonmode <0|1>"
.PP
-This command can be used to explicitely disable/enable monitoring mode on a node. The main purpose is if one wants to attach GDB to a running ctdb daemon but wants to prevent the other nodes from marking it as DISCONNECTED and issuing a recovery. To do this, set monitoring mode to 0 on all nodes before attaching with GDB. Remember to set monitoring mode back to 1 afterwards.
+This command can be used to explicitely disable/enable monitoring mode on a node\. The main purpose is if one wants to attach GDB to a running ctdb daemon but wants to prevent the other nodes from marking it as DISCONNECTED and issuing a recovery\. To do this, set monitoring mode to 0 on all nodes before attaching with GDB\. Remember to set monitoring mode back to 1 afterwards\.
.SS "attach <dbname>"
.PP
-This is a debugging command. This command will make the CTDB daemon create a new CTDB database and attach to it.
+This is a debugging command\. This command will make the CTDB daemon create a new CTDB database and attach to it\.
.SS "dumpmemory"
.PP
-This is a debugging command. This command will make the ctdb daemon to write a fill memory allocation map to standard output.
+This is a debugging command\. This command will make the ctdb daemon to write a fill memory allocation map to standard output\.
.SS "freeze"
.PP
-This command will lock all the local TDB databases causing clients that are accessing these TDBs such as samba3 to block until the databases are thawed.
+This command will lock all the local TDB databases causing clients that are accessing these TDBs such as samba3 to block until the databases are thawed\.
.PP
-This is primarily used by the recovery daemon to stop all samba daemons from accessing any databases while the database is recovered and rebuilt.
+This is primarily used by the recovery daemon to stop all samba daemons from accessing any databases while the database is recovered and rebuilt\.
.SS "thaw"
.PP
-Thaw a previously frozen node.
+Thaw a previously frozen node\.
.SH "SEE ALSO"
.PP
ctdbd(1), onnode(1)
\fI\%http://ctdb.samba.org/\fR
.SH "COPYRIGHT/LICENSE"
.sp
-.RS 3n
+.RS 4
.nf
Copyright (C) Andrew Tridgell 2007
Copyright (C) Ronnie sahlberg 2007
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or (at
-your option) any later version.
+your option) any later version\.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-General Public License for more details.
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE\. See the GNU
+General Public License for more details\.
You should have received a copy of the GNU General Public License
-along with this program; if not, see http://www.gnu.org/licenses/.
+along with this program; if not, see http://www\.gnu\.org/licenses/\.
.fi
.RE
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb</title><meta name="generator" content="DocBook XSL Stylesheets V1.7
1.0"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en"><a name="ctdb.1"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb — clustered tdb database management utility</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ctdb [ OPTIONS ] COMMAND ...</code> </p></div><div class="cmdsynopsis"><p><code class="command">ctdb</code> [-n <node>] [-Y] [-t <timeout>] [-T <timelimit>] [-? --help] [--usage] [-d --debug=<INTEGER>] [--socket=<filename>]</p></div></div><div class="refsect1" lang="en"><a name="id2480874"></a><h2>DESCRIPTION</h2><p>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb</title><meta name="generator" content="DocBook XSL Stylesheets V1.7
3.2"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en"><a name="ctdb.1"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb — clustered tdb database management utility</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ctdb [ OPTIONS ] COMMAND ...</code> </p></div><div class="cmdsynopsis"><p><code class="command">ctdb</code> [-n <node>] [-Y] [-t <timeout>] [-T <timelimit>] [-? --help] [--usage] [-d --debug=<INTEGER>] [--socket=<filename>]</p></div></div><div class="refsect1" lang="en"><a name="id2478395"></a><h2>DESCRIPTION</h2><p>
ctdb is a utility to view and manage a ctdb cluster.
- </p></div><div class="refsect1" lang="en"><a name="id24
80884"></a><h2>OPTIONS</h2><div class="variablelist"><dl><dt><span class="term">-n <pnn></span></dt><dd><p>
+ </p></div><div class="refsect1" lang="en"><a name="id24
78405"></a><h2>OPTIONS</h2><div class="variablelist"><dl><dt><span class="term">-n <pnn></span></dt><dd><p>
This specifies the physical node number on which to execute the
command. Default is to run the command on the deamon running on
the local host.
You only need to specify this parameter if you run multiple ctdb
daemons on the same physical host and thus can not use the default
name for the domain socket.
- </p></dd></dl></div></div><div class="refsect1" lang="en"><a name="id24
81194"></a><h2>Administrative Commands</h2><p>
+ </p></dd></dl></div></div><div class="refsect1" lang="en"><a name="id24
79674"></a><h2>Administrative Commands</h2><p>
These are commands used to monitor and administrate a CTDB cluster.
- </p><div class="refsect2" lang="en"><a name="id24
81203"></a><h3>pnn</h3><p>
+ </p><div class="refsect2" lang="en"><a name="id24
79683"></a><h3>pnn</h3><p>
This command displays the pnn of the current node.
- </p></div><div class="refsect2" lang="en"><a name="id24
81213"></a><h3>status</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id24
79693"></a><h3>status</h3><p>
This command shows the current status of the ctdb node.
- </p><div class="refsect3" lang="en"><a name="id24
81222"></a><h4>node status</h4><p>
- Node status reflects the current status of the node. There are four possible states:
+ </p><div class="refsect3" lang="en"><a name="id24
79702"></a><h4>node status</h4><p>
+ Node status reflects the current status of the node. There are five possible states:
</p><p>
OK - This node is fully functional.
</p><p>
UNHEALTHY - A service provided by this node is malfunctioning and should be investigated. The CTDB daemon itself is operational and participates in the cluster. Its public IP address has been taken over by a different node and no services are currnetly being hosted. All unhealthy nodes should be investigated and require an administrative action to rectify.
</p><p>
BANNED - This node failed too many recovery attempts and has been banned from participating in the cluster for a period of RecoveryBanPeriod seconds. Any public IP address has been taken over by other nodes. This node does not provide any services. All banned nodes should be investigated and require an administrative action to rectify. This node does not perticipate in the CTDB cluster but can still be communicated with. I.e. ctdb commands can be sent to it.
- </p></div><div class="refsect3" lang="en"><a name="id24
81273"></a><h4>generation</h4><p>
+ </p></div><div class="refsect3" lang="en"><a name="id24
79754"></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" lang="en"><a name="id24
81308"></a><h4>VNNMAP</h4><p>
+ </p></div><div class="refsect3" lang="en"><a name="id24
79789"></a><h4>VNNMAP</h4><p>
The list of Virtual Node Numbers. This is a list of all nodes that actively participates in the cluster and that share the workload of hosting the Clustered TDB database records.
Only nodes that are participating in the vnnmap can become lmaster or dmaster for a database record.
- </p></div><div class="refsect3" lang="en"><a name="id24
81323"></a><h4>Recovery mode</h4><p>
+ </p></div><div class="refsect3" lang="en"><a name="id24
79803"></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.
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" lang="en"><a name="id2528
429"></a><h4>Recovery master</h4><p>
+ </p></div><div class="refsect3" lang="en"><a name="id2528
502"></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
hash:3 lmaster:3
Recovery mode:NORMAL (0)
Recovery master:0
- </pre></div><div class="refsect2" lang="en"><a name="id2528
467"></a><h3>ping</h3><p>
+ </pre></div><div class="refsect2" lang="en"><a name="id2528
540"></a><h3>ping</h3><p>
This command will "ping" all CTDB daemons in the cluster to verify that they are processing commands correctly.
</p><p>
Example: ctdb ping
response from 1 time=0.000144 sec (2 clients)
response from 2 time=0.000105 sec (2 clients)
response from 3 time=0.000114 sec (2 clients)
- </pre></div><div class="refsect2" lang="en"><a name="id2528
493"></a><h3>ip</h3><p>
+ </pre></div><div class="refsect2" lang="en"><a name="id2528
566"></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.
</p><p>
Example: ctdb ip
12.1.1.2 1
12.1.1.3 2
12.1.1.4 3
- </pre></div><div class="refsect2" lang="en"><a name="id25285
19"></a><h3>getvar <name></h3><p>
+ </pre></div><div class="refsect2" lang="en"><a name="id25285
91"></a><h3>getvar <name></h3><p>
Get the runtime value of a tuneable variable.
</p><p>
Example: ctdb getvar MaxRedirectCount
Example output:
</p><pre class="screen">
MaxRedirectCount = 3
- </pre></div><div class="refsect2" lang="en"><a name="id2528
542"></a><h3>setvar <name> <value></h3><p>
+ </pre></div><div class="refsect2" lang="en"><a name="id2528
610"></a><h3>setvar <name> <value></h3><p>
Set the runtime value of a tuneable variable.
</p><p>
Example: ctdb setvar MaxRedirectCount 5
- </p></div><div class="refsect2" lang="en"><a name="id2528
556"></a><h3>listvars</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2528
625"></a><h3>listvars</h3><p>
List all tuneable variables.
</p><p>
Example: ctdb listvars
EventScriptTimeout = 20
RecoveryGracePeriod = 60
RecoveryBanPeriod = 300
- </pre></div><div class="refsect2" lang="en"><a name="id2528
585"></a><h3>lvsmaster</h3><p>
+ </pre></div><div class="refsect2" lang="en"><a name="id2528
653"></a><h3>lvsmaster</h3><p>
This command shows which node is currently the LVSMASTER. The
LVSMASTER is the node in the cluster which drives the LVS system and
which receives all incoming traffic from clients.
evenly onto the other nodes in the cluster. This is an alternative to using
public ip addresses. See the manpage for ctdbd for more information
about LVS.
- </p></div><div class="refsect2" lang="en"><a name="id25286
07"></a><h3>lvs</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id25286
75"></a><h3>lvs</h3><p>
This command shows which nodes in the cluster are currently active in the
LVS configuration. I.e. which nodes we are currently loadbalancing
the single ip address across.
</p><pre class="screen">
2:10.0.0.13
3:10.0.0.14
- </pre></div><div class="refsect2" lang="en"><a name="id2528
637"></a><h3>getcapabilities</h3><p>
+ </pre></div><div class="refsect2" lang="en"><a name="id2528
705"></a><h3>getcapabilities</h3><p>
This command shows the capabilities of the current node.
Please see manpage for ctdbd for a full list of all capabilities and
more detailed description.
RECMASTER: YES
LMASTER: YES
LVS: NO
- </pre></div><div class="refsect2" lang="en"><a name="id2528
673"></a><h3>statistics</h3><p>
+ </pre></div><div class="refsect2" lang="en"><a name="id2528
741"></a><h3>statistics</h3><p>
Collect statistics from the CTDB daemon about how many calls it has served.
</p><p>
Example: ctdb statistics
max_hop_count 0
max_call_latency 4.948321 sec
max_lockwait_latency 0.000000 sec
- </pre></div><div class="refsect2" lang="en"><a name="id25287
16"></a><h3>statisticsreset</h3><p>
+ </pre></div><div class="refsect2" lang="en"><a name="id25287
84"></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" lang="en"><a name="id25287
31"></a><h3>getdebug</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id25287
99"></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.
The list of debug levels from highest to lowest are :
</p><p>
EMERG ALERT CRIT ERR WARNING NOTICE INFO DEBUG
- </p></div><div class="refsect2" lang="en"><a name="id2528
756"></a><h3>setdebug <debuglevel></h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2528
825"></a><h3>setdebug <debuglevel></h3><p>
Set the debug level of a node. This controls what information will be logged.
</p><p>
The debuglevel is one of EMERG ALERT CRIT ERR WARNING NOTICE INFO DEBUG
- </p></div><div class="refsect2" lang="en"><a name="id2528
772"></a><h3>getpid</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2528
840"></a><h3>getpid</h3><p>
This command will return the process id of the ctdb daemon.
- </p></div><div class="refsect2" lang="en"><a name="id2528
782"></a><h3>disable</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2528
850"></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" lang="en"><a name="id2528
796"></a><h3>enable</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2528
864"></a><h3>enable</h3><p>
Re-enable a node that has been administratively disabled.
- </p></div><div class="refsect2" lang="en"><a name="id25288
06"></a><h3>ban <bantime|0></h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id25288
74"></a><h3>ban <bantime|0></h3><p>
Administratively ban a node for bantime seconds. A bantime of 0 means that the node should be permanently banned.
</p><p>
A banned node does not participate in the cluster and does not host any records for the clustered TDB. Its ip address has been taken over by an other node and no services are hosted.
</p><p>
Nodes are automatically banned if they are the cause of too many
cluster recoveries.
- </p></div><div class="refsect2" lang="en"><a name="id25288
30"></a><h3>moveip <public_ip> <node></h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id25288
98"></a><h3>moveip <public_ip> <node></h3><p>
This command can be used to manually fail a public ip address to a
specific node.
</p><p>
DeterministicIPs = 0
</p><p>
NoIPFailback = 1
- </p></div><div class="refsect2" lang="en"><a name="id2528
854"></a><h3>unban</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2528
922"></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 by the recovery daemon.
- </p></div><div class="refsect2" lang="en"><a name="id2528
866"></a><h3>shutdown</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2528
934"></a><h3>shutdown</h3><p>
This command will shutdown a specific CTDB daemon.
- </p></div><div class="refsect2" lang="en"><a name="id2528
876"></a><h3>recover</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2528
944"></a><h3>recover</h3><p>
This command will trigger the recovery daemon to do a cluster
recovery.
- </p></div><div class="refsect2" lang="en"><a name="id2528
887"></a><h3>killtcp <srcip:port> <dstip:port></h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2528
955"></a><h3>killtcp <srcip:port> <dstip:port></h3><p>
This command will kill the specified TCP connection by issuing a
TCP RST to the srcip:port endpoint.
- </p></div><div class="refsect2" lang="en"><a name="id2528
898"></a><h3>reloadnodes</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2528
966"></a><h3>reloadnodes</h3><p>
This command is used when adding new nodes to an existing cluster and
to reduce the disruption of this operation. This command should never
be used except when expanding an existing cluster.
5, Use 'ctdb status' on all nodes and verify that they now show the additional node.
</p><p>
6, Install and configure the new node and bring it online.
- </p></div><div class="refsect2" lang="en"><a name="id252
8950"></a><h3>tickle <srcip:port> <dstip:port></h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id252
9018"></a><h3>tickle <srcip:port> <dstip:port></h3><p>
This command will will send a TCP tickle to the source host for the
specified TCP connection.
A TCP tickle is a TCP ACK packet with an invalid sequence and
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" lang="en"><a name="id252
8975"></a><h3>repack [max_freelist]</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id252
9043"></a><h3>repack [max_freelist]</h3><p>
Over time, when records are created and deleted in a TDB, the TDB list of free space will become fragmented. This can lead to a slowdown in accessing TDB records.
This command is used to defragment a TDB database and pruning the freelist.
</p><p>
Example: ctdb repack 1000
</p><p>
By default, this operation is issued from the 00.ctdb event script every 5 minutes.
- </p></div><div class="refsect2" lang="en"><a name="id25290
21"></a><h3>vacuum [max_records]</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id25290
89"></a><h3>vacuum [max_records]</h3><p>
Over time CTDB databases will fill up with empty deleted records which will lead to a progressive slow down of CTDB database access.
This command is used to prune all databases and delete all empty records from the cluster.
</p><p>
Example: ctdb vacuum
</p><p>
By default, this operation is issued from the 00.ctdb event script every 5 minutes.
- </p></div></div><div class="refsect1" lang="en"><a name="id2529
058"></a><h2>Debugging Commands</h2><p>
+ </p></div></div><div class="refsect1" lang="en"><a name="id2529
126"></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" lang="en"><a name="id2529
068"></a><h3>process-exists <pid></h3><p>
+ </p><div class="refsect2" lang="en"><a name="id2529
136"></a><h3>process-exists <pid></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" lang="en"><a name="id2529
080"></a><h3>getdbmap</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2529
149"></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>
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.
dbid:0xb775fff6 name:secrets.tdb path:/var/ctdb/persistent/secrets.tdb.0 PERSISTENT
dbid:0xe98e08b6 name:group_mapping.tdb path:/var/ctdb/persistent/group_mapping.tdb.0 PERSISTENT
dbid:0x7bbbd26c name:passdb.tdb path:/var/ctdb/persistent/passdb.tdb.0 PERSISTENT
- </pre></div><div class="refsect2" lang="en"><a name="id25291
27"></a><h3>catdb <dbname></h3><p>
+ </pre></div><div class="refsect2" lang="en"><a name="id25291
95"></a><h3>catdb <dbname></h3><p>
This command will dump a clustered TDB database to the screen. This is a debugging command.
- </p></div><div class="refsect2" lang="en"><a name="id2529
138"></a><h3>getmonmode</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2529
206"></a><h3>getmonmode</h3><p>
This command returns the monutoring mode of a node. The monitoring mode is either ACTIVE or DISABLED. Normally a node will continously monitor that all other nodes that are expected are in fact connected and that they respond to commands.
</p><p>
ACTIVE - This is the normal mode. The node is actively monitoring all other nodes, both that the transport is connected and also that the node responds to commands. If a node becomes unavailable, it will be marked as DISCONNECTED and a recovery is initiated to restore the cluster.
</p><p>
DISABLED - This node is not monitoring that other nodes are available. In this mode a node failure will not be detected and no recovery will be performed. This mode is useful when for debugging purposes one wants to attach GDB to a ctdb process but wants to prevent the rest of the cluster from marking this node as DISCONNECTED and do a recovery.
- </p></div><div class="refsect2" lang="en"><a name="id2529
168"></a><h3>setmonmode <0|1></h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2529
236"></a><h3>setmonmode <0|1></h3><p>
This command can be used to explicitely disable/enable monitoring mode on a node. The main purpose is if one wants to attach GDB to a running ctdb daemon but wants to prevent the other nodes from marking it as DISCONNECTED and issuing a recovery. To do this, set monitoring mode to 0 on all nodes before attaching with GDB. Remember to set monitoring mode back to 1 afterwards.
- </p></div><div class="refsect2" lang="en"><a name="id2529
184"></a><h3>attach <dbname></h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2529
252"></a><h3>attach <dbname></h3><p>
This is a debugging command. This command will make the CTDB daemon create a new CTDB database and attach to it.
- </p></div><div class="refsect2" lang="en"><a name="id2529
195"></a><h3>dumpmemory</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2529
263"></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" lang="en"><a name="id25292
07"></a><h3>freeze</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id25292
75"></a><h3>freeze</h3><p>
This command will lock all the local TDB databases causing clients
that are accessing these TDBs such as samba3 to block until the
databases are thawed.
This is primarily used by the recovery daemon to stop all samba
daemons from accessing any databases while the database is recovered
and rebuilt.
- </p></div><div class="refsect2" lang="en"><a name="id25292
25"></a><h3>thaw</h3><p>
+ </p></div><div class="refsect2" lang="en"><a name="id25292
93"></a><h3>thaw</h3><p>
Thaw a previously frozen node.
- </p></div></div><div class="refsect1" lang="en"><a name="id2529
236"></a><h2>SEE ALSO</h2><p>
+ </p></div></div><div class="refsect1" lang="en"><a name="id2529
304"></a><h2>SEE ALSO</h2><p>
ctdbd(1), onnode(1)
- <a href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
- </p></div><div class="refsect1" lang="en"><a name="id2529
249"></a><h2>COPYRIGHT/LICENSE</h2><div class="literallayout"><p><br>
+ <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
+ </p></div><div class="refsect1" lang="en"><a name="id2529
317"></a><h2>COPYRIGHT/LICENSE</h2><div class="literallayout"><p><br>
Copyright (C) Andrew Tridgell 2007<br>
Copyright (C) Ronnie sahlberg 2007<br>
<br>
.\" Title: ctdbd
.\" Author:
-.\" Generator: DocBook XSL Stylesheets v1.71.0 <http://docbook.sf.net/>
-.\" Date: 07/10/2008
+.\" Generator: DocBook XSL Stylesheets v1.73.2 <http://docbook.sf.net/>
+.\" Date: 09/15/2008
.\" Manual:
.\" Source:
.\"
-.TH "CTDBD" "1" "07/10/2008" "" ""
+.TH "CTDBD" "1" "09/15/2008" "" ""
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.SH "NAME"
-ctdbd \- The CTDB cluster daemon
+ctdbd - The CTDB cluster daemon
.SH "SYNOPSIS"
.HP 6
\fBctdbd\fR
\fBctdbd\fR [\-?\ \-\-help] [\-d\ \-\-debug=<INTEGER>] {\-\-dbdir=<directory>} {\-\-dbdir\-persistent=<directory>} [\-\-event\-script\-dir=<directory>] [\-i\ \-\-interactive] [\-\-listen=<address>] [\-\-logfile=<filename>] [\-\-lvs] {\-\-nlist=<filename>} [\-\-no\-lmaster] [\-\-no\-recmaster] [\-\-nosetsched] [\-\-public\-addresses=<filename>] [\-\-public\-interface=<interface>] {\-\-reclock=<filename>} [\-\-single\-public\-ip=<address>] [\-\-socket=<filename>] [\-\-start\-as\-disabled] [\-\-syslog] [\-\-torture] [\-\-transport=<STRING>] [\-\-usage]
.SH "DESCRIPTION"
.PP
-ctdbd is the main ctdb daemon.
+ctdbd is the main ctdb daemon\.
.PP
-ctdbd provides a clustered version of the TDB database with automatic rebuild/recovery of the databases upon nodefailures.
+ctdbd provides a clustered version of the TDB database with automatic rebuild/recovery of the databases upon nodefailures\.
.PP
-Combined with a cluster filesystem ctdbd provides a full HA environment for services such as clustered Samba and NFS as well as other services.
+Combined with a cluster filesystem ctdbd provides a full HA environment for services such as clustered Samba and NFS as well as other services\.
.PP
-ctdbd provides monitoring of all nodes in the cluster and automatically reconfigures the cluster and recovers upon node failures.
+ctdbd provides monitoring of all nodes in the cluster and automatically reconfigures the cluster and recovers upon node failures\.
.PP
-ctdbd is the main component in clustered Samba that provides a high\-awailability load\-sharing CIFS server cluster.
+ctdbd is the main component in clustered Samba that provides a high\-availability load\-sharing CIFS server cluster\.
.SH "OPTIONS"
.PP
\-? \-\-help
-.RS 3n
-Print some help text to the screen.
+.RS 4
+Print some help text to the screen\.
.RE
.PP
\-d \-\-debug=<DEBUGLEVEL>
-.RS 3n
-This option sets the debuglevel on the ctdbd daemon which controls what will be written to the logfile. The default is 0 which will only log important events and errors. A larger number will provide additional logging.
+.RS 4
+This option sets the debuglevel on the ctdbd daemon which controls what will be written to the logfile\. The default is 0 which will only log important events and errors\. A larger number will provide additional logging\.
.RE
.PP
\-\-dbdir=<directory>
-.RS 3n
-This is the directory on local storage where ctdbd keeps the local copy of the TDB databases. This directory is local for each node and should not be stored on the shared cluster filesystem.
+.RS 4
+This is the directory on local storage where ctdbd keeps the local copy of the TDB databases\. This directory is local for each node and should not be stored on the shared cluster filesystem\.
.sp
-This directory would usually be /var/ctdb .
+This directory would usually be /var/ctdb \.
.RE
.PP
\-\-dbdir\-persistent=<directory>
-.RS 3n
-This is the directory on local storage where ctdbd keeps the local copy of the persistent TDB databases. This directory is local for each node and should not be stored on the shared cluster filesystem.
+.RS 4
+This is the directory on local storage where ctdbd keeps the local copy of the persistent TDB databases\. This directory is local for each node and should not be stored on the shared cluster filesystem\.
.sp
-This directory would usually be /etc/ctdb/persistent .
+This directory would usually be /etc/ctdb/persistent \.
.RE
.PP
\-\-event\-script\-dir=<directory>
-.RS 3n
-This option is used to specify the directory where the CTDB event scripts are stored.
+.RS 4
+This option is used to specify the directory where the CTDB event scripts are stored\.
.sp
-This will normally be /etc/ctdb/events.d which is part of the ctdb distribution.
+This will normally be /etc/ctdb/events\.d which is part of the ctdb distribution\.
.RE
.PP
\-i \-\-interactive
-.RS 3n
-By default ctdbd will detach itself from the shell and run in the background as a daemon. This option makes ctdbd to start in interactive mode.
+.RS 4
+By default ctdbd will detach itself from the shell and run in the background as a daemon\. This option makes ctdbd to start in interactive mode\.
.RE
.PP
\-\-listen=<address>
-.RS 3n
-This specifies which ip address ctdb will bind to. By default ctdbd will bind to the first address it finds in the /etc/ctdb/nodes file and which is also present on the local system in which case you do not need to provide this option.
+.RS 4
+This specifies which ip address ctdb will bind to\. By default ctdbd will bind to the first address it finds in the /etc/ctdb/nodes file and which is also present on the local system in which case you do not need to provide this option\.
.sp
-This option is only required when you want to run multiple ctdbd daemons/nodes on the same physical host in which case there would be multiple entries in /etc/ctdb/nodes what would match a local interface.
+This option is only required when you want to run multiple ctdbd daemons/nodes on the same physical host in which case there would be multiple entries in /etc/ctdb/nodes what would match a local interface\.
.RE
.PP
\-\-logfile=<filename>
-.RS 3n
-This is the file where ctdbd will write its log. This is usually /var/log/log.ctdb .
+.RS 4
+This is the file where ctdbd will write its log\. This is usually /var/log/log\.ctdb \.
.RE
.PP
\-\-lvs
-.RS 3n
-This option is used to activate the LVS capability on a CTDB node. Please see the LVS section.
+.RS 4
+This option is used to activate the LVS capability on a CTDB node\. Please see the LVS section\.
.RE
.PP
\-\-nlist=<filename>
-.RS 3n
-This file contains a list of the private ip addresses of every node in the cluster. There is one line/ip address for each node. This file must be the same for all nodes in the cluster.
+.RS 4
+This file contains a list of the private ip addresses of every node in the cluster\. There is one line/ip address for each node\. This file must be the same for all nodes in the cluster\.
.sp
-This file is usually /etc/ctdb/nodes .
+This file is usually /etc/ctdb/nodes \.
.RE
.PP
\-\-no\-lmaster
-.RS 3n
-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.
+.RS 4
+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\.
.sp
-Please see the "remote cluster nodes" section for more information.
+Please see the "remote cluster nodes" section for more information\.
.RE
.PP
\-\-no\-recmaster
-.RS 3n
-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.
+.RS 4
+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\.
.sp
-Please see the "remote cluster nodes" section for more information.
+Please see the "remote cluster nodes" section for more information\.
.RE
.PP
\-\-nosetsched
-.RS 3n
-This is a ctdbd debugging option. this option is only used when debugging ctdbd.
+.RS 4
+This is a ctdbd debugging option\. this option is only used when debugging ctdbd\.
.sp
-Normally ctdb 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.
+Normally ctdb 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\.
.sp
-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 real\-time process.)
+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 real\-time process\.)
.RE
.PP
\-\-public_addresses=<filename>
-.RS 3n
-When used with IP takeover this specifies a file containing the public ip addresses to use on the cluster. This file contains a list of ip addresses netmasks and interfaces. When ctdb is operational it will distribute these public ip addresses evenly across the available nodes.
+.RS 4
+When used with IP takeover this specifies a file containing the public ip addresses to use on the cluster\. This file contains a list of ip addresses netmasks and interfaces\. When ctdb is operational it will distribute these public ip addresses evenly across the available nodes\.
.sp
This is usually the file /etc/ctdb/public_addresses
.RE
.PP
\-\-public\-interface=<interface>
-.RS 3n
-This option tells ctdb which interface to attach public\-addresses to and also where to attach the single\-public\-ip when used.
+.RS 4
+This option tells ctdb which interface to attach public\-addresses to and also where to attach the single\-public\-ip when used\.
.sp
-This is only required when using public ip addresses and only when you dont specify the interface explicitely on in /etc/ctdb/public_addresses or when you are using \-\-single\-public\-ip.
+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\.
.sp
-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.
+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\.
.RE
.PP
\-\-reclock=<filename>
-.RS 3n
-This is the name of the lock file stored of the shared cluster filesystem that ctdbd uses to arbitrate which node has the role of recovery\-master. This file must be stored on shared storage.
+.RS 4
+This is the name of the lock file stored of the shared cluster filesystem that ctdbd uses to arbitrate which node has the role of recovery\-master\. This file must be stored on shared storage\.
.RE
.PP
\-\-single\-public\-ip=<address>
-.RS 3n
-This option is used to activate the "ipmux" or the "lvs" functionality of ctdb where the cluster provides a single public ip address for the entire cluster. When using this option you must also use the \-\-public\-interface option.
+.RS 4
+This option is used to activate the "ipmux" or the "lvs" functionality of ctdb where the cluster provides a single public ip address for the entire cluster\. When using this option you must also use the \-\-public\-interface option\.
.sp
-In this mode, all nodes of the cluster will expose a single ip address from all nodes with all incoming traffic to the cluster being passed through the current recmaster. This functionality is similar to using a load\-balancing switch.
+In this mode, all nodes of the cluster will expose a single ip address from all nodes with all incoming traffic to the cluster being passed through the current recmaster\. This functionality is similar to using a load\-balancing switch\.
.sp
-All incoming packets are sent to the recmaster which will multiplex the clients across all available nodes and pass the packets on to a different node in the cluster to manage the connection based on the clients ip address. Outgoing packets however are sent directly from the node that was choosen back to the client. Since all incoming packets are sent through the recmaster this will have a throughput and performance impact when used. This impact in performance primarily affects write\-performance while read\-performance should be mainly unaffected. Only use this feature if your environment is mostly\-read (i.e. most traffic is from the nodes back to the clients) or if it is not important to get maximum write\-performance to the cluster.
+All incoming packets are sent to the recmaster which will multiplex the clients across all available nodes and pass the packets on to a different node in the cluster to manage the connection based on the clients ip address\. Outgoing packets however are sent directly from the node that was choosen back to the client\. Since all incoming packets are sent through the recmaster this will have a throughput and performance impact when used\. This impact in performance primarily affects write\-performance while read\-performance should be mainly unaffected\. Only use this feature if your environment is mostly\-read (i\.e\. most traffic is from the nodes back to the clients) or if it is not important to get maximum write\-performance to the cluster\.
.sp
-This feature is completely controlled from the eventscripts and does not require any CTDBD involvement. However, the CTDBD daemon does need to know that the "single public ip" exists so that the CTDBD daemon will allow clients to set up killtcp to work on this ip address.
+This feature is completely controlled from the eventscripts and does not require any CTDBD involvement\. However, the CTDBD daemon does need to know that the "single public ip" exists so that the CTDBD daemon will allow clients to set up killtcp to work on this ip address\.
.sp
-CTDBD only allows clients to use killtcp to kill off (RST) tcp connections to/from an ip address that is either a normal public address or to/from the ip address specified by \-\-single\-public\-ip. No other tcp connections are allowed to be specified with killtcp.
+CTDBD only allows clients to use killtcp to kill off (RST) tcp connections to/from an ip address that is either a normal public address or to/from the ip address specified by \-\-single\-public\-ip\. No other tcp connections are allowed to be specified with killtcp\.
.sp
-Please note that ipmux is obsolete. Use LVS, not ipmux. Please see the LVS section in this manpage for instructions on how to configure and use CTDB with LVS.
+Please note that ipmux is obsolete\. Use LVS, not ipmux\. Please see the LVS section in this manpage for instructions on how to configure and use CTDB with LVS\.
.RE
.PP
\-\-socket=<filename>
-.RS 3n
-This specifies the name of the domain socket that ctdbd will create. This socket is used for local clients to attach to and communicate with the ctdbd daemon.
+.RS 4
+This specifies the name of the domain socket that ctdbd will create\. This socket is used for local clients to attach to and communicate with the ctdbd daemon\.
.sp
-The default is /tmp/ctdb.socket . You only need to use this option if you plan to run multiple ctdbd daemons on the same physical host.
+The default is /tmp/ctdb\.socket \. You only need to use this option if you plan to run multiple ctdbd daemons on the same physical host\.
.RE
.PP
\-\-start\-as\-disabled
-.RS 3n
-This makes the ctdb daemon to be DISABLED when it starts up.
+.RS 4
+This makes the ctdb daemon to be DISABLED when it starts up\.
.sp
-As it is DISABLED it will not get any of the public ip addresses allocated to it, and thus this allow you to start ctdb on a node without causing any ip address to failover from other nodes onto the new node.
+As it is DISABLED it will not get any of the public ip addresses allocated to it, and thus this allow you to start ctdb on a node without causing any ip address to failover from other nodes onto the new node\.
.sp
-When used, the administrator must keep track of when nodes start and manually enable them again using the "ctdb enable" command, or else the node will not host any services.
+When used, the administrator must keep track of when nodes start and manually enable them again using the "ctdb enable" command, or else the node will not host any services\.
.sp
-A node that is DISABLED will not host any services and will not be reachable/used by any clients.
+A node that is DISABLED will not host any services and will not be reachable/used by any clients\.
.RE
.PP
\-\-syslog
-.RS 3n
-Send all log messages to syslog instead of to the ctdb logfile.
+.RS 4
+Send all log messages to syslog instead of to the ctdb logfile\.
.RE
.PP
\-\-torture
-.RS 3n
-This option is only used for development and testing of ctdbd. It adds artificial errors and failures to the common codepaths in ctdbd to verify that ctdbd can recover correctly for failures.
+.RS 4
+This option is only used for development and testing of ctdbd\. It adds artificial errors and failures to the common codepaths in ctdbd to verify that ctdbd can recover correctly for failures\.
.sp
-You do NOT want to use this option unless you are developing and testing new functionality in ctdbd.
+You do NOT want to use this option unless you are developing and testing new functionality in ctdbd\.
.RE
.PP
\-\-transport=<STRING>
-.RS 3n
-This option specifies which transport to use for ctdbd internode communications. The default is "tcp".
+.RS 4
+This option specifies which transport to use for ctdbd internode communications\. The default is "tcp"\.
.sp
-Currently only "tcp" is supported but "infiniband" might be implemented in the future.
+Currently only "tcp" is supported but "infiniband" might be implemented in the future\.
.RE
.PP
\-\-usage
-.RS 3n
-Print useage information to the screen.
+.RS 4
+Print useage information to the screen\.
.RE
.SH "PRIVATE VS PUBLIC ADDRESSES"
.PP
-When used for ip takeover in a HA environment, each node in a ctdb cluster has multiple ip addresses assigned to it. One private and one or more public.
+When used for ip takeover in a HA environment, each node in a ctdb cluster has multiple ip addresses assigned to it\. One private and one or more public\.
.SS "Private address"
.PP
-This is the physical ip address of the node which is configured in linux and attached to a physical interface. This address uniquely identifies a physical node in the cluster and is the ip addresses that ctdbd will use to communicate with the ctdbd daemons on the other nodes in the cluster.
+This is the physical ip address of the node which is configured in linux and attached to a physical interface\. This address uniquely identifies a physical node in the cluster and is the ip addresses that ctdbd will use to communicate with the ctdbd daemons on the other nodes in the cluster\.
.PP
-The private addresses are configured in /etc/ctdb/nodes (unless the \-\-nlist option is used) and contain one line for each node in the cluster. Each line contains the private ip address for one node in the cluster. This file must be the same on all nodes in the cluster.
+The private addresses are configured in /etc/ctdb/nodes (unless the \-\-nlist option is used) and contain one line for each node in the cluster\. Each line contains the private ip address for one node in the cluster\. This file must be the same on all nodes in the cluster\.
.PP
-Since the private addresses are only available to the network when the corresponding node is up and running you should not use these addresses for clients to connect to services provided by the cluster. Instead client applications should only attach to the public addresses since these are guaranteed to always be available.
+Since the private addresses are only available to the network when the corresponding node is up and running you should not use these addresses for clients to connect to services provided by the cluster\. Instead client applications should only attach to the public addresses since these are guaranteed to always be available\.
.PP
-When using ip takeover, it is strongly recommended that the private addresses are configured on a private network physically separated from the rest of the network and that this private network is dedicated to CTDB traffic.
+When using ip takeover, it is strongly recommended that the private addresses are configured on a private network physically separated from the rest of the network and that this private network is dedicated to CTDB traffic\.
Example /etc/ctdb/nodes for a four node cluster:
.sp
-.RS 3n
+.RS 4
.nf
- 10.1.1.1
- 10.1.1.2
- 10.1.1.3
- 10.1.1.4
+ 10\.1\.1\.1
+ 10\.1\.1\.2
+ 10\.1\.1\.3
+ 10\.1\.1\.4
.fi
.RE
.SS "Public address"
.PP
-A public address on the other hand is not attached to an interface. This address is managed by ctdbd itself and is attached/detached to a physical node at runtime.
+A public address on the other hand is not attached to an interface\. This address is managed by ctdbd itself and is attached/detached to a physical node at runtime\.
.PP
-The ctdb cluster will assign/reassign these public addresses across the available healthy nodes in the cluster. When one node fails, its public address will be migrated to and taken over by a different node in the cluster to ensure that all public addresses are always available to clients as long as there are still nodes available capable of hosting this address.
+The ctdb cluster will assign/reassign these public addresses across the available healthy nodes in the cluster\. When one node fails, its public address will be migrated to and taken over by a different node in the cluster to ensure that all public addresses are always available to clients as long as there are still nodes available capable of hosting this address\.
.PP
-These addresses are not physically attached to a specific node. The 'ctdb ip' command can be used to view the current assignment of public addresses and which physical node is currently serving it.
+These addresses are not physically attached to a specific node\. The \'ctdb ip\' command can be used to view the current assignment of public addresses and which physical node is currently serving it\.
.PP
-On each node this file contains a list of the public addresses that this node is capable of hosting. The list also contain the netmask and the interface where this address should be attached for the case where you may want to serve data out through multiple different interfaces.
+On each node this file contains a list of the public addresses that this node is capable of hosting\. The list also contain the netmask and the interface where this address should be attached for the case where you may want to serve data out through multiple different interfaces\.
Example /etc/ctdb/public_addresses for a node that can host 4 public addresses:
.sp
-.RS 3n
+.RS 4
.nf
- 11.1.1.1/24 eth0
- 11.1.1.2/24 eth0
- 11.1.2.1/24 eth1
- 11.1.2.2/24 eth1
+ 11\.1\.1\.1/24 eth0
+ 11\.1\.1\.2/24 eth0
+ 11\.1\.2\.1/24 eth1
+ 11\.1\.2\.2/24 eth1
.fi
.RE
.PP
-In most cases this file would be the same on all nodes in a cluster but there are exceptions when one may want to use different files on different nodes.
+In most cases this file would be the same on all nodes in a cluster but there are exceptions when one may want to use different files on different nodes\.
Example: 4 nodes partitioned into two subgroups :
.sp
-.RS 3n
+.RS 4
.nf
Node 0:/etc/ctdb/public_addresses
- 10.1.1.1/24 eth0
- 10.1.1.2/24 eth0
+ 10\.1\.1\.1/24 eth0
+ 10\.1\.1\.2/24 eth0
Node 1:/etc/ctdb/public_addresses
- 10.1.1.1/24 eth0
- 10.1.1.2/24 eth0
+ 10\.1\.1\.1/24 eth0
+ 10\.1\.1\.2/24 eth0
Node 2:/etc/ctdb/public_addresses
- 10.2.1.1/24 eth0
- 10.2.1.2/24 eth0
+ 10\.2\.1\.1/24 eth0
+ 10\.2\.1\.2/24 eth0
Node 3:/etc/ctdb/public_addresses
- 10.2.1.1/24 eth0
- 10.2.1.2/24 eth0
+ 10\.2\.1\.1/24 eth0
+ 10\.2\.1\.2/24 eth0
.fi
.RE
.PP
-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.2.1.x network.
+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\.2\.1\.x network\.
.PP
-Ip address 10.1.1.1 can be hosted by either of nodes 0 or 1 and will be available to clients as long as at least one of these two nodes are available. If both nodes 0 and node 1 become unavailable 10.1.1.1 also becomes unavailable. 10.1.1.1 can not be failed over to node 2 or node 3 since these nodes do not have this ip address listed in their public addresses file.
+Ip address 10\.1\.1\.1 can be hosted by either of nodes 0 or 1 and will be available to clients as long as at least one of these two nodes are available\. If both nodes 0 and node 1 become unavailable 10\.1\.1\.1 also becomes unavailable\. 10\.1\.1\.1 can not be failed over to node 2 or node 3 since these nodes do not have this ip address listed in their public addresses file\.
.SH "NODE STATUS"
.PP
-The current status of each node in the cluster can be viewed by the 'ctdb status' command.
+The current status of each node in the cluster can be viewed by the \'ctdb status\' command\.
.PP
-There are five possible for a node.
+There are five possible states for a node\.
.PP
-OK \- This node is fully functional.
+OK \- This node is fully functional\.
.PP
-DISCONNECTED \- This node could not be connected through the network and is currently not particpating in the cluster. If there is a public IP address associated with this node it should have been taken over by a different node. No services are running on this node.
+DISCONNECTED \- This node could not be connected through the network and is currently not particpating in the cluster\. If there is a public IP address associated with this node it should have been taken over by a different node\. No services are running on this node\.
.PP
-DISABLED \- This node has been administratively disabled. This node is still functional and participates in the CTDB cluster but its IP addresses have been taken over by a different node and no services are currently being hosted.
+DISABLED \- This node has been administratively disabled\. This node is still functional and participates in the CTDB cluster but its IP addresses have been taken over by a different node and no services are currently being hosted\.
.PP
-UNHEALTHY \- A service provided by this node is malfunctioning and should be investigated. The CTDB daemon itself is operational and participates in the cluster. Its public IP address has been taken over by a different node and no services are currently being hosted. All unhealthy nodes should be investigated and require an administrative action to rectify.
+UNHEALTHY \- A service provided by this node is malfunctioning and should be investigated\. The CTDB daemon itself is operational and participates in the cluster\. Its public IP address has been taken over by a different node and no services are currently being hosted\. All unhealthy nodes should be investigated and require an administrative action to rectify\.
.PP
-BANNED \- This node failed too many recovery attempts and has been banned from participating in the cluster for a period of RecoveryBanPeriod seconds. Any public IP address has been taken over by other nodes. This node does not provide any services. All banned nodes should be investigated and require an administrative action to rectify. This node does not perticipate in the CTDB cluster but can still be communicated with. I.e. ctdb commands can be sent to it.
+BANNED \- This node failed too many recovery attempts and has been banned from participating in the cluster for a period of RecoveryBanPeriod seconds\. Any public IP address has been taken over by other nodes\. This node does not provide any services\. All banned nodes should be investigated and require an administrative action to rectify\. This node does not perticipate in the CTDB cluster but can still be communicated with\. I\.e\. ctdb commands can be sent to it\.
.SH "PUBLIC TUNABLES"
.PP
-These are the public tuneables that can be used to control how ctdb behaves.
+These are the public tuneables that can be used to control how ctdb behaves\.
.SS "KeepaliveInterval"
.PP
Default: 1
.PP
-How often should the nodes send keepalives to eachother.
+How often should the nodes send keepalives to eachother\.
.SS "KeepaliveLimit"
.PP
Default: 5
.PP
-After how many keepalive intervals without any traffic should a node wait until marking the peer as DISCONNECTED.
+After how many keepalive intervals without any traffic should a node wait until marking the peer as DISCONNECTED\.
.SS "MonitorInterval"
.PP
Default: 15
.PP
-How often should ctdb run the event scripts to check for a nodes health.
+How often should ctdb run the event scripts to check for a nodes health\.
.SS "TickleUpdateInterval"
.PP
Default: 20
.PP
-How often will ctdb record and store the "tickle" information used to kickstart stalled tcp connections after a recovery.
+How often will ctdb record and store the "tickle" information used to kickstart stalled tcp connections after a recovery\.
.SS "EventScriptTimeout"
.PP
Default: 20
.PP
-How long should ctdb let an event script run before aborting it and marking the node unhealthy.
+How long should ctdb let an event script run before aborting it and marking the node unhealthy\.
.SS "RecoveryBanPeriod"
.PP
Default: 300
.PP
-If a node becomes banned causing repetitive recovery failures. The node will eventually become banned from the cluster. This controls how long the culprit node will be banned from the cluster before it is allowed to try to join the cluster again. Dont set to small. A node gets banned for a reason and it is usually due to real problems with the node.
+If a node becomes banned causing repetitive recovery failures\. The node will eventually become banned from the cluster\. This controls how long the culprit node will be banned from the cluster before it is allowed to try to join the cluster again\. Dont set to small\. A node gets banned for a reason and it is usually due to real problems with the node\.
.SS "DatabaseHashSize"
.PP
Default: 100000
.PP
-Size of the hash chains for the local store of the tdbs that ctdb manages.
+Size of the hash chains for the local store of the tdbs that ctdb manages\.
.SS "RerecoveryTimeout"
.PP
Default: 10
.PP
-Once a recovery has completed, no additional recoveries are permitted until this timeout has expired.
+Once a recovery has completed, no additional recoveries are permitted until this timeout has expired\.
.SS "EnableBans"
.PP
Default: 1
.PP
-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\. Dont set to 0\.
.SS "DeterministicIPs"
.PP
Default: 1
.PP
-When enabled, this tunable makes ctdb try to keep public ip addresses locked to specific nodes as far as possible. This makes it easier for debugging since you can know that as long as all nodes are healthy public ip X will always be hosted by node Y.
+When enabled, this tunable makes ctdb try to keep public IP addresses locked to specific nodes as far as possible\. This makes it easier for debugging since you can know that as long as all nodes are healthy public IP X will always be hosted by node Y\.
.PP
-The cost of using deterministic ip address assignment is that it disables part of the logic where ctdb tries to reduce the number of public ip assignment changes in the cluster. This tunable may increase the number of ip failover/failbacks that are performed on the cluster by a small margin.
+The cost of using deterministic IP address assignment is that it disables part of the logic where ctdb tries to reduce the number of public IP assignment changes in the cluster\. This tunable may increase the number of IP failover/failbacks that are performed on the cluster by a small margin\.
.SS "DisableWhenUnhealthy"
.PP
Default: 0
.PP
-When set, As soon as a node becomes unhealthy, that node will also automatically become permanently DISABLED. Once a node is DISABLED, the only way to make it participate in the cluster again and host services is by manually enabling the node again using 'ctdb enable'.
+When set, As soon as a node becomes unhealthy, that node will also automatically become permanently DISABLED\. Once a node is DISABLED, the only way to make it participate in the cluster again and host services is by manually enabling the node again using \'ctdb enable\'\.
.PP
-This disables parts of the resilience and robustness of the cluster and should ONLY be used when the system administrator is actively monitoring the cluster, so that nodes can be enabled again.
+This disables parts of the resilience and robustness of the cluster and should ONLY be used when the system administrator is actively monitoring the cluster, so that nodes can be enabled again\.
.SS "NoIPFailback"
.PP
Default: 0
.PP
-When set to 1, ctdb will not perform failback of ip addresses when a node becomes healthy. Ctdb WILL perform failover of public ip addresses when a node becomes UNHEALTHY, but when the node becomes HEALTHY again, ctdb will not fail the addresses back.
+When set to 1, ctdb will not perform failback of IP addresses when a node becomes healthy\. Ctdb WILL perform failover of public IP addresses when a node becomes UNHEALTHY, but when the node becomes HEALTHY again, ctdb will not fail the addresses back\.
.PP
-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.
+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\.
.PP
-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.
+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\.
.SH "LVS"
.PP
-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.
+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\.
.PP
-This is similar to using a layer\-4 loadbalancing switch but with some restrictions.
+This is similar to using a layer\-4 loadbalancing switch but with some restrictions\.
.PP
-In this mode the cluster select a set of nodes in the cluster and loadbalance all client access to the LVS address across this set of nodes. This set of nodes are all LVS capable nodes that are HEALTHY, or if no HEALTHY nodes exists all LVS capable nodes regardless of health status. LVS will however never loadbalance traffic to nodes that are BANNED, DISABLED or DISCONNECTED. The "ctdb lvs" command is used to show which nodes are currently load\-balanced across.
+In this mode the cluster select a set of nodes in the cluster and loadbalance all client access to the LVS address across this set of nodes\. This set of nodes are all LVS capable nodes that are HEALTHY, or if no HEALTHY nodes exists all LVS capable nodes regardless of health status\. LVS will however never loadbalance traffic to nodes that are BANNED, DISABLED or DISCONNECTED\. The "ctdb lvs" command is used to show which nodes are currently load\-balanced across\.
.PP
-One of the these nodes are elected as the LVSMASTER. This node receives all traffic from clients coming in to the LVS address and multiplexes it across the internal network to one of the nodes that LVS is using. When responding to the client, that node will send the data back directly to the client, bypassing the LVSMASTER node. The command "ctdb lvsmaster" will show which node is the current LVSMASTER.
+One of the these nodes are elected as the LVSMASTER\. This node receives all traffic from clients coming in to the LVS address and multiplexes it across the internal network to one of the nodes that LVS is using\. When responding to the client, that node will send the data back directly to the client, bypassing the LVSMASTER node\. The command "ctdb lvsmaster" will show which node is the current LVSMASTER\.
.PP
The path used for a client i/o is thus :
.sp
-.RS 3n
+.RS 4
.nf
(1) Client sends request packet to LVSMASTER
- (2) LVSMASTER passes the request on to one node across the internal network.
- (3) Selected node processes the request.
- (4) Node responds back to client.
+ (2) LVSMASTER passes the request on to one node across the internal network\.
+ (3) Selected node processes the request\.
+ (4) Node responds back to client\.
.fi
.RE
-.sp
.PP
-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 wery 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 rates in this mode.
+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 wery 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 rates in this mode\.
.PP
-Note: you can use LVS and public addresses at the same time.
+Note: you can use LVS and public addresses at the same time\.
.SS "Configuration"
.PP
-To activate LVS on a CTDB node you must specify CTDB_PUBLIC_INTERFACE and CTDB_LVS_PUBLIC_ADDRESS in /etc/sysconfig/ctdb.
+To activate LVS on a CTDB node you must specify CTDB_PUBLIC_INTERFACE and CTDB_LVS_PUBLIC_ADDRESS in /etc/sysconfig/ctdb\.
.PP
-You must also specify the "\-\-lvs" command line argument to ctdbd to activete LVS as a capability of the node. This should be done automatically for you by the /etc/init.d/ctdb script.
+You must also specify the "\-\-lvs" command line argument to ctdbd to activete LVS as a capability of the node\. This should be done automatically for you by the /etc/init\.d/ctdb script\.
.PP
Example:
.sp
-.RS 3n
+.RS 4
.nf
CTDB_PUBLIC_INTERFACE=eth0
- CTDB_LVS_PUBLIC_IP=10.0.0.237
+ CTDB_LVS_PUBLIC_IP=10\.0\.0\.237
.fi
.RE
-.sp
.PP
-If you use LVS, you must still have a real/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. (we can not use the lvs ip address to initiate outgoing traffic)
+If you use LVS, you must still have a real/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\. (we can not use the lvs IP address to initiate outgoing traffic)
.PP
-I.e. make sure that you can "ping" both the domain controller and also all of the clients from the node BEFORE you enable LVS. Also make sure that when you ping these hosts that the traffic is routed out through the eth0 interface.
+I\.e\. make sure that you can "ping" both the domain controller and also all of the clients from the node BEFORE you enable LVS\. Also make sure that when you ping these hosts that the traffic is routed out through the eth0 interface\.
.SH "REMOTE CLUSTER NODES"
.PP
-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.
+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\.
.PP
-See the cluster as one single multihomed samba server where one of the NICs (the remote node) is very far away.
+See the cluster as one single multihomed samba server where one of the NICs (the remote node) is very far away\.
.PP
-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.
+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\.
.PP
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:
.sp
-.RS 3n
+.RS 4
.nf
CTDB_CAPABILITY_LMASTER=no
CTDB_CAPABILITY_RECMASTER=no
.fi
.RE
-.sp
.PP
-Verify with the command "ctdb getcapabilities" that that node no longer has the recmaster or the lmaster capabilities.
+Verify with the command "ctdb getcapabilities" that that node no longer has the recmaster or the lmaster capabilities\.
.SH "SEE ALSO"
.PP
ctdb(1), onnode(1)
\fI\%http://ctdb.samba.org/\fR
.SH "COPYRIGHT/LICENSE"
.sp
-.RS 3n
+.RS 4
.nf
Copyright (C) Andrew Tridgell 2007
Copyright (C) Ronnie sahlberg 2007
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or (at
-your option) any later version.
+your option) any later version\.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-General Public License for more details.
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE\. See the GNU
+General Public License for more details\.
You should have received a copy of the GNU General Public License
-along with this program; if not, see http://www.gnu.org/licenses/.
+along with this program; if not, see http://www\.gnu\.org/licenses/\.
.fi
.RE
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdbd</title><meta name="generator" content="DocBook XSL Stylesheets V1.7
1.0"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en"><a name="ctdbd.1"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdbd — The CTDB cluster daemon</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ctdbd</code> </p></div><div class="cmdsynopsis"><p><code class="command">ctdbd</code> [-? --help] [-d --debug=<INTEGER>] {--dbdir=<directory>} {--dbdir-persistent=<directory>} [--event-script-dir=<directory>] [-i --interactive] [--listen=<address>] [--logfile=<filename>] [--lvs] {--nlist=<filename>} [--no-lmaster] [--no-recmaster] [--nosetsched] [--public-addresses=<filename>] [--public-interface=<interface>] {--reclock=<filename>} [--single-public-ip=<address>] [--socket=<filename>] [--start-as-disabled] [--syslog] [--torture] [--transport=<STRING>] [--usage]</p></div></div><div class="refsect1" lang="en"><a name="id2481166"></a><h2>DESCRIPTION</h2><p>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdbd</title><meta name="generator" content="DocBook XSL Stylesheets V1.7
3.2"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en"><a name="ctdbd.1"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdbd — The CTDB cluster daemon</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">ctdbd</code> </p></div><div class="cmdsynopsis"><p><code class="command">ctdbd</code> [-? --help] [-d --debug=<INTEGER>] {--dbdir=<directory>} {--dbdir-persistent=<directory>} [--event-script-dir=<directory>] [-i --interactive] [--listen=<address>] [--logfile=<filename>] [--lvs] {--nlist=<filename>} [--no-lmaster] [--no-recmaster] [--nosetsched] [--public-addresses=<filename>] [--public-interface=<interface>] {--reclock=<filename>} [--single-public-ip=<address>] [--socket=<filename>] [--start-as-disabled] [--syslog] [--torture] [--transport=<STRING>] [--usage]</p></div></div><div class="refsect1" lang="en"><a name="id2479648"></a><h2>DESCRIPTION</h2><p>
ctdbd is the main ctdb daemon.
</p><p>
ctdbd provides a clustered version of the TDB database with automatic rebuild/recovery of the databases upon nodefailures.
</p><p>
ctdbd provides monitoring of all nodes in the cluster and automatically reconfigures the cluster and recovers upon node failures.
</p><p>
- ctdbd is the main component in clustered Samba that provides a high-awailability load-sharing CIFS server cluster.
- </p></div><div class="refsect1" lang="en"><a name="id24
81198"></a><h2>OPTIONS</h2><div class="variablelist"><dl><dt><span class="term">-? --help</span></dt><dd><p>
+ ctdbd is the main component in clustered Samba that provides a high-availability load-sharing CIFS server cluster.
+ </p></div><div class="refsect1" lang="en"><a name="id24
79679"></a><h2>OPTIONS</h2><div class="variablelist"><dl><dt><span class="term">-? --help</span></dt><dd><p>
Print some help text to the screen.
</p></dd><dt><span class="term">-d --debug=<DEBUGLEVEL></span></dt><dd><p>
This option sets the debuglevel on the ctdbd daemon which controls what will be written to the logfile. The default is 0 which will only log important events and errors. A larger number will provide additional logging.
to and also where to attach the single-public-ip when used.
</p><p>
This is only required when using public ip addresses and only when
- you dont specify the interface explicitely on in /etc/ctdb/public_addresses or when you are using --single-public-ip.
+ you dont specify the interface explicitly in /etc/ctdb/public_addresses or when you are using --single-public-ip.
</p><p>
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.
</p></dd><dt><span class="term">--reclock=<filename></span></dt><dd><p>
implemented in the future.
</p></dd><dt><span class="term">--usage</span></dt><dd><p>
Print useage information to the screen.
- </p></dd></dl></div></div><div class="refsect1" lang="en"><a name="id2528
782"></a><h2>Private vs Public addresses</h2><p>
+ </p></dd></dl></div></div><div class="refsect1" lang="en"><a name="id2528
846"></a><h2>Private vs Public addresses</h2><p>
When used for ip takeover in a HA environment, each node in a ctdb
cluster has multiple ip addresses assigned to it. One private and one or more public.
- </p><div class="refsect2" lang="en"><a name="id2528
792"></a><h3>Private address</h3><p>
+ </p><div class="refsect2" lang="en"><a name="id2528
856"></a><h3>Private address</h3><p>
This is the physical ip address of the node which is configured in
linux and attached to a physical interface. This address uniquely
identifies a physical node in the cluster and is the ip addresses
10.1.1.2
10.1.1.3
10.1.1.4
- </pre></div><div class="refsect2" lang="en"><a name="id2528
840"></a><h3>Public address</h3><p>
+ </pre></div><div class="refsect2" lang="en"><a name="id2528
904"></a><h3>Public address</h3><p>
A public address on the other hand is not attached to an interface.
This address is managed by ctdbd itself and is attached/detached to
a physical node at runtime.
unavailable. 10.1.1.1 can not be failed over to node 2 or node 3 since
these nodes do not have this ip address listed in their public
addresses file.
- </p></div></div><div class="refsect1" lang="en"><a name="id25289
22"></a><h2>Node status</h2><p>
+ </p></div></div><div class="refsect1" lang="en"><a name="id25289
86"></a><h2>Node status</h2><p>
The current status of each node in the cluster can be viewed by the
'ctdb status' command.
</p><p>
- There are five possible for a node.
+ There are five possible states for a node.
</p><p>
OK - This node is fully functional.
</p><p>
investigated and require an administrative action to rectify. This node
does not perticipate in the CTDB cluster but can still be communicated
with. I.e. ctdb commands can be sent to it.
- </p></div><div class="refsect1" lang="en"><a name="id252
8984"></a><h2>PUBLIC TUNABLES</h2><p>
+ </p></div><div class="refsect1" lang="en"><a name="id252
9049"></a><h2>PUBLIC TUNABLES</h2><p>
These are the public tuneables that can be used to control how ctdb behaves.
- </p><div class="refsect2" lang="en"><a name="id252
8995"></a><h3>KeepaliveInterval</h3><p>Default: 1</p><p>
+ </p><div class="refsect2" lang="en"><a name="id252
9059"></a><h3>KeepaliveInterval</h3><p>Default: 1</p><p>
How often should the nodes send keepalives to eachother.
- </p></div><div class="refsect2" lang="en"><a name="id25290
09"></a><h3>KeepaliveLimit</h3><p>Default: 5</p><p>
+ </p></div><div class="refsect2" lang="en"><a name="id25290
73"></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></div><div class="refsect2" lang="en"><a name="id25290
23"></a><h3>MonitorInterval</h3><p>Default: 15</p><p>
+ </p></div><div class="refsect2" lang="en"><a name="id25290
88"></a><h3>MonitorInterval</h3><p>Default: 15</p><p>
How often should ctdb run the event scripts to check for a nodes health.
- </p></div><div class="refsect2" lang="en"><a name="id2529
037"></a><h3>TickleUpdateInterval</h3><p>Default: 20</p><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2529
101"></a><h3>TickleUpdateInterval</h3><p>Default: 20</p><p>
How often will ctdb record and store the "tickle" information used to
kickstart stalled tcp connections after a recovery.
- </p></div><div class="refsect2" lang="en"><a name="id2529
052"></a><h3>EventScriptTimeout</h3><p>Default: 20</p><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2529
116"></a><h3>EventScriptTimeout</h3><p>Default: 20</p><p>
How long should ctdb let an event script run before aborting it and
marking the node unhealthy.
- </p></div><div class="refsect2" lang="en"><a name="id2529
066"></a><h3>RecoveryBanPeriod</h3><p>Default: 300</p><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2529
130"></a><h3>RecoveryBanPeriod</h3><p>Default: 300</p><p>
If a node becomes banned causing repetitive recovery failures. The node will
eventually become banned from the cluster.
This controls how long the culprit node will be banned from the cluster
before it is allowed to try to join the cluster again.
Dont set to small. A node gets banned for a reason and it is usually due
to real problems with the node.
- </p></div><div class="refsect2" lang="en"><a name="id2529
085"></a><h3>DatabaseHashSize</h3><p>Default: 100000</p><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2529
149"></a><h3>DatabaseHashSize</h3><p>Default: 100000</p><p>
Size of the hash chains for the local store of the tdbs that ctdb manages.
- </p></div><div class="refsect2" lang="en"><a name="id2529
099"></a><h3>RerecoveryTimeout</h3><p>Default: 10</p><p>
+ </p></div><div class="refsect2" lang="en"><a name="id2529
163"></a><h3>RerecoveryTimeout</h3><p>Default: 10</p><p>
Once a recovery has completed, no additional recoveries are permitted until this timeout has expired.
- </p></div><div class="refsect2" lang="en"><a name="id25291
14"></a><h3>EnableBans</h3><p>Default: 1</p><p>
+ </p></div><div class="refsect2" lang="en"><a name="id25291
78"></a><h3>EnableBans</h3><p>Default: 1</p><p>
When set to 0, this disables BANNING completely in the cluster and thus nodes can not get banned, even it they break. Dont set to 0.
- </p></div><div class="refsect2" lang="en"><a name="id25291
28"></a><h3>DeterministicIPs</h3><p>Default: 1</p><p>
- When enabled, this tunable makes ctdb try to keep public ip addresses locked to specific nodes as far as possible. This makes it easier for debugging since you can know that as long as all nodes are healthy public ip X will always be hosted by node Y.
+ </p></div><div class="refsect2" lang="en"><a name="id25291
93"></a><h3>DeterministicIPs</h3><p>Default: 1</p><p>
+ When enabled, this tunable makes ctdb try to keep public IP addresses locked to specific nodes as far as possible. This makes it easier for debugging since you can know that as long as all nodes are healthy public IP X will always be hosted by node Y.
</p><p>
- The cost of using deterministic ip address assignment is that it disables part of the logic where ctdb tries to reduce the number of public ip assignment changes in the cluster. This tunable may increase the number of ip failover/failbacks that are performed on the cluster by a small margin.
- </p></div><div class="refsect2" lang="en"><a name="id2529
158"></a><h3>DisableWhenUnhealthy</h3><p>Default: 0</p><p>
+ The cost of using deterministic IP address assignment is that it disables part of the logic where ctdb tries to reduce the number of public IP assignment changes in the cluster. This tunable may increase the number of IP failover/failbacks that are performed on the cluster by a small margin.
+ </p></div><div class="refsect2" lang="en"><a name="id2529
222"></a><h3>DisableWhenUnhealthy</h3><p>Default: 0</p><p>
When set, As soon as a node becomes unhealthy, that node will also automatically become permanently DISABLED. Once a node is DISABLED, the only way to make it participate in the cluster again and host services is by manually enabling the node again using 'ctdb enable'.
</p><p>
This disables parts of the resilience and robustness of the cluster and should ONLY be used when the system administrator is actively monitoring the cluster, so that nodes can be enabled again.
- </p></div><div class="refsect2" lang="en"><a name="id2529
182"></a><h3>NoIPFailback</h3><p>Default: 0</p><p>
- When set to 1, ctdb will not perform failback of ip addresses when a node becomes healthy. Ctdb WILL perform failover of public ip addresses when a node becomes UNHEALTHY, but when the node becomes HEALTHY again, ctdb will not fail the addresses back.
+ </p></div><div class="refsect2" lang="en"><a name="id2529
246"></a><h3>NoIPFailback</h3><p>Default: 0</p><p>
+ When set to 1, ctdb will not perform failback of IP addresses when a node becomes healthy. Ctdb WILL perform failover of public IP addresses when a node becomes UNHEALTHY, but when the node becomes HEALTHY again, ctdb will not fail the addresses back.
</p><p>
Use with caution! Normally when a node becomes available to the cluster
-ctdb will try to reassign public ip addresses onto the new node as a way to distribute the workload evenly across the clusternode. Ctdb tries to make sure that all running nodes have approximately the same number of public addresses it hosts.
+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><div class="refsect1" lang="en"><a name="id25292
18"></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
+ 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><div class="refsect1" lang="en"><a name="id25292
82"></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.
the processing node back to the clients. For read-intensive i/o patterns you can acheive very high throughput rates in this mode.
</p><p>
Note: you can use LVS and public addresses at the same time.
- </p><div class="refsect2" lang="en"><a name="id2529
290"></a><h3>Configuration</h3><p>
+ </p><div class="refsect2" lang="en"><a name="id2529
354"></a><h3>Configuration</h3><p>
To activate LVS on a CTDB node you must specify CTDB_PUBLIC_INTERFACE and
CTDB_LVS_PUBLIC_ADDRESS in /etc/sysconfig/ctdb.
</p><p>
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.
- (we can not use the lvs ip address to initiate outgoing traffic)
+ (we can not use the lvs IP address to initiate outgoing traffic)
</p><p>
I.e. make sure that you can "ping" both the domain controller and also
all of the clients from the node BEFORE you enable LVS. Also make sure
that when you ping these hosts that the traffic is routed out through the
eth0 interface.
- </p></div><div class="refsect1" lang="en"><a name="id2529
338"></a><h2>REMOTE CLUSTER NODES</h2><p>
+ </p></div><div class="refsect1" lang="en"><a name="id2529
402"></a><h2>REMOTE CLUSTER NODES</h2><p>
It is possible to have a CTDB cluster that spans across a WAN link.
For example where you have a CTDB cluster in your datacentre but you also
want to have one additional CTDB node located at a remote branch site.
</p><p>
Verify with the command "ctdb getcapabilities" that that node no longer
has the recmaster or the lmaster capabilities.
- </p></div><div class="refsect1" lang="en"><a name="id2529
389"></a><h2>SEE ALSO</h2><p>
+ </p></div><div class="refsect1" lang="en"><a name="id2529
453"></a><h2>SEE ALSO</h2><p>
ctdb(1), onnode(1)
- <a href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
- </p></div><div class="refsect1" lang="en"><a name="id25294
02"></a><h2>COPYRIGHT/LICENSE</h2><div class="literallayout"><p><br>
+ <a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
+ </p></div><div class="refsect1" lang="en"><a name="id25294
66"></a><h2>COPYRIGHT/LICENSE</h2><div class="literallayout"><p><br>
Copyright (C) Andrew Tridgell 2007<br>
Copyright (C) Ronnie sahlberg 2007<br>
<br>
git.samba.org / sahlberg / ctdb.git / commitdiff