--- metadata: - name: generator content: Diplodoc Platform v5.56.0 alternate: - https://ydb.tech/docs/en/maintenance/manual/blobdepot_decommit.md - https://ydb.tech/docs/ru/maintenance/manual/blobdepot_decommit.md - href: ru/maintenance/manual/blobdepot_decommit.md type: text/markdown title: Markdown version - href: ../../llms.txt type: text/markdown title: llms.txt sourcePath: ru/core/maintenance/manual/blobdepot_decommit.md --- > **Documentation Index:** Fetch the complete configuration index at https://ydb.tech/docs/ru/llms.txt # Декомиссия групп Физические группы являются ценным ресурсом в кластере: группы можно создавать, но их нельзя удалять без удаления использующей их базы, поскольку нет механизма гарантированного вытеснения данных таблеток из группы. При этом количество физических групп определяется размером кластера, а группы нельзя переносить из пула одного тенанта в пул другого из-за использования разных ключей шифрования для разных тенантов. Это может привести к тому, что для создания новой группы с целью расширения существующей или создания новой БД не хватает ресурсов, а удалить старую группу, чтобы освободить ресурсы, тоже нельзя, поскольку в ней могут быть данные. Чтобы решить эту проблему, можно завести виртуальную группу с каналами поверх оставшихся групп пула, скопировать в неё данные из физической группы, а затем освободить ресурсы, которые занимает физическая группа. Эту задачу решает процесс декомиссии групп. Декомиссия группы позволяет удалить избыточные VDisk'и с PDisk'ов, сохраняя при этом данные этой группы. Реализован такой режим через создание блобовницы, которая начинает обслуживать декомиссуемую группу вместо DS proxy. Параллельно с этим блобовница копирует данные из физической декомиссуемой группы. Как только все данные будут скопированы, физические VDisk'и удаляются и ресурсы освобождаются, при этом все данные декомиссованной группы распределяются по другим группам. Процесс декомиссии полностью прозрачен для таблеток и пользователя и состоит из нескольких этапов: 1. Создание таблетки блобовницы и распространение конфигурации группы с целью блокировки записи на диски физической группы. 2. Копирование метаданных блокировок из физической группы. После этого момента декомиссуемая группа становится доступной для работы. До момента копирования блокировок работа с группой невозможна. Однако этот процесс занимает очень короткий промежуток времени, поэтому практически незаметен для клиента. Запросы, приходящие в этот момент, встают в очередь и ждут завершения этапа. 3. Копирование метаданных барьеров из физической группы. 4. Копирование метаданных блобов из физической группы. 5. Копирование данных блобов из физической группы. 6. Удаление VDisk'ов физической группы. Стоит ещё раз заметить, что с момента блокировки записи в физическую группу и до момента считывания всех блокировок работа с группой приостанавливается. Время приостановки в условиях штатной работы составляет доли секунды. ## Как запускать Для запуска декомиссии выполняется команда BS\_CONTROLLER, в которой нужно указать список декомиссуемых групп, а также номер таблетки Hive, которая будет управлять блобовницами декомиссуемых групп. Также можно указать список пулов, в которых блобовница будет хранить свои данные. Если этот список не указан, то BS\_CONTROLLER автоматически выбирает для хранения данных те же пулы, в которых располагаются декомиссуемые группы, а число каналов данных делается равным числу физических групп в этих пулах (но не более 250 штук). ```bash dstool -e ... --direct group decommit --group-ids 2181038080 --database=/Root/db1 --wait ``` Параметры командной строки: * --wait дождаться запуска декомиссии; в случае возникновения ошибки запуска ошибка выводится на экран, декомиссия отменяется автоматически (только при указании этой опции); * --group-ids GROUP\_ID GROUP\_ID список групп, для которых можно провести декомиссию; * --database=DB указать тенант, в котором нужно делать декомиссию (или домен, если декомиссия делается для групп внутри домена); * --log-channel-sp=POOL\_NAME название пула, в котором будет размещён канал 0 таблетки блобовницы; * --snapshot-channel-sp=POOL\_NAME название пула, в котором будет размещён кана 1 таблетки блобовницы; если не указан, то используется значение из --log-channel-sp; * --data-channel-sp=POOL\_NAME[\*COUNT] название пула, в котором размещаются каналы данных; если указан параметр COUNT (после знака "звёздочка"), то создаётся COUNT каналов данных в указанном пуле. Если ни --log-channel-sp, ни --snapshot-channel-sp, ни --data-channel-sp не указаны, то автоматически находится storage pool, которому принадлежит декомиссуемая группа, и в нём заводится нулевой и первый канал блобовницы, а также N каналов данных, где N — число оставшихся физических групп в этом пуле. ## Как проверить, что всё запустилось {#decommit-check-running} Посмотреть результат декомиссии можно аналогично созданию виртуальных групп. Для декомиссуемых групп появляется дополнительное поле DecommitStatus, которое может принимать одно из следующих значений: * NONE — декомиссия для указанной группы не производится; * PENDING — ожидается декомиссия группы, но ещё не выполняется (создаётся блобовница); * IN\_PROGRESS — производится декомиссия группы (все записи уже попадают в блобовницу, чтения — в блобовницу и в старую группу); * DONE — декомиссия завершена полностью. ```bash $ dstool --cluster=$CLUSTER --direct group list --virtual-groups-only ┌────────────┬──────────────┬───────────────┬────────────┬────────────────┬─────────────────┬──────────────┬───────────────────┬──────────────────┬───────────────────┬─────────────┬────────────────┐ │ GroupId │ BoxId:PoolId │ PoolName │ Generation │ ErasureSpecies │ OperatingStatus │ VDisks_TOTAL │ VirtualGroupState │ VirtualGroupName │ BlobDepotId │ ErrorReason │ DecommitStatus │ ├────────────┼──────────────┼───────────────┼────────────┼────────────────┼─────────────────┼──────────────┼───────────────────┼──────────────────┼───────────────────┼─────────────┼────────────────┤ │ 2181038080 │ [1:1] │ /Root:ssd │ 2 │ block-4-2 │ FULL │ 8 │ WORKING │ │ 72075186224038160 │ │ IN_PROGRESS │ │ 2181038081 │ [1:1] │ /Root:ssd │ 2 │ block-4-2 │ FULL │ 8 │ WORKING │ │ 72075186224038161 │ │ IN_PROGRESS │ │ 4261412864 │ [1:2] │ /Root:virtual │ 0 │ none │ DISINTEGRATED │ 0 │ WORKING │ vg1 │ 72075186224037888 │ │ NONE │ │ 4261412865 │ [1:2] │ /Root:virtual │ 0 │ none │ DISINTEGRATED │ 0 │ WORKING │ vg2 │ 72075186224037890 │ │ NONE │ │ 4261412866 │ [1:2] │ /Root:virtual │ 0 │ none │ DISINTEGRATED │ 0 │ WORKING │ vg3 │ 72075186224037889 │ │ NONE │ │ 4261412867 │ [1:2] │ /Root:virtual │ 0 │ none │ DISINTEGRATED │ 0 │ WORKING │ vg4 │ 72075186224037891 │ │ NONE │ └────────────┴──────────────┴───────────────┴────────────┴────────────────┴─────────────────┴──────────────┴───────────────────┴──────────────────┴───────────────────┴─────────────┴────────────────┘ ``` ## Как оценить прогресс {#decommit-progress} Для оценки времени и прогресса декомиссии предусмотрены графики, по которым можно понять: * идёт ли декомиссия (Decommit/GetBytes); * проходит ли запись данных (Decommit/PutOkBytes); * сколько данных осталось декомиссовать (BytesToDecommit). Если всё выполняется успешно, то скорость Decommit/GetBytes примерно соответствует Decommit/PutOkBytes. Несущественные расхождения допустимы вследствие того, что декомиссуемые данные могут устаревать и удаляться таблеткой, которая хранит данные в ней. Для оценки оставшегося времени декомиссии достаточно разделить BytesToDecommit на среднюю скорость Decommit/PutOkBytes.