Skip to content
Merged
Changes from 9 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
161 changes: 160 additions & 1 deletion doc/reference/configuration/configuration_reference.rst
Original file line number Diff line number Diff line change
Expand Up @@ -3543,7 +3543,7 @@ replication
The ``replication`` section defines configuration parameters related to :ref:`replication <replication>`.

- :ref:`replication.anon <configuration_reference_replication_anon>`
- :ref:`replication.anon <configuration_reference_replication_autoexpel>`
- :ref:`replication.autoexpel <configuration_reference_replication_autoexpel>`
- :ref:`replication.bootstrap_strategy <configuration_reference_replication_bootstrap_strategy>`
- :ref:`replication.connect_timeout <configuration_reference_replication_connect_timeout>`
- :ref:`replication.election_mode <configuration_reference_replication_election_mode>`
Expand Down Expand Up @@ -3599,6 +3599,165 @@ The ``replication`` section defines configuration parameters related to :ref:`re
| Default: ``false``
| Environment variable: TT_REPLICATION_ANON

.. _configuration_reference_replication_autoexpel:

.. confval:: replication.autoexpel

The ``replication.autoexpel`` option designed for managing dynamic clusters using YAML-based configurations.
It enables the automatic expulsion of instances that are removed from the YAML configuration.

Only instances with names that match the specified prefix are considered for expulsion; all others are excluded.
Additionally, instances without a persistent name are ignored.

If an instance is in read-write mode and has the latest database schema, it initiates the expulsion of instances that:

- Match the specified prefix
- Absent from the updated YAML configuration

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.

New instances

``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.

.. NOTE::
The ``replication.autoexpel`` option governs the expelling process and is configurable at the replicaset, group, and
global levels. It is not applicable at the instance level.

Configuration fields

- ``enabled`` (boolean, default: ``false``): enables or disables the ``autoexpel`` logic.

- ``by`` (string, default: ``nil``): specifies the ``autoexpel`` criterion. Currently, only ``prefix`` is supported and must be explicitly set.

- ``prefix`` (string, default: ``nil``): defines the pattern for instance names that are considered part of the cluster.

**Example Patterns**:

- If instances are prefixed with the replicaset name, set:
``prefix: '{{ replicaset_name }}'``

- For instances matching a specific pattern (e.g., `i-\d\d\d`), set:
``prefix: 'i-'``

**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.

|
| Type: boolean
| Default: false
| Environment variable:
| TT_REPLICATION_AUTOEXPEL_BY
| TT_REPLICATION_AUTOEXPEL_ENABLED
| TT_REPLICATION_AUTOEXPEL_PREFIX


.. _configuration_reference_replication_bootstrap_strategy:

.. confval:: replication.bootstrap_strategy
Expand Down
Loading