| blob | 700709eb86fdcb47ed0ca2311ab9ef29111f62b4 |
1 <?xml version="1.0" encoding="iso-8859-1"?>
2 <!DOCTYPE refentry
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">
8 <refmeta>
9 <refentrytitle>ctdb-tunables</refentrytitle>
10 <manvolnum>7</manvolnum>
11 <refmiscinfo class="source">ctdb</refmiscinfo>
12 <refmiscinfo class="manual">CTDB - clustered TDB database</refmiscinfo>
13 </refmeta>
15 <refnamediv>
16 <refname>ctdb-tunables</refname>
17 <refpurpose>CTDB tunable configuration variables</refpurpose>
18 </refnamediv>
20 <refsect1>
21 <title>DESCRIPTION</title>
23 <para>
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.
30 </para>
32 <para>
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.
38 </para>
40 <para>
41 Tunables can be set at startup from the
42 <filename>/usr/local/etc/ctdb/ctdb.tunables</filename>
43 configuration file.
45 <literallayout>
46 <replaceable>TUNABLE</replaceable>=<replaceable>VALUE</replaceable>
47 </literallayout>
49 Comment lines beginning with '#' are permitted. Whitespace may
50 be used for formatting/alignment. VALUE must be a non-negative
51 integer and must be the last thing on a line (i.e. no trailing
52 garbage, trailing comments are not permitted).
53 </para>
55 <para>
56 For example:
58 <screen format="linespecific">
59 MonitorInterval=20
60 </screen>
61 </para>
63 <para>
64 The available tunable variables are listed alphabetically below.
65 </para>
67 <refsect2>
68 <title>AllowClientDBAttach</title>
69 <para>Default: 1</para>
70 <para>
71 When set to 0, clients are not allowed to attach to any databases.
72 This can be used to temporarily block any new processes from
73 attaching to and accessing the databases. This is mainly used
74 for detaching a volatile database using 'ctdb detach'.
75 </para>
76 </refsect2>
78 <refsect2>
79 <title>AllowMixedVersions</title>
80 <para>Default: 0</para>
81 <para>
82 CTDB will not allow incompatible versions to co-exist in
83 a cluster. If a version mismatch is found, then losing CTDB
84 will shutdown. To disable the incompatible version check,
85 set this tunable to 1.
86 </para>
87 <para>
88 For version checking, CTDB uses major and minor version.
89 For example, CTDB 4.6.1 and CTDB 4.6.2 are matching versions;
90 CTDB 4.5.x and CTDB 4.6.y do not match.
91 </para>
92 <para>
93 CTDB with version check support will lose to CTDB without
94 version check support. Between two different CTDB versions with
95 version check support, one running for less time will lose.
96 If the running time for both CTDB versions with version check
97 support is equal (to seconds), then the older version will lose.
98 The losing CTDB daemon will shutdown.
99 </para>
100 </refsect2>
102 <refsect2>
103 <title>AllowUnhealthyDBRead</title>
104 <para>Default: 0</para>
105 <para>
106 When set to 1, ctdb allows database traverses to read unhealthy
107 databases. By default, ctdb does not allow reading records from
108 unhealthy databases.
109 </para>
110 </refsect2>
112 <refsect2>
113 <title>ControlTimeout</title>
114 <para>Default: 60</para>
115 <para>
116 This is the default setting for timeout for when sending a
117 control message to either the local or a remote ctdb daemon.
118 </para>
119 </refsect2>
121 <refsect2>
122 <title>DatabaseHashSize</title>
123 <para>Default: 100001</para>
124 <para>
125 Number of the hash chains for the local store of the tdbs that
126 ctdb manages.
127 </para>
128 </refsect2>
130 <refsect2>
131 <title>DatabaseMaxDead</title>
132 <para>Default: 5</para>
133 <para>
134 Maximum number of dead records per hash chain for the tdb databses
135 managed by ctdb.
136 </para>
137 </refsect2>
139 <refsect2>
140 <title>DBRecordCountWarn</title>
141 <para>Default: 100000</para>
142 <para>
143 When set to non-zero, ctdb will log a warning during recovery if
144 a database has more than this many records. This will produce a
145 warning if a database grows uncontrollably with orphaned records.
146 </para>
147 </refsect2>
149 <refsect2>
150 <title>DBRecordSizeWarn</title>
151 <para>Default: 10000000</para>
152 <para>
153 When set to non-zero, ctdb will log a warning during recovery
154 if a single record is bigger than this size. This will produce
155 a warning if a database record grows uncontrollably.
156 </para>
157 </refsect2>
159 <refsect2>
160 <title>DBSizeWarn</title>
161 <para>Default: 1000000000</para>
162 <para>
163 When set to non-zero, ctdb will log a warning during recovery if
164 a database size is bigger than this. This will produce a warning
165 if a database grows uncontrollably.
166 </para>
167 </refsect2>
169 <refsect2>
170 <title>DeferredAttachTO</title>
171 <para>Default: 120</para>
172 <para>
173 When databases are frozen we do not allow clients to attach to
174 the databases. Instead of returning an error immediately to the
175 client, the attach request from the client is deferred until
176 the database becomes available again at which stage we respond
177 to the client.
178 </para>
179 <para>
180 This timeout controls how long we will defer the request from the
181 client before timing it out and returning an error to the client.
182 </para>
183 </refsect2>
185 <refsect2>
186 <title>ElectionTimeout</title>
187 <para>Default: 3</para>
188 <para>
189 The number of seconds to wait for the election of recovery
190 master to complete. If the election is not completed during this
191 interval, then that round of election fails and ctdb starts a
192 new election.
193 </para>
194 </refsect2>
196 <refsect2>
197 <title>EnableBans</title>
198 <para>Default: 1</para>
199 <para>
200 This parameter allows ctdb to ban a node if the node is misbehaving.
201 </para>
202 <para>
203 When set to 0, this disables banning completely in the cluster
204 and thus nodes can not get banned, even it they break. Don't
205 set to 0 unless you know what you are doing.
206 </para>
207 </refsect2>
209 <refsect2>
210 <title>EventScriptTimeout</title>
211 <para>Default: 30</para>
212 <para>
213 Maximum time in seconds to allow an event to run before timing
214 out. This is the total time for all enabled scripts that are
215 run for an event, not just a single event script.
216 </para>
217 <para>
218 Note that timeouts are ignored for some events ("takeip",
219 "releaseip", "startrecovery", "recovered") and converted to
220 success. The logic here is that the callers of these events
221 implement their own additional timeout.
222 </para>
223 </refsect2>
225 <refsect2>
226 <title>FetchCollapse</title>
227 <para>Default: 1</para>
228 <para>
229 This parameter is used to avoid multiple migration requests for
230 the same record from a single node. All the record requests for
231 the same record are queued up and processed when the record is
232 migrated to the current node.
233 </para>
234 <para>
235 When many clients across many nodes try to access the same record
236 at the same time this can lead to a fetch storm where the record
237 becomes very active and bounces between nodes very fast. This
238 leads to high CPU utilization of the ctdbd daemon, trying to
239 bounce that record around very fast, and poor performance.
240 This can improve performance and reduce CPU utilization for
241 certain workloads.
242 </para>
243 </refsect2>
245 <refsect2>
246 <title>HopcountMakeSticky</title>
247 <para>Default: 50</para>
248 <para>
249 For database(s) marked STICKY (using 'ctdb setdbsticky'),
250 any record that is migrating so fast that hopcount
251 exceeds this limit is marked as STICKY record for
252 <varname>StickyDuration</varname> seconds. This means that
253 after each migration the sticky record will be kept on the node
254 <varname>StickyPindown</varname>milliseconds and prevented from
255 being migrated off the node.
256 </para>
257 <para>
258 This will improve performance for certain workloads, such as
259 locking.tdb if many clients are opening/closing the same file
260 concurrently.
261 </para>
262 </refsect2>
264 <refsect2>
265 <title>IPAllocAlgorithm</title>
266 <para>Default: 2</para>
267 <para>
268 Selects the algorithm that CTDB should use when doing public
269 IP address allocation. Meaningful values are:
270 </para>
271 <variablelist>
272 <varlistentry>
273 <term>0</term>
274 <listitem>
275 <para>
276 Deterministic IP address allocation.
277 </para>
278 <para>
279 This is a simple and fast option. However, it can cause
280 unnecessary address movement during fail-over because
281 each address has a "home" node. Works badly when some
282 nodes do not have any addresses defined. Should be used
283 with care when addresses are defined across multiple
284 networks.
285 </para>
286 </listitem>
287 </varlistentry>
288 <varlistentry>
289 <term>1</term>
290 <listitem>
291 <para>
292 Non-deterministic IP address allocation.
293 </para>
294 <para>
295 This is a relatively fast option that attempts to do a
296 minimise unnecessary address movements. Addresses do
297 not have a "home" node. Rebalancing is limited but it
298 usually adequate. Works badly when addresses are
299 defined across multiple networks.
300 </para>
301 </listitem>
302 </varlistentry>
303 <varlistentry>
304 <term>2</term>
305 <listitem>
306 <para>
307 LCP2 IP address allocation.
308 </para>
309 <para>
310 Uses a heuristic to assign addresses defined across
311 multiple networks, usually balancing addresses on each
312 network evenly across nodes. Addresses do not have a
313 "home" node. Minimises unnecessary address movements.
314 The algorithm is complex, so is slower than other
315 choices for a large number of addresses. However, it
316 can calculate an optimal assignment of 900 addresses in
317 under 10 seconds on modern hardware.
318 </para>
319 </listitem>
320 </varlistentry>
321 </variablelist>
322 <para>
323 If the specified value is not one of these then the default
324 will be used.
325 </para>
326 </refsect2>
328 <refsect2>
329 <title>KeepaliveInterval</title>
330 <para>Default: 5</para>
331 <para>
332 How often in seconds should the nodes send keep-alive packets to
333 each other.
334 </para>
335 </refsect2>
337 <refsect2>
338 <title>KeepaliveLimit</title>
339 <para>Default: 5</para>
340 <para>
341 After how many keepalive intervals without any traffic should
342 a node wait until marking the peer as DISCONNECTED.
343 </para>
344 <para>
345 If a node has hung, it can take
346 <varname>KeepaliveInterval</varname> *
347 (<varname>KeepaliveLimit</varname> + 1) seconds before
348 ctdb determines that the node is DISCONNECTED and performs
349 a recovery. This limit should not be set too high to enable
350 early detection and avoid any application timeouts (e.g. SMB1)
351 to kick in before the fail over is completed.
352 </para>
353 </refsect2>
355 <refsect2>
356 <title>LockProcessesPerDB</title>
357 <para>Default: 200</para>
358 <para>
359 This is the maximum number of lock helper processes ctdb will
360 create for obtaining record locks. When ctdb cannot get a record
361 lock without blocking, it creates a helper process that waits
362 for the lock to be obtained.
363 </para>
364 </refsect2>
366 <refsect2>
367 <title>LogLatencyMs</title>
368 <para>Default: 0</para>
369 <para>
370 When set to non-zero, ctdb will log if certains operations
371 take longer than this value, in milliseconds, to complete.
372 These operations include "process a record request from client",
373 "take a record or database lock", "update a persistent database
374 record" and "vacuum a database".
375 </para>
376 </refsect2>
378 <refsect2>
379 <title>MaxQueueDropMsg</title>
380 <para>Default: 1000000</para>
381 <para>
382 This is the maximum number of messages to be queued up for
383 a client before ctdb will treat the client as hung and will
384 terminate the client connection.
385 </para>
386 </refsect2>
388 <refsect2>
389 <title>MonitorInterval</title>
390 <para>Default: 15</para>
391 <para>
392 How often should ctdb run the 'monitor' event in seconds to check
393 for a node's health.
394 </para>
395 </refsect2>
397 <refsect2>
398 <title>MonitorTimeoutCount</title>
399 <para>Default: 20</para>
400 <para>
401 How many 'monitor' events in a row need to timeout before a node
402 is flagged as UNHEALTHY. This setting is useful if scripts can
403 not be written so that they do not hang for benign reasons.
404 </para>
405 </refsect2>
407 <refsect2>
408 <title>NoIPFailback</title>
409 <para>Default: 0</para>
410 <para>
411 When set to 1, ctdb will not perform failback of IP addresses
412 when a node becomes healthy. When a node becomes UNHEALTHY,
413 ctdb WILL perform failover of public IP addresses, but when the
414 node becomes HEALTHY again, ctdb will not fail the addresses back.
415 </para>
416 <para>
417 Use with caution! Normally when a node becomes available to the
418 cluster ctdb will try to reassign public IP addresses onto the
419 new node as a way to distribute the workload evenly across the
420 clusternode. Ctdb tries to make sure that all running nodes have
421 approximately the same number of public addresses it hosts.
422 </para>
423 <para>
424 When you enable this tunable, ctdb will no longer attempt to
425 rebalance the cluster by failing IP addresses back to the new
426 nodes. An unbalanced cluster will therefore remain unbalanced
427 until there is manual intervention from the administrator. When
428 this parameter is set, you can manually fail public IP addresses
429 over to the new node(s) using the 'ctdb moveip' command.
430 </para>
431 </refsect2>
433 <refsect2>
434 <title>NoIPTakeover</title>
435 <para>Default: 0</para>
436 <para>
437 When set to 1, ctdb will not allow IP addresses to be failed
438 over to other nodes. Any IP addresses already hosted on
439 healthy nodes will remain. Any IP addresses hosted on
440 unhealthy nodes will be released by unhealthy nodes and will
441 become un-hosted.
442 </para>
443 </refsect2>
445 <refsect2>
446 <title>PullDBPreallocation</title>
447 <para>Default: 10*1024*1024</para>
448 <para>
449 This is the size of a record buffer to pre-allocate for sending
450 reply to PULLDB control. Usually record buffer starts with size
451 of the first record and gets reallocated every time a new record
452 is added to the record buffer. For a large number of records,
453 this can be very inefficient to grow the record buffer one record
454 at a time.
455 </para>
456 </refsect2>
458 <refsect2>
459 <title>QueueBufferSize</title>
460 <para>Default: 1024</para>
461 <para>
462 This is the maximum amount of data (in bytes) ctdb will read
463 from a socket at a time.
464 </para>
465 <para>
466 For a busy setup, if ctdb is not able to process the TCP sockets
467 fast enough (large amount of data in Recv-Q for tcp sockets),
468 then this tunable value should be increased. However, large
469 values can keep ctdb busy processing packets and prevent ctdb
470 from handling other events.
471 </para>
472 </refsect2>
474 <refsect2>
475 <title>RecBufferSizeLimit</title>
476 <para>Default: 1000000</para>
477 <para>
478 This is the limit on the size of the record buffer to be sent
479 in various controls. This limit is used by new controls used
480 for recovery and controls used in vacuuming.
481 </para>
482 </refsect2>
484 <refsect2>
485 <title>RecdFailCount</title>
486 <para>Default: 10</para>
487 <para>
488 If the recovery daemon has failed to ping the main daemon for
489 this many consecutive intervals, the main daemon will consider
490 the recovery daemon as hung and will try to restart it to recover.
491 </para>
492 </refsect2>
494 <refsect2>
495 <title>RecdPingTimeout</title>
496 <para>Default: 60</para>
497 <para>
498 If the main daemon has not heard a "ping" from the recovery daemon
499 for this many seconds, the main daemon will log a message that
500 the recovery daemon is potentially hung. This also increments a
501 counter which is checked against <varname>RecdFailCount</varname>
502 for detection of hung recovery daemon.
503 </para>
504 </refsect2>
506 <refsect2>
507 <title>RecLockLatencyMs</title>
508 <para>Default: 1000</para>
509 <para>
510 When using a reclock file for split brain prevention, if set
511 to non-zero this tunable will make the recovery daemon log a
512 message if the fcntl() call to lock/testlock the recovery file
513 takes longer than this number of milliseconds.
514 </para>
515 </refsect2>
517 <refsect2>
518 <title>RecoverInterval</title>
519 <para>Default: 1</para>
520 <para>
521 How frequently in seconds should the recovery daemon perform the
522 consistency checks to determine if it should perform a recovery.
523 </para>
524 </refsect2>
526 <refsect2>
527 <title>RecoverTimeout</title>
528 <para>Default: 120</para>
529 <para>
530 This is the default setting for timeouts for controls when sent
531 from the recovery daemon. We allow longer control timeouts from
532 the recovery daemon than from normal use since the recovery
533 daemon often use controls that can take a lot longer than normal
534 controls.
535 </para>
536 </refsect2>
538 <refsect2>
539 <title>RecoveryBanPeriod</title>
540 <para>Default: 300</para>
541 <para>
542 The duration in seconds for which a node is banned if the node
543 fails during recovery. After this time has elapsed the node will
544 automatically get unbanned and will attempt to rejoin the cluster.
545 </para>
546 <para>
547 A node usually gets banned due to real problems with the node.
548 Don't set this value too small. Otherwise, a problematic node
549 will try to re-join cluster too soon causing unnecessary recoveries.
550 </para>
551 </refsect2>
553 <refsect2>
554 <title>RecoveryDropAllIPs</title>
555 <para>Default: 120</para>
556 <para>
557 If a node is stuck in recovery, or stopped, or banned, for this
558 many seconds, then ctdb will release all public addresses on
559 that node.
560 </para>
561 </refsect2>
563 <refsect2>
564 <title>RecoveryGracePeriod</title>
565 <para>Default: 120</para>
566 <para>
567 During recoveries, if a node has not caused recovery failures
568 during the last grace period in seconds, any records of
569 transgressions that the node has caused recovery failures will be
570 forgiven. This resets the ban-counter back to zero for that node.
571 </para>
572 </refsect2>
574 <refsect2>
575 <title>RepackLimit</title>
576 <para>Default: 10000</para>
577 <para>
578 During vacuuming, if the number of freelist records are more than
579 <varname>RepackLimit</varname>, then the database is repacked
580 to get rid of the freelist records to avoid fragmentation.
581 </para>
582 </refsect2>
584 <refsect2>
585 <title>RerecoveryTimeout</title>
586 <para>Default: 10</para>
587 <para>
588 Once a recovery has completed, no additional recoveries are
589 permitted until this timeout in seconds has expired.
590 </para>
591 </refsect2>
593 <refsect2>
594 <title>SeqnumInterval</title>
595 <para>Default: 1000</para>
596 <para>
597 Some databases have seqnum tracking enabled, so that samba will
598 be able to detect asynchronously when there has been updates
599 to the database. Every time a database is updated its sequence
600 number is increased.
601 </para>
602 <para>
603 This tunable is used to specify in milliseconds how frequently
604 ctdb will send out updates to remote nodes to inform them that
605 the sequence number is increased.
606 </para>
607 </refsect2>
609 <refsect2>
610 <title>StatHistoryInterval</title>
611 <para>Default: 1</para>
612 <para>
613 Granularity of the statistics collected in the statistics
614 history. This is reported by 'ctdb stats' command.
615 </para>
616 </refsect2>
618 <refsect2>
619 <title>StickyDuration</title>
620 <para>Default: 600</para>
621 <para>
622 Once a record has been marked STICKY, this is the duration in
623 seconds, the record will be flagged as a STICKY record.
624 </para>
625 </refsect2>
627 <refsect2>
628 <title>StickyPindown</title>
629 <para>Default: 200</para>
630 <para>
631 Once a STICKY record has been migrated onto a node, it will be
632 pinned down on that node for this number of milliseconds. Any
633 request from other nodes to migrate the record off the node will
634 be deferred.
635 </para>
636 </refsect2>
638 <refsect2>
639 <title>TakeoverTimeout</title>
640 <para>Default: 9</para>
641 <para>
642 This is the duration in seconds in which ctdb tries to complete IP
643 failover.
644 </para>
645 </refsect2>
647 <refsect2>
648 <title>TickleUpdateInterval</title>
649 <para>Default: 20</para>
650 <para>
651 Every <varname>TickleUpdateInterval</varname> seconds, ctdb
652 synchronizes the client connection information across nodes.
653 </para>
654 </refsect2>
656 <refsect2>
657 <title>TraverseTimeout</title>
658 <para>Default: 20</para>
659 <para>
660 This is the duration in seconds for which a database traverse
661 is allowed to run. If the traverse does not complete during
662 this interval, ctdb will abort the traverse.
663 </para>
664 </refsect2>
666 <refsect2>
667 <title>VacuumFastPathCount</title>
668 <para>Default: 60</para>
669 <para>
670 During a vacuuming run, ctdb usually processes only the records
671 marked for deletion also called the fast path vacuuming. After
672 finishing <varname>VacuumFastPathCount</varname> number of fast
673 path vacuuming runs, ctdb will trigger a scan of complete database
674 for any empty records that need to be deleted.
675 </para>
676 </refsect2>
678 <refsect2>
679 <title>VacuumInterval</title>
680 <para>Default: 10</para>
681 <para>
682 Periodic interval in seconds when vacuuming is triggered for
683 volatile databases.
684 </para>
685 </refsect2>
687 <refsect2>
688 <title>VacuumMaxRunTime</title>
689 <para>Default: 120</para>
690 <para>
691 The maximum time in seconds for which the vacuuming process is
692 allowed to run. If vacuuming process takes longer than this
693 value, then the vacuuming process is terminated.
694 </para>
695 </refsect2>
697 <refsect2>
698 <title>VerboseMemoryNames</title>
699 <para>Default: 0</para>
700 <para>
701 When set to non-zero, ctdb assigns verbose names for some of
702 the talloc allocated memory objects. These names are visible
703 in the talloc memory report generated by 'ctdb dumpmemory'.
704 </para>
705 </refsect2>
707 </refsect1>
709 <refsect1>
710 <title>FILES></title>
712 <simplelist>
713 <member><filename>/usr/local/etc/ctdb/ctdb.tunables</filename></member>
714 </simplelist>
715 </refsect1>
717 <refsect1>
718 <title>SEE ALSO</title>
719 <para>
720 <citerefentry><refentrytitle>ctdb</refentrytitle>
721 <manvolnum>1</manvolnum></citerefentry>,
723 <citerefentry><refentrytitle>ctdbd</refentrytitle>
724 <manvolnum>1</manvolnum></citerefentry>,
726 <citerefentry><refentrytitle>ctdb.conf</refentrytitle>
727 <manvolnum>5</manvolnum></citerefentry>,
729 <citerefentry><refentrytitle>ctdb</refentrytitle>
730 <manvolnum>7</manvolnum></citerefentry>,
732 <ulink url="http://ctdb.samba.org/"/>
733 </para>
734 </refsect1>
736 <refentryinfo>
737 <author>
738 <contrib>
739 This documentation was written by
740 Ronnie Sahlberg,
741 Amitay Isaacs,
742 Martin Schwenke
743 </contrib>
744 </author>
746 <copyright>
747 <year>2007</year>
748 <holder>Andrew Tridgell</holder>
749 <holder>Ronnie Sahlberg</holder>
750 </copyright>
751 <legalnotice>
752 <para>
753 This program is free software; you can redistribute it and/or
754 modify it under the terms of the GNU General Public License as
755 published by the Free Software Foundation; either version 3 of
756 the License, or (at your option) any later version.
757 </para>
758 <para>
759 This program is distributed in the hope that it will be
760 useful, but WITHOUT ANY WARRANTY; without even the implied
761 warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
762 PURPOSE. See the GNU General Public License for more details.
763 </para>
764 <para>
765 You should have received a copy of the GNU General Public
766 License along with this program; if not, see
767 <ulink url="http://www.gnu.org/licenses"/>.
768 </para>
769 </legalnotice>
770 </refentryinfo>
772 </refentry>