Document the 'wal_queue_max_size' option

doc/concepts/engines/memtx.rst

@@ -55,7 +55,7 @@ For more details, see the ``box.slab`` module :doc:`reference </reference/refere
 .. image:: memtx/spaces_indexes.svg
 
 Also inside the TX thread, there is an event loop. Within the event loop, there are a number of :ref:`fibers <fiber-fibers>`.
-Fibers are cooperative primitives that allows interaction with spaces, that is, reading and writting the data.
+Fibers are cooperative primitives that allow interaction with spaces, that is, reading and writing the data.
 Fibers can interact with the event loop and between each other directly or by using special primitives called channels.
 Due to the usage of fibers and :ref:`cooperative multitasking <app-cooperative_multitasking>`, the ``memtx`` engine is lock-free in typical situations.
 

doc/dev_guide/internals/iproto/replication.rst

@@ -255,12 +255,12 @@ Here is what the request contains:
 
 In the header:
 
-*   IPROTO_REPLICA_ID is the replica ID of the the node that sent the request.
+*   IPROTO_REPLICA_ID is the replica ID of the node that sent the request.
 *   IPROTO_LSN is the actual LSN of the demote operation as recorded in the WAL.
 
 In the body:
 
-*   IPROTO_REPLICA_ID is the replica ID of the the node that sent the request
+*   IPROTO_REPLICA_ID is the replica ID of the node that sent the request
     (same as the value in the header).
 *   IPROTO_LSN is the LSN of the last synchronous transaction recorded in the node's WAL.
 *   IPROTO_TERM is the term in which the queue becomes empty.

doc/reference/configuration/cfg_binary_logging_snapshots.rst

@@ -3,6 +3,7 @@
 * :ref:`snap_io_rate_limit <cfg_binary_logging_snapshots-snap_io_rate_limit>`
 * :ref:`wal_mode <cfg_binary_logging_snapshots-wal_mode>`
 * :ref:`wal_dir_rescan_delay <cfg_binary_logging_snapshots-wal_dir_rescan_delay>`
+* :ref:`wal_queue_max_size <cfg_binary_logging_snapshots-wal_queue_max_size>`
 
 .. _cfg_binary_logging_snapshots-force_recovery:
 
@@ -89,3 +90,24 @@
     | Default: 2
     | Environment variable: TT_WAL_DIR_RESCAN_DELAY
     | Dynamic: no
+
+.. _cfg_binary_logging_snapshots-wal_queue_max_size:
+
+.. confval:: wal_queue_max_size
+
+    Since version 2.6.3.
+    The size of the queue (in bytes) used by a :ref:`replica <replication-roles>` to submit
+    new transactions to a :ref:`write-ahead log<internals-wal>` (WAL).
+    This option helps limit the rate at which a replica submits transactions to the WAL.
+    Limiting the queue size might be useful when a replica is trying to sync with a master and
+    reads new transactions faster than writing them to the WAL.
+
+    .. NOTE::
+
+        You might consider increasing the ``wal_queue_max_size`` value in case of
+        large tuples (approximately one megabyte or larger).
+
+    | Type: number
+    | Default: 16777216 bytes
+    | Environment variable: TT_WAL_QUEUE_MAX_SIZE
+    | Dynamic: **yes**

doc/reference/configuration/index.rst

@@ -175,7 +175,7 @@ You can do this in different ways:
         box.cfg { listen = "127.0.0.1:3301?p1=value1&p2=value2, /unix.sock?p3=value3" }
 
 *   Using the ``params`` table: a URI is passed in a table with additional parameters in the "params" table.
-    Parameters in the "params" table overwrite the ones from a URI string ("value2" overwries "value1" for ``p1`` in the example below).
+    Parameters in the "params" table overwrite the ones from a URI string ("value2" overwrites "value1" for ``p1`` in the example below).
 
     ..  code-block:: lua
 

doc/reference/reference_lua/swim.rst

@@ -1274,7 +1274,7 @@ Keys in the meta section are:
     message originator (can differ from
   * SWIM_META_SRC_ADDRESS and from SWIM_META_SRC_ADDRESS_PORT);
   * SWIM_ROUTE_DST_ADDRESS and SWIM_ROUTE_DST_PORT (destination
-    IP address and port, for the the message's final destination).
+    IP address and port, for the message's final destination).
 
   If a message was sent indirectly with the help of SWIM_META_ROUTING,
   then the reply should be sent back by the same route.

doc/reference/reference_sql/sql_statements_and_clauses.rst

@@ -3961,7 +3961,7 @@ columns have the collation specified by ``CREATE TABLE``.
 
 In other words, to pick a collation, Tarantool uses: |br|
 the first ``COLLATE`` clause in an expression if it was specified, |br|
-else the the column's ``COLLATE`` clause if it was specified, |br|
+else the column's ``COLLATE`` clause if it was specified, |br|
 else ``"binary"``.
 
 However, for searches and sometimes for sorting, the collation may be an index's collation,