Ignore:
Timestamp:
Nov 25, 2016, 8:04:54 PM (9 years ago)
Author:
Silvan Scherrer
Message:

Samba Server: update vendor to version 4.4.7

File:
1 edited

Legend:

Unmodified
Added
Removed

  • vendor/current/ctdb/doc/ctdb-tunables.7.xml

    r988 r989  
    3030    </para>
    3131
    32     <refsect2>
    33       <title>MaxRedirectCount</title>
    34       <para>Default: 3</para>
    35       <para>
    36         If we are not the DMASTER and need to fetch a record across the network
    37         we first send the request to the LMASTER after which the record
    38         is passed onto the current DMASTER. If the DMASTER changes before
    39         the request has reached that node, the request will be passed onto the
    40         "next" DMASTER. For very hot records that migrate rapidly across the
    41         cluster this can cause a request to "chase" the record for many hops
    42         before it catches up with the record.
    43 
    44         this is how many hops we allow trying to chase the DMASTER before we
    45         switch back to the LMASTER again to ask for new directions.
    46       </para>
    47       <para>
    48         When chasing a record, this is how many hops we will chase the record
    49         for before going back to the LMASTER to ask for new guidance.
    50       </para>
    51     </refsect2>
    52 
    53     <refsect2>
    54       <title>SeqnumInterval</title>
    55       <para>Default: 1000</para>
    56       <para>
    57         Some databases have seqnum tracking enabled, so that samba will be able
    58         to detect asynchronously when there has been updates to the database.
    59         Everytime a database is updated its sequence number is increased.
    60       </para>
    61       <para>
    62         This tunable is used to specify in 'ms' how frequently ctdb will
    63         send out updates to remote nodes to inform them that the sequence
    64         number is increased.
     32    <para>
     33      The tunable variables are listed alphabetically.
     34    </para>
     35
     36    <refsect2>
     37      <title>AllowClientDBAttach</title>
     38      <para>Default: 1</para>
     39      <para>
     40        When set to 0, clients are not allowed to attach to any databases.
     41        This can be used to temporarily block any new processes from
     42        attaching to and accessing the databases.  This is mainly used
     43        for detaching a volatile database using 'ctdb detach'.
     44      </para>
     45    </refsect2>
     46
     47    <refsect2>
     48      <title>AllowUnhealthyDBRead</title>
     49      <para>Default: 0</para>
     50      <para>
     51        When set to 1, ctdb allows database traverses to read unhealthy
     52        databases.  By default, ctdb does not allow reading records from
     53        unhealthy databases.
    6554      </para>
    6655    </refsect2>
    … …  
    7059      <para>Default: 60</para>
    7160      <para>
    72         This is the default
    73         setting for timeout for when sending a control message to either the
    74         local or a remote ctdb daemon.
    75       </para>
    76     </refsect2>
    77 
    78     <refsect2>
    79       <title>TraverseTimeout</title>
    80       <para>Default: 20</para>
    81       <para>
    82         This setting controls how long we allow a traverse process to run.
    83         After this timeout triggers, the main ctdb daemon will abort the
    84         traverse if it has not yet finished.
    85       </para>
    86     </refsect2>
    87 
    88     <refsect2>
    89       <title>KeepaliveInterval</title>
     61        This is the default setting for timeout for when sending a
     62        control message to either the local or a remote ctdb daemon.
     63      </para>
     64    </refsect2>
     65
     66    <refsect2>
     67      <title>DatabaseHashSize</title>
     68      <para>Default: 100001</para>
     69      <para>
     70        Number of the hash chains for the local store of the tdbs that
     71        ctdb manages.
     72      </para>
     73    </refsect2>
     74
     75    <refsect2>
     76      <title>DatabaseMaxDead</title>
    9077      <para>Default: 5</para>
    9178      <para>
    92         How often in seconds should the nodes send keepalives to eachother.
    93       </para>
    94     </refsect2>
    95 
    96     <refsect2>
    97       <title>KeepaliveLimit</title>
    98       <para>Default: 5</para>
    99       <para>
    100         After how many keepalive intervals without any traffic should a node
    101         wait until marking the peer as DISCONNECTED.
    102       </para>
    103       <para>
    104         If a node has hung, it can thus take KeepaliveInterval*(KeepaliveLimit+1)
    105         seconds before we determine that the node is DISCONNECTED and that we
    106         require a recovery. This limitshould not be set too high since we want
    107         a hung node to be detectec, and expunged from the cluster well before
    108         common CIFS timeouts (45-90 seconds) kick in.
    109       </para>
    110     </refsect2>
    111 
    112     <refsect2>
    113       <title>RecoverTimeout</title>
    114       <para>Default: 20</para>
    115       <para>
    116         This is the default setting for timeouts for controls when sent from the
    117         recovery daemon. We allow longer control timeouts from the recovery daemon
    118         than from normal use since the recovery dameon often use controls that
    119         can take a lot longer than normal controls.
    120       </para>
    121     </refsect2>
    122 
    123     <refsect2>
    124       <title>RecoverInterval</title>
    125       <para>Default: 1</para>
    126       <para>
    127         How frequently in seconds should the recovery daemon perform the
    128         consistency checks that determine if we need to perform a recovery or not.
     79        Maximum number of dead records per hash chain for the tdb databses
     80        managed by ctdb.
     81      </para>
     82    </refsect2>
     83
     84    <refsect2>
     85      <title>DBRecordCountWarn</title>
     86      <para>Default: 100000</para>
     87      <para>
     88        When set to non-zero, ctdb will log a warning during recovery if
     89        a database has more than this many records. This will produce a
     90        warning if a database grows uncontrollably with orphaned records.
     91      </para>
     92    </refsect2>
     93
     94    <refsect2>
     95      <title>DBRecordSizeWarn</title>
     96      <para>Default: 10000000</para>
     97      <para>
     98        When set to non-zero, ctdb will log a warning during recovery
     99        if a single record is bigger than this size. This will produce
     100        a warning if a database record grows uncontrollably.
     101      </para>
     102    </refsect2>
     103
     104    <refsect2>
     105      <title>DBSizeWarn</title>
     106      <para>Default: 1000000000</para>
     107      <para>
     108        When set to non-zero, ctdb will log a warning during recovery if
     109        a database size is bigger than this. This will produce a warning
     110        if a database grows uncontrollably.
     111      </para>
     112    </refsect2>
     113
     114    <refsect2>
     115      <title>DeferredAttachTO</title>
     116      <para>Default: 120</para>
     117      <para>
     118        When databases are frozen we do not allow clients to attach to
     119        the databases. Instead of returning an error immediately to the
     120        client, the attach request from the client is deferred until
     121        the database becomes available again at which stage we respond
     122        to the client.
     123      </para>
     124      <para>
     125        This timeout controls how long we will defer the request from the
     126        client before timing it out and returning an error to the client.
     127      </para>
     128    </refsect2>
     129
     130    <refsect2>
     131      <title>DeterministicIPs</title>
     132      <para>Default: 0</para>
     133      <para>
     134        When set to 1, ctdb will try to keep public IP addresses locked
     135        to specific nodes as far as possible. This makes it easier
     136        for debugging since you can know that as long as all nodes are
     137        healthy public IP X will always be hosted by node Y.
     138      </para>
     139      <para>
     140        The cost of using deterministic IP address assignment is that it
     141        disables part of the logic where ctdb tries to reduce the number
     142        of public IP assignment changes in the cluster. This tunable may
     143        increase the number of IP failover/failbacks that are performed
     144        on the cluster by a small margin.
     145      </para>
     146    </refsect2>
     147
     148    <refsect2>
     149      <title>DisableIPFailover</title>
     150      <para>Default: 0</para>
     151      <para>
     152        When set to non-zero, ctdb will not perform failover or
     153        failback. Even if a node fails while holding public IPs, ctdb
     154        will not recover the IPs or assign them to another node.
     155      </para>
     156      <para>
     157        When this tunable is enabled, ctdb will no longer attempt
     158        to recover the cluster by failing IP addresses over to other
     159        nodes. This leads to a service outage until the administrator
     160        has manually performed IP failover to replacement nodes using the
     161        'ctdb moveip' command.
    129162      </para>
    130163    </refsect2>
    … …  
    134167      <para>Default: 3</para>
    135168      <para>
    136         When electing a new recovery master, this is how many seconds we allow
    137         the election to take before we either deem the election finished
    138         or we fail the election and start a new one.
    139       </para>
    140     </refsect2>
    141 
    142     <refsect2>
    143       <title>TakeoverTimeout</title>
    144       <para>Default: 9</para>
    145       <para>
    146         This is how many seconds we allow controls to take for IP failover events.
    147       </para>
    148     </refsect2>
    149 
    150     <refsect2>
    151       <title>MonitorInterval</title>
    152       <para>Default: 15</para>
    153       <para>
    154         How often should ctdb run the event scripts to check for a nodes health.
    155       </para>
    156     </refsect2>
    157 
    158     <refsect2>
    159       <title>TickleUpdateInterval</title>
    160       <para>Default: 20</para>
    161       <para>
    162         How often will ctdb record and store the "tickle" information used to
    163         kickstart stalled tcp connections after a recovery.
     169        The number of seconds to wait for the election of recovery
     170        master to complete. If the election is not completed during this
     171        interval, then that round of election fails and ctdb starts a
     172        new election.
     173      </para>
     174    </refsect2>
     175
     176    <refsect2>
     177      <title>EnableBans</title>
     178      <para>Default: 1</para>
     179      <para>
     180        This parameter allows ctdb to ban a node if the node is misbehaving.
     181      </para>
     182      <para>
     183        When set to 0, this disables banning completely in the cluster
     184        and thus nodes can not get banned, even it they break. Don't
     185        set to 0 unless you know what you are doing.  You should set
     186        this to the same value on all nodes to avoid unexpected behaviour.
    164187      </para>
    165188    </refsect2>
    … …  
    173196        run for an event, not just a single event script.
    174197      </para>
    175 
    176198      <para>
    177199        Note that timeouts are ignored for some events ("takeip",
    … …  
    183205
    184206    <refsect2>
     207      <title>FetchCollapse</title>
     208      <para>Default: 1</para>
     209      <para>
     210       This parameter is used to avoid multiple migration requests for
     211       the same record from a single node. All the record requests for
     212       the same record are queued up and processed when the record is
     213       migrated to the current node.
     214      </para>
     215      <para>
     216        When many clients across many nodes try to access the same record
     217        at the same time this can lead to a fetch storm where the record
     218        becomes very active and bounces between nodes very fast. This
     219        leads to high CPU utilization of the ctdbd daemon, trying to
     220        bounce that record around very fast, and poor performance.
     221        This can improve performance and reduce CPU utilization for
     222        certain workloads.
     223      </para>
     224    </refsect2>
     225
     226    <refsect2>
     227      <title>HopcountMakeSticky</title>
     228      <para>Default: 50</para>
     229      <para>
     230        For database(s) marked STICKY (using 'ctdb setdbsticky'),
     231        any record that is migrating so fast that hopcount
     232        exceeds this limit is marked as STICKY record for
     233        <varname>StickyDuration</varname> seconds. This means that
     234        after each migration the sticky record will be kept on the node
     235        <varname>StickyPindown</varname>milliseconds and prevented from
     236        being migrated off the node.
     237       </para>
     238       <para>
     239        This will improve performance for certain workloads, such as
     240        locking.tdb if many clients are opening/closing the same file
     241        concurrently.
     242      </para>
     243    </refsect2>
     244
     245    <refsect2>
     246      <title>KeepaliveInterval</title>
     247      <para>Default: 5</para>
     248      <para>
     249        How often in seconds should the nodes send keep-alive packets to
     250        each other.
     251      </para>
     252    </refsect2>
     253
     254    <refsect2>
     255      <title>KeepaliveLimit</title>
     256      <para>Default: 5</para>
     257      <para>
     258        After how many keepalive intervals without any traffic should
     259        a node wait until marking the peer as DISCONNECTED.
     260       </para>
     261       <para>
     262        If a node has hung, it can take
     263        <varname>KeepaliveInterval</varname> *
     264        (<varname>KeepaliveLimit</varname> + 1) seconds before
     265        ctdb determines that the node is DISCONNECTED and performs
     266        a recovery. This limit should not be set too high to enable
     267        early detection and avoid any application timeouts (e.g. SMB1)
     268        to kick in before the fail over is completed.
     269      </para>
     270    </refsect2>
     271
     272    <refsect2>
     273      <title>LCP2PublicIPs</title>
     274      <para>Default: 1</para>
     275      <para>
     276        When set to 1, ctdb uses the LCP2 ip allocation algorithm.
     277      </para>
     278    </refsect2>
     279
     280    <refsect2>
     281      <title>LockProcessesPerDB</title>
     282      <para>Default: 200</para>
     283      <para>
     284        This is the maximum number of lock helper processes ctdb will
     285        create for obtaining record locks.  When ctdb cannot get a record
     286        lock without blocking, it creates a helper process that waits
     287        for the lock to be obtained.
     288      </para>
     289    </refsect2>
     290
     291    <refsect2>
     292      <title>LogLatencyMs</title>
     293      <para>Default: 0</para>
     294      <para>
     295        When set to non-zero, ctdb will log if certains operations
     296        take longer than this value, in milliseconds, to complete.
     297        These operations include "process a record request from client",
     298        "take a record or database lock", "update a persistent database
     299        record" and "vaccum a database".
     300      </para>
     301    </refsect2>
     302
     303    <refsect2>
     304      <title>MaxQueueDropMsg</title>
     305      <para>Default: 1000000</para>
     306      <para>
     307        This is the maximum number of messages to be queued up for
     308        a client before ctdb will treat the client as hung and will
     309        terminate the client connection.
     310      </para>
     311    </refsect2>
     312
     313    <refsect2>
     314      <title>MonitorInterval</title>
     315      <para>Default: 15</para>
     316      <para>
     317        How often should ctdb run the 'monitor' event in seconds to check
     318        for a node's health.
     319      </para>
     320    </refsect2>
     321
     322    <refsect2>
    185323      <title>MonitorTimeoutCount</title>
    186324      <para>Default: 20</para>
    187325      <para>
    188         How many monitor events in a row need to timeout before a node
    189         is flagged as UNHEALTHY.  This setting is useful if scripts
    190         can not be written so that they do not hang for benign
    191         reasons.
     326        How many 'monitor' events in a row need to timeout before a node
     327        is flagged as UNHEALTHY.  This setting is useful if scripts can
     328        not be written so that they do not hang for benign reasons.
     329      </para>
     330    </refsect2>
     331
     332    <refsect2>
     333      <title>NoIPFailback</title>
     334      <para>Default: 0</para>
     335      <para>
     336        When set to 1, ctdb will not perform failback of IP addresses
     337        when a node becomes healthy. When a node becomes UNHEALTHY,
     338        ctdb WILL perform failover of public IP addresses, but when the
     339        node becomes HEALTHY again, ctdb will not fail the addresses back.
     340      </para>
     341      <para>
     342        Use with caution! Normally when a node becomes available to the
     343        cluster ctdb will try to reassign public IP addresses onto the
     344        new node as a way to distribute the workload evenly across the
     345        clusternode. Ctdb tries to make sure that all running nodes have
     346        approximately the same number of public addresses it hosts.
     347      </para>
     348      <para>
     349        When you enable this tunable, ctdb will no longer attempt to
     350        rebalance the cluster by failing IP addresses back to the new
     351        nodes. An unbalanced cluster will therefore remain unbalanced
     352        until there is manual intervention from the administrator. When
     353        this parameter is set, you can manually fail public IP addresses
     354        over to the new node(s) using the 'ctdb moveip' command.
     355      </para>
     356    </refsect2>
     357
     358    <refsect2>
     359      <title>NoIPHostOnAllDisabled</title>
     360      <para>Default: 0</para>
     361      <para>
     362        If no nodes are HEALTHY then by default ctdb will happily host
     363        public IPs on disabled (unhealthy or administratively disabled)
     364        nodes.  This can cause problems, for example if the underlying
     365        cluster filesystem is not mounted.  When set to 1 on a node and
     366        that node is disabled, any IPs hosted by this node will be
     367        released and the node will not takeover any IPs until it is no
     368        longer disabled.
     369      </para>
     370    </refsect2>
     371
     372    <refsect2>
     373      <title>NoIPTakeover</title>
     374      <para>Default: 0</para>
     375      <para>
     376        When set to 1, ctdb will not allow IP addresses to be failed
     377        over onto this node. Any IP addresses that the node currently
     378        hosts will remain on the node but no new IP addresses can be
     379        failed over to the node.
     380      </para>
     381    </refsect2>
     382
     383    <refsect2>
     384      <title>PullDBPreallocation</title>
     385      <para>Default: 10*1024*1024</para>
     386      <para>
     387        This is the size of a record buffer to pre-allocate for sending
     388        reply to PULLDB control. Usually record buffer starts with size
     389        of the first record and gets reallocated every time a new record
     390        is added to the record buffer. For a large number of records,
     391        this can be very inefficient to grow the record buffer one record
     392        at a time.
     393      </para>
     394    </refsect2>
     395
     396    <refsect2>
     397      <title>RecBufferSizeLimit</title>
     398      <para>Default: 1000000</para>
     399      <para>
     400        This is the limit on the size of the record buffer to be sent
     401        in various controls.  This limit is used by new controls used
     402        for recovery and controls used in vacuuming.
     403      </para>
     404    </refsect2>
     405
     406    <refsect2>
     407      <title>RecdFailCount</title>
     408      <para>Default: 10</para>
     409      <para>
     410        If the recovery daemon has failed to ping the main dameon for
     411        this many consecutive intervals, the main daemon will consider
     412        the recovery daemon as hung and will try to restart it to recover.
     413      </para>
     414    </refsect2>
     415
     416    <refsect2>
     417      <title>RecdPingTimeout</title>
     418      <para>Default: 60</para>
     419      <para>
     420        If the main dameon has not heard a "ping" from the recovery dameon
     421        for this many seconds, the main dameon will log a message that
     422        the recovery daemon is potentially hung.  This also increments a
     423        counter which is checked against <varname>RecdFailCount</varname>
     424        for detection of hung recovery daemon.
     425      </para>
     426    </refsect2>
     427
     428    <refsect2>
     429      <title>RecLockLatencyMs</title>
     430      <para>Default: 1000</para>
     431      <para>
     432        When using a reclock file for split brain prevention, if set
     433        to non-zero this tunable will make the recovery dameon log a
     434        message if the fcntl() call to lock/testlock the recovery file
     435        takes longer than this number of milliseconds.
     436      </para>
     437    </refsect2>
     438
     439    <refsect2>
     440      <title>RecoverInterval</title>
     441      <para>Default: 1</para>
     442      <para>
     443        How frequently in seconds should the recovery daemon perform the
     444        consistency checks to determine if it should perform a recovery.
     445      </para>
     446    </refsect2>
     447
     448    <refsect2>
     449      <title>RecoverPDBBySeqNum</title>
     450      <para>Default: 1</para>
     451      <para>
     452        When set to zero, database recovery for persistent databases is
     453        record-by-record and recovery process simply collects the most
     454        recent version of every individual record.
     455      </para>
     456      <para>
     457        When set to non-zero, persistent databases will instead be
     458        recovered as a whole db and not by individual records. The
     459        node that contains the highest value stored in the record
     460        "__db_sequence_number__" is selected and the copy of that nodes
     461        database is used as the recovered database.
     462      </para>
     463      <para>
     464        By default, recovery of persistent databses is done using
     465        __db_sequence_number__ record.
     466      </para>
     467    </refsect2>
     468
     469    <refsect2>
     470      <title>RecoverTimeout</title>
     471      <para>Default: 120</para>
     472      <para>
     473        This is the default setting for timeouts for controls when sent
     474        from the recovery daemon. We allow longer control timeouts from
     475        the recovery daemon than from normal use since the recovery
     476        dameon often use controls that can take a lot longer than normal
     477        controls.
     478      </para>
     479    </refsect2>
     480
     481    <refsect2>
     482      <title>RecoveryBanPeriod</title>
     483      <para>Default: 300</para>
     484      <para>
     485       The duration in seconds for which a node is banned if the node
     486       fails during recovery.  After this time has elapsed the node will
     487       automatically get unbanned and will attempt to rejoin the cluster.
     488      </para>
     489      <para>
     490       A node usually gets banned due to real problems with the node.
     491       Don't set this value too small.  Otherwise, a problematic node
     492       will try to re-join cluster too soon causing unnecessary recoveries.
     493      </para>
     494    </refsect2>
     495
     496    <refsect2>
     497      <title>RecoveryDropAllIPs</title>
     498      <para>Default: 120</para>
     499      <para>
     500        If a node is stuck in recovery, or stopped, or banned, for this
     501        many seconds, then ctdb will release all public addresses on
     502        that node.
    192503      </para>
    193504    </refsect2>
    … …  
    197508      <para>Default: 120</para>
    198509      <para>
    199         During recoveries, if a node has not caused recovery failures during the
    200         last grace period, any records of transgressions that the node has caused
    201         recovery failures will be forgiven. This resets the ban-counter back to
    202         zero for that node.
    203       </para>
    204     </refsect2>
    205 
    206     <refsect2>
    207       <title>RecoveryBanPeriod</title>
    208       <para>Default: 300</para>
    209       <para>
    210         If a node becomes banned causing repetitive recovery failures. The node will
    211         eventually become banned from the cluster.
    212         This controls how long the culprit node will be banned from the cluster
    213         before it is allowed to try to join the cluster again.
    214         Don't set to small. A node gets banned for a reason and it is usually due
    215         to real problems with the node.
    216       </para>
    217     </refsect2>
    218 
    219     <refsect2>
    220       <title>DatabaseHashSize</title>
    221       <para>Default: 100001</para>
    222       <para>
    223         Size of the hash chains for the local store of the tdbs that ctdb manages.
    224       </para>
    225     </refsect2>
    226 
    227     <refsect2>
    228       <title>DatabaseMaxDead</title>
    229       <para>Default: 5</para>
    230       <para>
    231         How many dead records per hashchain in the TDB database do we allow before
    232         the freelist needs to be processed.
     510       During recoveries, if a node has not caused recovery failures
     511       during the last grace period in seconds, any records of
     512       transgressions that the node has caused recovery failures will be
     513       forgiven. This resets the ban-counter back to zero for that node.
     514      </para>
     515    </refsect2>
     516
     517    <refsect2>
     518      <title>RepackLimit</title>
     519      <para>Default: 10000</para>
     520      <para>
     521        During vacuuming, if the number of freelist records are more than
     522        <varname>RepackLimit</varname>, then the database is repacked
     523        to get rid of the freelist records to avoid fragmentation.
     524      </para>
     525      <para>
     526        Databases are repacked only if both <varname>RepackLimit</varname>
     527        and <varname>VacuumLimit</varname> are exceeded.
    233528      </para>
    234529    </refsect2>
    … …  
    238533      <para>Default: 10</para>
    239534      <para>
    240         Once a recovery has completed, no additional recoveries are permitted
    241         until this timeout has expired.
    242       </para>
    243     </refsect2>
    244 
    245     <refsect2>
    246       <title>EnableBans</title>
     535        Once a recovery has completed, no additional recoveries are
     536        permitted until this timeout in seconds has expired.
     537      </para>
     538    </refsect2>
     539
     540    <refsect2>
     541      <title>Samba3AvoidDeadlocks</title>
     542      <para>Default: 0</para>
     543      <para>
     544        If set to non-zero, enable code that prevents deadlocks with Samba
     545        (only for Samba 3.x).
     546      </para> <para>
     547        This should be set to 1 only when using Samba version 3.x
     548        to enable special code in ctdb to avoid deadlock with Samba
     549        version 3.x.  This code is not required for Samba version 4.x
     550        and must not be enabled for Samba 4.x.
     551      </para>
     552    </refsect2>
     553
     554    <refsect2>
     555      <title>SeqnumInterval</title>
     556      <para>Default: 1000</para>
     557      <para>
     558        Some databases have seqnum tracking enabled, so that samba will
     559        be able to detect asynchronously when there has been updates
     560        to the database.  Everytime a database is updated its sequence
     561        number is increased.
     562      </para>
     563      <para>
     564        This tunable is used to specify in milliseconds how frequently
     565        ctdb will send out updates to remote nodes to inform them that
     566        the sequence number is increased.
     567      </para>
     568    </refsect2>
     569
     570    <refsect2>
     571      <title>StatHistoryInterval</title>
    247572      <para>Default: 1</para>
    248573      <para>
    249         When set to 0, this disables BANNING completely in the cluster and thus
    250         nodes can not get banned, even it they break. Don't set to 0 unless you
    251         know what you are doing.  You should set this to the same value on
    252         all nodes to avoid unexpected behaviour.
    253       </para>
    254     </refsect2>
    255 
    256     <refsect2>
    257       <title>DeterministicIPs</title>
    258       <para>Default: 0</para>
    259       <para>
    260         When enabled, this tunable makes ctdb try to keep public IP addresses
    261         locked to specific nodes as far as possible. This makes it easier for
    262         debugging since you can know that as long as all nodes are healthy
    263         public IP X will always be hosted by node Y.
    264       </para>
    265       <para>
    266         The cost of using deterministic IP address assignment is that it
    267         disables part of the logic where ctdb tries to reduce the number of
    268         public IP assignment changes in the cluster. This tunable may increase
    269         the number of IP failover/failbacks that are performed on the cluster
    270         by a small margin.
    271       </para>
    272 
    273     </refsect2>
    274     <refsect2>
    275       <title>LCP2PublicIPs</title>
    276       <para>Default: 1</para>
    277       <para>
    278         When enabled this switches ctdb to use the LCP2 ip allocation
    279         algorithm.
    280       </para>
    281     </refsect2>
    282 
    283     <refsect2>
    284       <title>ReclockPingPeriod</title>
    285       <para>Default: x</para>
    286       <para>
    287         Obsolete
    288       </para>
    289     </refsect2>
    290 
    291     <refsect2>
    292       <title>NoIPFailback</title>
    293       <para>Default: 0</para>
    294       <para>
    295         When set to 1, ctdb will not perform failback of IP addresses when a node
    296         becomes healthy. Ctdb WILL perform failover of public IP addresses when a
    297         node becomes UNHEALTHY, but when the node becomes HEALTHY again, ctdb
    298         will not fail the addresses back.
    299       </para>
    300       <para>
    301         Use with caution! Normally when a node becomes available to the cluster
    302         ctdb will try to reassign public IP addresses onto the new node as a way
    303         to distribute the workload evenly across the clusternode. Ctdb tries to
    304         make sure that all running nodes have approximately the same number of
    305         public addresses it hosts.
    306       </para>
    307       <para>
    308         When you enable this tunable, CTDB will no longer attempt to rebalance
    309         the cluster by failing IP addresses back to the new nodes. An unbalanced
    310         cluster will therefore remain unbalanced until there is manual
    311         intervention from the administrator. When this parameter is set, you can
    312         manually fail public IP addresses over to the new node(s) using the
    313         'ctdb moveip' command.
    314       </para>
    315     </refsect2>
    316 
    317     <refsect2>
    318       <title>DisableIPFailover</title>
    319       <para>Default: 0</para>
    320       <para>
    321         When enabled, ctdb will not perform failover or failback. Even if a
    322         node fails while holding public IPs, ctdb will not recover the IPs or
    323         assign them to another node.
    324       </para>
    325       <para>
    326         When you enable this tunable, CTDB will no longer attempt to recover
    327         the cluster by failing IP addresses over to other nodes. This leads to
    328         a service outage until the administrator has manually performed failover
    329         to replacement nodes using the 'ctdb moveip' command.
    330       </para>
    331     </refsect2>
    332 
    333     <refsect2>
    334       <title>NoIPTakeover</title>
    335       <para>Default: 0</para>
    336       <para>
    337         When set to 1, ctdb will not allow IP addresses to be failed over
    338         onto this node. Any IP addresses that the node currently hosts
    339         will remain on the node but no new IP addresses can be failed over
    340         to the node.
    341       </para>
    342     </refsect2>
    343 
    344     <refsect2>
    345       <title>NoIPHostOnAllDisabled</title>
    346       <para>Default: 0</para>
    347       <para>
    348         If no nodes are healthy then by default ctdb will happily host
    349         public IPs on disabled (unhealthy or administratively disabled)
    350         nodes.  This can cause problems, for example if the underlying
    351         cluster filesystem is not mounted.  When set to 1 on a node and
    352         that node is disabled it, any IPs hosted by this node will be
    353         released and the node will not takeover any IPs until it is no
    354         longer disabled.
    355       </para>
    356     </refsect2>
    357 
    358     <refsect2>
    359       <title>DBRecordCountWarn</title>
    360       <para>Default: 100000</para>
    361       <para>
    362         When set to non-zero, ctdb will log a warning when we try to recover a
    363         database with more than this many records. This will produce a warning
    364         if a database grows uncontrollably with orphaned records.
    365       </para>
    366     </refsect2>
    367 
    368     <refsect2>
    369       <title>DBRecordSizeWarn</title>
    370       <para>Default: 10000000</para>
    371       <para>
    372         When set to non-zero, ctdb will log a warning when we try to recover a
    373         database where a single record is bigger than this. This will produce
    374         a warning if a database record grows uncontrollably with orphaned
    375         sub-records.
    376       </para>
    377     </refsect2>
    378 
    379     <refsect2>
    380       <title>DBSizeWarn</title>
    381       <para>Default: 1000000000</para>
    382       <para>
    383         When set to non-zero, ctdb will log a warning when we try to recover a
    384         database bigger than this. This will produce
    385         a warning if a database grows uncontrollably.
    386       </para>
    387     </refsect2>
    388 
    389     <refsect2>
    390       <title>VerboseMemoryNames</title>
    391       <para>Default: 0</para>
    392       <para>
    393         This feature consumes additional memory. when used the talloc library
    394         will create more verbose names for all talloc allocated objects.
    395       </para>
    396     </refsect2>
    397 
    398     <refsect2>
    399       <title>RecdPingTimeout</title>
     574        Granularity of the statistics collected in the statistics
     575        history. This is reported by 'ctdb stats' command.
     576      </para>
     577    </refsect2>
     578
     579    <refsect2>
     580      <title>StickyDuration</title>
     581      <para>Default: 600</para>
     582      <para>
     583        Once a record has been marked STICKY, this is the duration in
     584        seconds, the record will be flagged as a STICKY record.
     585      </para>
     586    </refsect2>
     587
     588    <refsect2>
     589      <title>StickyPindown</title>
     590      <para>Default: 200</para>
     591      <para>
     592        Once a STICKY record has been migrated onto a node, it will be
     593        pinned down on that node for this number of milliseconds. Any
     594        request from other nodes to migrate the record off the node will
     595        be deferred.
     596      </para>
     597    </refsect2>
     598
     599    <refsect2>
     600      <title>TakeoverTimeout</title>
     601      <para>Default: 9</para>
     602      <para>
     603        This is the duration in seconds in which ctdb tries to complete IP
     604        failover.
     605      </para>
     606    </refsect2>
     607
     608    <refsect2>
     609      <title>TDBMutexEnabled</title>
     610      <para>Default: 0</para>
     611      <para>
     612        This paramter enables TDB_MUTEX_LOCKING feature on volatile
     613        databases if the robust mutexes are supported. This optimizes the
     614        record locking using robust mutexes and is much more efficient
     615        that using posix locks.
     616      </para>
     617    </refsect2>
     618
     619    <refsect2>
     620      <title>TickleUpdateInterval</title>
     621      <para>Default: 20</para>
     622      <para>
     623        Every <varname>TickleUpdateInterval</varname> seconds, ctdb
     624        synchronizes the client connection information across nodes.
     625      </para>
     626    </refsect2>
     627
     628    <refsect2>
     629      <title>TraverseTimeout</title>
     630      <para>Default: 20</para>
     631      <para>
     632        This is the duration in seconds for which a database traverse
     633        is allowed to run.  If the traverse does not complete during
     634        this interval, ctdb will abort the traverse.
     635      </para>
     636    </refsect2>
     637
     638    <refsect2>
     639      <title>VacuumFastPathCount</title>
    400640      <para>Default: 60</para>
    401641      <para>
    402         If the main dameon has not heard a "ping" from the recovery dameon for
    403         this many seconds, the main dameon will log a message that the recovery
    404         daemon is potentially hung.
    405       </para>
    406     </refsect2>
    407 
    408     <refsect2>
    409       <title>RecdFailCount</title>
    410       <para>Default: 10</para>
    411       <para>
    412         If the recovery daemon has failed to ping the main dameon for this many
    413         consecutive intervals, the main daemon will consider the recovery daemon
    414         as hung and will try to restart it to recover.
    415       </para>
    416     </refsect2>
    417 
    418     <refsect2>
    419       <title>LogLatencyMs</title>
    420       <para>Default: 0</para>
    421       <para>
    422         When set to non-zero, this will make the main daemon log any operation that
    423         took longer than this value, in 'ms', to complete.
    424         These include "how long time a lockwait child process needed",
    425         "how long time to write to a persistent database" but also
    426         "how long did it take to get a response to a CALL from a remote node".
    427       </para>
    428     </refsect2>
    429 
    430     <refsect2>
    431       <title>RecLockLatencyMs</title>
    432       <para>Default: 1000</para>
    433       <para>
    434         When using a reclock file for split brain prevention, if set to non-zero
    435         this tunable will make the recovery dameon log a message if the fcntl()
    436         call to lock/testlock the recovery file takes longer than this number of
    437         ms.
    438       </para>
    439     </refsect2>
    440 
    441     <refsect2>
    442       <title>RecoveryDropAllIPs</title>
    443       <para>Default: 120</para>
    444       <para>
    445         If we have been stuck in recovery, or stopped, or banned, mode for
    446         this many seconds we will force drop all held public addresses.
     642       During a vacuuming run, ctdb usually processes only the records
     643       marked for deletion also called the fast path vacuuming. After
     644       finishing <varname>VacuumFastPathCount</varname> number of fast
     645       path vacuuming runs, ctdb will trigger a scan of complete database
     646       for any empty records that need to be deleted.
    447647      </para>
    448648    </refsect2>
    … …  
    454654        Periodic interval in seconds when vacuuming is triggered for
    455655        volatile databases.
     656      </para>
     657    </refsect2>
     658
     659    <refsect2>
     660      <title>VacuumLimit</title>
     661      <para>Default: 5000</para>
     662      <para>
     663        During vacuuming, if the number of deleted records are more than
     664        <varname>VacuumLimit</varname>, then databases are repacked to
     665        avoid fragmentation.
     666      </para>
     667      <para>
     668        Databases are repacked only if both <varname>RepackLimit</varname>
     669        and <varname>VacuumLimit</varname> are exceeded.
    456670      </para>
    457671    </refsect2>
    … …  
    468682
    469683    <refsect2>
    470       <title>RepackLimit</title>
    471       <para>Default: 10000</para>
    472       <para>
    473         During vacuuming, if the number of freelist records are more
    474         than <varname>RepackLimit</varname>, then databases are
    475         repacked to get rid of the freelist records to avoid
    476         fragmentation.
    477       </para>
    478       <para>
    479         Databases are repacked only if both
    480         <varname>RepackLimit</varname> and
    481         <varname>VacuumLimit</varname> are exceeded.
    482       </para>
    483     </refsect2>
    484 
    485     <refsect2>
    486       <title>VacuumLimit</title>
    487       <para>Default: 5000</para>
    488       <para>
    489         During vacuuming, if the number of deleted records are more
    490         than <varname>VacuumLimit</varname>, then databases are
    491         repacked to avoid fragmentation.
    492       </para>
    493       <para>
    494         Databases are repacked only if both
    495         <varname>RepackLimit</varname> and
    496         <varname>VacuumLimit</varname> are exceeded.
    497       </para>
    498     </refsect2>
    499 
    500     <refsect2>
    501       <title>VacuumFastPathCount</title>
    502       <para>Default: 60</para>
    503       <para>
    504         When a record is deleted, it is marked for deletion during
    505         vacuuming.  Vacuuming process usually processes this list to purge
    506         the records from the database.  If the number of records marked
    507         for deletion are more than VacuumFastPathCount, then vacuuming
    508         process will scan the complete database for empty records instead
    509         of using the list of records marked for deletion.
    510       </para>
    511     </refsect2>
    512 
    513     <refsect2>
    514       <title>DeferredAttachTO</title>
    515       <para>Default: 120</para>
    516       <para>
    517         When databases are frozen we do not allow clients to attach to the
    518         databases. Instead of returning an error immediately to the application
    519         the attach request from the client is deferred until the database
    520         becomes available again at which stage we respond to the client.
    521       </para>
    522       <para>
    523         This timeout controls how long we will defer the request from the client
    524         before timing it out and returning an error to the client.
    525       </para>
    526     </refsect2>
    527 
    528     <refsect2>
    529       <title>HopcountMakeSticky</title>
    530       <para>Default: 50</para>
    531       <para>
    532         If the database is set to 'STICKY' mode, using the 'ctdb setdbsticky'
    533         command, any record that is seen as very hot and migrating so fast that
    534         hopcount surpasses 50 is set to become a STICKY record for StickyDuration
    535         seconds. This means that after each migration the record will be kept on
    536         the node and prevented from being migrated off the node.
    537       </para>
    538       <para>
    539         This setting allows one to try to identify such records and stop them from
    540         migrating across the cluster so fast. This will improve performance for
    541         certain workloads, such as locking.tdb if many clients are opening/closing
    542         the same file concurrently.
    543       </para>
    544     </refsect2>
    545 
    546     <refsect2>
    547       <title>StickyDuration</title>
    548       <para>Default: 600</para>
    549       <para>
    550         Once a record has been found to be fetch-lock hot and has been flagged to
    551         become STICKY, this is for how long, in seconds, the record will be
    552         flagged as a STICKY record.
    553       </para>
    554     </refsect2>
    555 
    556     <refsect2>
    557       <title>StickyPindown</title>
    558       <para>Default: 200</para>
    559       <para>
    560         Once a STICKY record has been migrated onto a node, it will be pinned down
    561         on that node for this number of ms. Any request from other nodes to migrate
    562         the record off the node will be deferred until the pindown timer expires.
    563       </para>
    564     </refsect2>
    565 
    566     <refsect2>
    567       <title>StatHistoryInterval</title>
    568       <para>Default: 1</para>
    569       <para>
    570         Granularity of the statistics collected in the statistics history.
    571       </para>
    572     </refsect2>
    573 
    574     <refsect2>
    575       <title>AllowClientDBAttach</title>
    576       <para>Default: 1</para>
    577       <para>
    578         When set to 0, clients are not allowed to attach to any databases.
    579         This can be used to temporarily block any new processes from attaching
    580         to and accessing the databases.
    581       </para>
    582     </refsect2>
    583 
    584     <refsect2>
    585       <title>RecoverPDBBySeqNum</title>
    586       <para>Default: 1</para>
    587       <para>
    588         When set to zero, database recovery for persistent databases
    589         is record-by-record and recovery process simply collects the
    590         most recent version of every individual record.
    591       </para>
    592       <para>
    593         When set to non-zero, persistent databases will instead be
    594         recovered as a whole db and not by individual records. The
    595         node that contains the highest value stored in the record
    596         "__db_sequence_number__" is selected and the copy of that
    597         nodes database is used as the recovered database.
    598       </para>
    599       <para>
    600         By default, recovery of persistent databses is done using
    601         __db_sequence_number__ record.
    602       </para>
    603     </refsect2>
    604 
    605     <refsect2>
    606       <title>FetchCollapse</title>
    607       <para>Default: 1</para>
    608       <para>
    609         When many clients across many nodes try to access the same record at the
    610         same time this can lead to a fetch storm where the record becomes very
    611         active and bounces between nodes very fast. This leads to high CPU
    612         utilization of the ctdbd daemon, trying to bounce that record around
    613         very fast, and poor performance.
    614       </para>
    615       <para>
    616         This parameter is used to activate a fetch-collapse. A fetch-collapse
    617         is when we track which records we have requests in flight so that we only
    618         keep one request in flight from a certain node, even if multiple smbd
    619         processes are attemtping to fetch the record at the same time. This
    620         can improve performance and reduce CPU utilization for certain
    621         workloads.
    622       </para>
    623       <para>
    624         This timeout controls if we should collapse multiple fetch operations
    625         of the same record into a single request and defer all duplicates or not.
    626       </para>
    627     </refsect2>
    628 
    629     <refsect2>
    630       <title>Samba3AvoidDeadlocks</title>
    631       <para>Default: 0</para>
    632       <para>
    633         Enable code that prevents deadlocks with Samba (only for Samba 3.x).
    634       </para>
    635       <para>
    636         This should be set to 1 when using Samba version 3.x to enable special
    637         code in CTDB to avoid deadlock with Samba version 3.x.  This code
    638         is not required for Samba version 4.x and must not be enabled for
    639         Samba 4.x.
    640       </para>
    641     </refsect2>
     684      <title>VerboseMemoryNames</title>
     685      <para>Default: 0</para>
     686      <para>
     687        When set to non-zero, ctdb assigns verbose names for some of
     688        the talloc allocated memory objects.  These names are visible
     689        in the talloc memory report generated by 'ctdb dumpmemory'.
     690      </para>
     691    </refsect2>
     692
    642693  </refsect1>
    643694
Note: See TracChangeset for help on using the changeset viewer.