Manticore Search — это высокораспределённая система, которая предоставляет все необходимые компоненты для создания высокодоступной и масштабируемой базы данных для поиска. Это включает:
- распределённую таблицу для шардинга
- Зеркалирование для высокой доступности
- Балансировку нагрузки для масштабируемости
- Репликацию для безопасности данных
Manticore Search предлагает большую гибкость в том, как вы настраиваете свой кластер. Ограничений нет, поэтому вы сами можете спроектировать кластер в соответствии с вашими потребностями. Просто изучите перечисленные выше инструменты и используйте их для достижения желаемой цели.
Чтобы добавить новый узел в кластер, просто запустите еще один экземпляр Manticore и убедитесь, что он доступен для остальных узлов кластера. Подключите новый узел к остальным узлам кластера, используя распределенную таблицу, и обеспечьте безопасность данных с помощью репликации.
Для понима как добата табли с уда агents, важно first иметь базовое understanding о distributed tables In this article, we will focus на как использовать distributed table как basis для созда кластер Мanticore instances.
Here is example как split data over 4 servers, each serving one of shards:
- ini
table mydist {
type = distributed
agent = box1:9312:shard1
agent = box2:9312:shard2
agent = box3:9312:shard3
agent = box4:9312:shard4
}In event server failure, distributed table will still work, but results from failed shard will be missing.
Now that we've added mirrors, each shard is found on 2 servers. By default, master (searchd instance with distributed table) will randomly pick one of mirrors.
Mode used for picking mirrors can be set using ha_strategy setting. In addition to default random mode there's also ha_strategy = roundrobin.
More advanced strategies based on latency-weighted probabilities include noerrors and nodeads. These not only take out mirrors with issues but also monitor response times and do balancing. If mirror responds slower (for example, due to some operations running on it), it will receive fewer requests. When mirror recovers and provides better times, it will receive more requests.
- ini
table mydist {
type = distributed
agent = box1:9312|box5:9312:shard1
agent = box2:9312:|box6:9312:shard2
agent = box3:9312:|box7:9312:shard3
agent = box4:9312:|box8:9312:shard4
}Балансировка нагрузки включена по умолчанию для любой распределенной таблицы, использующей зеркалирование. По умолчанию запросы распределяются случайным образом между зеркалами. Это поведение можно изменить с помощью ha_strategy.
ha_strategy = {random|nodeads|noerrors|roundrobin}Стратегия выбора зеркала для балансировки нагрузки является опциональной и по умолчанию установлена в значение random.
ha_strategy может быть установлена глобально в конфигурации searchd или для каждой распределенной таблицы отдельно. Эта директива управляет стратегией выбора зеркала, или, другими словами, выбором конкретного зеркала агента в распределенной таблице. На практике эта директива контролирует, как мастер балансирует запросы между зеркальными узлами агентов. Реализованы следующие стратегии:
Режим балансировки по умолчанию — простая линейная случайная выборка среди зеркал. Каждому зеркалу назначаются равные вероятности выбора. Это похоже на циклический перебор (round-robin, RR), но не накладывает строгого порядка выбора.
- Config
- SQL
ha_strategy = randomCREATE TABLE products_dist type='distributed'
agent='127.0.0.1:9312:products|127.0.0.1:9313:products'
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 = nodeadsCREATE TABLE products_dist type='distributed'
agent='127.0.0.1:9312:products|127.0.0.1:9313:products'
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 = noerrorsCREATE TABLE products_dist type='distributed'
agent='127.0.0.1:9312:products|127.0.0.1:9313:products'
ha_strategy='noerrors';Простой циклический выбор, то есть выбор первого зеркала в списке, затем второго, затем третьего и так далее, с повторением процесса после достижения последнего зеркала в списке. В отличие от рандомизированных стратегий, RR устанавливает строгий порядок запросов (1, 2, 3, ..., N-1, N, 1, 2, 3, ... и так далее) и гарантирует, что два последовательных запроса не будут отправлены на одно и то же зеркало, пока все зеркала работоспособны.
- Config
- SQL
ha_strategy = roundrobinCREATE TABLE products_dist type='distributed'
agent='127.0.0.1:9312:products|127.0.0.1:9313:products'
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
}CREATE TABLE products_rr type='distributed'
agent='127.0.0.1:9312:products|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 = 300msCREATE TABLE products_dist type='distributed'
agent='127.0.0.1:9312:products|127.0.0.1:9313:products'
agent_connect_timeout='300ms';agent_query_timeout определяет, сколько времени Manticore ожидает, чтобы подключенный удалённый агент завершил запрос. Он поддерживается как настройка по умолчанию для всего экземпляра, для каждой распределённой таблицы и для каждого запроса как OPTION agent_query_timeout=.... Полные детали находятся в Searchd: agent_query_timeout и Remote tables: agent_query_timeout.
Если достигается agent_query_timeout, запрос не повторяется автоматически; вместо этого выводится предупреждение.
- Config
- SQL
agent_query_timeout = 500msSELECT * FROM products_dist OPTION agent_query_timeout=750;agent_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]
}SELECT * FROM products_dist OPTION retry_count=1;agent_retry_delay определяет задержку между попытками повторения. Он поддерживается как настройка по умолчанию для всего экземпляра и для каждого запроса как OPTION retry_delay=..., но не для каждой распределённой таблицы. Полные детали находятся в Searchd: agent_retry_delay.
Эта опция имеет значение только когда повторения включены через agent_retry_count или OPTION retry_count=....
- Config
- SQL
agent_retry_delay = 500msSELECT * FROM products_dist OPTION retry_count=2, retry_delay=300;