Apply review suggestions

Author: xuniq

doc/concepts/configuration/configuration_persistence.rst

@@ -41,7 +41,8 @@ that takes a new snapshot every ``snapshot.by.interval`` seconds.
 If the ``snapshot.by.interval`` option is set to zero, the checkpoint daemon is disabled.
 
 The ``snapshot.by.wal_size`` option defines the maximum size in bytes for of all WAL files created since the last snapshot taken.
-Once this size is exceeded, the checkpoint daemon takes a snapshot and deletes the old WAL files.
+Once this size is exceeded, the checkpoint daemon takes a snapshot. Then, :ref:`Tarantool garbage collector <configuration_persistence_garbage_collector>`
+deletes the old WAL files.
 
 The example shows how to specify the ``snapshot.by.interval`` and the ``snapshot.by.wal_size`` options:
 
@@ -51,25 +52,6 @@ The example shows how to specify the ``snapshot.by.interval`` and the ``snapshot
     :end-at: 1000000000000000000
     :dedent:
 
-..  _configuration_persistence_snapshot_count:
-
-Configure a maximum number of stored snapshots
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-You can set a limit on the number of snapshots stored in the :ref:`snapshot.dir <configuration_reference_snapshot_dir>`
-directory using the :ref:`snapshot.count <configuration_reference_snapshot_count>` option.
-When the number of snapshots in the directory reaches the limit,
-the checkpoint daemon activates Tarantool garbage collector after the new snapshot is taken.
-Tarantool garbage collector deletes the oldest snapshot file and any associated WAL files, after the new snapshot is taken.
-
-..  literalinclude:: /code_snippets/snippets/config/instances.enabled/persistence_snapshot/config.yaml
-    :language: yaml
-    :start-at: count:
-    :end-at: 3
-    :dedent:
-
-If the ``snapshot.count`` option is set to zero, the checkpoint daemon does not delete old snapshots.
-
 ..  _configuration_persistence_snapshot_dir:
 
 Specify a directory for snapshot files
@@ -97,6 +79,28 @@ For example, you can place snapshots and write-ahead logs on different hard driv
       wal:
         dir: '/media/drive2/wals'
 
+..  _configuration_persistence_snapshot_count:
+
+Configure a maximum number of stored snapshots
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can set a limit on the number of snapshots stored in the :ref:`snapshot.dir <configuration_reference_snapshot_dir>`
+directory using the :ref:`snapshot.count <configuration_reference_snapshot_count>` option.
+Once the number of snapshots reaches the given limit, :ref:`Tarantool garbage collector <configuration_persistence_garbage_collector>`
+deletes the oldest snapshot file and any associated WAL files after the new snapshot is taken.
+
+..  literalinclude:: /code_snippets/snippets/config/instances.enabled/persistence_snapshot/config.yaml
+    :language: yaml
+    :start-at: count:
+    :end-at: 7200
+    :dedent:
+
+In the example, the snapshot is created every two hours (every 7200 seconds) until there are three snapshots in the
+``snapshot.dir`` directory.
+After creating a new snapshot (the fourth one), the oldest snapshot and the corresponding WALs are deleted.
+
+If the ``snapshot.count`` option is set to zero, the garbage collector does not delete old snapshots.
+
 ..  _configuration_persistence_wal:
 
 Configure the write-ahead log
@@ -111,8 +115,15 @@ This section describes how to define WAL settings in the :ref:`wal <configuratio
 Set the WAL mode
 ~~~~~~~~~~~~~~~~
 
-To be able to recover data in case of a possible instance restart, enable recording to the write-ahead log.
-To do it, set the :ref:`wal.mode <configuration_reference_wal_mode>` configuration option to ``write`` or ``fsync``.
+The recording to the write-ahead log is enabled by default.
+It means that if an instance restart occurs, the data will be recovered.
+The recording to the WAL can be configured using the :ref:`wal.mode <configuration_reference_wal_mode>` configuration option.
+
+There are two modes that enable writing to the WAL:
+
+*   ``write`` (default) -- enable WAL and write the data without waiting the data to be flushed to the storage device.
+*   ``fsync`` -- enable WAL and ensure that the record is written to the storage device.
+
 The example below shows how to specify the ``write`` WAL mode for ``instance001``:
 
 ..  literalinclude:: /code_snippets/snippets/config/instances.enabled/persistence_wal/config.yaml
@@ -121,9 +132,6 @@ The example below shows how to specify the ``write`` WAL mode for ``instance001`
     :end-at: 'write'
     :dedent:
 
-The ``write`` mode enables WAL and writes the data without waiting the data to be flushed to the storage device.
-The ``fsync`` mode enables WAL and ensures that the record is written to the storage device.
-
 To turn the WAL writer off, set the ``wal.mode`` option to ``none``.
 
 ..  _configuration_persistence_wal_dir:
@@ -177,7 +185,7 @@ Set a delay for the garbage collector
 
 In Tarantool, the :ref:`checkpoint daemon <configuration_persistence_checkpoint_daemon>`
 takes new snapshots at the given interval (see :ref:`snapshot.by.interval <configuration_reference_snapshot_by_interval>`).
-After an instance restart, the daemon activates the Tarantool garbage collector that deletes the old WAL files.
+After an instance restart, the Tarantool garbage collector deletes the old WAL files.
 
 To delay the immediate deletion of WAL files, use the :ref:`wal.cleanup_delay <configuration_reference_wal_cleanup_delay>`
 configuration option. The delay eliminates possible erroneous situations when the master deletes WALs
@@ -198,7 +206,7 @@ In the example, the delay is set to 5 hours (18000 seconds):
 Specify the WAL extensions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-In Tarantool Enterprise, you can store an old and new tuple for each crud operation performed.
+In Tarantool Enterprise, you can store an old and new tuple for each CRUD operation performed.
 The detailed description and examples of the WAL extensions are provided in the :ref:`WAL extensions <wal_extensions>` section.
 
 See also: :ref:`wal.ext.* <configuration_reference_wal_ext>` configuration options.
@@ -209,37 +217,49 @@ Checkpoint daemon
 -----------------
 
 The checkpoint daemon (snapshot daemon) is a constantly running :ref:`fiber <app-fibers>`.
-If the checkpoint daemon is enabled, it takes new :ref:`snapshot (.snap) files <index-box_persistence>` at the
-:ref:`given interval <configuration_reference_snapshot_by_interval>` automatically.
-If necessary, the checkpoint daemon also activates the Tarantool garbage collector that deletes old snapshot and WAL files.
+The checkpoint daemon creates a schedule for the periodic snapshot creation based on
+the :ref:`configuration options <configuration_reference_snapshot_by>`and the speed of file size growth.
+If enabled, the daemon makes new snapshots (.snap) files according to this schedule.
+
+The work of checkpoint daemon is based on the following configuration options:
+
+*   :ref:`snapshot.by.interval <configuration_reference_snapshot_by_interval>` -- a new snapshot is taken once in a given period.
+*   :ref:`snapshot.by.wal_size <configuration_reference_snapshot_by_wal_size>` -- a new snapshot is taken once the size
+    of all WAL files created since the last snapshot exceeds a given limit.
+
+If necessary, the checkpoint daemon also activates the :ref:`Tarantool garbage collector <configuration_persistence_garbage_collector>` that deletes old snapshot and WAL files.
 
 ..  _configuration_persistence_garbage_collector:
 
 Tarantool garbage collector
 ---------------------------
 
+Tarantool garbage collector can be activated by the :ref:`checkpoint daemon <configuration_persistence_checkpoint_daemon>`.
+The garbage collector tracks the snapshots that are to be :ref:`relayed to a replica <memtx-replication>` or needed
+by other consumers. When the files are no longer needed, Tarantool garbage collector deletes them.
+
 ..  NOTE::
 
-    The garbage collector  called by the checkpoint daemon, is distinct from the `Lua garbage collector <https://www.lua.org/manual/5.1/manual.html#2.10>`_
+    The garbage collector called by the checkpoint daemon, is distinct from the `Lua garbage collector <https://www.lua.org/manual/5.1/manual.html#2.10>`_
     which is for Lua objects, and distinct from the Tarantool garbage collector that specializes in :ref:`handling shard buckets <vshard-gc>`.
 
 This garbage collector is called as follows:
 
 *   When the number of snapshots reaches the limit of :ref:`snapshot.count <configuration_reference_snapshot_count>` size.
     After a new snapshot is taken, Tarantool garbage collector deletes the oldest snapshot file and any associated WAL files.
 
-*   When the size all WAL files created since the last snapshot reaches the limit of :ref:`snapshot.by.wal_size <configuration_reference_snapshot_by_wal_size>`.
+*   When the size of all WAL files created since the last snapshot reaches the limit of :ref:`snapshot.by.wal_size <configuration_reference_snapshot_by_wal_size>`.
     Once this size is exceeded, the checkpoint daemon takes a snapshot, then the garbage collector deletes the old WAL files.
 
-If the checkpoint daemon deletes an old snapshot file, the Tarantool garbage collector also deletes
+If an old snapshot filen is deleted, the Tarantool garbage collector also deletes
 any :ref:`write-ahead log (.xlog) <internals-wal>` files that meet the following conditions:
 
 *   The WAL files are older than the snapshot file.
 *   The WAL files contain information present in the snapshot file.
 
 Tarantool garbage collector also deletes obsolete vinyl ``.run`` files.
 
-The checkpoint daemon and the Tarantool garbage collector don't delete a file in the following cases:
+Tarantool garbage collector doesn't delete a file in the following cases:
 
 *   A **backup** is running, and the file has not been backed up
     (see :ref:`"Hot backup" <admin-backups-hot_backup_vinyl_memtx>`).

doc/reference/configuration/configuration_reference.rst

@@ -2451,8 +2451,8 @@ To learn more about the snapshots' configuration, check the :ref:`Persistence <c
 
     The maximum number of snapshots that are stored in the
     :ref:`snapshot.dir <configuration_reference_snapshot_dir>` directory
-    before the :ref:`checkpoint daemon <configuration_persistence_checkpoint_daemon>` deletes old snapshots.
-    If ``snapshot.count`` is set to zero zero, the checkpoint daemon
+    before the :ref:`Tarantool garbage collector <configuration_persistence_garbage_collector>` deletes old snapshots.
+    If ``snapshot.count`` is set to zero zero, the garbage collector
     does not delete old snapshots.
 
     Example:
@@ -2464,9 +2464,9 @@ To learn more about the snapshots' configuration, check the :ref:`Persistence <c
             interval: 7200
           count: 3
 
-    In the example, the checkpoint daemon creates a new snapshot every two hours until
-    it has created three snapshots. After that, it deletes the oldest snapshot
-    (and any associated write-ahead-log files) after creating a new one.
+    In the example, the checkpoint daemon creates a snapshot every two hours until
+    it has created three snapshots. After creating a new snapshot (the fourth one), the oldest snapshot
+    (and any associated write-ahead-log files) is deleted.
 
     ..  NOTE::
 
@@ -2639,6 +2639,7 @@ To learn more about the WAL configuration, check the :ref:`Persistence <configur
     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.