Manticore Search 29.0.2 уже выпущен. На этот раз основной акцент операционный: шардированные и распределенные таблицы проще проверять и обслуживать, долгие записи в шарды стали надежнее, а также исправлены несколько неприятных сценариев отказа вокруг оптимизации RT и резервного копирования.
Этот пост охватывает все изменения после 28.6.6, от 28.6.7 до 29.0.2.
Заметки по обновлению
Большинство установок можно обновлять обычным образом. Формат таблиц не менялся, и существующие данные и конфигурация остаются совместимыми.
Есть одно важное замечание для развертываний с разными версиями, где используются нативные записи в шардированные таблицы или передача состояния репликации (SST): в 29.0.0 изменились внутренний API SHARD_WRITE и кластерный протокол, чтобы передавать данные heartbeat. Сначала обновляйте удаленные shard-агенты, а уже потом координаторы, которые пишут в них. Для репликации перед запуском SST обновите все узлы-пиры.
Для автономных узлов и развертываний, где не используются ни нативные записи в шардированные таблицы, ни SST репликации, никакой специальной подготовки не требуется. Понижение версии тоже возможно без перестройки данных, но сначала следует откатить координаторы, а уже потом агенты, и SST не должен выполняться, пока у репликационных пиров разные версии.
Нативный OPTIMIZE для распределенных и шардированных таблиц
OPTIMIZE TABLE
теперь может напрямую уплотнять распределенные и шардированные таблицы:
OPTIMIZE TABLE products OPTION sync=1, cutoff=1;
Для распределенной таблицы Manticore применяет заданный cutoff к каждому локальному RT-компоненту и каждому настроенному удаленному зеркалу. Нативные шардированные таблицы используют тот же синхронный fan-out на все свои физические RT-таблицы.
Раньше операторам приходилось обращаться к этим физическим таблицам по отдельности. Теперь достаточно логической таблицы. Для таких типов таблиц команда по замыслу синхронная, поэтому успех означает, что запрошенная работа завершена на всех выбранных целях; ошибки удаленных целей не скрываются за успешным локальным ответом.
Настройки шардированных таблиц видны
SHOW TABLE SETTINGS
теперь работает для нативных шардированных таблиц:
SHOW TABLE products SETTINGS;
Она возвращает единые настройки tokenizer, dictionary и таблицы, хранимые оберткой шардированной таблицы. Помимо пользы при ручной отладке таблицы, это также дает функциям на базе Buddy надежный способ проверять, как настроена логическая таблица.
Долгие записи в шарды больше не зависят от завышенных таймаутов
Векторная таблица может тратить секунды на построение данных HNSW, пока выгружается RAM chunk. На шардированной таблице это могло превышать agent_query_timeout: координатор сдавался бы, хотя удаленный узел продолжал выполнять корректную работу.
Теперь Manticore отправляет heartbeat-ответы по тому же соединению во время долгих записей в шард. Каждый валидный heartbeat продлевает таймаут по скользящей схеме аренды, поэтому соединение остается живым, пока операция продвигается вперед. Больше не нужно прятать нормальное время flush за чрезмерно большим query timeout.
Та же транспортная схема используется для долгих операций SST репликации и для синхронной оптимизации распределенных таблиц. Это также объясняет замечание о развертывании с разными версиями выше.
Больше контроля в векторном поиске
Этот релиз добавляет access_columnar_attrs и access_secondary, позволяя файлам columnar и вторичного индекса использовать буферизованный доступ file или mmap. Это дает операторам прямой способ выбрать режим доступа, который подходит под хост и нагрузку, вместо одного фиксированного поведения.
Columnar KNN search также выполняет меньше работы на каждого кандидата при пересчете. Теперь вычисления расстояния в полной точности батчатся перед финальной сортировкой. Набор результатов не меняется; просто у финального этапа ранжирования меньше накладных расходов.
Разговорный поиск тоже получил небольшое улучшение надежности: неудачные вызовы инструмента для выбора маршрута LLM теперь повторяются до трех раз, прежде чем возвращается ошибка.
Исправления надежности
Оптимизация RT и KNN
Одновременное обновление, которое увеличивало blob-backed атрибут, могло переназначить исходный disk chunk, пока OPTIMIZE TABLE сливал его. После этого workers слияния могли продолжить работу через устаревший адрес памяти и уронить searchd. Теперь исходные адреса обновляются после точек планирования слияния, что покрывает как обычное копирование атрибутов, так и построение KNN. (Issue #4780
)
Явные значения optimize_cutoff
теперь также управляют порогом уплотнения KNN. Векторные таблицы больше не продолжают использовать отдельное значение по умолчанию, если задан серверный или табличный cutoff. (Issue #4738
)
Резервные копии и совместимость клиентов
Manticore Backup
1.10.3 исправляет еще один сценарий отказа, связанный с зависанием. Если резервное копирование завершается с ошибкой после табличного FREEZE — например, потому что замороженный файл исчезает до копирования, — оба уровня freeze теперь снимаются, а RT-таблица остается доступной для записи. (Backup PR #140
)
Buddy 4.4.1 восстанавливает инициализацию MySQL Connector/J за счет поддержки @@query_cache_size и числовых значений системных переменных в запросе инициализации. (Issue #4434
)
Проверка запросов, подсветка и распределенная память
CALL SNIPPETS и HIGHLIGHT()теперь сохраняют существующие границы HTML-элементов приhtml_strip_mode=retain, формируя корректную вложенную разметку. (Issue #4792 )SHOW THREADSбольше не рискует use-after-free при анализе параллельных HTTP SQL-запросов. (Issue #4678 )EXPLAIN QUERYбольше не зависает на template tables, когда полнотекстовый запрос содержит селекторы полей. Неверные селекторы теперь возвращают синтаксическую ошибку. (PR #4777 )- Завершенные операции distributed-agent теперь освобождают большие буферы запросов и ответов после разбора, вместо того чтобы удерживать их до истечения
agent_query_timeout. Это уменьшает потребление памяти master-daemon после больших распределенных запросов. (Issue #4771 )
Полный список см. в журнале изменений версии 29.0.2 .
Получите Manticore Search 29.0.2
Установите или обновите Manticore Search по руководству по установке . Если вы используете нативные шардированные таблицы или кластер репликации, соблюдайте порядок развертывания из заметок по обновлению, прежде чем менять production-трафик.
Нужна помощь или хотите связаться с нами?
- Присоединяйтесь к нашему Slack
- Посетите Forum
- Сообщайте о проблемах или предлагайте идеи на GitHub
- Пишите нам на
[email protected]

