| blob | 766213e14231836958204db3c8996f1c869e0b3c |
1 <?xml version="1.0" encoding="UTF-8"?>
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 databases
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 <para>
287 You can override the automatic "home" node allocation by
288 creating a file "home_nodes" next to the
289 "public_addresses" file. As an example the following
290 "home_nodes" file assigns the address 192.168.1.1 to
291 node 0 and 192.168.1.2 to node 2:
292 </para>
293 <screen format="linespecific">
294 192.168.1.1 0
295 192.168.1.2 2
296 </screen>
297 </listitem>
298 </varlistentry>
299 <varlistentry>
300 <term>1</term>
301 <listitem>
302 <para>
303 Non-deterministic IP address allocation.
304 </para>
305 <para>
306 This is a relatively fast option that attempts to do a
307 minimise unnecessary address movements. Addresses do
308 not have a "home" node. Rebalancing is limited but it
309 usually adequate. Works badly when addresses are
310 defined across multiple networks.
311 </para>
312 </listitem>
313 </varlistentry>
314 <varlistentry>
315 <term>2</term>
316 <listitem>
317 <para>
318 LCP2 IP address allocation.
319 </para>
320 <para>
321 Uses a heuristic to assign addresses defined across
322 multiple networks, usually balancing addresses on each
323 network evenly across nodes. Addresses do not have a
324 "home" node. Minimises unnecessary address movements.
325 The algorithm is complex, so is slower than other
326 choices for a large number of addresses. However, it
327 can calculate an optimal assignment of 900 addresses in
328 under 10 seconds on modern hardware.
329 </para>
330 </listitem>
331 </varlistentry>
332 </variablelist>
333 <para>
334 If the specified value is not one of these then the default
335 will be used.
336 </para>
337 </refsect2>
339 <refsect2>
340 <title>KeepaliveInterval</title>
341 <para>Default: 5</para>
342 <para>
343 How often in seconds should the nodes send keep-alive packets to
344 each other.
345 </para>
346 </refsect2>
348 <refsect2>
349 <title>KeepaliveLimit</title>
350 <para>Default: 5</para>
351 <para>
352 After how many keepalive intervals without any traffic should
353 a node wait until marking the peer as DISCONNECTED.
354 </para>
355 <para>
356 If a node has hung, it can take
357 <varname>KeepaliveInterval</varname> *
358 (<varname>KeepaliveLimit</varname> + 1) seconds before
359 ctdb determines that the node is DISCONNECTED and performs
360 a recovery. This limit should not be set too high to enable
361 early detection and avoid any application timeouts (e.g. SMB1)
362 to kick in before the fail over is completed.
363 </para>
364 </refsect2>
366 <refsect2>
367 <title>LockProcessesPerDB</title>
368 <para>Default: 200</para>
369 <para>
370 This is the maximum number of lock helper processes ctdb will
371 create for obtaining record locks. When ctdb cannot get a record
372 lock without blocking, it creates a helper process that waits
373 for the lock to be obtained.
374 </para>
375 </refsect2>
377 <refsect2>
378 <title>LogLatencyMs</title>
379 <para>Default: 0</para>
380 <para>
381 When set to non-zero, ctdb will log if certains operations
382 take longer than this value, in milliseconds, to complete.
383 These operations include "process a record request from client",
384 "take a record or database lock", "update a persistent database
385 record" and "vacuum a database".
386 </para>
387 </refsect2>
389 <refsect2>
390 <title>MaxQueueDropMsg</title>
391 <para>Default: 1000000</para>
392 <para>
393 This is the maximum number of messages to be queued up for
394 a client before ctdb will treat the client as hung and will
395 terminate the client connection.
396 </para>
397 </refsect2>
399 <refsect2>
400 <title>MonitorInterval</title>
401 <para>Default: 15</para>
402 <para>
403 How often should ctdb run the 'monitor' event in seconds to check
404 for a node's health.
405 </para>
406 </refsect2>
408 <refsect2>
409 <title>MonitorTimeoutCount</title>
410 <para>Default: 20</para>
411 <para>
412 How many 'monitor' events in a row need to timeout before a node
413 is flagged as UNHEALTHY. This setting is useful if scripts can
414 not be written so that they do not hang for benign reasons.
415 </para>
416 </refsect2>
418 <refsect2>
419 <title>NoIPFailback</title>
420 <para>Default: 0</para>
421 <para>
422 When set to 1, ctdb will not perform failback of IP addresses
423 when a node becomes healthy. When a node becomes UNHEALTHY,
424 ctdb WILL perform failover of public IP addresses, but when the
425 node becomes HEALTHY again, ctdb will not fail the addresses back.
426 </para>
427 <para>
428 Use with caution! Normally when a node becomes available to the
429 cluster ctdb will try to reassign public IP addresses onto the
430 new node as a way to distribute the workload evenly across the
431 clusternode. Ctdb tries to make sure that all running nodes have
432 approximately the same number of public addresses it hosts.
433 </para>
434 <para>
435 When you enable this tunable, ctdb will no longer attempt to
436 rebalance the cluster by failing IP addresses back to the new
437 nodes. An unbalanced cluster will therefore remain unbalanced
438 until there is manual intervention from the administrator. When
439 this parameter is set, you can manually fail public IP addresses
440 over to the new node(s) using the 'ctdb moveip' command.
441 </para>
442 </refsect2>
444 <refsect2>
445 <title>NoIPTakeover</title>
446 <para>Default: 0</para>
447 <para>
448 When set to 1, ctdb will not allow IP addresses to be failed
449 over to other nodes. Any IP addresses already hosted on
450 healthy nodes will remain. Any IP addresses hosted on
451 unhealthy nodes will be released by unhealthy nodes and will
452 become un-hosted.
453 </para>
454 </refsect2>
456 <refsect2>
457 <title>PullDBPreallocation</title>
458 <para>Default: 10*1024*1024</para>
459 <para>
460 This is the size of a record buffer to pre-allocate for sending
461 reply to PULLDB control. Usually record buffer starts with size
462 of the first record and gets reallocated every time a new record
463 is added to the record buffer. For a large number of records,
464 this can be very inefficient to grow the record buffer one record
465 at a time.
466 </para>
467 </refsect2>
469 <refsect2>
470 <title>QueueBufferSize</title>
471 <para>Default: 1024</para>
472 <para>
473 This is the maximum amount of data (in bytes) ctdb will read
474 from a socket at a time.
475 </para>
476 <para>
477 For a busy setup, if ctdb is not able to process the TCP sockets
478 fast enough (large amount of data in Recv-Q for tcp sockets),
479 then this tunable value should be increased. However, large
480 values can keep ctdb busy processing packets and prevent ctdb
481 from handling other events.
482 </para>
483 </refsect2>
485 <refsect2>
486 <title>RecBufferSizeLimit</title>
487 <para>Default: 1000000</para>
488 <para>
489 This is the limit on the size of the record buffer to be sent
490 in various controls. This limit is used by new controls used
491 for recovery and controls used in vacuuming.
492 </para>
493 </refsect2>
495 <refsect2>
496 <title>RecdFailCount</title>
497 <para>Default: 10</para>
498 <para>
499 If the recovery daemon has failed to ping the main daemon for
500 this many consecutive intervals, the main daemon will consider
501 the recovery daemon as hung and will try to restart it to recover.
502 </para>
503 </refsect2>
505 <refsect2>
506 <title>RecdPingTimeout</title>
507 <para>Default: 60</para>
508 <para>
509 If the main daemon has not heard a "ping" from the recovery daemon
510 for this many seconds, the main daemon will log a message that
511 the recovery daemon is potentially hung. This also increments a
512 counter which is checked against <varname>RecdFailCount</varname>
513 for detection of hung recovery daemon.
514 </para>
515 </refsect2>
517 <refsect2>
518 <title>RecLockLatencyMs</title>
519 <para>Default: 1000</para>
520 <para>
521 When using a reclock file for split brain prevention, if set
522 to non-zero this tunable will make the recovery daemon log a
523 message if the fcntl() call to lock/testlock the recovery file
524 takes longer than this number of milliseconds.
525 </para>
526 </refsect2>
528 <refsect2>
529 <title>RecoverInterval</title>
530 <para>Default: 1</para>
531 <para>
532 How frequently in seconds should the recovery daemon perform the
533 consistency checks to determine if it should perform a recovery.
534 </para>
535 </refsect2>
537 <refsect2>
538 <title>RecoverTimeout</title>
539 <para>Default: 120</para>
540 <para>
541 This is the default setting for timeouts for controls when sent
542 from the recovery daemon. We allow longer control timeouts from
543 the recovery daemon than from normal use since the recovery
544 daemon often use controls that can take a lot longer than normal
545 controls.
546 </para>
547 </refsect2>
549 <refsect2>
550 <title>RecoveryBanPeriod</title>
551 <para>Default: 300</para>
552 <para>
553 The duration in seconds for which a node is banned if the node
554 fails during recovery. After this time has elapsed the node will
555 automatically get unbanned and will attempt to rejoin the cluster.
556 </para>
557 <para>
558 A node usually gets banned due to real problems with the node.
559 Don't set this value too small. Otherwise, a problematic node
560 will try to re-join cluster too soon causing unnecessary recoveries.
561 </para>
562 </refsect2>
564 <refsect2>
565 <title>RecoveryDropAllIPs</title>
566 <para>Default: 120</para>
567 <para>
568 If a node is stuck in recovery, or stopped, or banned, for this
569 many seconds, then ctdb will release all public addresses on
570 that node.
571 </para>
572 </refsect2>
574 <refsect2>
575 <title>RecoveryGracePeriod</title>
576 <para>Default: 120</para>
577 <para>
578 During recoveries, if a node has not caused recovery failures
579 during the last grace period in seconds, any records of
580 transgressions that the node has caused recovery failures will be
581 forgiven. This resets the ban-counter back to zero for that node.
582 </para>
583 </refsect2>
585 <refsect2>
586 <title>RepackLimit</title>
587 <para>Default: 10000</para>
588 <para>
589 During vacuuming, if the number of freelist records are more than
590 <varname>RepackLimit</varname>, then the database is repacked
591 to get rid of the freelist records to avoid fragmentation.
592 </para>
593 </refsect2>
595 <refsect2>
596 <title>RerecoveryTimeout</title>
597 <para>Default: 10</para>
598 <para>
599 Once a recovery has completed, no additional recoveries are
600 permitted until this timeout in seconds has expired.
601 </para>
602 </refsect2>
604 <refsect2>
605 <title>SeqnumInterval</title>
606 <para>Default: 1000</para>
607 <para>
608 Some databases have seqnum tracking enabled, so that samba will
609 be able to detect asynchronously when there has been updates
610 to the database. Every time a database is updated its sequence
611 number is increased.
612 </para>
613 <para>
614 This tunable is used to specify in milliseconds how frequently
615 ctdb will send out updates to remote nodes to inform them that
616 the sequence number is increased.
617 </para>
618 </refsect2>
620 <refsect2>
621 <title>StatHistoryInterval</title>
622 <para>Default: 1</para>
623 <para>
624 Granularity of the statistics collected in the statistics
625 history. This is reported by 'ctdb stats' command.
626 </para>
627 </refsect2>
629 <refsect2>
630 <title>StickyDuration</title>
631 <para>Default: 600</para>
632 <para>
633 Once a record has been marked STICKY, this is the duration in
634 seconds, the record will be flagged as a STICKY record.
635 </para>
636 </refsect2>
638 <refsect2>
639 <title>StickyPindown</title>
640 <para>Default: 200</para>
641 <para>
642 Once a STICKY record has been migrated onto a node, it will be
643 pinned down on that node for this number of milliseconds. Any
644 request from other nodes to migrate the record off the node will
645 be deferred.
646 </para>
647 </refsect2>
649 <refsect2>
650 <title>TakeoverTimeout</title>
651 <para>Default: 9</para>
652 <para>
653 This is the duration in seconds in which ctdb tries to complete IP
654 failover.
655 </para>
656 </refsect2>
658 <refsect2>
659 <title>TickleUpdateInterval</title>
660 <para>Default: 20</para>
661 <para>
662 Every <varname>TickleUpdateInterval</varname> seconds, ctdb
663 synchronizes the client connection information across nodes.
664 </para>
665 </refsect2>
667 <refsect2>
668 <title>TraverseTimeout</title>
669 <para>Default: 20</para>
670 <para>
671 This is the duration in seconds for which a database traverse
672 is allowed to run. If the traverse does not complete during
673 this interval, ctdb will abort the traverse.
674 </para>
675 </refsect2>
677 <refsect2>
678 <title>VacuumFastPathCount</title>
679 <para>Default: 60</para>
680 <para>
681 During a vacuuming run, ctdb usually processes only the records
682 marked for deletion also called the fast path vacuuming. After
683 finishing <varname>VacuumFastPathCount</varname> number of fast
684 path vacuuming runs, ctdb will trigger a scan of complete database
685 for any empty records that need to be deleted.
686 </para>
687 </refsect2>
689 <refsect2>
690 <title>VacuumInterval</title>
691 <para>Default: 10</para>
692 <para>
693 Periodic interval in seconds when vacuuming is triggered for
694 volatile databases.
695 </para>
696 </refsect2>
698 <refsect2>
699 <title>VacuumMaxRunTime</title>
700 <para>Default: 120</para>
701 <para>
702 The maximum time in seconds for which the vacuuming process is
703 allowed to run. If vacuuming process takes longer than this
704 value, then the vacuuming process is terminated.
705 </para>
706 </refsect2>
708 <refsect2>
709 <title>VerboseMemoryNames</title>
710 <para>Default: 0</para>
711 <para>
712 When set to non-zero, ctdb assigns verbose names for some of
713 the talloc allocated memory objects. These names are visible
714 in the talloc memory report generated by 'ctdb dumpmemory'.
715 </para>
716 </refsect2>
718 </refsect1>
720 <refsect1>
721 <title>FILES></title>
723 <simplelist>
724 <member><filename>/usr/local/etc/ctdb/ctdb.tunables</filename></member>
725 </simplelist>
726 </refsect1>
728 <refsect1>
729 <title>SEE ALSO</title>
730 <para>
731 <citerefentry><refentrytitle>ctdb</refentrytitle>
732 <manvolnum>1</manvolnum></citerefentry>,
734 <citerefentry><refentrytitle>ctdbd</refentrytitle>
735 <manvolnum>1</manvolnum></citerefentry>,
737 <citerefentry><refentrytitle>ctdb.conf</refentrytitle>
738 <manvolnum>5</manvolnum></citerefentry>,
740 <citerefentry><refentrytitle>ctdb</refentrytitle>
741 <manvolnum>7</manvolnum></citerefentry>,
743 <ulink url="http://ctdb.samba.org/"/>
744 </para>
745 </refsect1>
747 <refentryinfo>
748 <author>
749 <contrib>
750 This documentation was written by
751 Ronnie Sahlberg,
752 Amitay Isaacs,
753 Martin Schwenke
754 </contrib>
755 </author>
757 <copyright>
758 <year>2007</year>
759 <holder>Andrew Tridgell</holder>
760 <holder>Ronnie Sahlberg</holder>
761 </copyright>
762 <legalnotice>
763 <para>
764 This program is free software; you can redistribute it and/or
765 modify it under the terms of the GNU General Public License as
766 published by the Free Software Foundation; either version 3 of
767 the License, or (at your option) any later version.
768 </para>
769 <para>
770 This program is distributed in the hope that it will be
771 useful, but WITHOUT ANY WARRANTY; without even the implied
772 warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
773 PURPOSE. See the GNU General Public License for more details.
774 </para>
775 <para>
776 You should have received a copy of the GNU General Public
777 License along with this program; if not, see
778 <ulink url="http://www.gnu.org/licenses"/>.
779 </para>
780 </legalnotice>
781 </refentryinfo>
783 </refentry>