---
metadata:
  - name: generator
    content: Diplodoc Platform v5.50.4
alternate:
  - https://ydb.tech/docs/en/devops/configuration-management/configuration-v2/static-group-move.md
  - https://ydb.tech/docs/ru/devops/configuration-management/configuration-v2/static-group-move.md
sourcePath: ru/core/devops/configuration-management/configuration-v2/static-group-move.md
---
> **Documentation Index:** Fetch the complete configuration index at https://ydb.tech/docs/ru/llms.txt

# Перемещение статической группы

{% cut "Статья находится в разработке" %}

<!-- source: ru/devops/configuration-management/_includes/experimental_v2.md -->
{% note warning %}

Эта статья посвящена кластерам YDB, в которых используется [конфигурация V2](https://ydb.tech/docs/ru/devops/configuration-management/configuration-v2/index.md). Данный способ конфигурирования пока является экспериментальным и доступен только для версий YDB начиная с v25.1. Для использования в продакшене мы рекомендуем выбирать [конфигурацию V1](https://ydb.tech/docs/ru/devops/configuration-management/index.md) — она является основной и официально поддерживаемой для всех кластеров YDB.

{% endnote %}
<!-- endsource: ru/devops/configuration-management/_includes/experimental_v2.md -->

При использовании Конфигурации V2 управление статической группой остуществляется автоматически и механизм Self Heal выполнит реконфигурацию при выходе из строя одного узла статической группы.

При необхоидмости ручного управления конфигурацией статической группы, необходимо выключить автоматическое урпавление статисческой группой, получить текущую конфигурацию статической группы, внести изменения и применить измененную конфигурацию в качестве целевой конфигурации статической группы. Затем необходимо убрать целевую конфигурацию статической группы из файла конфигурации и включить автоматическое управление конфигурацией статической группы.

<!-- source: ru/devops/configuration-management/configuration-v1/_includes/warning-configuration-error.md -->
{% note warning %}

Неправильная последовательность действий или ошибка в конфигурации могут привести к недоступности кластера YDB.

{% endnote %}
<!-- endsource: ru/devops/configuration-management/configuration-v1/_includes/warning-configuration-error.md -->

В качестве примера рассмотрим кластер YDB, в котором на хосте с `node_id:1` сконфигурирован и запущен [статический узел](https://ydb.tech/docs/ru/devops/configuration-management/configuration-v2/config-settings.md#hosts). Этот узел обслуживает часть статической группы.

Фрагмент конфигурации статической группы:

```yaml
...
groups:
  ...
  rings:
    ...
    fail_domains:
    - vdisk_locations:
      - node_id: 1
        path: /dev/vda
        pdisk_category: SSD
    ...
...
```

Для замены `node_id:1` мы используем другой хост с развернутым на нем статическим узлом с `node_id:10`.

Чтобы переместить часть статической группы с хоста `node_id:1` на `node_id:10`:


1. Выключить автоматическое урпавление статисческой группой
2. Получить текущую конфигурацию статической группы
3. Внести изменения и применить измененную конфигурацию в качестве целевой конфигурации статической группы
    В конфигурационном файле `config.yaml` измените значение `node_id`, заменив идентификатор удаляемого хоста на идентификатор добавляемого:

    ```yaml
    ...
    groups:
      ...
      rings:
        ...
        fail_domains:
        - vdisk_locations:
          - node_id: 10
            path: /dev/vda
            pdisk_category: SSD
        ...
    ...
    ```

      Измените путь `path` и категорию `pdisk_category` диска, если на хосте с `node_id: 10` они отличаются.
4. Перейдите на страницу мониторинга Embedded UI и убедитесь, что VDisk статической группы появился на целевом физическом диске и реплицируется. Подробнее см. [Мониторинг статической группы](https://ydb.tech/docs/ru/reference/embedded-ui/ydb-monitoring.md#static-group).
5. Убрать целевую конфигурацию статической группы из файла конфигурации и включить автоматическое управление конфигурацией статической группы.

{% endcut %}