Последнее обновление 18 мая 2026 г.

Управление репликами данных

Этот документ предназначен для администраторов кластера. В нём описаны механизмы балансировки и восстановления реплик Apache Doris, приоритеты планирования, способы просмотра состояния реплик и основные приёмы работы при сбоях реплик или неравномерной нагрузке на кластер.

Начиная с версии 0.9.0, в Doris появилась оптимизированная стратегия управления репликами и расширенные средства просмотра их состояния. Этот документ поможет понять принципы планирования задач для реплик и быстро восстановить кластер при повреждении реплик, простое узлов или неравномерном использовании дисков.

О восстановлении и балансировке реплик таблиц с атрибутом Colocation см. Colocate Join.

Сценарии применения

Сценарий	Рекомендуемый раздел
Изучение принципов планирования задач для реплик	Восстановление реплик, Балансировка реплик
Просмотр общего состояния реплик кластера	Просмотр состояния реплик
Поиск проблемных реплик определённого Tablet	Проверка состояния на уровне Tablet
Ручное восстановление после отказа BE или диска	Практические рекомендации
Настройка скорости восстановления и балансировки или приостановка балансировки	Управление ресурсами, Связанные настройки
Неравномерная нагрузка на кластер или неравномерное использование дисков	Балансировка реплик

Терминология

Термин	Значение
Tablet	Логический шард таблицы Doris. Таблица состоит из нескольких шардов.
Реплика	Копия шарда. По умолчанию у шарда 3 реплики.
Исправная реплика	Реплика, у которой Backend работает, а набор версий полон.
TabletChecker (TC)	Постоянно работающий фоновый поток, который периодически сканирует все Tablet, проверяет их состояние и по результату решает, нужно ли передать Tablet в TabletScheduler.
TabletScheduler (TS)	Постоянно работающий фоновый поток, который обрабатывает Tablet, переданные TabletChecker для восстановления, а также выполняет балансировку реплик кластера.
TabletSchedCtx (TSC)	Объект, инкапсулирующий Tablet. Выбрав Tablet, TC оборачивает его в TSC и передаёт в TS.
Носитель данных	Носитель для хранения данных. Doris позволяет задавать разные типы носителей (SSD и HDD) на уровне партиций. Планирование задач для реплик выполняется отдельно для каждого типа носителя.

Общий процесс выглядит следующим образом:

              +--------+              +-----------+
              |  Meta  |              |  Backends |
              +---^----+              +------^----+
                  | |                        | 3. Send clone tasks
 1. Check tablets | |                        |
           +--------v------+        +-----------------+
           | TabletChecker +--------> TabletScheduler |
           +---------------+        +-----------------+
                   2. Waiting to be scheduled

На схеме выше показан упрощённый процесс: TabletChecker проверяет состояние Tablet и передаёт нуждающиеся в восстановлении Tablet в TabletScheduler, который отправляет задачи клонирования на BE.

Состояние реплик

По разным причинам состояние реплик одного Tablet может различаться. Doris пытается автоматически восстановить такие реплики, чтобы как можно быстрее вернуть кластер в рабочее состояние.

Состояние исправности реплики

Состояние	Значение
BAD	Реплика повреждена. Сюда относятся, в частности, невосстановимые повреждения из-за отказов диска, ошибок программного обеспечения и других причин.
VERSION_MISSING	Отсутствуют версии. Каждой партии загружаемых в Doris данных соответствует версия данных, а данные реплики состоят из нескольких последовательных версий. Из-за ошибок загрузки, задержек или других причин набор версий данных некоторых реплик может быть неполным.
HEALTHY	Исправная реплика. Данные в норме, а узел BE, на котором находится реплика, работает штатно: heartbeat поступает нормально, и узел не находится в процессе вывода из эксплуатации.

Состояние исправности Tablet

Состояние исправности Tablet определяется состоянием всех его реплик. Возможны следующие состояния:

Состояние	Значение
REPLICA_MISSING	Отсутствуют реплики. Число работающих реплик меньше ожидаемого числа реплик.
VERSION_INCOMPLETE	Число работающих реплик больше или равно ожидаемому числу реплик, но число исправных реплик меньше ожидаемого.
REPLICA_RELOCATING	Число работающих реплик с полным набором версий равно заданному числу реплик, но некоторые узлы BE, на которых находятся эти реплики, недоступны, например выводятся из эксплуатации.
REPLICA_MISSING_IN_CLUSTER	В сценариях с несколькими кластерами число исправных реплик больше или равно ожидаемому, но число реплик в соответствующем кластере меньше ожидаемого.
REDUNDANT	Избыточные реплики. Все исправные реплики находятся в соответствующем кластере, но их число превышает ожидаемое; либо присутствуют лишние недоступные реплики.
FORCE_REDUNDANT	Особое состояние. Возникает только при условии «число существующих реплик >= число доступных узлов >= ожидаемое число реплик, а число работающих реплик < ожидаемого числа реплик». В этом случае сначала необходимо удалить реплику, чтобы освободить доступный узел для создания новой реплики.
COLOCATE_MISMATCH	Состояние шарда, характерное для таблиц Colocation: распределение реплик шарда не соответствует распределению, заданному Colocation Group.
COLOCATE_REDUNDANT	Состояние шарда, характерное для таблиц Colocation: у шарда таблицы Colocation есть избыточные реплики.
HEALTHY	Исправный шард: ни одно из приведённых выше условий с 1 по 8 не выполняется.

Восстановление реплик

TabletChecker постоянно работает в фоновом режиме и периодически проверяет состояние всех шардов. Неисправные шарды передаются в TabletScheduler для планирования и восстановления. Само восстановление выполняется задачами клонирования на BE; FE отвечает только за создание этих задач.

Примечание 1: Основной принцип восстановления реплик — сначала довести число реплик до ожидаемого значения, создав новые или дополнив существующие, а затем удалить избыточные реплики.

Примечание 2: Задача клонирования — это процесс копирования указанных данных с заданного удалённого BE на заданный целевой BE.

Восстановление в зависимости от состояния

Для разных состояний Doris использует разные способы восстановления:

REPLICA_MISSING / REPLICA_RELOCATING

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

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

Обрабатывается так же, как REPLICA_MISSING.
REDUNDANT

После восстановления у шарда обычно остаются избыточные реплики. Для удаления выбирается одна из них. Выбор выполняется в следующем порядке приоритета:
1. BE, на котором находится реплика, выведен из эксплуатации
2. Реплика повреждена
3. BE, на котором находится реплика, недоступен или выводится из эксплуатации
4. Реплика находится в состоянии CLONE — промежуточном состоянии при выполнении задачи клонирования
5. У реплики отсутствуют версии
6. Реплика находится не в том кластере
7. BE, на котором находится реплика, сильно нагружен
FORCE_REDUNDANT

В отличие от REDUNDANT, в этом случае число работающих реплик меньше ожидаемого, но дополнительных доступных узлов для создания новой реплики нет. Поэтому сначала необходимо удалить реплику, чтобы освободить доступный узел для создания новой реплики. Порядок удаления реплик такой же, как для REDUNDANT.
COLOCATE_MISMATCH

В качестве целевого узла для добавления недостающей реплики выбирается один из узлов BE, указанных в распределении реплик Colocation Group.
COLOCATE_REDUNDANT

Удаляется реплика на узле BE, который не указан в распределении реплик Colocation Group.

При выборе узлов для реплик Doris не размещает реплики одного Tablet на разных BE одного хоста. Благодаря этому даже отказ всех BE на одном хосте не приводит к потере всех реплик.

Приоритет планирования

Шардам, ожидающим планирования в TabletScheduler, назначаются разные приоритеты в зависимости от их состояния. Шарды с более высоким приоритетом планируются первыми. Сейчас предусмотрены следующие приоритеты:

Приоритет	Условие назначения
VERY_HIGH	REDUNDANT: шарды с избыточными репликами. Хотя срочность минимальна, обработка выполняется быстрее всего и позволяет быстро освободить дисковое пространство и другие ресурсы, поэтому она выполняется первой. FORCE_REDUNDANT: аналогично предыдущему случаю.
HIGH	REPLICA_MISSING, когда отсутствует большинство реплик, например потеряны 2 из 3 реплик. VERSION_INCOMPLETE, когда у большинства реплик отсутствуют версии. COLOCATE_MISMATCH: шарды таблиц Colocation необходимо восстанавливать как можно скорее. COLOCATE_REDUNDANT.
NORMAL	REPLICA_MISSING, когда большинство реплик работает, например потеряна 1 из 3 реплик. VERSION_INCOMPLETE, когда у большинства реплик полный набор версий. REPLICA_RELOCATING, когда большинство реплик нужно переместить, например 2 из 3 реплик.
LOW	REPLICA_MISSING_IN_CLUSTER. REPLICA_RELOCATING, когда большинство реплик находится в стабильном состоянии.

Назначение приоритета вручную

Система определяет приоритет планирования автоматически. Однако если нужно быстрее восстановить определённые таблицы или партиции, следующая команда позволяет назначить таблице или партиции приоритетное восстановление:

ADMIN REPAIR TABLE tbl [PARTITION (p1, p2, ...)];

Эта команда указывает TabletChecker, что при сканировании Tablet проблемным Tablet в таблицах или партициях, помеченных для приоритетного восстановления, следует назначать приоритет VERY_HIGH.

Примечание: Эта команда служит лишь подсказкой и не гарантирует успешного восстановления. Приоритет может меняться в процессе планирования TabletScheduler. После смены или перезапуска Master FE эта информация теряется.

Чтобы отменить приоритет, используйте следующую команду:

ADMIN CANCEL REPAIR TABLE tbl [PARTITION (p1, p2, ...)];

Динамическое изменение приоритета

Приоритет обеспечивает первоочередное восстановление сильно повреждённых шардов и повышает доступность системы. Однако если задачи восстановления с высоким приоритетом постоянно завершаются неудачей, задачи с низким приоритетом могут так и не попасть в планирование. Поэтому Doris динамически меняет приоритеты задач в зависимости от хода их выполнения, чтобы каждая задача получила возможность быть запланированной:

После 5 последовательных неудачных попыток планирования, например из-за невозможности получить ресурсы или найти подходящий источник либо целевой узел, приоритет понижается.
Если задача не была запланирована в течение 30 минут, её приоритет повышается.
Приоритет задачи для одного и того же Tablet меняется не чаще одного раза в 5 минут.

Чтобы сохранить значимость исходного приоритета, действуют следующие правила: исходный приоритет VERY_HIGH понижается не ниже NORMAL; исходный приоритет LOW повышается не выше HIGH. Такое динамическое изменение применяется и к приоритетам, заданным пользователями вручную.

Балансировка реплик

Doris автоматически выполняет балансировку реплик в кластере. Сейчас поддерживаются две стратегии: балансировка нагрузки и балансировка партиций.

Стратегия	Основная цель	Сценарии применения	Примечания
Балансировка нагрузки	Выровнять использование дисков и число реплик на узлах	Нужно учитывать как дисковую ёмкость, так и равномерность распределения реплик	Оценка рассчитывается по двум показателям
Балансировка партиций	Равномерно распределить реплики каждой партиции между узлами	Высокие требования к чтению и записи партиций, необходимость избегать горячих точек	Использование дисков не учитывается; нужно следить за их ёмкостью

Стратегию можно настроить только через tablet_rebalancer_type до запуска FE; переключение во время работы не поддерживается.

Независимо от стратегии балансировка реплик всегда гарантирует, что реплики одного Tablet не размещаются на BE одного хоста.

Балансировка нагрузки

Основной принцип балансировки нагрузки: для выбранных шардов сначала создать реплику на слабо нагруженном узле, а затем удалить реплики этих шардов на сильно нагруженных узлах. При этом из-за наличия разных типов носителей узлы BE в одном кластере могут использовать один или два типа носителей. Шард с типом носителя A после балансировки должен по возможности оставаться на носителе типа A. Поэтому узлы BE кластера группируются по типу носителя, а планирование балансировки нагрузки выполняется отдельно для каждой такой группы.

Нагрузка на узел BE

ClusterLoadStatistics (CLS) отражает распределение нагрузки между Backend в кластере. TabletScheduler использует эту статистику для запуска балансировки кластера. Сейчас для каждого BE рассчитывается оценка нагрузки loadScore по двум метрикам: использование дисков и число реплик. Чем выше оценка, тем сильнее нагружен BE.

У использования дисков и числа реплик есть весовые коэффициенты capacityCoefficient и replicaNumCoefficient, сумма которых всегда равна 1.

Если параметр backend_load_capacity_coeficient имеет допустимое значение в диапазоне 0.0~1.0, то capacityCoefficient = backend_load_capacity_coeficient.
В противном случае capacityCoefficient динамически меняется в зависимости от фактического использования дисков:
- Если общая заполненность дисков BE ниже 50%, capacityCoefficient равен 0.5.
- Если заполненность превышает 75% (порог настраивается параметром FE capacity_used_percent_high_water), значение равно 1.
- При заполненности от 50% до 75% весовой коэффициент плавно растёт по формуле:

capacityCoefficient = 2 * disk usage - 0.5

Благодаря этому весовому коэффициенту при слишком высокой заполненности дисков оценка нагрузки Backend становится выше, чтобы как можно быстрее снизить нагрузку на BE.

TabletScheduler обновляет CLS каждые 20 секунд.

Балансировка партиций

Основной принцип балансировки партиций — свести к минимуму разницу в числе реплик каждой партиции на разных Backend, то есть перекос партиции. Поэтому учитывается только число реплик, а использование дисков не учитывается.

Чтобы минимизировать число перемещений, балансировка партиций использует двумерную жадную стратегию и сначала балансирует партицию с наибольшим перекосом. При балансировке партиции она старается выбрать направление, которое уменьшит разницу в числе реплик между Backend по всему кластеру, то есть перекос кластера / общий перекос.

Статистика перекоса

Статистика перекоса представлена в ClusterBalanceInfo:

partitionInfoBySkew: отсортировано по ключу перекоса партиции, что позволяет легко найти максимальный перекос партиции.
beByTotalReplicaCount: отсортировано по ключу общего числа реплик на каждом Backend.

ClusterBalanceInfo также хранится в CLS и обновляется каждые 20 секунд. Партиций с максимальным перекосом может быть несколько; для расчёта случайным образом выбирается одна из них.

Планирование балансировки

В каждом цикле планирования TabletScheduler с помощью LoadBalancer выбирает определённое число исправных шардов в качестве кандидатов для балансировки. В следующем цикле он пытается запланировать балансировку этих шардов.

Управление ресурсами

И восстановление, и балансировка реплик выполняются путём копирования реплик между BE. Если на одном BE одновременно выполняется слишком много задач, возникает значительная нагрузка на IO. Поэтому при планировании Doris ограничивает число задач, которые могут выполняться на каждом узле.

Ресурс	Описание
Единица управления ресурсами	Минимальная единица — диск, то есть путь к данным, указанный в `be.conf`.
Слот восстановления реплик	По умолчанию на каждом диске есть 2 слота. Задача клонирования занимает по одному слоту на источнике и на целевом узле. Если число свободных слотов равно 0, новые задачи не назначаются. Число слотов можно настроить параметрами FE `schedule_slot_num_per_hdd_path` или `schedule_slot_num_per_ssd_path`.
Слот задач балансировки	По умолчанию каждый диск предоставляет 2 независимых слота для задач балансировки. Это позволяет сильно нагруженным узлам освобождать место за счёт балансировки, даже если слоты восстановления заняты.

Просмотр состояния реплик

Просмотр состояния реплик позволяет оценить состояние самих реплик, а также ход выполнения задач восстановления и балансировки. Большая часть этой информации доступна только на узле Master FE, поэтому следующие команды необходимо выполнять при прямом подключении к Master FE.

Состояние реплик

Проверка общего состояния

Состояние реплик всего кластера можно просмотреть командой SHOW PROC '/cluster_health/tablet_health';:

+-------+--------------------------------+-----------+------------+-------------------+----------------------+----------------------+--------------+----------------------------+-------------------------+-------------------+---------------------+----------------------+----------------------+------------------+-----------------------------+-----------------+-------------+------------+
| DbId  | DbName                         | TabletNum | HealthyNum | ReplicaMissingNum | VersionIncompleteNum | ReplicaRelocatingNum | RedundantNum | ReplicaMissingInClusterNum | ReplicaMissingForTagNum | ForceRedundantNum | ColocateMismatchNum | ColocateRedundantNum | NeedFurtherRepairNum | UnrecoverableNum | ReplicaCompactionTooSlowNum | InconsistentNum | OversizeNum | CloningNum |
+-------+--------------------------------+-----------+------------+-------------------+----------------------+----------------------+--------------+----------------------------+-------------------------+-------------------+---------------------+----------------------+----------------------+------------------+-----------------------------+-----------------+-------------+------------+
| 10005 | default_cluster:doris_audit_db | 84        | 84         | 0                 | 0                    | 0                    | 0            | 0                          | 0                       | 0                 | 0                   | 0                    | 0                    | 0                | 0                           | 0               | 0           | 0          |
| 13402 | default_cluster:ssb1           | 709       | 708        | 1                 | 0                    | 0                    | 0            | 0                          | 0                       | 0                 | 0                   | 0                    | 0                    | 0                | 0                           | 0               | 0           | 0          |
| 10108 | default_cluster:tpch1          | 278       | 278        | 0                 | 0                    | 0                    | 0            | 0                          | 0                       | 0                 | 0                   | 0                    | 0                    | 0                | 0                           | 0               | 0           | 0          |
| Total | 3                              | 1071      | 1070       | 1                 | 0                    | 0                    | 0            | 0                          | 0                       | 0                 | 0                   | 0                    | 0                    | 0                | 0                           | 0               | 0           | 0          |
+-------+--------------------------------+-----------+------------+-------------------+----------------------+----------------------+--------------+----------------------------+-------------------------+-------------------+---------------------+----------------------+----------------------+------------------+-----------------------------+-----------------+-------------+------------+

Описание основных столбцов:

HealthyNum: число исправных Tablet в соответствующей базе данных.
ReplicaCompactionTooSlowNum: число Tablet, у реплик которых слишком много версий.
InconsistentNum: число Tablet с несогласованными репликами.
Строка Total: статистика по всему кластеру. В нормальных условиях значения TabletNum и HealthyNum должны совпадать; если это не так, можно перейти к подробной информации и найти конкретный Tablet.

Например, в базе данных ssb1 есть 1 неисправный Tablet. Его можно найти следующей командой, где 13402 — соответствующий DbId:

SHOW PROC '/cluster_health/tablet_health/13402';

+-----------------------+--------------------------+--------------------------+------------------+--------------------------------+-----------------------------+-----------------------+-------------------------+--------------------------+--------------------------+----------------------+---------------------------------+---------------------+-----------------+
| ReplicaMissingTablets | VersionIncompleteTablets | ReplicaRelocatingTablets | RedundantTablets | ReplicaMissingInClusterTablets | ReplicaMissingForTagTablets | ForceRedundantTablets | ColocateMismatchTablets | ColocateRedundantTablets | NeedFurtherRepairTablets | UnrecoverableTablets | ReplicaCompactionTooSlowTablets | InconsistentTablets | OversizeTablets |
+-----------------------+--------------------------+--------------------------+------------------+--------------------------------+-----------------------------+-----------------------+-------------------------+--------------------------+--------------------------+----------------------+---------------------------------+---------------------+-----------------+
| 14679                 |                          |                          |                  |                                |                             |                       |                         |                          |                          |                      |                                 |                     |                 |
+-----------------------+--------------------------+--------------------------+------------------+--------------------------------+-----------------------------+-----------------------+-------------------------+--------------------------+--------------------------+----------------------+---------------------------------+---------------------+-----------------+

В выводе указан ID конкретного неисправного Tablet, например 14679, который находится в состоянии ReplicaMissing. В следующем разделе описано, как просмотреть состояние каждой реплики определённого Tablet.

Проверка состояния на уровне таблицы или партиции

Следующая команда позволяет просмотреть состояние реплик указанной таблицы или партиции, а предложение WHERE — отфильтровать их по состоянию. Например, чтобы просмотреть реплики в состоянии OK в партициях p1 и p2 таблицы tbl1:

SHOW REPLICA STATUS FROM tbl1 PARTITION (p1, p2) WHERE STATUS = "OK";

+----------+-----------+-----------+---------+-------------------+--------------------+------------------+------------+------------+-------+--------+--------+
| TabletId | ReplicaId | BackendId | Version | LastFailedVersion | LastSuccessVersion | CommittedVersion | SchemaHash | VersionNum | IsBad | State  | Status |
+----------+-----------+-----------+---------+-------------------+--------------------+------------------+------------+------------+-------+--------+--------+
| 29502429 | 29502432  | 10006     | 2       | -1                | 2                  | 1                | -1         | 2          | false | NORMAL | OK     |
| 29502429 | 36885996  | 10002     | 2       | -1                | -1                 | 1                | -1         | 2          | false | NORMAL | OK     |
| 29502429 | 48100551  | 10007     | 2       | -1                | -1                 | 1                | -1         | 2          | false | NORMAL | OK     |
| 29502433 | 29502434  | 10001     | 2       | -1                | 2                  | 1                | -1         | 2          | false | NORMAL | OK     |
| 29502433 | 44900737  | 10004     | 2       | -1                | -1                 | 1                | -1         | 2          | false | NORMAL | OK     |
| 29502433 | 48369135  | 10006     | 2       | -1                | -1                 | 1                | -1         | 2          | false | NORMAL | OK     |
+----------+-----------+-----------+---------+-------------------+--------------------+------------------+------------+------------+-------+--------+--------+

Здесь показано состояние всех реплик:

Значение IsBad, равное true, означает, что реплика повреждена.
Столбец Status показывает другие состояния. Для получения подробной информации выполните HELP SHOW REPLICA STATUS;.

Команда SHOW REPLICA STATUS в основном используется для просмотра состояния исправности реплик. Для получения дополнительной информации о репликах используйте:

SHOW TABLETS FROM tbl1;

+----------+-----------+-----------+------------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+----------+----------+--------+-------------------------+--------------+----------------------+--------------+----------------------+----------------------+----------------------+
| TabletId | ReplicaId | BackendId | SchemaHash | Version | VersionHash | LstSuccessVersion | LstSuccessVersionHash | LstFailedVersion | LstFailedVersionHash | LstFailedTime | DataSize | RowCount | State  | LstConsistencyCheckTime | CheckVersion |     CheckVersionHash | VersionCount | PathHash             | MetaUrl              | CompactionStatus     |
+----------+-----------+-----------+------------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+----------+----------+--------+-------------------------+--------------+----------------------+--------------+----------------------+----------------------+----------------------+
| 29502429 | 29502432  | 10006     | 1421156361 | 2       | 0           | 2                 | 0                     | -1               | 0                    | N/A           | 784      | 0        | NORMAL | N/A                     | -1           |     -1               | 2            | -5822326203532286804 | url                  | url                  |
| 29502429 | 36885996  | 10002     | 1421156361 | 2       | 0           | -1                | 0                     | -1               | 0                    | N/A           | 784      | 0        | NORMAL | N/A                     | -1           |     -1               | 2            | -1441285706148429853 | url                  | url                  |
| 29502429 | 48100551  | 10007     | 1421156361 | 2       | 0           | -1                | 0                     | -1               | 0                    | N/A           | 784      | 0        | NORMAL | N/A                     | -1           |     -1               | 2            | -4784691547051455525 | url                  | url                  |
+----------+-----------+-----------+------------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+----------+----------+--------+-------------------------+--------------+----------------------+--------------+----------------------+----------------------+----------------------+

В выводе выше представлена дополнительная информация: размер реплики, число строк, число версий и путь к данным, по которому хранится реплика.

Примечание: Столбец State здесь отражает состояние задачи реплики, например CLONE, SCHEMA_CHANGE, ROLLUP и т. д., а не состояние её исправности.

Кроме того, следующая команда позволяет просмотреть распределение реплик указанной таблицы или партиции и проверить его равномерность:

SHOW REPLICA DISTRIBUTION FROM tbl1;

+-----------+------------+-------+---------+
| BackendId | ReplicaNum | Graph | Percent |
+-----------+------------+-------+---------+
| 10000     | 7          |       | 7.29 %  |
| 10001     | 9          |       | 9.38 %  |
| 10002     | 7          |       | 7.29 %  |
| 10003     | 7          |       | 7.29 %  |
| 10004     | 9          |       | 9.38 %  |
| 10005     | 11         | >     | 11.46 % |
| 10006     | 18         | >     | 18.75 % |
| 10007     | 15         | >     | 15.62 % |
| 10008     | 13         | >     | 13.54 % |
+-----------+------------+-------+---------+

В выводе показаны число и процент реплик таблицы tbl1 на каждом узле BE, а также простое графическое представление.

Проверка состояния на уровне Tablet

Для поиска конкретного Tablet используйте следующую команду. Например, чтобы просмотреть Tablet с ID 29502553:

SHOW TABLET 29502553;

+------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+
| DbName                 | TableName | PartitionName | IndexName | DbId     | TableId  | PartitionId | IndexId  | IsSync | DetailCmd                                                                 |
+------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+
| default_cluster:test   | test      | test          | test      | 29502391 | 29502428 | 29502427    | 29502428 | true   | SHOW PROC '/dbs/29502391/29502428/partitions/29502427/29502428/29502553'; |
+------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+

В выводе показаны база данных, таблица, партиция, таблица rollup и другая информация о принадлежности Tablet. Скопируйте команду из столбца DetailCmd и выполните её:

SHOW PROC '/dbs/29502391/29502428/partitions/29502427/29502428/29502553';

+-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+
| ReplicaId | BackendId | Version | VersionHash | LstSuccessVersion | LstSuccessVersionHash | LstFailedVersion | LstFailedVersionHash | LstFailedTime | SchemaHash | DataSize | RowCount | State  | IsBad | VersionCount | PathHash             | MetaUrl  | CompactionStatus |
+-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+
| 43734060  | 10004     | 2       | 0           | -1                | 0                     | -1               | 0                    | N/A           | -1         | 784      | 0        | NORMAL | false | 2            | -8566523878520798656 | url      | url              |
| 29502555  | 10002     | 2       | 0           | 2                 | 0                     | -1               | 0                    | N/A           | -1         | 784      | 0        | NORMAL | false | 2            | 1885826196444191611  | url      | url              |
| 39279319  | 10007     | 2       | 0           | -1                | 0                     | -1               | 0                    | N/A           | -1         | 784      | 0        | NORMAL | false | 2            | 1656508631294397870  | url      | url              |
+-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+

В выводе показано состояние всех реплик соответствующего Tablet. Содержимое такое же, как у SHOW TABLETS FROM tbl1;, но здесь наглядно представлено состояние всех реплик одного конкретного Tablet.

Задачи планирования реплик

Следующие команды позволяют отдельно просмотреть ожидающие, выполняющиеся и завершённые задачи планирования:

Состояние	Команда
Ожидает	`SHOW PROC '/cluster_balance/pending_tablets';`
Выполняется	`SHOW PROC '/cluster_balance/running_tablets';`
Завершена	`SHOW PROC '/cluster_balance/history_tablets';`

Пример вывода (pending_tablets):

+----------+--------+-----------------+---------+----------+----------+-------+---------+--------+----------+---------+---------------------+---------------------+---------------------+----------+------+-------------+---------------+---------------------+------------+---------------------+--------+---------------------+-------------------------------+
| TabletId | Type   | Status          | State   | OrigPrio | DynmPrio | SrcBe | SrcPath | DestBe | DestPath | Timeout | Create              | LstSched            | LstVisit            | Finished | Rate | FailedSched | FailedRunning | LstAdjPrio          | VisibleVer | VisibleVerHash      | CmtVer | CmtVerHash          | ErrMsg                        |
+----------+--------+-----------------+---------+----------+----------+-------+---------+--------+----------+---------+---------------------+---------------------+---------------------+----------+------+-------------+---------------+---------------------+------------+---------------------+--------+---------------------+-------------------------------+
| 4203036  | REPAIR | REPLICA_MISSING | PENDING | HIGH     | LOW      | -1    | -1      | -1     | -1       | 0       | 2019-02-21 15:00:20 | 2019-02-24 11:18:41 | 2019-02-24 11:18:41 | N/A      | N/A  | 2           | 0             | 2019-02-21 15:00:43 | 1          | 0                   | 2      | 0                   | unable to find source replica |
+----------+--------+-----------------+---------+----------+----------+-------+---------+--------+----------+---------+---------------------+---------------------+---------------------+----------+------+-------------+---------------+---------------------+------------+---------------------+--------+---------------------+-------------------------------+

Значения столбцов:

Столбец	Значение
TabletId	ID Tablet, ожидающего планирования. Одна задача планирования относится только к одному Tablet.
Type	Тип задачи: REPAIR или BALANCE.
Status	Текущее состояние Tablet, например REPLICA_MISSING.
State	Состояние задачи планирования: PENDING / RUNNING / FINISHED / CANCELLED / TIMEOUT / UNEXPECTED.
OrigPrio	Исходный приоритет.
DynmPrio	Текущий приоритет после динамического изменения.
SrcBe	ID исходного узла BE.
SrcPath	Хеш пути на исходном узле BE.
DestBe	ID целевого узла BE.
DestPath	Хеш пути на целевом узле BE.
Timeout	Тайм-аут задачи в секундах после её успешного планирования.
Create	Время создания задачи.
LstSched	Время последнего планирования задачи.
LstVisit	Время последнего обращения к задаче. Под обращением понимается любая обработка, связанная с задачей, включая планирование и получение отчёта о выполнении.
Finished	Время завершения задачи.
Rate	Скорость копирования данных задачей клонирования.
FailedSched	Число неудачных попыток планирования задачи.
FailedRunning	Число неудачных попыток выполнения задачи.
LstAdjPrio	Время последнего изменения приоритета.
CmtVer / CmtVerHash / VisibleVer / VisibleVerHash	Информация о версиях, используемая для выполнения задачи клонирования.
ErrMsg	Сообщения об ошибках, возникших при планировании и выполнении задачи.

Значения столбцов в running_tablets такие же, как в pending_tablets.

history_tablets по умолчанию хранит только последние 1000 завершённых задач. Значения столбцов такие же, как описано выше:

Значение State, равное FINISHED, означает, что задача завершилась штатно.
Другие значения можно диагностировать по сообщению об ошибке в столбце ErrMsg.

Просмотр нагрузки кластера и ресурсов планирования

Нагрузка кластера

Текущую нагрузку кластера можно просмотреть следующей командой:

SHOW PROC '/cluster_balance/cluster_load_stat/location_default';

Сначала отображается разбивка по типам носителей:

+---------------+
| StorageMedium |
+---------------+
| HDD           |
| SSD           |
+---------------+

Перейдите к определённому типу носителя, чтобы увидеть состояние балансировки узлов BE, на которых он используется:

SHOW PROC '/cluster_balance/cluster_load_stat/location_default/HDD';

+----------+-----------------+-----------+---------------+----------------+-------------+------------+----------+-----------+--------------------+-------+
| BeId     | Cluster         | Available | UsedCapacity  | Capacity       | UsedPercent | ReplicaNum | CapCoeff | ReplCoeff | Score              | Class |
+----------+-----------------+-----------+---------------+----------------+-------------+------------+----------+-----------+--------------------+-------+
| 10003    | default_cluster | true      | 3477875259079 | 19377459077121 | 17.948      | 493477     | 0.5      | 0.5       | 0.9284678149967587 | MID   |
| 10002    | default_cluster | true      | 3607326225443 | 19377459077121 | 18.616      | 496928     | 0.5      | 0.5       | 0.948660871419998  | MID   |
| 10005    | default_cluster | true      | 3523518578241 | 19377459077121 | 18.184      | 545331     | 0.5      | 0.5       | 0.9843539990641831 | MID   |
| 10001    | default_cluster | true      | 3535547090016 | 19377459077121 | 18.246      | 558067     | 0.5      | 0.5       | 0.9981869446537612 | MID   |
| 10006    | default_cluster | true      | 3636050364835 | 19377459077121 | 18.764      | 547543     | 0.5      | 0.5       | 1.0011489897614072 | MID   |
| 10004    | default_cluster | true      | 3506558163744 | 15501967261697 | 22.620      | 468957     | 0.5      | 0.5       | 1.0228319835582569 | MID   |
| 10007    | default_cluster | true      | 4036460478905 | 19377459077121 | 20.831      | 551645     | 0.5      | 0.5       | 1.057279369420761  | MID   |
| 10000    | default_cluster | true      | 4369719923760 | 19377459077121 | 22.551      | 547175     | 0.5      | 0.5       | 1.0964036415787461 | MID   |
+----------+-----------------+-----------+---------------+----------------+-------------+------------+----------+-----------+--------------------+-------+

Значения столбцов:

Столбец	Значение
Available	Значение true означает, что heartbeat BE поступает нормально и узел не находится в процессе вывода из эксплуатации.
UsedCapacity	Занятое дисковое пространство BE в байтах.
Capacity	Общий объём дискового пространства BE в байтах.
UsedPercent	Использование дискового пространства BE в процентах.
ReplicaNum	Число реплик на BE.
CapCoeff / ReplCoeff	Весовые коэффициенты дискового пространства и числа реплик.
Score	Оценка нагрузки. Чем выше значение, тем сильнее нагрузка.
Class	Классификация по уровню нагрузки: LOW / MID / HIGH. При планировании балансировки реплики перемещаются с сильно нагруженных узлов на слабо нагруженные.

Можно перейти ещё на уровень ниже и просмотреть использование каждого пути на конкретном BE. Например, чтобы просмотреть BE с ID 10001:

SHOW PROC '/cluster_balance/cluster_load_stat/location_default/HDD/10001';

+------------------+------------------+---------------+---------------+---------+--------+----------------------+
| RootPath         | DataUsedCapacity | AvailCapacity | TotalCapacity | UsedPct | State  | PathHash             |
+------------------+------------------+---------------+---------------+---------+--------+----------------------+
| /home/disk4/palo | 498.757 GB       | 3.033 TB      | 3.525 TB      | 13.94 % | ONLINE | 4883406271918338267  |
| /home/disk3/palo | 704.200 GB       | 2.832 TB      | 3.525 TB      | 19.65 % | ONLINE | -5467083960906519443 |
| /home/disk1/palo | 512.833 GB       | 3.007 TB      | 3.525 TB      | 14.69 % | ONLINE | -7733211489989964053 |
| /home/disk2/palo | 881.955 GB       | 2.656 TB      | 3.525 TB      | 24.65 % | ONLINE | 4870995507205544622  |
| /home/disk5/palo | 694.992 GB       | 2.842 TB      | 3.525 TB      | 19.36 % | ONLINE | 1916696897889786739  |
+------------------+------------------+---------------+---------------+---------+--------+----------------------+

В выводе показано использование диска для каждого пути к данным на указанном BE.

Ресурсы планирования

Использование слотов каждого узла можно просмотреть следующей командой:

SHOW PROC '/cluster_balance/working_slots';

+----------+----------------------+------------+------------+-------------+----------------------+
| BeId     | PathHash             | AvailSlots | TotalSlots | BalanceSlot | AvgRate              |
+----------+----------------------+------------+------------+-------------+----------------------+
| 10000    | 8110346074333016794  | 2          | 2          | 2           | 2.459007474009069E7  |
| 10000    | -5617618290584731137 | 2          | 2          | 2           | 2.4730105014001578E7 |
| 10001    | 4883406271918338267  | 2          | 2          | 2           | 1.6711402709780257E7 |
| 10001    | -5467083960906519443 | 2          | 2          | 2           | 2.7540126380326536E7 |
| 10002    | 9137404661108133814  | 2          | 2          | 2           | 2.417217089806745E7  |
| 10002    | 1885826196444191611  | 2          | 2          | 2           | 1.6327378456676323E7 |
+----------+----------------------+------------+------------+-------------+----------------------+

Использование слотов показано на уровне отдельных путей к данным. AvgRate — рассчитанная по накопленной статистике скорость копирования задач клонирования для данного пути, в байтах в секунду.

Просмотр приоритетного восстановления

Следующая команда показывает таблицы или партиции, для которых командой ADMIN REPAIR TABLE задано приоритетное восстановление:

SHOW PROC '/cluster_balance/priority_repair';

RemainingTimeMs показывает, сколько времени осталось до автоматического удаления этих элементов из очереди приоритетного восстановления. Это предотвращает ситуацию, когда приоритетное восстановление постоянно завершается неудачей и занимает ресурсы.

Просмотр статистики планировщика

Во время работы Doris собирает статистику TabletChecker и TabletScheduler. Её можно просмотреть следующей командой:

SHOW PROC '/cluster_balance/sched_stat';

+---------------------------------------------------+-------------+
| Item                                              | Value       |
+---------------------------------------------------+-------------+
| num of tablet check round                         | 12041       |
| cost of tablet check(ms)                          | 7162342     |
| num of tablet checked in tablet checker           | 18793506362 |
| num of unhealthy tablet checked in tablet checker | 7043900     |
| num of tablet being added to tablet scheduler     | 1153        |
| num of tablet schedule round                      | 49538       |
| cost of tablet schedule(ms)                       | 49822       |
| num of tablet being scheduled                     | 4356200     |
| num of tablet being scheduled succeeded           | 320         |
| num of tablet being scheduled failed              | 4355594     |
| num of tablet being scheduled discard             | 286         |
| num of tablet priority upgraded                   | 0           |
| num of tablet priority downgraded                 | 1096        |
| num of clone task                                 | 230         |
| num of clone task succeeded                       | 228         |
| num of clone task failed                          | 2           |
| num of clone task timeout                         | 2           |
| num of replica missing error                      | 4354857     |
| num of replica version missing error              | 967         |
| num of replica relocating                         | 0           |
| num of replica redundant error                    | 90          |
| num of replica missing in cluster error           | 0           |
| num of balance scheduled                          | 0           |
+---------------------------------------------------+-------------+

Значения строк:

Метрика	Значение
num of tablet check round	Число запусков Tablet Checker.
cost of tablet check(ms)	Общее время работы Tablet Checker.
num of tablet checked in tablet checker	Число Tablet, проверенных Tablet Checker.
num of unhealthy tablet checked in tablet checker	Число неисправных Tablet, проверенных Tablet Checker.
num of tablet being added to tablet scheduler	Число Tablet, переданных в Tablet Scheduler.
num of tablet schedule round	Число запусков Tablet Scheduler.
cost of tablet schedule(ms)	Общее время работы Tablet Scheduler.
num of tablet being scheduled	Общее число Tablet, для которых выполнялось планирование.
num of tablet being scheduled succeeded	Общее число успешно запланированных Tablet.
num of tablet being scheduled failed	Общее число Tablet, которые не удалось запланировать.
num of tablet being scheduled discard	Общее число Tablet, которые не удалось запланировать и которые были отброшены.
num of tablet priority upgraded	Число повышений приоритета.
num of tablet priority downgraded	Число понижений приоритета.
num of clone task	Число созданных задач клонирования.
num of clone task succeeded	Число успешно выполненных задач клонирования.
num of clone task failed	Число задач клонирования, завершившихся ошибкой.
num of clone task timeout	Число задач клонирования, завершившихся по тайм-ауту.
num of replica missing error	Число проверенных Tablet с состоянием отсутствия реплик.
num of replica version missing error	Число проверенных Tablet с состоянием отсутствия версий, включая num of replica relocating и num of replica missing in cluster error.
num of replica relocating	Число проверенных Tablet с состоянием перемещения реплик.
num of replica redundant error	Число проверенных Tablet с состоянием избыточности реплик.
num of replica missing in cluster error	Число проверенных Tablet с состоянием отсутствия реплик в соответствующем кластере.
num of balance scheduled	Число выполненных планирований балансировки.

Примечание: Все приведённые выше показатели накапливаются за время работы. Эта статистика также периодически выводится в журнал FE; значение в скобках показывает изменение каждого показателя с момента предыдущего вывода статистики.

Настраиваемые параметры (FE)

Все следующие параметры можно настроить в fe.conf.

Параметр	Описание	Значение по умолчанию	Важность
use_new_tablet_scheduler	Включает новый способ планирования задач для реплик, описанный в этом документе.	true	Высокая
tablet_repair_delay_factor_second	Задаёт разную задержку восстановления для разных приоритетов планирования, чтобы предотвратить создание большого числа ненужных задач восстановления реплик при плановых перезапусках, обновлениях и т. д. Базовый коэффициент: для HIGH задержка равна `base coefficient * 1`, для NORMAL — `base coefficient * 2`, для LOW — `base coefficient * 3`. Чем ниже приоритет, тем дольше ожидание. Уменьшите значение, если реплики нужно восстанавливать быстрее.	60 секунд	Высокая
schedule_slot_num_per_path	Число слотов, выделяемых по умолчанию на каждом диске для восстановления реплик. Определяет число задач восстановления реплик, которые могут одновременно выполняться на одном диске. Более высокое значение ускоряет восстановление, но увеличивает нагрузку на IO.	2	Высокая
balance_load_score_threshold	Порог балансировки кластера. Если отклонение оценки нагрузки узла BE от средней оценки нагрузки не превышает это значение, кластер считается сбалансированным. Уменьшите значение, если нужна более равномерная нагрузка.	0.1 (то есть 10%)	Средняя
storage_high_watermark_usage_percent	Максимально допустимая заполненность диска. При превышении этого предела диск больше не выбирается в качестве целевого для задач балансировки.	0.85	Средняя
storage_min_left_capacity_bytes	Минимально допустимый объём свободного места на диске. Если свободного места меньше этого значения, диск больше не выбирается в качестве целевого для задач балансировки.	2097152000 (2 GB)	Средняя
disable_balance	Управляет отключением балансировки. Во время балансировки некоторые операции, например ALTER TABLE, запрещены, а сама балансировка может длиться долго. Установите true, если запрещённые операции нужно выполнить как можно скорее.	false	Средняя

Настраиваемые параметры (BE)

Все следующие параметры можно настроить в be.conf.

Параметр	Описание	Значение по умолчанию	Важность
clone_worker_count	Влияет на скорость балансировки реплик. При низкой нагрузке на диски этот параметр можно изменить, чтобы ускорить балансировку реплик.	3	Средняя

Ненастраиваемые параметры

Следующие параметры пока нельзя изменить; они приведены только для справки.

Параметр	Описание
Интервал планирования TabletChecker	TabletChecker выполняет проверку и планирование каждые 20 секунд.
Интервал планирования TabletScheduler	TabletScheduler выполняет планирование каждые 5 секунд.
Число задач TabletScheduler, планируемых за один пакет	TabletScheduler планирует не более 50 Tablet за цикл.
Максимальное число ожидающих и выполняющихся задач TabletScheduler	Максимальное число ожидающих и выполняющихся задач — 2000. При превышении этого значения TabletChecker перестаёт создавать новые задачи планирования для TabletScheduler.
Максимальное число задач балансировки TabletScheduler	Максимальное число задач балансировки — 500. При превышении этого значения новые задачи балансировки не создаются.
Число слотов задач балансировки на диске	На каждом диске для задач балансировки предусмотрено 2 слота. Эти слоты независимы от слотов восстановления реплик.
Интервал обновления информации о балансировке кластера	TabletScheduler пересчитывает оценку нагрузки кластера каждые 20 секунд.
Минимальный и максимальный тайм-аут задачи клонирования	Тайм-аут задачи клонирования составляет от 3 минут до 2 часов. Конкретное значение рассчитывается как `(tablet size) / (5 MB/s)`. Задача клонирования прекращается после 3 неудачных запусков.
Стратегия динамического изменения приоритета	Минимальный интервал изменения приоритета — 5 минут. Приоритет Tablet понижается после 5 неудачных попыток планирования и повышается, если Tablet не был запланирован в течение 30 минут.

В некоторых случаях стратегия восстановления и балансировки реплик по умолчанию может полностью загрузить сеть. Это часто происходит при использовании гигабитных сетевых карт и большого числа дисков на каждом BE. В таком случае нужно изменить некоторые параметры, чтобы сократить число одновременно выполняемых задач балансировки и восстановления.
Текущая стратегия балансировки реплик таблиц Colocate не гарантирует, что реплики одного Tablet не окажутся на BE одного хоста. Однако стратегия восстановления реплик таблиц Colocate обнаруживает и исправляет такое распределение. После исправления стратегия балансировки может снова посчитать распределение реплик несбалансированным и перераспределить их. В результате эти два состояния постоянно сменяют друг друга, и Colocate Group не может стабилизироваться. Чтобы снизить вероятность размещения реплик на одном хосте, при использовании атрибута Colocate старайтесь поддерживать однородную конфигурацию кластера.

Практические рекомендации

Контроль и управление ходом восстановления и балансировки реплик кластера

В большинстве случаев с настройками по умолчанию Doris автоматически выполняет восстановление реплик и балансировку кластера. Однако иногда для достижения конкретных целей параметры нужно изменить вручную. Например, чтобы приоритетно восстановить определённую таблицу или партицию, отключить балансировку для снижения нагрузки на кластер или сначала восстановить данные обычных таблиц без Colocation. В этом разделе описано, как управлять ходом восстановления и балансировки реплик кластера с помощью параметров.

1. Удаление повреждённых реплик

В некоторых случаях Doris не может автоматически обнаружить повреждённые реплики, из-за чего запросы или загрузки часто завершаются ошибками на этих репликах. Тогда повреждённые реплики нужно удалить вручную. Этот способ подходит, например, для удаления реплик со слишком большим числом версий, вызывающих ошибки -235, или реплик с повреждёнными файлами.

Порядок действий:

Найдите ID Tablet, которому принадлежит реплика. Предположим, это 10001.
Выполните show tablet 10001;, а затем возвращённую команду show proc, чтобы просмотреть подробную информацию о каждой реплике Tablet.
Предположим, ID Backend, на котором находится удаляемая реплика, — 20001. Выполните следующую команду, чтобы пометить реплику как bad:
```
ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "10001", "backend_id" = "20001", "status" = "bad");
```
Снова выполните команду show proc и убедитесь, что столбец IsBad соответствующей реплики имеет значение true.

Реплика, помеченная как bad, больше не участвует в загрузках и запросах. При этом механизм восстановления реплик автоматически создаёт новую реплику взамен неё.

2. Приоритетное восстановление таблицы или партиции

Выполните help admin repair table;, чтобы просмотреть справку. Эта команда пытается приоритетно восстановить Tablet указанной таблицы или партиции.

3. Остановка задач балансировки

Задачи балансировки потребляют часть пропускной способности сети и ресурсов IO. Чтобы прекратить создание новых задач балансировки, выполните:

ADMIN SET FRONTEND CONFIG ("disable_balance" = "true");

4. Остановка всех задач планирования реплик

Задачи планирования реплик включают задачи балансировки и восстановления. Они потребляют часть пропускной способности сети и ресурсов IO. Следующая команда останавливает все задачи планирования реплик, кроме уже выполняющихся, как для таблиц Colocation, так и для обычных таблиц:

ADMIN SET FRONTEND CONFIG ("disable_tablet_scheduler" = "true");

5. Остановка всех задач планирования реплик для таблиц Colocation

Планирование задач для реплик таблиц Colocation и обычных таблиц выполняется независимо. В некоторых случаях имеет смысл сначала остановить балансировку и восстановление таблиц Colocation, чтобы направить ресурсы кластера на восстановление обычных таблиц:

ADMIN SET FRONTEND CONFIG ("disable_colocate_balance" = "true");

6. Более консервативная стратегия восстановления реплик

Doris автоматически восстанавливает реплики при обнаружении недостающих реплик, простоя BE и других подобных ситуаций. Чтобы уменьшить число ошибок, вызванных кратковременными сбоями, например непродолжительным простоем BE, Doris запускает эти задачи с задержкой.

Параметр tablet_repair_delay_factor_second: по умолчанию равен 60 секундам. В зависимости от приоритета задача восстановления запускается с задержкой 60 секунд, 120 секунд или 180 секунд. Следующая команда увеличивает это время, чтобы допускать более длительные сбои и не запускать ненужные задачи восстановления:
```
ADMIN SET FRONTEND CONFIG ("tablet_repair_delay_factor_second" = "120");
```

7. Более консервативная стратегия запуска перераспределения Colocation Group

Перераспределение групп Colocation может сопровождаться большим числом перемещений Tablet. Параметр colocate_group_relocate_delay_second задаёт задержку запуска перераспределения; по умолчанию она составляет 1800 секунд. Если узел BE может быть недоступен долгое время, попробуйте увеличить этот параметр, чтобы избежать ненужного перераспределения:

ADMIN SET FRONTEND CONFIG ("colocate_group_relocate_delay_second" = "3600");

8. Ускорение балансировки реплик

При балансировке Doris сначала добавляет исправную реплику, а затем удаляет старую, тем самым перемещая реплику. Перед удалением старой реплики Doris ждёт завершения уже запущенных на ней задач загрузки, чтобы балансировка не повлияла на них. Однако это замедляет балансировку. Следующий параметр позволяет Doris пропустить ожидание и сразу удалить старую реплику:

ADMIN SET FRONTEND CONFIG ("enable_force_drop_redundant_replica" = "true");

Это может привести к ошибкам некоторых задач загрузки во время балансировки и потребовать их повторного выполнения, но значительно ускоряет балансировку.

Часто задаваемые вопросы

Вопрос: Команда `SHOW PROC '/cluster_health/tablet_health'` возвращает ошибку или неполные данные. Что делать?

Для этой команды необходимо прямое подключение к Master FE. Проверьте, является ли FE, к которому вы сейчас подключены, узлом Master.

Вопрос: Реплика долго находится в состоянии `REPLICA_MISSING` и не восстанавливается. Как найти причину?

Проверьте ErrMsg в выводе SHOW PROC '/cluster_balance/pending_tablets'. Частые причины: не удаётся найти подходящий источник или целевой узел, недостаточно места на диске, узел выводится из эксплуатации.

Вопрос: Слишком много неудачных попыток планирования задач восстановления. Что делать?

Используйте SHOW PROC '/cluster_balance/sched_stat' для просмотра статистики сбоев. Попробуйте увеличить schedule_slot_num_per_hdd_path или schedule_slot_num_per_ssd_path либо проверьте, нет ли таких проблем, как нехватка места на диске или недоступность узлов.

Вопрос: Балансировка реплик полностью загружает сеть. Что делать?

Уменьшите число одновременно выполняемых задач балансировки и восстановления или временно выполните ADMIN SET FRONTEND CONFIG ("disable_balance" = "true");.

Вопрос: Colocate Group долго не может стабилизироваться. Что делать?

Старайтесь поддерживать однородную конфигурацию кластера и увеличьте colocate_group_relocate_delay_second, чтобы сократить число ненужных перераспределений.

Вопрос: После отказа BE сразу начинается восстановление большого числа реплик, вызывая колебания нагрузки. Что делать?

Увеличьте tablet_repair_delay_factor_second, чтобы система дольше допускала временную недоступность узла.

Вопрос: После удаления реплики `bad` ошибки продолжаются. Что делать?

С помощью SHOW PROC '/dbs/.../<tablet_id>' убедитесь, что все недостающие реплики восстановлены, и дождитесь завершения задачи клонирования.

Сценарии применения​

Терминология​

Состояние реплик​

Состояние исправности реплики​

Состояние исправности Tablet​

Восстановление реплик​

Восстановление в зависимости от состояния​

Приоритет планирования​

Назначение приоритета вручную​

Динамическое изменение приоритета​

Балансировка реплик​

Балансировка нагрузки​

Нагрузка на узел BE​

Балансировка партиций​

Статистика перекоса​

Планирование балансировки​

Управление ресурсами​

Просмотр состояния реплик​

Состояние реплик​

Проверка общего состояния​

Проверка состояния на уровне таблицы или партиции​

Проверка состояния на уровне Tablet​

Задачи планирования реплик​

Просмотр нагрузки кластера и ресурсов планирования​

Нагрузка кластера​

Ресурсы планирования​

Просмотр приоритетного восстановления​

Просмотр статистики планировщика​

Связанные настройки​

Настраиваемые параметры (FE)​

Настраиваемые параметры (BE)​

Ненастраиваемые параметры​

Известные проблемы​

Практические рекомендации​

Контроль и управление ходом восстановления и балансировки реплик кластера​

1. Удаление повреждённых реплик​

2. Приоритетное восстановление таблицы или партиции​

3. Остановка задач балансировки​

4. Остановка всех задач планирования реплик​

5. Остановка всех задач планирования реплик для таблиц Colocation​

6. Более консервативная стратегия восстановления реплик​

7. Более консервативная стратегия запуска перераспределения Colocation Group​

8. Ускорение балансировки реплик​

Рекомендуемый порядок быстрого восстановления кластера​

Часто задаваемые вопросы​

Вопрос: Команда SHOW PROC '/cluster_health/tablet_health' возвращает ошибку или неполные данные. Что делать?​

Вопрос: Реплика долго находится в состоянии REPLICA_MISSING и не восстанавливается. Как найти причину?​

Вопрос: Слишком много неудачных попыток планирования задач восстановления. Что делать?​

Вопрос: Балансировка реплик полностью загружает сеть. Что делать?​

Вопрос: Colocate Group долго не может стабилизироваться. Что делать?​

Вопрос: После отказа BE сразу начинается восстановление большого числа реплик, вызывая колебания нагрузки. Что делать?​

Вопрос: После удаления реплики bad ошибки продолжаются. Что делать?​

Сценарии применения

Терминология

Состояние реплик

Состояние исправности реплики

Состояние исправности Tablet

Восстановление реплик

Восстановление в зависимости от состояния

Приоритет планирования

Назначение приоритета вручную

Динамическое изменение приоритета

Балансировка реплик

Балансировка нагрузки

Нагрузка на узел BE

Балансировка партиций

Статистика перекоса

Планирование балансировки

Управление ресурсами

Просмотр состояния реплик

Состояние реплик

Проверка общего состояния

Проверка состояния на уровне таблицы или партиции

Проверка состояния на уровне Tablet

Задачи планирования реплик

Просмотр нагрузки кластера и ресурсов планирования

Нагрузка кластера

Ресурсы планирования

Просмотр приоритетного восстановления

Просмотр статистики планировщика

Связанные настройки

Настраиваемые параметры (FE)

Настраиваемые параметры (BE)

Ненастраиваемые параметры

Известные проблемы

Практические рекомендации

Контроль и управление ходом восстановления и балансировки реплик кластера

1. Удаление повреждённых реплик

2. Приоритетное восстановление таблицы или партиции

3. Остановка задач балансировки

4. Остановка всех задач планирования реплик

5. Остановка всех задач планирования реплик для таблиц Colocation

6. Более консервативная стратегия восстановления реплик

7. Более консервативная стратегия запуска перераспределения Colocation Group

8. Ускорение балансировки реплик

Рекомендуемый порядок быстрого восстановления кластера

Часто задаваемые вопросы

Вопрос: Команда `SHOW PROC '/cluster_health/tablet_health'` возвращает ошибку или неполные данные. Что делать?

Вопрос: Реплика долго находится в состоянии `REPLICA_MISSING` и не восстанавливается. Как найти причину?

Вопрос: Слишком много неудачных попыток планирования задач восстановления. Что делать?

Вопрос: Балансировка реплик полностью загружает сеть. Что делать?

Вопрос: Colocate Group долго не может стабилизироваться. Что делать?

Вопрос: После отказа BE сразу начинается восстановление большого числа реплик, вызывая колебания нагрузки. Что делать?

Вопрос: После удаления реплики `bad` ошибки продолжаются. Что делать?