Document the 'wal_cleanup_delay' option (#3350)

Document the 'wal_cleanup_delay' option.

Resolves #2022

Author: andreyaksenov

doc/reference/configuration/cfg_binary_logging_snapshots.rst

@@ -4,6 +4,7 @@
 * :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>`
+* :ref:`wal_cleanup_delay <cfg_binary_logging_snapshots-wal_cleanup_delay>`
 
 .. _cfg_binary_logging_snapshots-force_recovery:
 
@@ -111,3 +112,28 @@
     | Default: 16777216 bytes
     | Environment variable: TT_WAL_QUEUE_MAX_SIZE
     | Dynamic: **yes**
+
+.. _cfg_binary_logging_snapshots-wal_cleanup_delay:
+
+.. confval:: wal_cleanup_delay
+
+    Since version :doc:`2.6.3 </release/2.6.3>`.
+    The delay (in seconds) used to prevent the :ref:`Tarantool garbage collector <cfg_checkpoint_daemon-garbage-collector>`
+    from immediately removing :ref:`write-ahead log<internals-wal>` files after a node restart.
+    This delay eliminates possible erroneous situations when the master deletes WALs
+    needed by :ref:`replicas <replication-roles>` after restart.
+    As a consequence, replicas sync with the master faster after its restart and
+    don't need to download all the data again.
+
+    Once all the nodes in the replica set are up and running,
+    automatic cleanup is started again even if ``wal_cleanup_delay`` has not expired.
+
+    .. NOTE::
+
+        The ``wal_cleanup_delay`` option has no effect on nodes running as
+        :ref:`anonymous replicas<cfg_replication-replication_anon>`.
+
+    | Type: number
+    | Default: 14400 seconds
+    | Environment variable: TT_WAL_CLEANUP_DELAY
+    | Dynamic: **yes**