Балансировка нагрузки включена по умолчанию для любой распределенной таблицы, использующей зеркалирование. По умолчанию запросы распределяются случайным образом между зеркалами. Это поведение можно изменить с помощью ha_strategy.
ha_strategy = {random|nodeads|noerrors|roundrobin}Стратегия выбора зеркала для балансировки нагрузки является опциональной и по умолчанию установлена в значение random.
ha_strategy может быть установлена глобально в конфигурации searchd или для каждой распределенной таблицы отдельно. Эта директива управляет стратегией выбора зеркала, или, другими словами, выбором конкретного зеркала агента в распределенной таблице. На практике эта директива контролирует, как мастер балансирует запросы между зеркальными узлами агентов. Реализованы следующие стратегии:
Режим балансировки по умолчанию — простая линейная случайная выборка среди зеркал. Каждому зеркалу назначаются равные вероятности выбора. Это похоже на циклический перебор (round-robin, RR), но не накладывает строгого порядка выбора.
- Config
- SQL
ha_strategy = randomПростая случайная стратегия по умолчанию не учитывает статус зеркал, частоту ошибок и, что наиболее важно, фактическую задержку ответов. Для работы с неоднородными кластерами и временными всплесками нагрузки на узлах агентов существует группа стратегий балансировки, которые динамически корректируют вероятности на основе задержек запросов, наблюдаемых мастером.
Адаптивные стратегии, основанные на вероятностях, взвешенных по задержке, работают следующим образом. Размер окна статистики контролируется параметром ha_period_karma, в то время как проверка работоспособности неактивных зеркал и отслеживание времени кругового оборота управляются параметром ha_ping_interval. Оба параметра описаны далее на этой странице и в разделе Настройки Searchd.
- Статистика задержек накапливается блоками по
ha_period_karmaсекунд. - Вероятности, взвешенные по задержкам, пересчитываются один раз за период кармы.
- Флаг "живой или мёртвый" корректируется на каждый запрос, включая ping-запросы.
Изначально вероятности равны. На каждом шаге они масштабируются обратными значениями задержек, наблюдаемых в течение последнего периода кармы, а затем нормализуются заново. Например, если в первые 60 секунд после запуска мастера 4 зеркала показали задержки 10 мс, 5 мс, 30 мс и 3 мс соответственно, то первый шаг корректировки будет следующим:
- Исходные проценты: 0.25, 0.25, 0.25, 0.25.
- Наблюдаемые задержки: 10 мс, 5 мс, 30 мс, 3 мс.
- Обратные значения задержек: 0.1, 0.2, 0.0333, 0.333.
- Масштабированные проценты: 0.025, 0.05, 0.008333, 0.0833.
- Нормализованные проценты: 0.15, 0.30, 0.05, 0.50.
Это означает, что первое зеркало будет иметь 15% шанс быть выбранным в следующий период кармы, второе — 30%, третье (самое медленное, с задержкой 30 мс) — только 5%, а четвёртое и самое быстрое (3 мс) — 50%. После этого периода второй шаг корректировки снова обновит эти шансы и так далее.
Идея в том, что как только наблюдаемые задержки стабилизируются, вероятности, взвешенные по задержке, также стабилизируются. Все эти итерации корректировки предназначены для сходимости к точке, где средние задержки примерно равны на всех зеркалах.
Вероятности, взвешенные по задержке, но зеркала со слишком большим количеством последовательных неудачных попыток исключаются из выбора. Счетчик последовательных ошибок сбрасывается только полностью успешным запросом. Предупреждения не сбрасывают его. Зеркало начинает считаться мертвым после более чем 3 последовательных неуспешных исходов, поэтому первые 3 неудачи подряд допускаются, но 4-я делает это зеркало непригодным для выбора по стратегии nodeads, пока оно снова не ответит успешно.
- Config
- SQL
ha_strategy = nodeadsВероятности, взвешенные по задержке, но зеркала с худшим недавним соотношением ошибок/успехов понижаются в приоритете и могут быть исключены из выбора.
noerrors анализирует недавние счетчики для каждого зеркала, собранные за последние окна ha_period_karma. Сначала он сравнивает соотношение критических сбоев транспорта (connect_timeouts, connect_failures, network_errors, wrong_replies, unexpected_closings) к общей недавней активности. Соотношения на уровне 3% или ниже считаются практически нулевыми. Если несколько зеркал имеют одинаковый результат, затем сравнивается более широкое соотношение ошибок, которое также включает ответы с предупреждениями. Зеркала без успешных запросов вообще в последнем окне полностью пропускаются.
Таким образом, noerrors наиболее полезен для периодических сбоев на транспортном уровне и деградировавших зеркал, а не как гарантия того, что каждая логическая проблема удаленной таблицы исчезнет немедленно. Например, если одно зеркало указывает на отсутствующую таблицу, вы все равно можете увидеть сбои запросов, прежде чем это зеркало накопит достаточно плохой истории, чтобы перестать быть предпочтительным. Используйте SHOW AGENT STATUS для проверки недавних успехов, предупреждений и сетевых ошибок для каждого зеркала.
- Config
- SQL
ha_strategy = noerrorsПростой циклический выбор, то есть выбор первого зеркала в списке, затем второго, затем третьего и так далее, с повторением процесса после достижения последнего зеркала в списке. В отличие от рандомизированных стратегий, RR устанавливает строгий порядок запросов (1, 2, 3, ..., N-1, N, 1, 2, 3, ... и так далее) и гарантирует, что два последовательных запроса не будут отправлены на одно и то же зеркало, пока все зеркала работоспособны.
- Config
- SQL
ha_strategy = roundrobinПредположим, что зеркальные распределенные таблицы уже существуют, например:
CREATE TABLE products_random type='distributed'
agent='127.0.0.1:9312:products|127.0.0.1:9313:products';
CREATE TABLE products_rr type='distributed'
agent='127.0.0.1:9312:products|127.0.0.1:9313:products'
ha_strategy='roundrobin';Разница между random и roundrobin становится заметной при повторяющихся запросах к зеркальным распределенным таблицам.
- SQL
SELECT node FROM products_random;
SELECT node FROM products_random;
SELECT node FROM products_rr;
SELECT node FROM products_rr;+-------+
| node |
+-------+
| node2 |
+-------+
+-------+
| node |
+-------+
| node1 |
+-------+
+-------+
| node |
+-------+
| node1 |
+-------+
+-------+
| node |
+-------+
| node2 |
+-------+SHOW AGENT STATUS — это основной инструмент отладки для зеркальных распределенных таблиц. Полный синтаксис оператора и все форматы вывода смотрите в SHOW AGENT STATUS. Для балансировки нагрузки наиболее полезными полями являются:
ag_N_pingtripmsec— текущее время кругового пути пинга для зеркалаNag_N_errorsarow— последовательные неуспешные результаты; это то, за чем фактически следитnodeadsag_N_1periods_connect_timeouts,connect_failures,network_errors,wrong_replies,unexpected_closings— недавние транспортные сбоиag_N_1periods_warnings— ответы, которые завершились успешно, но вернули предупрежденияag_N_1periods_succeeded_queries— недавние успешные запросыag_N_1periods_msecsperquery— недавнее среднее время запроса
Эти счетчики за период отчитываются за скользящие окна 1, 5 и 15, где каждое окно имеет длину ha_period_karma секунд.
Используйте эти команды на мастере, чтобы проверить, что было сохранено и как ведут себя зеркала.
- SQL
SHOW CREATE TABLE products_rr;
SHOW AGENT STATUS;
SHOW AGENT STATUS LIKE '%errorsarow%';
SHOW AGENT STATUS LIKE '%1periods_%';+---------------------------------+-------+
| Key | Value |
+---------------------------------+-------+
| ag_0_pingtripmsec | 0.233 |
| ag_0_errorsarow | 0 |
| ag_0_1periods_network_errors | 0 |
| ag_0_1periods_warnings | 0 |
| ag_0_1periods_succeeded_queries | 11 |
| ag_0_1periods_msecsperquery | n/a |
+---------------------------------+-------+Практическая интерпретация:
- Если
errorsarowпревышает 3,nodeadsначинает считать это зеркало неработоспособным. - Если у зеркала нет недавних
succeeded_queries,noerrorsполностью пропустит его. - Если у нескольких зеркал низкий коэффициент ошибок,
noerrorsвсе равно предпочтет те, у которых меньше задержка, потому что обычная перебалансировка весов остается в силе. pingtripmsecпомогает отличить "доступные, но медленные" зеркала от "сбойных".
Опции, связанные с зеркалированием, таймаутами и повторными попытками, поддерживаются не во всех областях видимости одновременно. Эта страница фокусируется на том, как они влияют на балансировку нагрузки. Полный синтаксис и поведение на уровне демона смотрите на связанных справочных страницах.
| Опция | Для всего экземпляра | На таблицу | На запрос | На агента | Полные детали |
|---|---|---|---|---|---|
ha_strategy |
да | да | нет | да | Балансировка нагрузки, Удаленные таблицы |
ha_period_karma |
да | нет | нет | нет | Searchd: ha_period_karma |
ha_ping_interval |
да | нет | нет | нет | Searchd: ha_ping_interval |
agent_connect_timeout |
да | да | нет | нет | Searchd: agent_connect_timeout, Удаленные таблицы: agent_connect_timeout |
agent_query_timeout |
да | да | да | нет | Searchd: agent_query_timeout, Удаленные таблицы: agent_query_timeout |
agent_retry_count / mirror_retry_count / retry_count |
да (agent_retry_count) |
да (agent_retry_count или mirror_retry_count) |
да (OPTION retry_count=...) |
да (agent=...[retry_count=...]) |
Searchd: agent_retry_count, Удаленные таблицы: agent_retry_count, Удаленные таблицы: mirror_retry_count, Удаленные таблицы: agent |
agent_retry_delay |
да | нет | да | нет | Searchd: agent_retry_delay |
ha_strategy управляет выбором зеркальных агентов. Её можно установить глобально в searchd, для каждой распределенной таблицы или для каждого агента внутри agent = ... [ha_strategy=...]. Более узкая область видимости переопределяет более широкую.
Примеры стратегий выше уже показывают как глобальную, так и табличную формы. Синтаксис переопределения для конкретного агента смотрите в Удаленных таблицах.
Если вы хотите, чтобы одна распределенная таблица использовала стратегию балансировки, отличную от глобальной по умолчанию, установите её для этой таблицы.
- Config
- SQL
ha_strategy = random
table products_rr {
type = distributed
agent = 127.0.0.1:9312|127.0.0.1:9313:products
ha_strategy = roundrobin
}ha_period_karma определяет окно статистики зеркал агентов, используемое адаптивными стратегиями балансировки выше, и поддерживается только как настройка searchd для всего экземпляра. Полные детали на уровне демона находятся в Searchd: ha_period_karma.
- Config
ha_period_karma = 2mha_ping_interval определяет, как часто проверяются неактивные зеркала, и поддерживается только как настройка searchd на уровне всего экземпляра. Полные детали на уровне демона находятся в Searchd: ha_ping_interval.
- Config
ha_ping_interval = 3sagent_connect_timeout определяет, сколько времени Manticore ожидает для установления соединения с удалённым агентом. Он поддерживается как настройка по умолчанию для всего экземпляра и для каждой распределённой таблицы. Полные детали находятся в Searchd: agent_connect_timeout и Remote tables: agent_connect_timeout.
- Config
- SQL
agent_connect_timeout = 300msagent_query_timeout определяет, сколько времени Manticore ожидает, чтобы подключенный удалённый агент завершил запрос. Он поддерживается как настройка по умолчанию для всего экземпляра, для каждой распределённой таблицы и для каждого запроса как OPTION agent_query_timeout=.... Полные детали находятся в Searchd: agent_query_timeout и Remote tables: agent_query_timeout.
Если достигается agent_query_timeout, запрос не повторяется автоматически; вместо этого выводится предупреждение.
- Config
- SQL
agent_query_timeout = 500msagent_retry_count определяет, сколько раз Manticore повторяет работу удалённого агента перед сообщением о фатальной ошибке запроса. Имя варьируется по области применения: используйте agent_retry_count как настройку для всего экземпляра, agent_retry_count или его алиас mirror_retry_count на распределённой таблице, OPTION retry_count=... для каждого запроса и [retry_count=...] внутри отдельного объявления agent=.... Полные детали находятся в Searchd: agent_retry_count, Remote tables: agent_retry_count и Remote tables: mirror_retry_count.
Если вы используете зеркала агентов, количество повторений суммируется по всем зеркалам. Опция [retry_count=...] для каждого агента действует как абсолютное ограничение для этого конкретного объявления агента.
- Config
- SQL
table products_dist {
type = distributed
agent = 127.0.0.1:9312|127.0.0.1:9313:products[retry_count=2]
}agent_retry_delay определяет задержку между попытками повторения. Он поддерживается как настройка по умолчанию для всего экземпляра и для каждого запроса как OPTION retry_delay=..., но не для каждой распределённой таблицы. Полные детали находятся в Searchd: agent_retry_delay.
Эта опция имеет значение только когда повторения включены через agent_retry_count или OPTION retry_count=....
- Config
- SQL
agent_retry_delay = 500ms