<!DOCTYPE book [
<!ENTITY % tnt SYSTEM "../tnt.ent">
%tnt;
]>
<chapter xmlns="http://docbook.org/ns/docbook" version="5.0"
         xmlns:xi="http://www.w3.org/2001/XInclude"
         xmlns:xlink="http://www.w3.org/1999/xlink"
         xml:id="configuration-reference">

<title>Configuration reference</title>
<blockquote><para>
  This chapter provides a reference of options which
  can be set in the command line or
  <filename>tarantool.cfg</filename> configuration file.
</para></blockquote>

<para>
Tarantool splits its configuration parameters between command
line options and a configuration file. Command line options
are provided only for the most basic properties; the rest
must be set in the configuration file.
At runtime, this allows to disambiguate the source of
a configuration setting: it unequivocally comes either from
the command line, or from the configuration file, but never from
both.
</para>

<section xml:id="command-line-options">
<title>Command line options</title>
  <para>
    Tarantool follows the <citetitle
    xlink:href="http://www.gnu.org/prep/standards/standards.html#Command_002dLine-Interfaces">GNU
    standard</citetitle> for its command line interface: long
    options start with a double dash (<option>--option</option>),
    their short counterparts use a single one (<option>-o</option>).
    For phrases, both dashes and
    underscores can be used as word separators
    (<option>--cfg-get</option> and <option>--cfg_get</option> both work).
    If an option requires an argument, you can either separate it
    with a space or equals sign (<option>--cfg-get=pid_file</option> and
    <option>--cfg-get pid_file</option> both work).
  </para>
  <itemizedlist>
    <listitem xml:id="help-option">
      <para><option>--help</option>, <option>-h</option></para>
      <para>Print an annotated list of all available options and exit.</para>
    </listitem>

    <listitem xml:id="version-option">
      <para><option>--version</option>, <option>-V</option></para>
      <para>Print product name and version, for example:
        <programlisting><prompt>$ </prompt> ./tarantool_box --version
Tarantool 1.4.0-69-g45551dd
        </programlisting>
        In this example:
        <simplelist>
          <member>
            <quote>Tarantool</quote> is the name
            of the reusable asynchronous networking programming framework.
         </member>
          <member>
            <quote>Box</quote> is the name
            of the storage back-end.
         </member>
          <member>
            The 3-number version follows the standard
            <literal>&lt;major&gt;-&lt;minor&gt;-&lt;patch&gt;</literal>
            scheme, in which <literal>&lt;major&gt;</literal> number
            is changed only rarely, <literal>&lt;minor&gt;</literal>
            is incremented for each new milestone and
            indicates possible incompatible changes,
            and <literal>&lt;patch&gt;</literal> stands for the number of
            bug fix releases made after the start of the
            milestone. The optional commit number and
            commit SHA1 are output for non-released versions
            only, and indicate how much this particular build has diverged
            from the last release.
         </member>
        </simplelist>
      </para>
      <note><para>
        Tarantool uses <link
        xlink:href="http://www.kernel.org/pub/software/scm/git/docs/git-describe.html">git describe</link> to produce its version id, and
        this id can be used at any time to check out the
        corresponding source from our <link
        xlink:href="git://github.com/tarantool/tarantool.git">git repository</link>.
      </para></note>
    </listitem>

    <listitem xml:id="config-option">
      <para><option>--config=</option><userinput><filename>/path/to/config.file</filename></userinput>, <option>-c</option></para>
      <para>
        Tarantool does not start without a configuration file. By
        default, the server looks for file named
        <filename>tarantool.cfg</filename> in the current working
        directory. An alternative location can be provided using
        this option.
      </para>
    </listitem>

    <listitem>
      <para><option>--check-config</option></para>
      <para>Check the configuration file for errors. This option is
        normally used on the command line
        before <quote>reload configuration</quote>
        is issued on the administrative port, to ensure that the new
        configuration is valid. When configuration is
        indeed correct, the program produces no output and returns <literal>0</literal>.
        Otherwise, information about discovered error is printed out
        and the program terminates with a non-zero value.
      </para>
    </listitem>

    <listitem>
      <para><option>--cfg-get=</option><userinput>option_name</userinput></para>
      <para>Given option name, print option value. If the
        option does not exist, or the configuration file is
        incorrect, an error is returned. If the option
        is not explicitly specified, its default value is used
        instead. Example:
        <programlisting><prompt>$ </prompt>./tarantool_box --cfg-get=admin_port
33015   </programlisting>
      </para>
    </listitem>
    <listitem>
      <para>
      <option xml:id="init-storage-option"
            xreflabel="--init-storage">
          --init-storage
      </option></para>
      <para>Initialize the directory, specified in <emphasis>vardir</emphasis>
      configuration option by creating an empty snapshot file in
      it. If <filename>vardir</filename> doesn't contain at
      least one snapshot, the server does not start. There is no
      <quote>magic</quote> with automatic initialization of
      <filename>vardir</filename> on boot to make
      potential system errors more noticeable. For example, if the
      operating system reboots and fails to mount the partition on
      which <filename>vardir</filename> is expected to reside, the
      <filename>rc.d</filename> or <command>service</command> script
      responsible for server restart will also fail, thanks to this
      option.
      </para>
    </listitem>
  </itemizedlist>
  <para>
    The only two options which could affect a running server are:
  </para>
  <itemizedlist>
    <listitem>
      <para><option>--verbose</option>, <option>-v</option></para>
      <para>Increase verbosity level in log messages. This option
      currently has no effect.</para>
    </listitem>

    <listitem>
      <para><option>--background</option>, <option>-b</option></para>
      <para>Detach from the controlling terminal and run in the
        background.
        <caution><para>Tarantool uses
        <filename>stdout</filename> and
        <filename>stderr</filename> for
        debug and error log output. When starting the server with
        option <option>--background</option>, make sure to
        either redirect its standard out and standard error
        streams, or provide <emphasis>logger</emphasis> option
        in the configuration file, since otherwise all logging
        information will be lost.</para></caution>
      </para>
    </listitem>
  </itemizedlist>
</section>

<section xml:id="configuration-file" xreflabel="configuration file">
<title>The configuration file</title>
  <para>
    All advanced configuration parameters must be specified in a
    configuration file, which is required for server start. If no path to
    the configuration file is specified on the command line (see
    <option xlink:href="#config-option"
    xlink:title="--config=...">--config</option>),
    the server looks for a file named <filename>tarantool.cfg</filename>
    in the current working directory.
  </para>
  <para>
    To facilitate centralized and automated configuration
    management, runtime configuration modifications are supported
    solely through the <olink targetptr="reload-configuration"/>
    administrative statement. Thus, the
    procedure to change Tarantool configuration at runtime is to
    edit the configuration file.  This ensures that, should the
    server get killed or restart, no unexpected changes to
    configuration can occur.
  </para>
  <para>
    Not all configuration file settings are changeable at runtime:
    such settings will be highlighted in this reference.
    If the same setting is given more than once, the latest occurrence
    takes effect.
    You can always invoke <olink targetptr="show-configuration"/>
    from the administrative console to show the current
    configuration.
  </para>
  <para>
    Tarantool maintains a set of all allowed configuration
    parameters in two template files, which are easy to maintain
    and extend:
    <filename xlink:href="https://github.com/tarantool/tarantool/blob/master/cfg/core_cfg.cfg_tmpl">cfg/core_cfg.cfg_tmpl</filename>,
    <filename xlink:href="https://github.com/tarantool/tarantool/blob/master/src/box/box_cfg.cfg_tmpl">src/box/box_cfg.cfg_tmpl</filename>.
    These files can always be used as a reference for any
    parameter in this manual.
  </para>

  <para>In addition, two working examples can be found in the source tree:
    <filename xlink:href="https://github.com/tarantool/tarantool/blob/master/test/box/tarantool.cfg">test/box/tarantool.cfg</filename>,
    <filename xlink:href="https://github.com/tarantool/tarantool/blob/master/test/big/tarantool.cfg">test/big/tarantool.cfg</filename>.
  </para>

  <table frame='all' pgwide='1'>
    <title>Basic parameters</title>
    <tgroup cols='6' colsep='1' rowsep='1'>
      <colspec colnum="1" colname="col1" colwidth="2*"/>
      <colspec colnum="6" colname="col4" colwidth="6*"/>

      <thead>
        <row>
          <entry>Name</entry>
          <entry>Type</entry>
          <entry>Default</entry>
          <entry>Required?</entry>
          <entry>Dynamic?</entry>
          <entry>Description</entry>
        </row>
      </thead>

      <tbody>

        <row>
          <entry>username</entry>
          <entry>string</entry>
          <entry>""</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>UNIX user name to switch to after start.</entry>
        </row>

        <row>
          <entry xml:id="work_dir" xreflabel="work_dir">work_dir</entry>
          <entry>string</entry>
          <entry>""</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>A directory where database working files will be stored.
          The server switches to work_dir with chdir(2) after
          start. Can be relative to the current directory.
          If not specified, defaults to the current directory.</entry>
        </row>

        <row>
          <entry xml:id="script_dir" xreflabel="script_dir">script_dir</entry>
          <entry>string</entry>
          <entry>""</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>If this path is set, it is added to the Lua package
          search path, so that instance-specific Lua scripts can
          be loaded and executed. If the directory specified in
          the path contains <filename>init.lua</filename> file, it
          is loaded and executed at server start.
          </entry>
        </row>

        <row>
          <entry xml:id="wal_dir" xreflabel="wal_dir">wal_dir</entry>
          <entry>string</entry>
          <entry>""</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>A directory where write ahead log (.xlog) files are stored.
          Can be relative to work_dir. Most commonly used so
          that snapshot files and write ahead log files
          can be stored on separate disks.
          If not specified, defaults to work_dir.</entry>
        </row>

        <row>
          <entry xml:id="snap_dir" xreflabel="snap_dir">snap_dir</entry>
          <entry>string</entry>
          <entry>""</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>A directory where snapshot (.snap) files will be stored. Can be
          relative to work_dir. If not specified, defaults to
          work_dir. See also <olink targetptr="wal_dir"/>.</entry>
        </row>
<!--
        <row>
          <entry>coredump</entry><entry>0 or 1</entry><entry>0</entry>
          <entry>Deprecated. Save core on abort/assert? You may
          turn off the coredump off when using ulimit</entry>
        </row>
-->
        <row>
          <entry xml:id="bind_ipaddr" xreflabel="bind_ipaddr">bind_ipaddr</entry>
          <entry>string</entry>
          <entry><emphasis role="strong">"INADDR_ANY"</emphasis></entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>The network interface to bind to. By default,
          the server binds to all available addresses.
          Applies to all ports opened by the server.
          </entry>
        </row>
        <row>
          <entry xml:id="primary_port" xreflabel="primary_port">primary_port</entry>
          <entry>integer</entry>
          <entry><emphasis role="strong">none</emphasis></entry>
          <entry><emphasis role="strong">yes</emphasis></entry>
          <entry>no</entry>
          <entry>The read/write data port.
          Has no default value, so <emphasis
          role="strong">must be specified</emphasis>
          in the configuration file. Normally set to 33013.
          Note: a replica also binds to this port, and accepts
          connections, but these connections can only serve
          reads until the replica becomes a master.</entry>
        </row>

        <row>
          <entry xml:id="secondary_port"
            xreflabel="secondary_port">secondary_port</entry>
          <entry>integer</entry>
          <entry>none</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>Additional, read-only port. Normally set to
          33014. Not used unless is set.</entry>
        </row>

        <row>
          <entry xml:id="admin_port" xreflabel="admin_port">admin_port</entry>
          <entry>integer</entry>
          <entry>none</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>The TCP port to listen on for administrative
          connections. Has no default value. Not used unless
          assigned a value. Normally set to 33015.</entry>
        </row>

        <row>
          <entry>pid_file</entry>
          <entry>string</entry>
          <entry>tarantool.pid</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>Store the process id in this file. Can be
          relative to work_dir.</entry>
        </row>

        <row>
          <entry xml:id="custom_proc_title"
                 xreflabel="custom_proc_title">
            custom_proc_title
          </entry>
          <entry>string</entry>
          <entry>""</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>
            <para>Inject the given string into <olink
            targetptr="proctitle">server process title</olink>
            (what's shown in the COMMAND column for <command>ps</command>
            and <command>top</command> commands). For example,
             ordinarily <command>ps</command> shows the Tarantool server process thus:
            </para>
<programlisting>kostja@shmita:~$ ps -a -o command | grep box
tarantool_box: primary pri: 33013 sec: 33014 adm: 33015</programlisting>
          <para>But if the configuration file contains custom_proc_title=sessions then
          the output looks like:</para>
<programlisting>kostja@shmita:~$ ps -a -o command | grep box
tarantool_box: primary@sessions pri: 33013 sec: 33014 adm: 33015</programlisting>
          </entry>
        </row>

      </tbody>
    </tgroup>
  </table>

  <table frame='all' pgwide='1'>
    <title>Configuring the storage</title>
    <tgroup cols='6' colsep='1' rowsep='1'>
      <colspec colnum="1" colname="col1" colwidth="2*"/>
      <colspec colnum="6" colname="col4" colwidth="6*"/>

      <thead>
        <row>
          <entry>Name</entry>
          <entry>Type</entry>
          <entry>Default</entry>
          <entry>Required?</entry>
          <entry>Dynamic?</entry>
          <entry>Description</entry>
        </row>
      </thead>

      <tbody>

        <row>
          <entry>slab_alloc_arena</entry>
          <entry>float</entry>
          <entry>1.0</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>
            <anchor xml:id="slab_alloc_arena" xreflabel="slab_alloc_arena"/>
            How much memory Tarantool
          allocates to actually
          store tuples, <emphasis role="strong">in
          gigabytes</emphasis>. When the limit is reached, INSERT
          or UPDATE requests begin failing with error
          <olink targetptr="ER_MEMORY_ISSUE"/>.
          While the server does not go
          beyond the defined limit to allocate tuples, there is
          additional memory used to store indexes and connection
          information.  Depending on actual configuration and
          workload, Tarantool can consume up to 20% more than the
          limit set here.</entry>
        </row>

        <row>
          <entry>slab_alloc_minimal</entry>
          <entry>integer</entry>
          <entry>64</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>Size of the smallest allocation unit. It can be
          tuned down if most of the tuples are very small.</entry>
        </row>

        <row>
          <entry>slab_alloc_factor</entry>
          <entry>float</entry>
          <entry>2.0</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>Use slab_alloc_factor as the multiplier for
          computing the sizes of memory chunks that tuples are
          stored in. A lower value  may result in less wasted
          memory depending on the total amount of memory available
          and the distribution of item sizes.</entry>
        </row>

        <row>
          <entry>space</entry>
          <entry>array of objects</entry>
          <entry>none</entry>
          <entry><emphasis role="strong">yes</emphasis></entry>
          <entry><emphasis role="strong">no</emphasis></entry>
          <entry>This is the main Tarantool parameter, describing
          the data structure that users get access to via the
          client/server protocol. It holds an array of
          entries, and each entry describes a tuple set
          and its indexes. Every entry is a composite object,
          best seen as a C programming language "struct"
          <footnote><xi:include href="space.xml"/></footnote>.
          </entry>
        </row>

      </tbody>
    </tgroup>
  </table>

  <table frame='all' pgwide='1'>
    <title>Binary logging and snapshots</title>
    <tgroup cols='6' colsep='1' rowsep='1'>
      <colspec colnum="1" colname="col1" colwidth="2*"/>
      <colspec colnum="6" colname="col4" colwidth="6*"/>

      <thead>
        <row>
          <entry>Name</entry>
          <entry>Type</entry>
          <entry>Default</entry>
          <entry>Required?</entry>
          <entry>Dynamic?</entry>
          <entry>Description</entry>
        </row>
      </thead>

      <tbody>

        <row>
          <entry>panic_on_snap_error</entry>
          <entry>boolean</entry>
          <entry>true</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>If there is an error reading the snapshot file (at
            server start), abort.</entry>
        </row>

        <row>
          <entry>panic_on_wal_error</entry>
          <entry>boolean</entry>
          <entry>false</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>If there is an error reading a write ahead
          log file (at server start), abort.</entry>
        </row>

        <row>
          <entry xml:id="rows_per_wal" xreflabel="rows_per_wal">rows_per_wal</entry>
          <entry>integer</entry>
          <entry>500000</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>How many log records to store in a single write
          ahead log file. When this limit is reached, Tarantool
          creates another WAL file named
          <filename>&lt;first-lsn-in-wal&gt;.xlog</filename>
          This can be useful for simple rsync-based backups.
          </entry>
        </row>

        <row>
          <entry>snap_io_rate_limit</entry>
          <entry>float</entry>
          <entry>0.0</entry>
          <entry>no</entry>
          <entry>yes</entry>
          <entry>Reduce the throttling effect of <olink
          targetptr="save-snapshot"/> on INSERT/UPDATE/DELETE
          performance by setting a limit on
          how many megabytes per second it can write to disk.
          The same can be achieved by splitting <olink
          targetptr="wal_dir"/> and <olink targetptr="snap_dir"/>
          locations and moving snapshots to a separate disk.</entry>
        </row>

        <row>
        <entry>wal_fsync_delay</entry>
        <entry>float</entry>
        <entry>0</entry>
        <entry>no</entry>
        <entry>yes</entry>
        <entry>Do not flush the write ahead log to disk more often
          than once in wal_fsync_delay seconds. By default the
          delay is zero, which means there is no flushing after writes
          (the meaning of wal_fsync_delay=0 may change in later versions).
          Setting the delay may be necessary to increase write
          throughput, but may lead to several last updates being
          lost in case of a power failure. Such failure, however,
          does not lead to data corruption: all WAL records have a
          checksum, and only complete records are processed during
          recovery.</entry>
        </row>

        <row>
            <entry xml:id="wal_mode" xreflabel="wal_mode">wal_mode</entry>
            <entry>string</entry>
            <entry>"fsync_delay"</entry>
            <entry>no</entry>
            <entry>yes</entry>
            <entry>Specify fiber-WAL-disk synchronization mode as:
                <emphasis>none:</emphasis> write ahead log is not maintained; <emphasis>write:</emphasis> fibers wait for their data to
                be written to the write ahead log (no fsync(2)); <emphasis>fsync</emphasis>:
                fibers wait for their data, fsync(2) follows each write(2);
                <emphasis>fsync_delay</emphasis>: fibers wait for their
                data, fsync(2) is called every N=<emphasis>wal_fsync_delay</emphasis>
                seconds (N=0.0 means no fsync(2) - equivalent to
                <emphasis>wal_mode = "write"</emphasis>);</entry>
        </row>

      </tbody>
    </tgroup>
  </table>

  <table frame='all' pgwide='1'>
    <title>Replication</title>
    <tgroup cols='6' colsep='1' rowsep='1'>
      <colspec colnum="1" colname="col1" colwidth="2*"/>
      <colspec colnum="6" colname="col4" colwidth="6*"/>

      <thead>
        <row>
          <entry>Name</entry>
          <entry>Type</entry>
          <entry>Default</entry>
          <entry>Required?</entry>
          <entry>Dynamic?</entry>
          <entry>Description</entry>
        </row>
      </thead>

      <tbody>
        <row>
          <entry xml:id="replication_port"
            xreflabel="replication_port">replication_port</entry>
          <entry>integer</entry>
          <entry>0</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>If replication_port is greater than zero, the
          server is considered to be a Tarantool master.
          The master server listens on the specified port
          for incoming connections from
          replicas. See also <olink
          targetptr="replication_source"/>, which complements
          this setting on the replica side.</entry>
        </row>

        <row>
          <entry xml:id="replication_source"
          xreflabel="replication_source">replication_source</entry>
          <entry>string</entry>
          <entry>NULL</entry>
          <entry>no</entry>
          <entry><emphasis role="strong">yes</emphasis></entry>
          <entry>If replication_source is not an empty string, the
          server is considered to be a Tarantool replica.
          The replica server will try to connect to the master
          which replication_source specifies with format ip:port.
          For example, if replication_source = "1.2.3.4:55555" then
          the replica server tries to connect to 1.2.3.4 port 55555.
          A replica server does not accept updates
          on <olink targetptr="primary_port"/>. This parameter is
          dynamic, that is, to enter master mode, simply set
          replication_source to an empty string and issue <olink
          targetptr="reload-configuration"/>.</entry>
        </row>

      </tbody>
    </tgroup>
  </table>

  <table frame='all' pgwide='1'>
    <title>Networking</title>
    <tgroup cols='6' colsep='1' rowsep='1'>
      <colspec colnum="1" colname="col1" colwidth="2*"/>
      <colspec colnum="6" colname="col4" colwidth="6*"/>

      <thead>
        <row>
          <entry>Name</entry>
          <entry>Type</entry>
          <entry>Default</entry>
          <entry>Required?</entry>
          <entry>Dynamic?</entry>
          <entry>Description</entry>
        </row>
      </thead>

      <tbody>

        <row>
          <entry>io_collect_interval</entry>
          <entry>float</entry>
          <entry>0.0</entry>
          <entry>no</entry>
          <entry>yes</entry>
          <entry>The server will sleep for io_collect_interval seconds
          between iterations of the event loop. Can be
          used to reduce CPU load in deployments in which the
          number of client connections is large, but requests are
          not so frequent (for example, each connection issues
          just a handful of requests per second). </entry>
        </row>

        <row>
          <entry>readahead</entry>
          <entry>integer</entry>
          <entry>16384</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>The size of the read-ahead buffer associated with a
          client connection. The larger the buffer, the more
          memory an active connection consumes and the more requests
          can be read from the operating system buffer in a single
          system call. The rule of thumb is to make sure the buffer
          can contain at least a few dozen requests. Therefore, if
          a typical tuple in a request is large, e.g. a few
          kilobytes or even megabytes, the read-ahead buffer size should
          be increased.  If batched request processing is not
          used, it's prudent to leave this setting at its
          default.</entry>
        </row>

        <row>
          <entry>backlog</entry>
          <entry>integer</entry>
          <entry>1024</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>The size of the listen backlog.</entry>
       </row>

      </tbody>
    </tgroup>
  </table>

  <table frame='all' pgwide='1'>
    <title>Logging</title>
    <tgroup cols='6' colsep='1' rowsep='1'>
      <colspec colnum="1" colname="col1" colwidth="2*"/>
      <colspec colnum="6" colname="col4" colwidth="6*"/>

      <thead>
        <row>
          <entry>Name</entry>
          <entry>Type</entry>
          <entry>Default</entry>
          <entry>Required?</entry>
          <entry>Dynamic?</entry>
          <entry>Description</entry>
        </row>
      </thead>

      <tbody>

        <row>
          <entry>log_level</entry>
          <entry>integer</entry>
          <entry>4</entry>
          <entry>no</entry>
          <entry><emphasis role="strong">yes</emphasis></entry>
          <entry>How verbose the logging is. There are 5 log
            verbosity classes: 1 -- ERROR, 2 -- CRITICAL, 3 --
            WARNING, 4 -- INFO, 5 -- DEBUG. By setting log_level,
            one can enable logging of all classes below or equal
            to the given level. Tarantool prints its logs to the
            standard error stream by default, but this can be
            changed with the "logger" configuration parameter.
          </entry>
        </row>

        <row>
          <entry>logger</entry>
          <entry>string</entry>
          <entry>""</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>By default, the log is sent to the standard
          error stream (<filename>stderr</filename>). If logger
          is given a value, Tarantool creates a child process,
          executes the command indicated by the value, and pipes its standard
          output to the standard input of the created process.
          Example setting: <command>tee --append
          tarantool.log</command> (this will duplicate log output
          to <filename>stdout</filename> and a log file).
          </entry>
        </row>

        <row>
          <entry>logger_nonblock</entry>
          <entry>integer</entry>
          <entry>0</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>If logger_nonblock equals 1, Tarantool does not
          block on the log file descriptor when it's not
          ready for write, and drops the message instead. If
          log_level is high, and a lot of messages go to the log
          file, setting logger_nonblock to 1 may improve logging
          performance at the cost of some log messages getting
          lost.</entry>
        </row>

        <row>
          <entry>too_long_threshold</entry>
          <entry>float</entry>
          <entry>0.5</entry>
          <entry>no</entry>
          <entry><emphasis role="strong">yes</emphasis></entry>
          <entry>If processing a request takes longer than the
          given value (in seconds), warn about it in the log.
          Has effect only if log_level is less than or equal to 3
          (WARNING).</entry>
        </row>

      </tbody>
    </tgroup>
  </table>

  <table frame='all' pgwide='1'>
    <title>Memcached protocol support</title>
    <tgroup cols='6' colsep='1' rowsep='1'>
      <colspec colnum="1" colname="col1" colwidth="2*"/>
      <colspec colnum="6" colname="col4" colwidth="6*"/>

      <thead>
        <row>
          <entry>Name</entry>
          <entry>Type</entry>
          <entry>Default</entry>
          <entry>Required?</entry>
          <entry>Dynamic?</entry>
          <entry>Description</entry>
        </row>
      </thead>

      <tbody>

        <row>
          <entry>memcached_port</entry>
          <entry>integer</entry>
          <entry>none</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>
            <anchor xml:id="memcached_port" xreflabel="memcached_port"/>

          Turn on Memcached protocol support on the given
            port. All requests on this port are directed to
            a dedicated space, set in <olink
            targetptr="memcached_space"/>.
            Memcached-style flags are supported and stored
            along with the value. The expiration time can also be
            set and is persistent, but is ignored, unless <olink
            targetptr="memcached_expire"/> is turned on.
            Unlike Memcached, all data still goes to the binary
            log and to the replica, if the latter is set up, which
            means that power outage does not lead to loss of all
            data. Thanks to data persistence, cache warm up time
            is also very short.
          </entry>
        </row>

        <row>
          <entry>memcached_space</entry>
          <entry>integer</entry>
          <entry>23</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>
            <anchor xml:id="memcached_space"
            xreflabel="memcached_space"/>
          Space id to store memcached data in. The
          format of tuple is [key, metadata, value], with a HASH
          index based on the key. Since the space format
          is defined by the Memcached data model, it must not be
          previously configured.</entry>
        </row>

        <row>
          <entry>memcached_expire</entry>
          <entry>boolean</entry>
          <entry>false</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>
            <anchor xml:id="memcached_expire"
            xreflabel="memcached_expire"/>
            Turn on tuple time-to-live support in
            <olink targetptr="memcached_space"/>. This
            effectively turns Tarantool into a persistent,
            replicated and scriptable implementation of Memcached.
          </entry>
        </row>

        <row>
          <entry>memcached_expire_per_loop</entry>
          <entry>integer</entry>
          <entry>1024</entry>
          <entry>no</entry>
          <entry><emphasis role="strong">yes</emphasis></entry>
          <entry>How many records to consider per iteration of the
            expiration loop. Tuple expiration is performed in a separate
            <quote>green</quote> thread within our cooperative multitasking
            framework and this setting effectively limits how long
            the expiration loop stays uninterrupted on the CPU.
          </entry>
        </row>

        <row>
          <entry>memcached_expire_full_sweep</entry>
          <entry>float</entry>
          <entry>3600</entry>
          <entry>no</entry>
          <entry><emphasis role="strong">yes</emphasis></entry>
          <entry>Try to make sure that every tuple is considered
            for expiration within this time frame (in seconds).
            Together with memcached_expire_per_loop this defines
            how often the expiration <quote>green</quote> thread
            is scheduled on the CPU.
          </entry>
        </row>

      </tbody>
    </tgroup>
  </table>
  
  <table frame='all' pgwide='1'>
    <title>Hot Standby</title>
    <tgroup cols='6' colsep='1' rowsep='1'>
      <colspec colnum="1" colname="col1" colwidth="2*"/>
      <colspec colnum="6" colname="col4" colwidth="6*"/>

      <thead>
        <row>
          <entry>Name</entry>
          <entry>Type</entry>
          <entry>Default</entry>
          <entry>Required?</entry>
          <entry>Dynamic?</entry>
          <entry>Description</entry>
        </row>
      </thead>

      <tbody>

        <row>
          <entry>local_hot_standby</entry>
          <entry>boolean</entry>
          <entry>false</entry>
          <entry>no</entry>
          <entry>no</entry>
          <entry>
            <anchor xml:id="local_hot_standby" xreflabel="local_hot_standby"/>
          If local_hot_standby=true, the expectation is that there will be two
          instances of the server using the same configuration file.
          The first one to start will be the "primary" instance.
          The second one to start will be the "standby" instance.
          The standby instance will initialize and will try to connect on primary_port
          and secondary_port and admin_port, but will fail because the
          primary instance has already taken them.
          So the standby instance goes into a loop, reading the write
          ahead log which the primary instance is writing (so the
          two instances are always in synch), and trying to connect on the
          ports. If the primary instance goes down for any reason,
          the ports will become free so the standby instance will
          succeed in connecting, and will become the primary instance.
          Thus there is no noticeable downtime if the primary instance goes down.
          If local_hot_standby=true, then replication_source should be an
          empty string and wal_mode should not be equal to "none".
          </entry>
        </row>
      </tbody>
    </tgroup>
  </table>
  
</section>
</chapter>

<!--
vim: tw=66 syntax=docbk
vim: spell spelllang=en_us
-->
