Перейти к основному содержимому
Версия: 2.0.x

Управление репликами

В этом разделе описывается, как управлять репликами данных в вашем cluster Selena.

Обзор

Selena использует стратегию множественных replica для гарантии высокой доступности данных. При создании таблицы необходимо указать количество replica с помощью свойства таблицы replication_num (значение по умолчанию: 3). Когда начинается транзакция загрузки, данные одновременно загружаются в указанное количество replica. Транзакция возвращается с успехом только после того, как данные сохранены в большинстве replica. Подробную информацию см. в разделе Кворум записи. Тем не менее, Selena позволяет указать более низкий кворум записи для таблицы для достижения лучшей производительности загрузки.

Selena хранит несколько replica на разных узлах BE. Например, если вы хотите хранить три replica для таблицы, вы должны развернуть как минимум три узла BE в вашем cluster Selena. Если какая-либо из replica выходит из строя, Selena клонирует здоровую replica, частично или полностью, с другого узла BE для восстановления неисправной replica. Используя технику Multi-Version Concurrency Control (MVCC), Selena ускоряет восстановление replica путём дублирования физических копий этих многоверсионных данных.

Загрузка данных в таблицу с множественными репликами

Replica-1

Процедура транзакции загрузки следующая:

  1. Клиент отправляет запрос на загрузку в FE.

  2. FE выбирает узел BE в качестве координатора BE для этой транзакции загрузки и генерирует план выполнения для транзакции.

  3. Координатор BE читает данные для загрузки от клиента.

  4. Координатор BE распределяет данные по всем replica tablet.

    ПРИМЕЧАНИЕ

    Tablet — это логический фрагмент таблицы. Таблица имеет несколько tablet, и каждый tablet имеет replication_num replica. Количество tablet в таблице определяется свойством bucket_size таблицы.

  5. После того как данные загружены и сохранены во всех tablet, FE делает загруженные данные видимыми.

  6. FE возвращает клиенту успешное завершение загрузки.

Такая процедура гарантирует доступность сервиса даже в экстремальных сценариях.

Кворум записи

Загрузка данных в таблицу с множественными replica может занять много времени. Если вы хотите улучшить производительность загрузки и можете допустить относительно более низкую доступность данных, вы можете установить более низкий кворум записи для таблиц. Кворум записи относится к минимальному количеству replica, которые должны подтвердить операцию записи, прежде чем она будет считаться успешной. Вы можете указать кворум записи, добавив свойство write_quorum при CREATE TABLE или добавить это свойство к существующей таблице с помощью ALTER TABLE. Это свойство поддерживается с версии v1.5.2.

write_quorum поддерживает следующие значения:

  • MAJORITY: Значение по умолчанию. Когда большинство replica данных возвращают успех загрузки, Selena возвращает успех задачи загрузки. В противном случае Selena возвращает неудачу задачи загрузки.
  • ONE: Когда одна из replica данных возвращает успех загрузки, Selena возвращает успех задачи загрузки. В противном случае Selena возвращает неудачу задачи загрузки.
  • ALL: Когда все replica данных возвращают успех загрузки, Selena возвращает успех задачи загрузки. В противном случае Selena возвращает неудачу задачи загрузки.

Автоматическое восстановление реплик

Replica могут выходить из строя из-за сбоя некоторых узлов BE или неудачи некоторых задач загрузки. Selena автоматически восстанавливает эти неисправные replica.

Каждые tablet_sched_checker_interval_seconds (по умолчанию 20 секунд) Tablet Checker в FE сканирует все replica tablet всех таблиц в вашем cluster Selena и определяет, является ли replica здоровой, проверяя номер версии текущих видимых данных и состояние здоровья узла BE. Если видимая версия replica отстаёт от версий других replica, Selena выполняет инкрементное клонирование для восстановления неисправной replica. Если узел BE не получает heartbeat или удалён из cluster, или replica слишком сильно отстаёт, чтобы её можно было восстановить инкрементным клонированием, Selena выполняет полное клонирование для восстановления потерянной replica.

После обнаружения replica tablet, требующих восстановления, FE генерирует задачу планирования tablet и добавляет задачу в очередь задач планирования. Tablet Scheduler в FE получает задачу планирования из очереди, создаёт задачи клонирования для каждой неисправной replica в соответствии с типом клонирования, который им нужен, и назначает задачи исполнительным узлам BE.

Задача клонирования по сути представляет собой копирование данных с исходного узла BE (на котором находится здоровая replica) и загрузку данных на целевой узел BE (на котором находится неисправная replica). Для replica с отстающей версией данных FE назначает задачу инкрементного клонирования исполнителю BE, который хранит неисправную replica, и сообщает исполнительному узлу BE, с какого однорангового узла BE он может найти здоровую replica и клонировать новые данные. Если replica потеряна, FE выбирает выживший узел BE в качестве исполнительного узла BE, создаёт пустую replica на узле BE и назначает задачу полного клонирования узлу BE.

Для каждой задачи клонирования, независимо от её типа, исполнительный узел BE дублирует физические файлы данных со здоровой replica, а затем соответствующим образом обновляет свои метаданные. После завершения задачи клонирования исполнительный узел BE сообщает об успехе задачи в Tablet Scheduler в FE. После удаления избыточных replica tablet FE обновляет свои метаданные, отмечая завершение восстановления replica.

Replica-2

Во время восстановления tablet Selena по-прежнему может выполнять запросы. Selena может загружать данные в таблицу, пока количество здоровых replica удовлетворяет write_quorum.

Ручное восстановление реплик

Ручное восстановление replica состоит из двух шагов:

  1. Проверка статуса replica.
  2. Установка уровня приоритета replica.

Проверка статуса реплик

Следуйте этим шагам, чтобы проверить статус replica tablet для идентификации нездоровых (неисправных) tablet.

  1. Проверьте статус всех tablet в cluster.

    SHOW PROC '/statistic';

    Пример:

    mysql> SHOW PROC '/statistic';
    +----------+-----------------------------+----------+--------------+----------+-----------+------------+--------------------+-----------------------+
    | DbId | DbName | TableNum | PartitionNum | IndexNum | TabletNum | ReplicaNum | UnhealthyTabletNum | InconsistentTabletNum |
    +----------+-----------------------------+----------+--------------+----------+-----------+------------+--------------------+-----------------------+
    | 35153636 | default_cluster:DF_Newrisk | 3 | 3 | 3 | 96 | 288 | 0 | 0 |
    | 48297972 | default_cluster:PaperData | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
    | 5909381 | default_cluster:UM_TEST | 7 | 7 | 10 | 320 | 960 | 1 | 0 |
    | Total | 240 | 10 | 10 | 13 | 416 | 1248 | 1 | 0 |
    +----------+-----------------------------+----------+--------------+----------+-----------+------------+--------------------+-----------------------+
    • UnhealthyTabletNum: указывает количество нездоровых tablet в соответствующей базе данных.
    • InconsistentTabletNum: указывает количество tablet, replica которых несогласованы.

    Если значение UnhealthyTabletNum или InconsistentTabletNum не равно 0 в конкретной базе данных, вы можете проверить нездоровые tablet в базе данных по её DbId.

    SHOW PROC '/statistic/<DbId>'

    Пример:

    mysql> SHOW PROC '/statistic/5909381';
    +------------------+---------------------+
    | UnhealthyTablets | InconsistentTablets |
    +------------------+---------------------+
    | [40467980] | [] |
    +------------------+---------------------+

    ID нездорового tablet возвращается в поле UnhealthyTablets.

  2. Проверьте статус tablet в конкретной таблице или partition.

    Вы можете использовать предложение WHERE в ADMIN SHOW REPLICA STATUS для фильтрации tablet с определённым STATUS.

    ADMIN SHOW REPLICA STATUS FROM <table_name>
    [PARTITION (<partition_name_1>[, <partition_name_2>, ...])]
    [WHERE STATUS = {'OK'|'DEAD'|'VERSION_ERROR'|'SCHEMA_ERROR'|'MISSING'}]

    Пример:

    mysql> ADMIN SHOW REPLICA STATUS FROM tbl 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, этот tablet повреждён.

    Подробную информацию, предоставляемую в поле Status, см. в ADMIN SHOW REPLICA STATUS.

    Вы можете дополнительно изучить детали tablet в таблице с помощью SHOW TABLET.

    SHOW TABLET FROM <table_name>

    Пример:

    mysql> SHOW TABLET 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 |
    +----------+-----------+-----------+------------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+----------+----------+--------+-------------------------+--------------+----------------------+--------------+----------------------+----------------------+----------------------+

    Возвращаемые результаты показывают размер, количество строк, версию и URL tablet.

    Поле State, возвращаемое SHOW TABLET, указывает состояние задачи tablet, включая CLONE, SCHEMA_CHANGE и ROLLUP.

    Вы также можете проверить распределение replica конкретной таблицы или partition, чтобы увидеть, равномерно ли распределены эти replica, используя ADMIN SHOW REPLICA DISTRIBUTION.

    ADMIN SHOW REPLICA DISTRIBUTION FROM <table_name>

    Пример:

    mysql> ADMIN 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 % |
    +-----------+------------+-------+---------+

    Возвращаемые результаты показывают количество replica tablet на каждом узле BE и их соответствующие процентные доли.

  3. Проверьте статус replica конкретного tablet.

    С помощью TabletId нездоровых tablet, полученных в предыдущих процедурах, вы можете изучить статусы replica.

    SHOW TABLET <TabletId>

    Пример:

    mysql> 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'; |
    +------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+

    Возвращаемые результаты показывают подробную информацию о базе данных, таблице, partition и индексе (Rollup) tablet.

    Вы можете скопировать SQL-выражение из поля DetailCmd для дальнейшего изучения статуса replica tablet.

    Пример:

    mysql> 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 |
    +-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+

    Возвращаемые результаты показывают все replica tablet.

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

Tablet Scheduler автоматически назначает разный уровень приоритета каждому типу задачи клонирования.

Если вы хотите, чтобы tablet из определённой таблицы или определённых partition были восстановлены в первую очередь, вы можете вручную назначить им уровень приоритета VERY_HIGH с помощью ADMIN REPAIR TABLE.

ADMIN REPAIR TABLE <table_name>
[PARTITION (<partition_name_1>[, <partition_name_2>, ...])]

ПРИМЕЧАНИЕ

  • Выполнение этого SQL-выражения только отправляет подсказку для изменения уровня приоритета tablet, которые должны быть восстановлены. Это не гарантирует, что эти tablet будут успешно восстановлены.
  • Tablet Scheduler может по-прежнему назначать разные уровни приоритета этим tablet после выполнения этого SQL-выражения.
  • Когда Leader FE узел изменяется или перезапускается, подсказка, отправленная этим SQL-выражением, истекает.

Вы можете отменить эту операцию с помощью ADMIN CANCEL REPAIR TABLE.

ADMIN CANCEL REPAIR TABLE <table_name>
[PARTITION (<partition_name_1>[, <partition_name_2>, ...])]

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

Selena автоматически балансирует tablet между узлами BE.

Чтобы переместить tablet с узла с высокой нагрузкой на узел с низкой нагрузкой, Selena сначала создаёт replica tablet на узле с низкой нагрузкой, а затем удаляет соответствующую replica на узле с высокой нагрузкой. Если в cluster используются разные типы носителей данных, Selena категоризирует все узлы BE в соответствии с типами носителей данных. Selena перемещает tablet между узлами BE одного типа носителя данных, когда это возможно. Replica одного tablet хранятся на разных узлах BE.

Нагрузка BE

Selena показывает статистику нагрузки каждого узла BE в cluster с помощью ClusterLoadStatistics (CLS). Tablet Scheduler запускает балансировку replica на основе ClusterLoadStatistics. Selena оценивает использование диска и количество replica каждого узла BE и вычисляет loadScore соответственно. Чем выше loadScore узла BE, тем выше нагрузка на узел. Tablet Scheduler обновляет ClusterLoadStatistics каждую минуту.

capacityCoefficient и replicaNumCoefficient — это весовые коэффициенты для использования диска и количества replica соответственно. Сумма capacityCoefficient и replicaNumCoefficient равна единице. capacityCoefficient динамически регулируется в соответствии с фактическим использованием диска. Когда общее использование диска узла BE ниже 50%, значение capacityCoefficient равно 0.5. Когда использование диска выше 75%, значение равно 1. Вы можете настроить этот лимит через элемент конфигурации FE capacity_used_percent_high_water. Если использование находится между 50% и 75%, capacityCoefficient увеличивается плавно на основе этой формулы:

capacityCoefficient= 2 * Использование диска - 0.5

capacityCoefficient гарантирует, что когда использование диска чрезмерно высоко, loadScore этого узла BE становится выше, заставляя систему снизить нагрузку на этот узел BE в кратчайшие сроки.

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

Каждый раз, когда Tablet Scheduler планирует tablet, он выбирает определённое количество здоровых tablet в качестве кандидатов для балансировки через Load Balancer. В следующий раз при планировании tablet Tablet Scheduler балансирует эти здоровые tablet.

Просмотр статуса балансировки системы

Вы можете просмотреть текущий общий статус балансировки системы и детали различных типов балансировки.

  • Просмотр текущего общего статуса балансировки системы:

    SHOW PROC '/cluster_balance/balance_stat';

    Пример:

    +---------------+--------------------------------+----------+----------------+----------------+
    | StorageMedium | BalanceType | Balanced | PendingTablets | RunningTablets |
    +---------------+--------------------------------+----------+----------------+----------------+
    | HDD | inter-node disk usage | true | 0 | 0 |
    | HDD | inter-node tablet distribution | true | 0 | 0 |
    | HDD | intra-node disk usage | true | 0 | 0 |
    | HDD | intra-node tablet distribution | true | 0 | 0 |
    | HDD | colocation group | true | 0 | 0 |
    | HDD | label-aware location | true | 0 | 0 |
    +---------------+--------------------------------+----------+----------------+----------------+
    • StorageMedium: Носитель данных.
    • BalanceType: Тип балансировки.
    • Balanced: Достигнуто ли сбалансированное состояние.
    • PendingTablets: Количество tablet со статусом задачи Pending.
    • RunningTablets: Количество tablet со статусом задачи Running.
  • Просмотр баланса использования диска по узлам:

    SHOW PROC '/cluster_balance/cluster_load_stat';

    Пример:

    +---------------+----------------------------------------------------------------------------------------------------------------------+
    | StorageMedium | ClusterDiskBalanceStat |
    +---------------+----------------------------------------------------------------------------------------------------------------------+
    | HDD | {"balanced":false,"maxBeId":1,"minBeId":2,"maxUsedPercent":0.9,"minUsedPercent":0.1,"type":"INTER_NODE_DISK_USAGE"} |
    | SSD | {"balanced":true} |
    +---------------+----------------------------------------------------------------------------------------------------------------------+
    • StorageMedium: Носитель данных.
    • ClusterDiskBalanceStat: Статус балансировки между узлами на основе использования диска. Если не сбалансировано, отображает максимальное и минимальное использование диска и соответствующие BE.
  • Просмотр баланса использования диска внутри узла:

    SHOW PROC '/cluster_balance/cluster_load_stat/HDD';

    Пример:

    +-------+-----------------+-----------+--------------+--------------+-------------+------------+----------+-----------+-------+-------+---------------------------------------------------------------------------------------------------------------------------------------------+
    | BeId | Cluster | Available | UsedCapacity | Capacity | UsedPercent | ReplicaNum | CapCoeff | ReplCoeff | Score | Class | BackendDiskBalanceStat |
    +-------+-----------------+-----------+--------------+--------------+-------------+------------+----------+-----------+-------+-------+---------------------------------------------------------------------------------------------------------------------------------------------+
    | 10004 | default_cluster | true | 651509602 | 243695955810 | 0.267 | 339 | 0.5 | 0.5 | 1.0 | MID | {"maxUsedPercent":0.9,"minUsedPercent":0.1,"beId":1,"maxPath":"/disk1","minPath":"/disk2","type":"INTRA_NODE_DISK_USAGE","balanced":false} |
    | 10005 | default_cluster | true | 651509602 | 243695955810 | 0.267 | 339 | 0.5 | 0.5 | 1.0 | MID | {"balanced":true} |
    +-------+-----------------+-----------+--------------+--------------+-------------+------------+----------+-----------+-------+-------+---------------------------------------------------------------------------------------------------------------------------------------------+
    • BeId: ID узла BE.
    • BackendDiskBalanceStat: Статус балансировки между дисками внутри узла на основе использования диска. Если не сбалансировано, отображает максимальное и минимальное использование диска и соответствующие пути к дискам.
  • Просмотр сбалансированного распределения по tablet:

    SHOW PROC '/dbs/ssb/lineorder/partitions/lineorder';

    Пример:

    +---------+-----------+--------+--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------+
    | IndexId | IndexName | State | LastConsistencyCheckTime | TabletBalanceStat |
    +---------+-----------+--------+--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------+
    | 11129 | lineorder | NORMAL | NULL | {"maxTabletNum":23,"minTabletNum":21,"maxBeId":10012,"minBeId":10013,"type":"INTER_NODE_TABLET_DISTRIBUTION","balanced":false} |
    | 11230 | lineorder | NORMAL | NULL | {"maxTabletNum":23,"minTabletNum":21,"beId":10012,"maxPath":"/disk1","minPath":"/disk2","type":"INTRA_NODE_TABLET_DISTRIBUTION","balanced":false} |
    | 10432 | lineorder | NORMAL | NULL | {"tabletId":10435,"currentBes":[10002,10004],"expectedBes":[10003,10004],"type":"COLOCATION_GROUP","balanced":false} |
    | 10436 | lineorder | NORMAL | NULL | {"tabletId":10438,"currentBes":[10005,10006],"expectedLocations":{"rack":["rack1","rack2"]},"type":"LABEL_AWARE_LOCATION","balanced":false} |
    +---------+-----------+--------+--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------+
    • IndexId: ID материализованного индекса внутри partition.
    • TabletBalanceStat: Статус балансировки распределения tablet между узлами или внутри узлов. Если не сбалансировано, отображает детали дисбаланса, включая Colocation Group, Label-aware Location.
  • Просмотр partition с несбалансированным распределением tablet:

    SELECT DB_NAME, TABLE_NAME, PARTITION_NAME, TABLET_BALANCED FROM information_schema.partitions_meta WHERE TABLET_BALANCED = 0;

    Пример:

    +--------------+---------------+----------------+-----------------+
    | DB_NAME | TABLE_NAME | PARTITION_NAME | TABLET_BALANCED |
    +--------------+---------------+----------------+-----------------+
    | ssb | lineorder | lineorder | 0 |
    +--------------+---------------+----------------+-----------------+
    • TABLET_BALANCED: сбалансировано ли распределение tablet.

Проверка задач планирования tablet

Вы можете проверить задачи планирования tablet, которые находятся в ожидании, выполняются и завершены.

  • Проверка ожидающих задач планирования tablet

    SHOW PROC '/cluster_balance/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: сообщение об ошибке, возникающее при планировании и выполнении задачи.
  • Проверка выполняющихся задач планирования tablet

    SHOW PROC '/cluster_balance/running_tablets';

    Возвращаемые результаты идентичны результатам для ожидающих задач.

  • Проверка завершённых задач планирования tablet

    SHOW PROC '/cluster_balance/history_tablets';

    Возвращаемые результаты идентичны результатам для ожидающих задач. Если State задачи — FINISHED, задача успешно завершена. Если нет, пожалуйста, проверьте поле ErrMsg для определения причины неудачи задачи.

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

Поскольку Selena восстанавливает и балансирует tablet путём клонирования tablet с одного узла BE на другой, нагрузка ввода-вывода узла BE может резко возрасти, если узел выполняет такие задачи слишком часто за короткое время. Чтобы избежать этой ситуации, Selena устанавливает лимит параллелизма для задач клонирования для каждого узла BE. Минимальная единица управления ресурсами — это диск, который представляет собой путь хранения данных (storage_root_path), указанный вами в файле конфигурации BE. По умолчанию Selena выделяет два слота для каждого диска для обработки задач восстановления tablet. Задача клонирования занимает один слот на исходном узле BE и один на целевом узле BE. Если все слоты на узле BE заняты, Selena прекращает планирование задач на этот узел. Вы можете увеличить количество слотов на узле BE, увеличив значение динамического параметра FE tablet_sched_slot_num_per_path.

Selena выделяет два слота специально для задач балансировки tablet, чтобы избежать ситуации, когда узел BE с высокой нагрузкой не может освободить дисковое пространство путём балансировки tablet, потому что задачи восстановления tablet постоянно занимают слоты.