1 <?xml version="1.0" encoding="iso-8859-1"?>
3 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
4 "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
6 <refentry id="ctdb-tunables.7">
9 <refentrytitle>ctdb-tunables</refentrytitle>
10 <manvolnum>7</manvolnum>
11 <refmiscinfo class="source">ctdb</refmiscinfo>
12 <refmiscinfo class="manual">CTDB - clustered TDB database</refmiscinfo>
16 <refname>ctdb-tunables</refname>
17 <refpurpose>CTDB tunable configuration variables</refpurpose>
21 <title>DESCRIPTION</title>
24 CTDB's behaviour can be configured by setting run-time tunable
25 variables. This lists and describes all tunables. See the
26 <citerefentry><refentrytitle>ctdb</refentrytitle>
27 <manvolnum>1</manvolnum></citerefentry>
28 <command>listvars</command>, <command>setvar</command> and
29 <command>getvar</command> commands for more details.
33 Unless otherwise stated, tunables should be set to the same
34 value on all nodes. Setting tunables to different values across
35 nodes may produce unexpected results. Future releases may set
36 (some or most) tunables globally across the cluster but doing so
37 is currently a manual process.
41 Tunables can be set at startup from the
42 <filename>/usr/local/etc/ctdb/ctdb.tunables</filename>
46 <replaceable>TUNABLE</replaceable>=<replaceable>VALUE</replaceable>
53 <screen format="linespecific">
59 The available tunable variables are listed alphabetically below.
63 <title>AllowClientDBAttach</title>
64 <para>Default: 1</para>
66 When set to 0, clients are not allowed to attach to any databases.
67 This can be used to temporarily block any new processes from
68 attaching to and accessing the databases. This is mainly used
69 for detaching a volatile database using 'ctdb detach'.
74 <title>AllowMixedVersions</title>
75 <para>Default: 0</para>
77 CTDB will not allow incompatible versions to co-exist in
78 a cluster. If a version mismatch is found, then losing CTDB
79 will shutdown. To disable the incompatible version check,
80 set this tunable to 1.
83 For version checking, CTDB uses major and minor version.
84 For example, CTDB 4.6.1 and CTDB CTDB 4.6.2 are matching versions;
85 CTDB 4.5.x and CTDB 4.6.y do not match.
88 CTDB with version check support will lose to CTDB without
89 version check support. Between two different CTDB versions with
90 version check support, one running for less time will lose.
91 If the running time for both CTDB versions with version check
92 support is equal (to seconds), then the older version will lose.
93 The losing CTDB daemon will shutdown.
98 <title>AllowUnhealthyDBRead</title>
99 <para>Default: 0</para>
101 When set to 1, ctdb allows database traverses to read unhealthy
102 databases. By default, ctdb does not allow reading records from
108 <title>ControlTimeout</title>
109 <para>Default: 60</para>
111 This is the default setting for timeout for when sending a
112 control message to either the local or a remote ctdb daemon.
117 <title>DatabaseHashSize</title>
118 <para>Default: 100001</para>
120 Number of the hash chains for the local store of the tdbs that
126 <title>DatabaseMaxDead</title>
127 <para>Default: 5</para>
129 Maximum number of dead records per hash chain for the tdb databses
135 <title>DBRecordCountWarn</title>
136 <para>Default: 100000</para>
138 When set to non-zero, ctdb will log a warning during recovery if
139 a database has more than this many records. This will produce a
140 warning if a database grows uncontrollably with orphaned records.
145 <title>DBRecordSizeWarn</title>
146 <para>Default: 10000000</para>
148 When set to non-zero, ctdb will log a warning during recovery
149 if a single record is bigger than this size. This will produce
150 a warning if a database record grows uncontrollably.
155 <title>DBSizeWarn</title>
156 <para>Default: 1000000000</para>
158 When set to non-zero, ctdb will log a warning during recovery if
159 a database size is bigger than this. This will produce a warning
160 if a database grows uncontrollably.
165 <title>DeferredAttachTO</title>
166 <para>Default: 120</para>
168 When databases are frozen we do not allow clients to attach to
169 the databases. Instead of returning an error immediately to the
170 client, the attach request from the client is deferred until
171 the database becomes available again at which stage we respond
175 This timeout controls how long we will defer the request from the
176 client before timing it out and returning an error to the client.
181 <title>DisableIPFailover</title>
182 <para>Default: 0</para>
184 When set to non-zero, ctdb will not perform failover or
185 failback. Even if a node fails while holding public IPs, ctdb
186 will not recover the IPs or assign them to another node.
189 When this tunable is enabled, ctdb will no longer attempt
190 to recover the cluster by failing IP addresses over to other
191 nodes. This leads to a service outage until the administrator
192 has manually performed IP failover to replacement nodes using the
193 'ctdb moveip' command.
198 <title>ElectionTimeout</title>
199 <para>Default: 3</para>
201 The number of seconds to wait for the election of recovery
202 master to complete. If the election is not completed during this
203 interval, then that round of election fails and ctdb starts a
209 <title>EnableBans</title>
210 <para>Default: 1</para>
212 This parameter allows ctdb to ban a node if the node is misbehaving.
215 When set to 0, this disables banning completely in the cluster
216 and thus nodes can not get banned, even it they break. Don't
217 set to 0 unless you know what you are doing.
222 <title>EventScriptTimeout</title>
223 <para>Default: 30</para>
225 Maximum time in seconds to allow an event to run before timing
226 out. This is the total time for all enabled scripts that are
227 run for an event, not just a single event script.
230 Note that timeouts are ignored for some events ("takeip",
231 "releaseip", "startrecovery", "recovered") and converted to
232 success. The logic here is that the callers of these events
233 implement their own additional timeout.
238 <title>FetchCollapse</title>
239 <para>Default: 1</para>
241 This parameter is used to avoid multiple migration requests for
242 the same record from a single node. All the record requests for
243 the same record are queued up and processed when the record is
244 migrated to the current node.
247 When many clients across many nodes try to access the same record
248 at the same time this can lead to a fetch storm where the record
249 becomes very active and bounces between nodes very fast. This
250 leads to high CPU utilization of the ctdbd daemon, trying to
251 bounce that record around very fast, and poor performance.
252 This can improve performance and reduce CPU utilization for
258 <title>HopcountMakeSticky</title>
259 <para>Default: 50</para>
261 For database(s) marked STICKY (using 'ctdb setdbsticky'),
262 any record that is migrating so fast that hopcount
263 exceeds this limit is marked as STICKY record for
264 <varname>StickyDuration</varname> seconds. This means that
265 after each migration the sticky record will be kept on the node
266 <varname>StickyPindown</varname>milliseconds and prevented from
267 being migrated off the node.
270 This will improve performance for certain workloads, such as
271 locking.tdb if many clients are opening/closing the same file
277 <title>IPAllocAlgorithm</title>
278 <para>Default: 2</para>
280 Selects the algorithm that CTDB should use when doing public
281 IP address allocation. Meaningful values are:
288 Deterministic IP address allocation.
291 This is a simple and fast option. However, it can cause
292 unnecessary address movement during fail-over because
293 each address has a "home" node. Works badly when some
294 nodes do not have any addresses defined. Should be used
295 with care when addresses are defined across multiple
304 Non-deterministic IP address allocation.
307 This is a relatively fast option that attempts to do a
308 minimise unnecessary address movements. Addresses do
309 not have a "home" node. Rebalancing is limited but it
310 usually adequate. Works badly when addresses are
311 defined across multiple networks.
319 LCP2 IP address allocation.
322 Uses a heuristic to assign addresses defined across
323 multiple networks, usually balancing addresses on each
324 network evenly across nodes. Addresses do not have a
325 "home" node. Minimises unnecessary address movements.
326 The algorithm is complex, so is slower than other
327 choices for a large number of addresses. However, it
328 can calculate an optimal assignment of 900 addresses in
329 under 10 seconds on modern hardware.
335 If the specified value is not one of these then the default
341 <title>KeepaliveInterval</title>
342 <para>Default: 5</para>
344 How often in seconds should the nodes send keep-alive packets to
350 <title>KeepaliveLimit</title>
351 <para>Default: 5</para>
353 After how many keepalive intervals without any traffic should
354 a node wait until marking the peer as DISCONNECTED.
357 If a node has hung, it can take
358 <varname>KeepaliveInterval</varname> *
359 (<varname>KeepaliveLimit</varname> + 1) seconds before
360 ctdb determines that the node is DISCONNECTED and performs
361 a recovery. This limit should not be set too high to enable
362 early detection and avoid any application timeouts (e.g. SMB1)
363 to kick in before the fail over is completed.
368 <title>LockProcessesPerDB</title>
369 <para>Default: 200</para>
371 This is the maximum number of lock helper processes ctdb will
372 create for obtaining record locks. When ctdb cannot get a record
373 lock without blocking, it creates a helper process that waits
374 for the lock to be obtained.
379 <title>LogLatencyMs</title>
380 <para>Default: 0</para>
382 When set to non-zero, ctdb will log if certains operations
383 take longer than this value, in milliseconds, to complete.
384 These operations include "process a record request from client",
385 "take a record or database lock", "update a persistent database
386 record" and "vaccum a database".
391 <title>MaxQueueDropMsg</title>
392 <para>Default: 1000000</para>
394 This is the maximum number of messages to be queued up for
395 a client before ctdb will treat the client as hung and will
396 terminate the client connection.
401 <title>MonitorInterval</title>
402 <para>Default: 15</para>
404 How often should ctdb run the 'monitor' event in seconds to check
410 <title>MonitorTimeoutCount</title>
411 <para>Default: 20</para>
413 How many 'monitor' events in a row need to timeout before a node
414 is flagged as UNHEALTHY. This setting is useful if scripts can
415 not be written so that they do not hang for benign reasons.
420 <title>NoIPFailback</title>
421 <para>Default: 0</para>
423 When set to 1, ctdb will not perform failback of IP addresses
424 when a node becomes healthy. When a node becomes UNHEALTHY,
425 ctdb WILL perform failover of public IP addresses, but when the
426 node becomes HEALTHY again, ctdb will not fail the addresses back.
429 Use with caution! Normally when a node becomes available to the
430 cluster ctdb will try to reassign public IP addresses onto the
431 new node as a way to distribute the workload evenly across the
432 clusternode. Ctdb tries to make sure that all running nodes have
433 approximately the same number of public addresses it hosts.
436 When you enable this tunable, ctdb will no longer attempt to
437 rebalance the cluster by failing IP addresses back to the new
438 nodes. An unbalanced cluster will therefore remain unbalanced
439 until there is manual intervention from the administrator. When
440 this parameter is set, you can manually fail public IP addresses
441 over to the new node(s) using the 'ctdb moveip' command.
446 <title>NoIPTakeover</title>
447 <para>Default: 0</para>
449 When set to 1, ctdb will not allow IP addresses to be failed
450 over to other nodes. Any IP addresses already hosted on
451 healthy nodes will remain. Any IP addresses hosted on
452 unhealthy nodes will be released by unhealthy nodes and will
458 <title>PullDBPreallocation</title>
459 <para>Default: 10*1024*1024</para>
461 This is the size of a record buffer to pre-allocate for sending
462 reply to PULLDB control. Usually record buffer starts with size
463 of the first record and gets reallocated every time a new record
464 is added to the record buffer. For a large number of records,
465 this can be very inefficient to grow the record buffer one record
471 <title>QueueBufferSize</title>
472 <para>Default: 1024</para>
474 This is the maximum amount of data (in bytes) ctdb will read
475 from a socket at a time.
478 For a busy setup, if ctdb is not able to process the TCP sockets
479 fast enough (large amount of data in Recv-Q for tcp sockets),
480 then this tunable value should be increased. However, large
481 values can keep ctdb busy processing packets and prevent ctdb
482 from handling other events.
487 <title>RecBufferSizeLimit</title>
488 <para>Default: 1000000</para>
490 This is the limit on the size of the record buffer to be sent
491 in various controls. This limit is used by new controls used
492 for recovery and controls used in vacuuming.
497 <title>RecdFailCount</title>
498 <para>Default: 10</para>
500 If the recovery daemon has failed to ping the main dameon for
501 this many consecutive intervals, the main daemon will consider
502 the recovery daemon as hung and will try to restart it to recover.
507 <title>RecdPingTimeout</title>
508 <para>Default: 60</para>
510 If the main dameon has not heard a "ping" from the recovery dameon
511 for this many seconds, the main dameon will log a message that
512 the recovery daemon is potentially hung. This also increments a
513 counter which is checked against <varname>RecdFailCount</varname>
514 for detection of hung recovery daemon.
519 <title>RecLockLatencyMs</title>
520 <para>Default: 1000</para>
522 When using a reclock file for split brain prevention, if set
523 to non-zero this tunable will make the recovery dameon log a
524 message if the fcntl() call to lock/testlock the recovery file
525 takes longer than this number of milliseconds.
530 <title>RecoverInterval</title>
531 <para>Default: 1</para>
533 How frequently in seconds should the recovery daemon perform the
534 consistency checks to determine if it should perform a recovery.
539 <title>RecoverTimeout</title>
540 <para>Default: 120</para>
542 This is the default setting for timeouts for controls when sent
543 from the recovery daemon. We allow longer control timeouts from
544 the recovery daemon than from normal use since the recovery
545 dameon often use controls that can take a lot longer than normal
551 <title>RecoveryBanPeriod</title>
552 <para>Default: 300</para>
554 The duration in seconds for which a node is banned if the node
555 fails during recovery. After this time has elapsed the node will
556 automatically get unbanned and will attempt to rejoin the cluster.
559 A node usually gets banned due to real problems with the node.
560 Don't set this value too small. Otherwise, a problematic node
561 will try to re-join cluster too soon causing unnecessary recoveries.
566 <title>RecoveryDropAllIPs</title>
567 <para>Default: 120</para>
569 If a node is stuck in recovery, or stopped, or banned, for this
570 many seconds, then ctdb will release all public addresses on
576 <title>RecoveryGracePeriod</title>
577 <para>Default: 120</para>
579 During recoveries, if a node has not caused recovery failures
580 during the last grace period in seconds, any records of
581 transgressions that the node has caused recovery failures will be
582 forgiven. This resets the ban-counter back to zero for that node.
587 <title>RepackLimit</title>
588 <para>Default: 10000</para>
590 During vacuuming, if the number of freelist records are more than
591 <varname>RepackLimit</varname>, then the database is repacked
592 to get rid of the freelist records to avoid fragmentation.
595 Databases are repacked only if both <varname>RepackLimit</varname>
596 and <varname>VacuumLimit</varname> are exceeded.
601 <title>RerecoveryTimeout</title>
602 <para>Default: 10</para>
604 Once a recovery has completed, no additional recoveries are
605 permitted until this timeout in seconds has expired.
610 <title>SeqnumInterval</title>
611 <para>Default: 1000</para>
613 Some databases have seqnum tracking enabled, so that samba will
614 be able to detect asynchronously when there has been updates
615 to the database. Every time a database is updated its sequence
619 This tunable is used to specify in milliseconds how frequently
620 ctdb will send out updates to remote nodes to inform them that
621 the sequence number is increased.
626 <title>StatHistoryInterval</title>
627 <para>Default: 1</para>
629 Granularity of the statistics collected in the statistics
630 history. This is reported by 'ctdb stats' command.
635 <title>StickyDuration</title>
636 <para>Default: 600</para>
638 Once a record has been marked STICKY, this is the duration in
639 seconds, the record will be flagged as a STICKY record.
644 <title>StickyPindown</title>
645 <para>Default: 200</para>
647 Once a STICKY record has been migrated onto a node, it will be
648 pinned down on that node for this number of milliseconds. Any
649 request from other nodes to migrate the record off the node will
655 <title>TakeoverTimeout</title>
656 <para>Default: 9</para>
658 This is the duration in seconds in which ctdb tries to complete IP
664 <title>TDBMutexEnabled</title>
665 <para>Default: 1</para>
667 This parameter enables TDB_MUTEX_LOCKING feature on volatile
668 databases if the robust mutexes are supported. This optimizes the
669 record locking using robust mutexes and is much more efficient
670 that using posix locks.
675 <title>TickleUpdateInterval</title>
676 <para>Default: 20</para>
678 Every <varname>TickleUpdateInterval</varname> seconds, ctdb
679 synchronizes the client connection information across nodes.
684 <title>TraverseTimeout</title>
685 <para>Default: 20</para>
687 This is the duration in seconds for which a database traverse
688 is allowed to run. If the traverse does not complete during
689 this interval, ctdb will abort the traverse.
694 <title>VacuumFastPathCount</title>
695 <para>Default: 60</para>
697 During a vacuuming run, ctdb usually processes only the records
698 marked for deletion also called the fast path vacuuming. After
699 finishing <varname>VacuumFastPathCount</varname> number of fast
700 path vacuuming runs, ctdb will trigger a scan of complete database
701 for any empty records that need to be deleted.
706 <title>VacuumInterval</title>
707 <para>Default: 10</para>
709 Periodic interval in seconds when vacuuming is triggered for
715 <title>VacuumLimit</title>
716 <para>Default: 5000</para>
718 During vacuuming, if the number of deleted records are more than
719 <varname>VacuumLimit</varname>, then databases are repacked to
723 Databases are repacked only if both <varname>RepackLimit</varname>
724 and <varname>VacuumLimit</varname> are exceeded.
729 <title>VacuumMaxRunTime</title>
730 <para>Default: 120</para>
732 The maximum time in seconds for which the vacuuming process is
733 allowed to run. If vacuuming process takes longer than this
734 value, then the vacuuming process is terminated.
739 <title>VerboseMemoryNames</title>
740 <para>Default: 0</para>
742 When set to non-zero, ctdb assigns verbose names for some of
743 the talloc allocated memory objects. These names are visible
744 in the talloc memory report generated by 'ctdb dumpmemory'.
751 <title>FILES></title>
754 <member><filename>/usr/local/etc/ctdb/ctdb.tunables</filename></member>
759 <title>SEE ALSO</title>
761 <citerefentry><refentrytitle>ctdb</refentrytitle>
762 <manvolnum>1</manvolnum></citerefentry>,
764 <citerefentry><refentrytitle>ctdbd</refentrytitle>
765 <manvolnum>1</manvolnum></citerefentry>,
767 <citerefentry><refentrytitle>ctdb.conf</refentrytitle>
768 <manvolnum>5</manvolnum></citerefentry>,
770 <citerefentry><refentrytitle>ctdb</refentrytitle>
771 <manvolnum>7</manvolnum></citerefentry>,
773 <ulink url="http://ctdb.samba.org/"/>
780 This documentation was written by
789 <holder>Andrew Tridgell</holder>
790 <holder>Ronnie Sahlberg</holder>
794 This program is free software; you can redistribute it and/or
795 modify it under the terms of the GNU General Public License as
796 published by the Free Software Foundation; either version 3 of
797 the License, or (at your option) any later version.
800 This program is distributed in the hope that it will be
801 useful, but WITHOUT ANY WARRANTY; without even the implied
802 warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
803 PURPOSE. See the GNU General Public License for more details.
806 You should have received a copy of the GNU General Public
807 License along with this program; if not, see
808 <ulink url="http://www.gnu.org/licenses"/>.