Merge branch 'latest' into gh-4575-rep-queue-max-size

Author: maryiaLichko

doc/reference/configuration/configuration_reference.rst

@@ -3619,13 +3619,6 @@ The ``replication`` section defines configuration parameters related to :ref:`re
 
     The expulsion process follows the standard procedure, involving the removal of the instance from the ``_cluster`` system space.
 
-    The ``autoexpel`` logic is activated during specific events:
-
-	- **Startup**. When the cluster starts, ``autoexpel`` checks and removes instances not matching the updated configuration.
-	- **Reconfiguration**. When the YAML configuration is reloaded, ``autoexpel`` compares the current state to the updated configuration and performs necessary expulsions.
-	- ``box.status`` **watcher event**. Changes detected by the ``box.status`` watcher also trigger the ``autoexpel`` mechanism.
-
-
     ``autoexpel`` does not take any actions on newly joined instances unless one of the triggering events occurs.
     This means that an instance meeting the ``autoexpel`` criterion can still join the cluster, but it may be removed
     later during reconfiguration or on subsequent triggering events.
@@ -3635,7 +3628,7 @@ The ``replication`` section defines configuration parameters related to :ref:`re
         global levels. It is not applicable at the instance level.
 
 
-    Configuration fields
+    **Configuration fields**
 
     - ``by`` (string, default: ``nil``): specifies the ``autoexpel`` criterion. Currently, only ``prefix`` is supported and must be explicitly set.
 
@@ -3645,7 +3638,8 @@ The ``replication`` section defines configuration parameters related to :ref:`re
 
 
 
-replication.autoexpel_by.*
+
+replication.autoexpel.by
 ~~~~~~~~~~~~~
 
     ``replication.autoexpel_by`` purpose is to define the criterion used for determining which instances in a cluster are
@@ -3655,15 +3649,16 @@ replication.autoexpel_by.*
 
     - Instances that are part of the cluster and should adhere to the YAML configuration.
 
-	- Instances or tools (e.g., CDC tools) that use the replication channel but are not part of the cluster configuration.
+    - Instances or tools (e.g., CDC tools) that use the replication channel but are not part of the cluster configuration.
 
 
-    The default value of by is ``nil``, meaning no ``autoexpel`` criterion is applied unless explicitly set.
+    The default value of ``by`` is ``nil``, meaning no ``autoexpel`` criterion is applied unless explicitly set.
 
     Currently, the only supported value for by is ``prefix``. The ``prefix`` value instructs the system to identify instances
     based on their names, matching them against a prefix pattern defined in the configuration.
 
-    If the ``autoexpel`` feature is enabled (``enabled: true``), the ``by`` field must be explicitly set to ``prefix``.
+
+    If the ``autoexpel`` feature is enabled, the ``by`` field must be explicitly set to ``prefix``.
 
     The absence of this field or an unsupported value will result in configuration errors.
 
@@ -3682,7 +3677,8 @@ replication.autoexpel_by.*
 
 
 
-replication.autoexpel_enabled.*
+
+replication.autoexpel.enabled
 ~~~~~~~~~~~~~
 
     The ``replication.autoexpel_enabled`` field is a boolean configuration option that determines whether the autoexpel logic is active for the cluster.
@@ -3692,8 +3688,9 @@ replication.autoexpel_enabled.*
 
         By default, the ``enabled`` field is set to ``false``, meaning the ``autoexpel`` logic is turned off. This ensures that no instances are automatically removed unless explicitly configured.
 
-    Enabling ``autoexpel`` logic
 
+    **Enabling ``autoexpel`` logic**
+    
     To enable ``autoexpel``, you should set enabled to true in the ``replication.autoexpel`` section of your YAML configuration:
 
     .. code-block:: yaml
@@ -3708,7 +3705,8 @@ replication.autoexpel_enabled.*
     To disable ``autoexpel``, set enabled to ``false``.
 
 
-    Dependencies
+
+    **Dependencies**
 
     If ``enabled`` is set to ``true``, the following fields are required:
 
@@ -3723,8 +3721,8 @@ replication.autoexpel_enabled.*
     | Environment variable: TT_REPLICATION_AUTOEXPEL_ENABLED
 
 
-replication.autoexpel_prefix.*
-~~~~~~~~~~~~~
+
+replication.autoexpel.prefix
 
     The ``prefix`` field filters instances for expulsion by differentiating cluster instances (from the YAML configuration) from external services (e.g., CDC tools). Only instances matching the prefix are considered.
 
@@ -3754,7 +3752,8 @@ replication.autoexpel_prefix.*
 
     In this setup:
 
-	- Instances are grouped by replicaset names (e.g., ``r-001-i-001`` for ``replicaset r-001``).
+	- Instances are prefixed with a replicaset name (e.g., ``r-001-i-001`` for replicaset ``r-001``).
+  
 	- The prefix ensures that only instances with names matching the replicaset name are auto expelled when removed from the configuration.
 
 
@@ -3779,111 +3778,6 @@ replication.autoexpel_prefix.*
     | Environment variable: TT_REPLICATION_AUTOEXPEL_PREFIX
 
 
-
-autoexpel full example
-~~~~~~~~~~~~~
-
-    1. Create a ``config.yaml`` file with the following content:
-
-    .. code-block:: yaml
-
-        credentials:
-          users:
-            guest:
-              roles: [super]
-
-        replication:
-          failover: manual
-          autoexpel:
-            enabled: true
-            by: prefix
-            prefix: '{{ replicaset_name }}'
-
-        iproto:
-          listen:
-            - uri: 'unix/:./var/run/{{ instance_name }}.iproto'
-
-        groups:
-          g-001:
-            replicasets:
-              r-001:
-                leader: r-001-i-001
-                instances:
-                  r-001-i-001: {}
-                  r-001-i-002: {}
-                  r-001-i-003: {}
-
-
-    This configuration:
-	- Sets up authentication with a guest user assigned the super role.
-	- Enables the ``autoexpel`` option to automatically expel instances not present in the YAML file.
-	- Defines instance names based on a prefix pattern: ``{{ replicaset_name }}``.
-	- Lists three instances: ``r-001-i-001``, ``r-001-i-002``, and ``r-001-i-003``.
-
-
-    2. Open terminal window and start three instances using the following commands:
-
-    .. code-block:: lua
-
-        tarantool --name r-001-i-001 --config config.yaml -i
-
-
-    .. code-block:: lua
-
-        tarantool --name r-001-i-002 --config config.yaml -i
-
-
-    .. code-block:: lua
-
-        tarantool --name r-001-i-003 --config config.yaml -i
-
-    3. Edit ``config.yaml`` and remove the following entry for ``r-001-i-003``:
-
-    .. code-block:: lua
-        r-001-i-003: {}
-
-
-    The updated ``config.yaml`` should look like this:
-
-    .. code-block:: yaml
-
-        groups:
-          g-001:
-            replicasets:
-              r-001:
-                leader: r-001-i-001
-                instances:
-                  r-001-i-001: {}
-                  r-001-i-002: {}
-
-    Save the file.
-
-    4. For the leader instance (``r-001-i-001``), check the ``_cluster`` space:
-
-    .. hint::
-
-        The ``_cluster`` system space in Tarantool stores metadata about all instances currently recognized as part of the cluster.
-        It shows which instances are registered and active.
-
-    You should see ``r-001-i-003`` still listed in the ``_cluster`` system space.
-
-    5. Reload the configuration:
-
-    .. code-block:: lua
-
-        config = require('config')
-        config:reload()
-
-    6. Verify the changes:
-
-    .. code-block:: lua
-
-        box.space._cluster:fselect()
-
-    After the reload, ``r-001-i-003`` should no longer appear in the ``_cluster`` system space.
-
-
-
 .. _configuration_reference_replication_bootstrap_strategy:
 
 .. confval:: replication.bootstrap_strategy