Перейти к основному содержимому

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

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

Обзор​

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

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

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

Replica-1

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

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

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

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

  4. Координирующий BE узел распределяет данные по всем репликам tablet'ов.

    ПРИМЕЧАНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Replica-2

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

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

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

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

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

Выполните эти шаги для проверки статуса реплик tablet'ов для идентификации нездоровых (неисправных) tablet'ов.

  1. Проверьте статус всех tablet'ов в кластере.

    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'ов, реплики которых несогласованы.

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

    SHOW PROC '/statistic/<DbId>'

    Пример:

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

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

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

    Вы можете использовать предложение 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.

    Вы также можете проверить распределение реплик конкретной таблицы или раздела, чтобы увидеть, распределены ли эти реплики равномерно, используя 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 % |
    +-----------+------------+-------+---------+

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

  3. Проверьте статус реплик конкретного tablet'а.

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

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

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

    Вы можете скопировать SQL-оператор в поле DetailCmd для дальнейшего изучения статуса реплик 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              |
    +-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+

    Возвращенные результаты показывают все реплики tablet'а.

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

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

Если вы хотите, чтобы tablet'ы из определенной таблицы или определенных разделов были восстановлены в самую первую очередь, вы можете вручную назначить им уровень приоритета 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 сначала создает реплику tablet'а в низконагруженном узле, а затем удаляет соответствующую реплику на высоконагруженном узле. Если в кластере используются различные типы носителей хранения, Selena категоризирует все BE узлы в соответствии с типами носителей хранения. Selena перемещает tablet между BE узлами одного типа носителя хранения, когда это возможно. Реплики одного tablet'а хранятся на разных BE узлах.

Нагрузка BE​

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

capacityCoefficient и replicaNumCoefficient являются весовыми факторами для использования диска и количества реплик соответственно. Сумма 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'ы.

Проверка задач планирования 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 узла на другой, нагрузка I/O 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'ов постоянно занимают слоты.