--- metadata: - name: generator content: Diplodoc Platform v5.52.0 alternate: - https://ydb.tech/docs/ru/maintenance/manual/virtual_storage_groups_decommit.md?version=v25.3 - href: ru/maintenance/manual/virtual_storage_groups_decommit.md type: text/markdown title: Markdown version - href: ../../llms.txt type: text/markdown title: llms.txt sourcePath: ru/core/maintenance/manual/virtual_storage_groups_decommit.md --- > **Documentation Index:** Fetch the complete configuration index at https://ydb.tech/docs/ru/llms.txt # Декомиссия групп с использованием виртуальных групп {% note alert %} Операция декомиссии является крайне опасной и может привести к необратимой потере данных. Перед выполнением декомиссии **обязательно** создайте резервную копию всех данных кластера. {% endnote %} {% note alert %} Возможность откатить декомиссию группы хранения находится в разработке. В данный момент операция необратима. Рекомендуется использовать декомиссию только в исключительных случаях, когда требуется разово освободить ресурсы. {% endnote %} ## Описание работы Физические [группы хранения](https://ydb.tech/docs/ru/concepts/glossary.md?version=v25.3#storage-group) являются ограниченным ресурсом в [кластере](https://ydb.tech/docs/ru/concepts/glossary.md?version=v25.3#cluster): их количество определяется размером кластера, и их нельзя удалить, пока в них хранятся данные. Это может привести к ситуации, когда для создания новой [базы данных](https://ydb.tech/docs/ru/concepts/glossary.md?version=v25.3#database) или расширения существующей не хватает групп, а освободить пространство на физических дисках нельзя, поскольку старые группы содержат данные. Рассмотрим пример: в базе данных используется 10 групп хранения. Каждая из этих групп содержит некоторый объём пользовательских данных, но при этом заполнены они только на 5%. Пропускная способность также используется не полностью. В результате все группы формально заняты, и при попытке создать новую базу данных новая группа хранения не может быть выделена — свободных [слотов](https://ydb.tech/docs/ru/concepts/glossary.md?version=v25.3#slot) на [PDisk](https://ydb.tech/docs/ru/concepts/glossary.md?version=v25.3#pdisk) больше нет. При этом существующие группы используются неэффективно. ![before-decommit](./_assets/storage_groups_before.png) В такой ситуации возникает задача освободить часть групп хранения (декомиссовать их) у текущей базы данных, чтобы вернуть их в пул доступных ресурсов для последующего использования. Для решения этой задачи применяется механизм декомиссии групп хранения. В рамках этого механизма для исходной физической группы создаётся одна новая [виртуальная группа хранения](https://ydb.tech/docs/ru/concepts/glossary.md?version=v25.3#virtual-storage-groups), которая заменяет эту физическую группу. После выполнения операции система переходит в следующее состояние: - Исходная физическая группа хранения заменяется на виртуальную - Данные копируются из исходной группы в оставшиеся физические группы кластера (увеличивая их заполненность) - Виртуальная группа хранит данные в оставшихся физических группах кластера - Ресурсы, используемые исходной группой, освобождаются ([VDisk'и](https://ydb.tech/docs/ru/concepts/glossary.md?version=v25.3#vdisk) удаляются, [слоты PDisk'ов](https://ydb.tech/docs/ru/concepts/glossary.md?version=v25.3#slot) освобождаются) ![after-decommit](./_assets/storage_group_after_decomm.png) ## Этапы процесса декомиссии {% note info %} Во время декомиссии доступ к данным сохраняется — пользователи могут читать и записывать данные, как обычно. Все перемещения данных происходят в фоновом режиме параллельно с основной работой приложения. Стоит отметить, что во во время декомиссии все же создается повышенная нагрузка на систему хранения. {% endnote %} **В дальнейшем под исходной физической группой будем подразумевать группу, над которой проходит процесс декомиссии.** ### Инициализация виртуальной группы хранения и блокировка записи в исходную физическую группу **Что происходит:** - Создается виртуальная группа - Блокируется запись новых данных в исходную физическую группу - Все новые записи начинают идти в виртуальную группу **Статус:** `DecommitStatus: PENDING` → `IN_PROGRESS` **Время:** Обычно доли секунды ### Копирование метаданных **Что происходит:** - Копируются метаданные всех блобов (информация о том, какие данные есть, но не сами данные) из исходной физической группы в оставшиеся физические группы хранения **Статус:** `DecommitStatus: IN_PROGRESS` **Время:** Обычно секунды ### Копирование данных **Что происходит:** - Читаются данные из исходной физической группы - Записываются в оставшиеся физические группы кластера, через виртуальную группу - Данные распределяются по нескольким группам для балансировки **Статус:** `DecommitStatus: IN_PROGRESS` **Время:** Зависит от объема данных (могут быть часы для больших групп) ### Освобождение ресурсов исходной физической группы **Что происходит:** - Все данные скопированы - Удаляется исходная физическая группа и её VDisk'и - Освобождаются ресурсы [PDisk](https://ydb.tech/docs/ru/concepts/glossary.md?version=v25.3#pdisk) - Группа помечается как декомиссированная **Статус:** `DecommitStatus: IN_PROGRESS` → `DONE` **Время:** Минуты (удаление VDisk) ## Предварительные требования Инструкция по декомиссии групп работает при выполнении следующих условий: 1. Развернутый [кластер](https://ydb.tech/docs/ru/concepts/glossary.md?version=v25.3#cluster) YDB. Инструкции по развертыванию доступны в разделе [Первоначальное развёртывание](https://ydb.tech/docs/ru/devops/deployment-options/manual/initial-deployment/index.md?version=v25.3). 2. Установленная утилита `ydb-dstool`. Инструкции по установке доступны в [документации по установке YDB DSTool](https://ydb.tech/docs/ru/reference/ydb-dstool/install.md?version=v25.3). 3. Сгенерированный токен аутентификации для доступа к кластеру: ```bash ydb -e grpc:// -d --user auth get-token -f > ~/ydb_token ``` Замените `` на адрес вашего кластера, `` - путь к базе данных, `` на имя пользователя для авторизации. {% note info %} Декомиссию можно проводить даже на пустом кластере, наличие данных не обязательно. Однако если в кластере есть данные, это позволит проверить их консистентность после декомиссии. При необходимости можно загрузить тестовые данные с помощью утилиты `ydb workload tpcc`: ```bash ydb workload tpcc --path tpcc/10wh init -w 100 ydb workload tpcc --path tpcc/10wh import -w 100 ``` И запустить тест TPC-C до и после декомиссии: ```bash ydb workload tpcc --path tpcc/10wh run -w 100 ``` Подробнее о работе с тестовой нагрузкой в [документации по ydb workload tpcc](https://ydb.tech/docs/ru/reference/ydb-cli/workload-tpcc.md?version=v25.3). {% endnote %} ## Запуск декомиссии ### Выбор группы для декомиссии Перед запуском декомиссии необходимо выбрать группу (group ID), которую вы хотите вывести из эксплуатации. Выбирать можно любую группу, однако рекомендуется выбирать менее занятую группу — это поможет завершить процесс декомиссии быстрее. Это можно сделать через веб-интерфейс кластера или с помощью CLI: {% list tabs %} - UI (Веб-интерфейс) 1. Откройте веб-интерфейс управления кластером `https://:8765` 2. Откройте вкладку `Storage` 3. Выберите нужную вам группу и сохраните `Group ID` - CLI 1. Выполните команду получения списка групп хранения ```bash ydb-dstool -e \ --ca-file \ --token-file ~/ydb_token \ group list ``` 2. В выводе команды найдите нужную группу и сохраните её `Group ID`. {% endlist %} ### Команда для запуска Для запуска декомиссии выполните команду `ydb-dstool` с параметром `group decommit`, она автоматически создаст виртуальную группу и начнёт процесс декомиссии: ```bash ydb-dstool -e grpcs://:2135 \ --ca-file \ --token-file ~/ydb_token \ group decommit \ --group-ids \ --database /Root/ \ --wait ``` ### Параметры команды * `-e ` — адрес кластера (например, `grpcs://static-node-1.ydb-cluster.com:2135`); * `--ca-file ` — путь к файлу сертификата CA для TLS-соединения; * `--token-file ` — путь к файлу с токеном аутентификации; * `--group-ids ` — идентификатор группы для декомиссии (можно указать несколько групп через пробел); * `--database=` — путь к [базе данных](https://ydb.tech/docs/ru/concepts/glossary.md?version=v25.3#database) или домену, в котором выполняется декомиссия (например, `/Root/database`); * `--wait` — дождаться запуска декомиссии; в случае возникновения ошибки запуска ошибка выводится на экран, декомиссия отменяется автоматически (только при указании этой опции). ### Пример команды ```bash ydb-dstool -e grpcs://static-node-1.ydb-cluster.com:2135 \ --ca-file /home/ubuntu/ansible-11-nov-244/3-nodes-mirror-3-dc/files/TLS/certs/ca.crt \ --token-file ~/ydb_token \ group decommit \ --group-ids 2181038081 \ --database=/Root/database \ --wait ``` ## Проверка статуса декомиссии После запуска декомиссии можно проверить её статус с помощью команды: ```bash ydb-dstool -e grpcs://:2135 \ --ca-file \ --token-file ~/ydb_token \ group list --columns GroupId PoolName \ ErasureSpecies OperatingStatus VDisks_TOTAL BlobDepotId DecommitStatus ``` В выводе команды для групп, для которых была начата процедура декомиссии, появляется дополнительное поле `DecommitStatus`, которое может принимать одно из следующих значений: * `NONE` — декомиссия для указанной группы не производится; * `PENDING` — ожидается декомиссия группы, но ещё не выполняется (создаётся виртуальная группа); * `IN_PROGRESS` — производится декомиссия группы (все записи уже попадают в виртуальную группу, чтения — в виртуальную группу и в старую группу); * `DONE` — декомиссия завершена полностью (физическая группа превратилась в виртуальную). ### Пример вывода команды ```text ┌────────────┬────────────────────┬────────────────┬─────────────────┬──────────────┬───────────────────┬────────────────┐ │ GroupId │ PoolName │ ErasureSpecies │ OperatingStatus │ VDisks_TOTAL │ BlobDepotId │ DecommitStatus │ ├────────────┼────────────────────┼────────────────┼─────────────────┼──────────────┼───────────────────┼────────────────┤ │ 2181038080 │ /Root/database:ssd │ mirror-3-dc │ FULL │ 9 │ 0 │ NONE │ │ 2181038081 │ /Root/database:ssd │ mirror-3-dc │ FULL │ 0 │ 72075186224038889 │ DONE │ │ 2181038082 │ /Root/database:ssd │ mirror-3-dc │ FULL │ 9 │ 0 │ NONE │ │ 2181038083 │ /Root/database:ssd │ mirror-3-dc │ FULL │ 9 │ 0 │ NONE │ │ 2181038084 │ /Root/database:ssd │ mirror-3-dc │ FULL │ 9 │ 0 │ NONE │ │ 2181038085 │ /Root/database:ssd │ mirror-3-dc │ FULL │ 9 │ 0 │ NONE │ │ 2181038086 │ /Root/database:ssd │ mirror-3-dc │ FULL │ 9 │ 0 │ NONE │ │ 2181038087 │ /Root/database:ssd │ mirror-3-dc │ FULL │ 9 │ 0 │ NONE │ └────────────┴────────────────────┴────────────────┴─────────────────┴──────────────┴───────────────────┴────────────────┘ ``` Обратите внимание, что в приведённом выше примере вывода для группы `2181038081` изменилось количество VDisks (оно стало равно 0), появилась id виртуальной группы в поле `BlobDepotId`, а статус декомиссии (`DecommitStatus`) изменился на `DONE`. Это отражает успешное завершение процедуры декомиссии для данной группы.