diff --git a/doc/sphinx/book/administration.rst b/doc/sphinx/book/administration.rst
index 08de541aa47ec9faf3382c3239871520f2b22b22..3364011fac09ba67d9bd71c0691dc97124719e85 100644
--- a/doc/sphinx/book/administration.rst
+++ b/doc/sphinx/book/administration.rst
@@ -12,23 +12,23 @@ reloading configuration, taking snapshots, log rotation.
Server signal handling
=====================================================================
-The server is configured to shut down gracefully on SIGTERM and SIGINT (keyboard
-interrupt) or SIGHUP. SIGUSR1 can be used to save a snapshot. All other signals
-are blocked or ignored. The signals are processed in the main event loop. Thus,
-if the control flow never reaches the event loop (thanks to a runaway stored
-procedure), the server stops responding to any signal, and can only be killed
-with SIGKILL (this signal can not be ignored).
-
+The server is configured to shut down gracefully on SIGTERM and SIGINT
+(keyboard interrupt) or SIGHUP. SIGUSR1 can be used to save a snapshot. All
+other signals are blocked or ignored. The signals are processed in the main
+thread event loop. Thus, if the control flow never reaches the event loop
+(thanks to a runaway stored procedure), the server stops responding to any
+signal, and can only be killed with SIGKILL (this signal can not be ignored).
=====================================================================
- Utility ``tarantool``
+ Using ``tarantool`` as a client
=====================================================================
.. program:: tarantool
-If ``tarantool`` is started without an initialization file, then there will be
-a prompt ("``tarantool>``") and it will be possible to enter requests. When
-used this way, ``tarantool`` is a client program as well as a server program.
+If ``tarantool`` is started without a Lua script to run, it automatically
+enters interactive mode. There will be a prompt ("``tarantool>``") and it will
+be possible to enter requests. When used this way, ``tarantool`` can be
+a client for a remote server.
This section shows all legal syntax for the tarantool program, with short notes
and examples. Other client programs may have similar options and request
@@ -96,7 +96,7 @@ which is legal according to the rules for Lua identifiers. Procedure
identifiers are also called function names. Notes: function names are case
insensitive so ``insert`` and ``Insert`` are not the same thing.
-tring literals are: Any sequence of zero or more characters enclosed in
+String literals are: Any sequence of zero or more characters enclosed in
single quotes. Double quotes are legal but single quotes are preferred.
Enclosing in double square brackets is good for multi-line strings as
described in `Lua documentation`_.
@@ -144,11 +144,6 @@ To go back to normal mode: ``console.delimiter('')string-literal``. Example:
end!
console.delimiter('')!
-For a condensed Backus-Naur Form [BNF] description of the suggested form of
-client requests, see `doc/dev_guide/box-protocol.html`_.
-
-.. _doc/dev_guide/box-protocol.html: http://tarantool.org/doc/dev_guide/box-protocol.html
-
In *interactive* mode, one types requests and gets results. Typically the
requests are typed in by the user following prompts. Here is an example of
an interactive-mode tarantool client session:
diff --git a/doc/sphinx/book/app_b_proctitle.rst b/doc/sphinx/book/app_b_proctitle.rst
index 4152d2c146e7cae3c8df85e6e9c3efcfc7568a79..582caf13ba00a0871d93c399538d904d0632ddce 100644
--- a/doc/sphinx/book/app_b_proctitle.rst
+++ b/doc/sphinx/book/app_b_proctitle.rst
@@ -19,10 +19,7 @@ A Tarantool server process title follows the following naming scheme:
* **loading** -- ordinary node recovering from old snap and wal files,
* **orphan** -- not in a cluster,
* **hot_standby** -- see section :ref:`local_hot_standby`,
-* **dumper + process-id** -- saving files before exiting,
-* **spawner** -- controls other processes,
-* **replica + URI/status** -- replication node accepting connections on :ref:`replication_port`,
-* **relay + sockaddr** -- serves a single replication connection,
+* **dumper + process-id** -- saving a snapshot,
For example:
@@ -30,4 +27,3 @@ For example:
$ ps -A -f | grep tarantool
1000 17701 2778 0 08:27 pts/0 00:00:00 tarantool: running
- 1000 17704 17701 0 08:27 pts/0 00:00:00 tarantool: spawner
diff --git a/doc/sphinx/book/configuration.rst b/doc/sphinx/book/configuration.rst
index 711635920557688d6b8c7163530c3eb0f67d7aa2..0d301f43396729a00783b21c060672b537978800 100644
--- a/doc/sphinx/book/configuration.rst
+++ b/doc/sphinx/book/configuration.rst
@@ -265,9 +265,13 @@ for binary logging and snapshots, for replication, for networking, and for loggi
| | | | | and workload, Tarantool can consume up to 20% |
| | | | | more than the limit set here. |
+--------------------------+-----------+----------+----------+-------------------------------------------------+
- | slab_alloc_minimal | integer | null | no | Size of the smallest allocation unit. It can be |
+ | slab_alloc_minimal | integer | 64 | no | Size of the smallest allocation unit. It can be |
| | | | | tuned down if most of the tuples are very small |
+--------------------------+-----------+----------+----------+-------------------------------------------------+
+ | slab_alloc_maximal | integer | 1048576 | no | Size of the largest allocation unit. It can be |
+ | | | | | tuned down up if it is necessary to store large |
+ | | | | | tuples. |
+ +--------------------------+-----------+----------+----------+-------------------------------------------------+
| slab_alloc_factor | float | 2.0 | no | Use slab_alloc_factor as the multiplier for |
| | | | | computing the sizes of memory chunks that |
| | | | | tuples are stored in. A lower value may result |
@@ -295,7 +299,7 @@ for binary logging and snapshots, for replication, for networking, and for loggi
+--------------------+-----------+----------+----------+-----------------------------------------------------+
| Name | Type | Default | Dynamic? | Description |
+====================+===========+==========+==========+=====================================================+
- | snapshot_period | float | 0 | yes | The interval between actions by the snapshot |
+ | snapshot_period | integer | 0 | yes | The interval between actions by the snapshot |
| | | | | daemon, in seconds. The snapshot daemon is a |
| | | | | fiber which is constantly running. If |
| | | | | ``snapshot_period`` is set to a value greater |
@@ -307,7 +311,7 @@ for binary logging and snapshots, for replication, for networking, and for loggi
| | | | | the snapshot daemon to create a new database |
| | | | | snapshot once per hour. |
+--------------------+-----------+----------+----------+-----------------------------------------------------+
- | snapshot_count | float | 6 | yes | The maximum number of snapshots that the |
+ | snapshot_count | integer | 6 | yes | The maximum number of snapshots that the |
| | | | | snapshot daemon maintains. For example, |
| | | | | ``box.cfg{snapshot_period=3600, snapshot_count=10}``|
| | | | | will cause the snapshot daemon to create a new |
@@ -327,8 +331,9 @@ for binary logging and snapshots, for replication, for networking, and for loggi
| panic_on_snap_error | boolean | true | no | If there is an error while reading the snapshot |
| | | | | file (at server start), abort. |
+----------------------+-----------+----------+----------+-----------------------------------------------------+
- | panic_on_wal_error | boolean | false | no | If there is an error while reading a write-ahead |
- | | | | | log file (at server start), abort. |
+ | panic_on_wal_error | boolean | true | no | If there is an error while reading a write-ahead |
+ | | | | | log file (at server start or to relay to a replica),|
+ | | | | | abort. |
+----------------------+-----------+----------+----------+-----------------------------------------------------+
| rows_per_val | integer | 500000 | no | How many log records to store in a single |
| | | | | write-ahead log file. When this limit is reached, |
@@ -368,10 +373,8 @@ for binary logging and snapshots, for replication, for networking, and for loggi
| | | | | which replication_source specifies with a `URI`_ |
| | | | | (Universal Resource Identifier), for example |
| | | | | '``konstantin:secret_password@tarantool.org:3301``' |
- | | | | | The default user name is 'guest'. A replica server |
- | | | | | does not accept data-change |
- | | | | | requests on the ``listen`` |
- | | | | | port. The replication_source parameter is dynamic, |
+ | | | | | The default user name is 'guest'. |
+ | | | | | The replication_source parameter is dynamic, |
| | | | | that is, to enter master mode, simply set |
| | | | | replication_source to an empty string and issue |
| | | | | "``box.cfg{replication_source=new-value}``" |
@@ -424,6 +427,13 @@ for binary logging and snapshots, for replication, for networking, and for loggi
| | | | | Example setting: ``logger = 'tarantool.log'`` (this |
| | | | | will open tarantool.log for output on the server's |
| | | | | default directory). |
+ | | | | | If logger string begins with a pipe, for example |
+ | | | | | '| cronolog tarantool.log', the program specified in|
+ | | | | | the option is executed at server start and all log |
+ | | | | | When logging to a file, tarantool reopens the log |
+ | | | | | on SIGHUP. When log is a program, it's pid is saved |
+ | | | | | in logger_pid variable of package log. You need to |
+ | | | | | send it a signal to rotate logs. |
+----------------------+-----------+----------+----------+-----------------------------------------------------+
| logger_nonblock | boolean | true | no | If logger_nonblock equals true, Tarantool does not |
| | | | | block on the log file descriptor when it's not |
@@ -459,14 +469,14 @@ first instance goes down.
The expectation is that there will be two instances of the server using the
same configuration. 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 listen address and admin address,
-but will fail because the primary instance has already taken them. So the
+will initialize and will try to connect on listen address,
+but will fail because the primary instance has already taken it. 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
+and trying to connect on the port. If the primary instance goes down for any
+reason, the port 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 this ``local_hot_standby`` feature is being used, then ``replication_source``
-should be an empty string and ``wal_mode`` should not be equal to "none".
+If this ``local_hot_standby`` feature is being used, then ``wal_mode`` should
+not be equal to "none".
diff --git a/doc/sphinx/faq.rst b/doc/sphinx/faq.rst
index 7eb6673898e435243cf47c3ff4b4ab9f15d9b779..54161b0faaf2b9e878eb57d1e5a384a5322e93d9 100644
--- a/doc/sphinx/faq.rst
+++ b/doc/sphinx/faq.rst
@@ -52,19 +52,6 @@
part of Mail.Ru backbone, so it gets a lot of support from Mail.ru.
- :Q: Why is Tarantool primary port number 3303?
- :A: It's a prime number which is easy to remember, because 3313, 3301, 313, 13 and
- 3 are also prime numbers.
-
-
- :Q: My arena_used/items_used in SHOW SLAB output is >> 1. What does it mean and what should I do?
- :A: If the ratio of arena_used to items_used >> 1, that indicates that there is
- fragmentation accumulated by the slab allocator. Imagine there are a lot of
- small tuples stored in the system initially, and later on each tuple becomes
- bigger and doesn't fit into its old slab size. The old slabs are never
- relinquished by the allocator. Currently this can be solved only by a server restart.
-
-
:Q: What happens when Tarantool runs out of memory?
:A: The server stops accepting updates until more memory is available. Read and
delete requests are served just fine.