diff --git a/.translation-cache/Server_settings/Searchd.md.json b/.translation-cache/Server_settings/Searchd.md.json
index 670602a7f8..b27ece3249 100644
--- a/.translation-cache/Server_settings/Searchd.md.json
+++ b/.translation-cache/Server_settings/Searchd.md.json
@@ -110,5 +110,85 @@
"russian": "Сервер использует файл CA для проверки подписи на сертификате. Файл должен быть в формате PEM.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_74\n\n\n\n### ssl_cert\n\n\n\nПуть к SSL-сертификату сервера. Необязательно, по умолчанию пусто.\n\nСервер использует этот сертификат как самоподписанный открытый ключ для шифрования HTTP-трафика по SSL. Файл должен быть в формате PEM.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_75\n\n\n\n### ssl_key\n\n\n\nПуть к ключу SSL-сертификата. Необязательно, по умолчанию пусто.\n\nСервер использует этот приватный ключ для шифрования HTTP-трафика по SSL. Файл должен быть в формате PEM.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_76\n\n\n\n### subtree_docs_cache\n\n\n\nМаксимальный размер кеша документов общего поддерева, на запрос. Необязательно, по умолчанию 0 (отключено).\n\nЭта настройка ограничивает использование ОЗУ оптимизатором общего поддерева (см. [multi-queries](../Searching/Multi-queries.md)). Максимум столько ОЗУ будет потрачено на кеширование записей документов для каждого запроса. Установка лимита в 0 отключает оптимизатор.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_77\n\n\n\n### subtree_hits_cache\n\n\n\nМаксимальный размер кеша попаданий общего поддерева, на запрос. Необязательно, по умолчанию 0 (отключено).\n\nЭта настройка ограничивает использование ОЗУ оптимизатором общего поддерева (см. [multi-queries](../Searching/Multi-queries.md)). Максимум столько ОЗУ будет потрачено на кеширование вхождений ключевых слов (попаданий) для каждого запроса. Установка лимита в 0 отключает оптимизатор.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_78\n\n\n\n### threads\n\n\n\nКоличество рабочих потоков (или размер пула потоков) для демона Manticore. Manticore создаёт такое количество потоков ОС при запуске, и они выполняют все задачи внутри демона, такие как выполнение запросов, создание сниппетов и т.д. Некоторые операции могут быть разбиты на подзадачи и выполняться параллельно, например:\n\n* Поиск в таблице реального времени\n\n* Поиск в распределённой таблице, состоящей из локальных таблиц\n\n* Вызов перколяции запроса\n\n* и другие\n\nПо умолчанию установлено количество ядер CPU на сервере. Manticore создаёт потоки при запуске и держит их до остановки. Каждая подзадача может использовать один из потоков, когда это необходимо. Когда подзадача завершается, она освобождает поток, чтобы другая подзадача могла его использовать.\n\nВ случае интенсивной нагрузки типа I/O может иметь смысл установить значение выше количества ядер CPU.\n\n\n\nCODE_BLOCK_79\n\n\n\n### thread_stack\n\n\n\nМаксимальный размер стека для задачи (корутина, один поисковый запрос может вызвать несколько задач/корутин). Необязательно, по умолчанию 128K.\n\nКаждая задача имеет свой собственный стек размером 128K. При запуске запроса проверяется, сколько стека он требует. Если стандартных 128K достаточно, запрос просто обрабатывается. Если требуется больше, планируется другая задача с увеличенным стеком, которая продолжает обработку. Максимальный размер такого расширенного стека ограничен этой настройкой.\n\nУстановка значения на разумно высоком уровне поможет обрабатывать очень глубокие запросы без значительного увеличения общего потребления ОЗУ. Например, установка 1G не означает, что каждая новая задача будет занимать 1G ОЗУ, но если мы видим, что требуется, скажем, 100M стека, мы выделяем 100M для задачи. Другие задачи в это время будут работать со стандартным стеком 128K. Аналогично, можно запускать ещё более сложные запросы, которым нужен стек в 500M. И только если мы **увидим** внутренне, что задача требует более 1G стека, мы завершимся с ошибкой и сообщим о слишком низком thread_stack.\n\nОднако на практике даже запрос, требующий 16M стека, часто слишком сложен для парсинга и потребляет слишком много времени и ресурсов для обработки. Поэтому демон обработает его, но ограничение таких запросов настройкой `thread_stack` выглядит вполне разумным.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_80\n\n\n\n### unlink_old\n\n\n\nОпределяет, следует ли удалять копии таблиц с расширением `.old` после успешной ротации. Необязательно, по умолчанию 1 (удалять).\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_81\n\n\n\n### watchdog\n\n\n\nПоточный сторож сервера. Необязательно, по умолчанию 1 (сторож включён).\n\nКогда запрос Manticore аварийно завершается, он может привести к падению всего сервера. При включённой функции сторожа `searchd` также поддерживает отдельный лёгкий процесс, который следит за основным процессом сервера и автоматически перезапускает его в случае ненормального завершения. Сторож включён по умолчанию.\n\n\n\nCODE_BLOCK_82\n\n\n\n"
},
"is_code_or_comment": false
+ },
+ "230be7c57f09194f0132555a814b877ed53bf5d1d0ebb9711ec5f36c2863e7b4": {
+ "original": "By default, all 'group by time' expressions (like group by day, week, month, and year in API, also group by day, month, year, yearmonth, yearmonthday in SQL) are done using the timezone configured for time functions (see the `timezone` setting or `TZ` environment variable). For example, if you have documents with attributes timed `13:00 utc` and `15:00 utc`, in the case of grouping, they both will fall into facility groups according to your timezone setting. If you live in `utc`, it will be one day, but if you live in `utc+10`, then these documents will be matched into different `group by day` facility groups (since 13:00 utc in UTC+10 timezone is 23:00 local time, but 15:00 is 01:00 of the next day). Sometimes such behavior is unacceptable, and it is desirable to make time grouping not dependent on timezone. Switching 'on' this option (either in config or using [SET global](../Server_settings/Setting_variables_online.md#SET) statement in SQL) will cause all time grouping expressions to be calculated in UTC, regardless of the timezone setting.\n\n**Note:** Logging always uses the actual system local timezone (determined from `/etc/localtime` on Unix-like systems), regardless of the `TZ` environment variable or the `timezone` config setting. This ensures that log timestamps reflect the actual system time, which is useful for debugging and monitoring.\n\n### timezone\n\nThis setting specifies the timezone to be used by date/time-related functions (such as `NOW()`, `CURTIME()`, `FROM_UNIXTIME()`, etc.). By default, the system's local timezone is used, but you can specify a different timezone in IANA format (e.g., `Europe/Amsterdam` or `Asia/Singapore`).\n\n**Timezone resolution order:**\n\n1. If the `timezone` config setting is explicitly set, it takes precedence.\n\n2. Otherwise, if the `TZ` environment variable is set, it is used.\n\n3. If neither is set, the system's local timezone (from `/etc/localtime` on Unix-like systems) is used.\n\n**Important notes:**\n\n- **Logging**: Logging always uses the actual system local timezone (determined from `/etc/localtime`), regardless of the `TZ` environment variable or the `timezone` config setting. This ensures that log timestamps reflect the actual system time, which is useful for debugging and monitoring.\n\n- **Time functions**: Date/time-related functions respect the `timezone` config setting or `TZ` environment variable if set, otherwise they use the system local timezone.\n\n- **Grouping**: If `grouping_in_utc` is enabled, the 'group by time' function will use UTC, while other date/time-related functions will use the timezone specified by this setting. Overall, it is not recommended to mix `grouping_in_utc` and `timezone`.\n\nYou can configure this option either in the config or by using the [SET global](../Server_settings/Setting_variables_online.md#SET) statement in SQL.\n\n### ha_period_karma\n\n\n\nThis setting specifies the agent mirror statistics window size, in seconds (or [special_suffixes](../Server_settings/Special_suffixes.md)). It is optional, with a default value of 60 seconds.\n\nFor a distributed table with agent mirrors in it (see more in [agent](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md), the master tracks several different per-mirror counters. These counters are then used for failover and balancing (the master picks the best mirror to use based on the counters). Counters are accumulated in blocks of `ha_period_karma` seconds.\n\nAfter beginning a new block, the master may still use the accumulated values from the previous one until the new one is half full. As a result, any previous history stops affecting the mirror choice after 1.5 times ha_period_karma seconds at most.\n\nEven though at most two blocks are used for mirror selection, up to 15 last blocks are stored for instrumentation purposes. These blocks can be inspected using the [SHOW AGENT STATUS](../Node_info_and_management/Node_status.md#SHOW-AGENT-STATUS) statement.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_25\n\n\n\n### ha_ping_interval\n\n\n\nThis setting configures the interval between agent mirror pings, in milliseconds (or [special_suffixes](../Server_settings/Special_suffixes.md)). It is optional, with a default value of 1000 milliseconds.\n\nFor a distributed table with agent mirrors in it (see more in [agent](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)), the master sends all mirrors a ping command during idle periods. This is to track the current agent status (alive or dead, network roundtrip, etc). The interval between such pings is defined by this directive. To disable pings, set ha_ping_interval to 0.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_26\n\n\n\n### hostname_lookup\n\nThe `hostname_lookup` option defines the strategy for renewing hostnames. By default, the IP addresses of agent host names are cached at server start to avoid excessive access to DNS. However, in some cases, the IP can change dynamically (e.g. cloud hosting) and it may be desirable to not cache the IPs. Setting this option to `request` disables the caching and queries the DNS for each query. The IP addresses can also be manually renewed using the `FLUSH HOSTNAMES` command.\n\n### jobs_queue_size\n\nThe jobs_queue_size setting defines how many \"jobs\" can be in the queue at the same time. It is unlimited by default.",
+ "translations": {
+ "chinese": "默认情况下，所有“按时间分组”表达式（如 API 中的按天、周、月和年分组，以及 SQL 中的按天、月、年、年月、年月日分组）均使用为时间函数配置的时区（参见 `timezone` 设置或 `TZ` 环境变量）进行。例如，如果您有属性时间为 `13:00 utc` 和 `15:00 utc` 的文档，在分组时，它们都会根据您的时区设置归入相应的分组。如果您所在时区是 `utc`，则它们属于同一天，但如果您所在时区是 `utc+10`，那么这些文档将被匹配到不同的“按天分组”中（因为 UTC+10 时区的 13:00 utc 是当地时间 23:00，而 15:00 是第二天的 01:00）。有时这种行为是不可接受的，且希望时间分组不依赖于时区。开启此选项（无论是在配置中还是使用 SQL 中的 [SET global](../Server_settings/Setting_variables_online.md#SET) 语句）将导致所有时间分组表达式均以 UTC 计算，而不管时区设置如何。\n\n**注意：** 日志记录始终使用实际的系统本地时区（在类 Unix 系统中从 `/etc/localtime` 确定），无论 `TZ` 环境变量或 `timezone` 配置设置为何。这确保日志时间戳反映实际系统时间，有助于调试和监控。\n\n### timezone\n\n此设置指定日期/时间相关函数（如 `NOW()`、`CURTIME()`、`FROM_UNIXTIME()` 等）使用的时区。默认情况下，使用系统本地时区，但您可以指定 IANA 格式的其他时区（例如 `Europe/Amsterdam` 或 `Asia/Singapore`）。\n\n**时区解析顺序：**\n\n1. 如果显式设置了 `timezone` 配置，则优先使用。\n\n2. 否则，如果设置了 `TZ` 环境变量，则使用该变量。\n\n3. 如果两者都未设置，则使用系统本地时区（类 Unix 系统中从 `/etc/localtime` 获取）。\n\n**重要说明：**\n\n- **日志记录**：日志始终使用实际的系统本地时区（从 `/etc/localtime` 确定），无论 `TZ` 环境变量或 `timezone` 配置为何。这确保日志时间戳反映实际系统时间，有助于调试和监控。\n\n- **时间函数**：日期/时间相关函数遵循 `timezone` 配置或 `TZ` 环境变量（如果设置），否则使用系统本地时区。\n\n- **分组**：如果启用 `grouping_in_utc`，则“按时间分组”功能将使用 UTC，而其他日期/时间相关函数将使用此设置指定的时区。总体而言，不建议混用 `grouping_in_utc` 和 `timezone`。\n\n您可以在配置中设置此选项，或使用 SQL 中的 [SET global](../Server_settings/Setting_variables_online.md#SET) 语句进行配置。\n\n### ha_period_karma\n\n\n\n此设置指定代理镜像统计窗口大小，单位为秒（或 [special_suffixes](../Server_settings/Special_suffixes.md)）。此项为可选，默认值为 60 秒。\n\n对于包含代理镜像的分布式表（详见 [agent](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)），主节点跟踪多个不同的每镜像计数器。这些计数器用于故障转移和平衡（主节点根据计数器选择最佳镜像）。计数器以 `ha_period_karma` 秒为块进行累积。\n\n开始新块后，主节点可能仍使用前一块的累积值，直到新块填充到一半。因此，任何之前的历史最多在 1.5 倍 ha_period_karma 秒后停止影响镜像选择。\n\n尽管最多使用两个块进行镜像选择，但最多存储最近 15 个块以供监控使用。可以使用 [SHOW AGENT STATUS](../Node_info_and_management/Node_status.md#SHOW-AGENT-STATUS) 语句查看这些块。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_25\n\n\n\n### ha_ping_interval\n\n\n\n此设置配置代理镜像之间的 ping 间隔，单位为毫秒（或 [special_suffixes](../Server_settings/Special_suffixes.md)）。此项为可选，默认值为 1000 毫秒。\n\n对于包含代理镜像的分布式表（详见 [agent](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)），主节点在空闲期间向所有镜像发送 ping 命令，以跟踪当前代理状态（存活或死亡、网络往返时间等）。此指令定义了 ping 之间的间隔。要禁用 ping，将 ha_ping_interval 设置为 0。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_26\n\n\n\n### hostname_lookup\n\n`hostname_lookup` 选项定义了主机名更新策略。默认情况下，代理主机名的 IP 地址在服务器启动时缓存，以避免频繁访问 DNS。但在某些情况下，IP 可能动态变化（例如云托管），此时可能希望不缓存 IP。将此选项设置为 `request` 可禁用缓存，并在每次查询时查询 DNS。IP 地址也可以通过 `FLUSH HOSTNAMES` 命令手动更新。\n\n### jobs_queue_size\n\njobs_queue_size 设置定义了队列中可以同时存在多少“作业”。默认情况下无限制。",
+ "russian": "По умолчанию все выражения 'group by time' (например, group by day, week, month и year в API, а также group by day, month, year, yearmonth, yearmonthday в SQL) выполняются с использованием часового пояса, настроенного для временных функций (см. настройку `timezone` или переменную окружения `TZ`). Например, если у вас есть документы с атрибутами времени `13:00 utc` и `15:00 utc`, при группировке они оба попадут в группы по объектам в соответствии с вашей настройкой часового пояса. Если вы находитесь в `utc`, это будет один день, но если вы находитесь в `utc+10`, то эти документы будут отнесены к разным группам `group by day` (поскольку 13:00 utc в часовом поясе UTC+10 — это 23:00 местного времени, а 15:00 — это 01:00 следующего дня). Иногда такое поведение неприемлемо, и желательно сделать группировку времени независимой от часового пояса. Включение этой опции (либо в конфиге, либо с помощью оператора [SET global](../Server_settings/Setting_variables_online.md#SET) в SQL) приведет к тому, что все выражения группировки времени будут вычисляться в UTC, независимо от настройки часового пояса.\n\n**Примечание:** Логирование всегда использует фактический локальный системный часовой пояс (определяемый из `/etc/localtime` в системах, подобных Unix), независимо от переменной окружения `TZ` или настройки `timezone`. Это гарантирует, что временные метки в логах отражают фактическое системное время, что полезно для отладки и мониторинга.\n\n### timezone\n\nЭта настройка указывает часовой пояс, который будет использоваться функциями, связанными с датой и временем (такими как `NOW()`, `CURTIME()`, `FROM_UNIXTIME()` и др.). По умолчанию используется локальный часовой пояс системы, но вы можете указать другой часовой пояс в формате IANA (например, `Europe/Amsterdam` или `Asia/Singapore`).\n\n**Порядок определения часового пояса:**\n\n1. Если явно задана настройка `timezone` в конфиге, она имеет приоритет.\n\n2. В противном случае, если установлена переменная окружения `TZ`, используется она.\n\n3. Если ни одна из них не установлена, используется локальный часовой пояс системы (из `/etc/localtime` в системах, подобных Unix).\n\n**Важные замечания:**\n\n- **Логирование**: Логирование всегда использует фактический локальный системный часовой пояс (определяемый из `/etc/localtime`), независимо от переменной окружения `TZ` или настройки `timezone`. Это гарантирует, что временные метки в логах отражают фактическое системное время, что полезно для отладки и мониторинга.\n\n- **Временные функции**: Функции, связанные с датой и временем, учитывают настройку `timezone` или переменную окружения `TZ`, если они заданы, иначе используют локальный часовой пояс системы.\n\n- **Группировка**: Если включена опция `grouping_in_utc`, функция 'group by time' будет использовать UTC, в то время как другие функции, связанные с датой и временем, будут использовать часовой пояс, указанный в этой настройке. В целом не рекомендуется смешивать `grouping_in_utc` и `timezone`.\n\nВы можете настроить эту опцию либо в конфиге, либо с помощью оператора [SET global](../Server_settings/Setting_variables_online.md#SET) в SQL.\n\n### ha_period_karma\n\n\n\nЭта настройка задает размер окна статистики зеркал агента в секундах (или с использованием [special_suffixes](../Server_settings/Special_suffixes.md)). Она необязательна, значение по умолчанию — 60 секунд.\n\nДля распределенной таблицы с зеркалами агента (подробнее см. в [agent](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)) мастер отслеживает несколько различных счетчиков для каждого зеркала. Эти счетчики затем используются для переключения и балансировки (мастер выбирает лучшее зеркало на основе счетчиков). Счетчики накапливаются блоками по `ha_period_karma` секунд.\n\nПосле начала нового блока мастер может продолжать использовать накопленные значения из предыдущего блока, пока новый блок не заполнится наполовину. В результате любая предыдущая история перестает влиять на выбор зеркала максимум через 1.5 раза `ha_period_karma` секунд.\n\nХотя для выбора зеркала используется максимум два блока, до 15 последних блоков сохраняются для целей инструментирования. Эти блоки можно просмотреть с помощью оператора [SHOW AGENT STATUS](../Node_info_and_management/Node_status.md#SHOW-AGENT-STATUS).\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_25\n\n\n\n### ha_ping_interval\n\n\n\nЭта настройка задает интервал между пингами зеркал агента в миллисекундах (или с использованием [special_suffixes](../Server_settings/Special_suffixes.md)). Она необязательна, значение по умолчанию — 1000 миллисекунд.\n\nДля распределенной таблицы с зеркалами агента (подробнее см. в [agent](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)) мастер отправляет всем зеркалам команду пинга в периоды простоя. Это необходимо для отслеживания текущего статуса агента (активен или нет, время сетевого отклика и т.д.). Интервал между такими пингами определяется этой директивой. Чтобы отключить пинги, установите `ha_ping_interval` в 0.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_26\n\n\n\n### hostname_lookup\n\nОпция `hostname_lookup` определяет стратегию обновления имен хостов. По умолчанию IP-адреса имен хостов агентов кэшируются при запуске сервера, чтобы избежать чрезмерных обращений к DNS. Однако в некоторых случаях IP может динамически меняться (например, в облачном хостинге), и может быть желательно не кэшировать IP. Установка этой опции в значение `request` отключает кэширование и выполняет запросы к DNS при каждом запросе. IP-адреса также можно обновить вручную с помощью команды `FLUSH HOSTNAMES`.\n\n### jobs_queue_size\n\nНастройка `jobs_queue_size` определяет, сколько \"заданий\" может находиться в очереди одновременно. По умолчанию ограничений нет."
+ },
+ "is_code_or_comment": false
+ },
+ "0a501c054a7ae44dfb109952e952a315e82960acd69d34ee66481ff215d99b21": {
+ "original": "In most cases, a \"job\" means one query to a single local table (plain table or a disk chunk of a real-time table). For example, if you have a distributed table consisting of 2 local tables or a real-time table with 2 disk chunks, a search query to either of them will mostly put 2 jobs in the queue. Then, the thread pool (whose size is defined by [threads](../Server_settings/Searchd.md#threads) will process them. However, in some cases, if the query is too complex, more jobs can be created. Changing this setting is recommended when [max_connections](../Server_settings/Searchd.md#max_connections) and [threads](../Server_settings/Searchd.md#threads) are not enough to find a balance between the desired performance.\n\n### join_batch_size\n\nTable joins work by accumulating a batch of matches, which are the results of the query executed on the left table. This batch is then processed as a single query on the right table.\n\nThis option allows you to adjust the batch size. The default value is `1000`, and setting this option to `0` disables batching.\n\nA larger batch size may improve performance; however, for some queries, it can lead to excessive memory consumption.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_27\n\n\n\n### join_cache_size\n\nEach query executed on the right table is defined by specific JOIN ON conditions, which determine the result set retrieved from the right table.\n\nIf there are only a few unique JOIN ON conditions, reusing the results can be more efficient than repeatedly executing queries on the right table. To enable this, the result sets are stored in a cache.\n\nThis option allows you to configure the size of this cache. The default value is `20 MB`, and setting this option to 0 disables caching.\n\nNote that each thread maintains its own cache, so you should account for the number of threads executing queries when estimating total memory usage.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_28\n\n\n\n### listen_backlog\n\n\n\nThe listen_backlog setting determines the length of the TCP listen backlog for incoming connections. This is particularly relevant for Windows builds that process requests one by one. When the connection queue reaches its limit, new incoming connections will be refused.\n\nFor non-Windows builds, the default value should work fine, and there is usually no need to adjust this setting.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_29\n\n\n\n### kibana_version_string\n\n\n\nA server version string to return to Kibana or OpenSearch Dashboards. Optional — by default, it's set `7.6.0`.\n\nSome versions of Kibana and OpenSearch Dashboards expect the server to report a specific version number, and might behave differently depending on it. To workaround such issues, you can use this setting, which makes Manticore report a custom version to Kibana or OpenSearch Dashboards.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_30\n\n\n\n### listen\n\n\n\nThis setting lets you specify an IP address and port, or Unix-domain socket path, that Manticore will accept connections on.\n\nThe general syntax for `listen` is:\n\nCODE_BLOCK_31\n\nYou can specify:\n\n* either an IP address (or hostname) and a port number\n\n* or just a port number\n\n* or a Unix socket path (not supported on Windows)\n\n* or an IP address and port range\n\nIf you specify a port number but not an address, `searchd` will listen on all network interfaces. Unix path is identified by a leading slash. Port range can be set only for the replication protocol.\n\nYou can also specify a protocol handler (listener) to be used for connections on this socket. The listeners are:\n\n* **Not specified** - Manticore will accept connections at this port from:\n\n - other Manticore agents (i.e., a remote distributed table)\n\n - clients via HTTP and HTTPS\n\n - [Manticore Buddy](https://manticoresearch.com/blog/manticoresearch-buddy-intro/). **Ensure you have a listener of this kind (or an `http` listener, as mentioned below) to avoid limitations in Manticore functionality.**\n\n* `mysql` MySQL protocol for connections from MySQL clients. Note:\n\n - Compressed protocol is also supported.\n\n - If [SSL](../Security/SSL.md#SSL) is enabled, you can make an encrypted connection.\n\n* `replication` - replication protocol used for nodes communication. More details can be found in the [replication](../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md) section. You can specify multiple replication listeners, but they must all listen on the same IP; only the ports can be different. When you define a replication listener with a port range (e.g., `listen = 192.168.0.1:9320-9328:replication`), Manticore doesn't immediately start listening on these ports. Instead, it will take random free ports from the specified range only when you start using replication. At least 2 ports are required in the range for replication to work properly.\n\n* `http` - same as **Not specified**. Manticore will accept connections at this port from remote agents and clients via HTTP and HTTPS.\n\n* `https` - HTTPS protocol. Manticore will accept **only** HTTPS connections at this port. More details can be found in section [SSL](../Security/SSL.md).\n\n* `sphinx` - legacy binary protocol. Used to serve connections from remote [SphinxSE](../Extensions/SphinxSE.md) clients. Some Sphinx API clients implementations (an example is the Java one) require the explicit declaration of the listener.\n\nAdding suffix `_vip` to client protocols (that is, all except `replication`, for instance `mysql_vip` or `http_vip` or just `_vip`) forces creating a dedicated thread for the connection to bypass different limitations. That's useful for node maintenance in case of severe overload when the server would either stall or not let you connect via a regular port otherwise.\n\nSuffix `_readonly` sets [read-only mode](../Security/Read_only.md) for the listener and limits it to accept only read queries.\n\n",
+ "translations": {
+ "chinese": "在大多数情况下，“作业”指的是对单个本地表（普通表或实时表的磁盘块）的一次查询。例如，如果您有一个由2个本地表组成的分布式表，或者一个有2个磁盘块的实时表，对其中任意一个的搜索查询通常会在队列中放入2个作业。然后，线程池（其大小由[threads](../Server_settings/Searchd.md#threads)定义）将处理它们。然而，在某些情况下，如果查询过于复杂，可能会创建更多作业。当[max_connections](../Server_settings/Searchd.md#max_connections)和[threads](../Server_settings/Searchd.md#threads)不足以在期望的性能之间找到平衡时，建议更改此设置。\n\n### join_batch_size\n\n表连接通过累积一批匹配项来工作，这些匹配项是对左表执行查询的结果。然后，这批数据作为单个查询在右表上处理。\n\n此选项允许您调整批处理大小。默认值为`1000`，将此选项设置为`0`则禁用批处理。\n\n较大的批处理大小可能提高性能；但是，对于某些查询，可能导致过度的内存消耗。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_27\n\n\n\n### join_cache_size\n\n对右表执行的每个查询由特定的JOIN ON条件定义，这些条件决定了从右表检索的结果集。\n\n如果只有少数唯一的JOIN ON条件，重用结果比反复执行右表查询更高效。为启用此功能，结果集存储在缓存中。\n\n此选项允许您配置此缓存的大小。默认值为`20 MB`，将此选项设置为0则禁用缓存。\n\n请注意，每个线程维护自己的缓存，因此在估算总内存使用时应考虑执行查询的线程数。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_28\n\n\n\n### listen_backlog\n\n\n\nlisten_backlog设置确定传入连接的TCP监听队列长度。这对于逐个处理请求的Windows版本尤为重要。当连接队列达到其限制时，新传入的连接将被拒绝。\n\n对于非Windows版本，默认值通常适用，通常无需调整此设置。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_29\n\n\n\n### kibana_version_string\n\n\n\n返回给Kibana或OpenSearch Dashboards的服务器版本字符串。可选——默认设置为`7.6.0`。\n\n某些版本的Kibana和OpenSearch Dashboards期望服务器报告特定的版本号，并可能根据版本号表现不同。为解决此类问题，您可以使用此设置，使Manticore向Kibana或OpenSearch Dashboards报告自定义版本。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_30\n\n\n\n### listen\n\n\n\n此设置允许您指定Manticore将接受连接的IP地址和端口，或Unix域套接字路径。\n\n`listen`的一般语法为：\n\nCODE_BLOCK_31\n\n您可以指定：\n\n* IP地址（或主机名）和端口号\n\n* 或仅端口号\n\n* 或Unix套接字路径（Windows不支持）\n\n* 或IP地址和端口范围\n\n如果指定端口号但未指定地址，`searchd`将监听所有网络接口。Unix路径以斜杠开头。端口范围仅可用于复制协议。\n\n您还可以为此套接字上的连接指定协议处理程序（监听器）。监听器包括：\n\n* **未指定** - Manticore将在此端口接受来自：\n\n - 其他Manticore代理（即远程分布式表）\n\n - 通过HTTP和HTTPS的客户端\n\n - [Manticore Buddy](https://manticoresearch.com/blog/manticoresearch-buddy-intro/)。**确保您有此类监听器（或下面提到的`http`监听器），以避免Manticore功能受限。**\n\n* `mysql` MySQL协议，用于MySQL客户端连接。注意：\n\n - 也支持压缩协议。\n\n - 如果启用了[SSL](../Security/SSL.md#SSL)，可以建立加密连接。\n\n* `replication` - 用于节点通信的复制协议。更多细节见[复制](../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md)部分。您可以指定多个复制监听器，但它们必须监听相同IP；端口可以不同。当您定义带端口范围的复制监听器（例如`listen = 192.168.0.1:9320-9328:replication`）时，Manticore不会立即开始监听这些端口。只有在开始使用复制时，才会从指定范围中随机选择空闲端口。复制正常工作至少需要2个端口。\n\n* `http` - 与**未指定**相同。Manticore将在此端口接受来自远程代理和通过HTTP及HTTPS的客户端连接。\n\n* `https` - HTTPS协议。Manticore将在此端口**仅**接受HTTPS连接。更多细节见[SSL](../Security/SSL.md)部分。\n\n* `sphinx` - 传统二进制协议。用于服务来自远程[SphinxSE](../Extensions/SphinxSE.md)客户端的连接。一些Sphinx API客户端实现（例如Java客户端）需要显式声明监听器。\n\n在客户端协议后添加后缀`_vip`（即除`replication`外的所有协议，如`mysql_vip`、`http_vip`或仅`_vip`）会强制为连接创建专用线程，以绕过各种限制。这在服务器严重过载时进行节点维护非常有用，否则服务器可能会停滞或不允许通过常规端口连接。\n\n后缀`_readonly`为监听器设置[只读模式](../Security/Read_only.md)，并限制其仅接受读取查询。\n\n",
+ "russian": "В большинстве случаев \"задача\" означает один запрос к одной локальной таблице (обычной таблице или дисковому чанку таблицы реального времени). Например, если у вас есть распределённая таблица, состоящая из 2 локальных таблиц, или таблица реального времени с 2 дисковыми чанками, поисковый запрос к любой из них в основном поставит в очередь 2 задачи. Затем пул потоков (размер которого определяется параметром [threads](../Server_settings/Searchd.md#threads)) будет их обрабатывать. Однако в некоторых случаях, если запрос слишком сложный, может быть создано больше задач. Рекомендуется изменить этот параметр, когда [max_connections](../Server_settings/Searchd.md#max_connections) и [threads](../Server_settings/Searchd.md#threads) недостаточны для достижения баланса между желаемой производительностью.\n\n### join_batch_size\n\nОбъединения таблиц работают путём накопления партии совпадений, которые являются результатами запроса, выполненного по левой таблице. Эта партия затем обрабатывается как единый запрос к правой таблице.\n\nЭтот параметр позволяет настроить размер партии. Значение по умолчанию — `1000`, а установка этого параметра в `0` отключает пакетную обработку.\n\nБольший размер партии может улучшить производительность; однако для некоторых запросов это может привести к чрезмерному потреблению памяти.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_27\n\n\n\n### join_cache_size\n\nКаждый запрос, выполняемый по правой таблице, определяется конкретными условиями JOIN ON, которые определяют набор результатов, извлекаемых из правой таблицы.\n\nЕсли уникальных условий JOIN ON немного, повторное использование результатов может быть более эффективным, чем многократное выполнение запросов к правой таблице. Для этого наборы результатов сохраняются в кэше.\n\nЭтот параметр позволяет настроить размер этого кэша. Значение по умолчанию — `20 MB`, а установка этого параметра в 0 отключает кэширование.\n\nОбратите внимание, что каждый поток поддерживает собственный кэш, поэтому при оценке общего потребления памяти следует учитывать количество потоков, выполняющих запросы.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_28\n\n\n\n### listen_backlog\n\n\n\nПараметр listen_backlog определяет длину очереди TCP для входящих соединений. Это особенно актуально для сборок под Windows, которые обрабатывают запросы по одному. Когда очередь соединений достигает своего предела, новые входящие соединения будут отклоняться.\n\nДля сборок не под Windows значение по умолчанию обычно подходит, и обычно нет необходимости изменять этот параметр.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_29\n\n\n\n### kibana_version_string\n\n\n\nСтрока версии сервера, возвращаемая Kibana или OpenSearch Dashboards. Необязательно — по умолчанию установлено `7.6.0`.\n\nНекоторые версии Kibana и OpenSearch Dashboards ожидают, что сервер будет сообщать конкретный номер версии, и могут вести себя по-разному в зависимости от него. Чтобы обойти такие проблемы, вы можете использовать этот параметр, который заставляет Manticore сообщать Kibana или OpenSearch Dashboards пользовательскую версию.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_30\n\n\n\n### listen\n\n\n\nЭтот параметр позволяет указать IP-адрес и порт или путь к Unix-доменному сокету, на которых Manticore будет принимать соединения.\n\nОбщий синтаксис для `listen`:\n\nCODE_BLOCK_31\n\nВы можете указать:\n\n* либо IP-адрес (или имя хоста) и номер порта\n\n* либо только номер порта\n\n* либо путь к Unix-сокету (не поддерживается в Windows)\n\n* либо IP-адрес и диапазон портов\n\nЕсли вы указываете номер порта, но не адрес, `searchd` будет слушать на всех сетевых интерфейсах. Путь Unix-сокета определяется ведущим слэшем. Диапазон портов можно задать только для протокола репликации.\n\nВы также можете указать обработчик протокола (listener), который будет использоваться для соединений на этом сокете. Слушатели:\n\n* **Не указан** — Manticore будет принимать соединения на этом порту от:\n\n - других агентов Manticore (то есть удалённой распределённой таблицы)\n\n - клиентов через HTTP и HTTPS\n\n - [Manticore Buddy](https://manticoresearch.com/blog/manticoresearch-buddy-intro/). **Убедитесь, что у вас есть слушатель такого типа (или `http` слушатель, как указано ниже), чтобы избежать ограничений в функциональности Manticore.**\n\n* `mysql` — протокол MySQL для соединений от MySQL-клиентов. Обратите внимание:\n\n - Поддерживается также сжатый протокол.\n\n - Если включён [SSL](../Security/SSL.md#SSL), можно установить зашифрованное соединение.\n\n* `replication` — протокол репликации, используемый для связи между узлами. Подробнее см. в разделе [репликация](../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md). Можно указать несколько слушателей репликации, но все они должны слушать на одном IP; различаться могут только порты. При определении слушателя репликации с диапазоном портов (например, `listen = 192.168.0.1:9320-9328:replication`) Manticore не начинает сразу слушать эти порты. Вместо этого он будет брать случайные свободные порты из указанного диапазона только при начале использования репликации. Для корректной работы репликации в диапазоне должно быть не менее 2 портов.\n\n* `http` — то же, что и **Не указан**. Manticore будет принимать соединения на этом порту от удалённых агентов и клиентов через HTTP и HTTPS.\n\n* `https` — протокол HTTPS. Manticore будет принимать **только** HTTPS-соединения на этом порту. Подробнее см. в разделе [SSL](../Security/SSL.md).\n\n* `sphinx` — устаревший бинарный протокол. Используется для обслуживания соединений от удалённых клиентов [SphinxSE](../Extensions/SphinxSE.md). Некоторые реализации клиентов Sphinx API (например, Java) требуют явного указания слушателя.\n\nДобавление суффикса `_vip` к протоколам клиентов (то есть ко всем, кроме `replication`, например `mysql_vip` или `http_vip` или просто `_vip`) заставляет создавать выделенный поток для соединения, чтобы обойти различные ограничения. Это полезно для обслуживания узла в случае серьёзной перегрузки, когда сервер в противном случае либо зависнет, либо не позволит подключиться через обычный порт.\n\nСуффикс `_readonly` устанавливает [режим только для чтения](../Security/Read_only.md) для слушателя и ограничивает его приём только запросами на чтение.\n\n"
+ },
+ "is_code_or_comment": false
+ },
+ "5a8d8b1a5a650a29ef1ae6fed06128ad5cdb9ee8bdd807c3572bd565a52778ab": {
+ "original": "##### Example:\n\n\n\nCODE_BLOCK_32\n\n\n\nThere can be multiple `listen` directives. `searchd` will listen for client connections on all specified ports and sockets. The default config provided in Manticore packages defines listening on ports:\n\n* `9308` and `9312` for connections from remote agents and non-MySQL based clients\n\n* and on port `9306` for MySQL connections.\n\nIf you don't specify any `listen` in the configuration at all, Manticore will wait for connections on:\n\n* `127.0.0.1:9306` for MySQL clients\n\n* `127.0.0.1:9312` for HTTP/HTTPS and connections from other Manticore nodes and clients based on the Manticore binary API.\n\n#### Listening on privileged ports\n\nBy default, Linux won't allow you to let Manticore listen on a port below 1024 (e.g. `listen = 127.0.0.1:80:http` or `listen = 127.0.0.1:443:https`) unless you run searchd under root. If you still want to be able to start Manticore, so it listens on ports < 1024 under a non-root user, consider doing one of the following (either of these should work):\n\n* Run the command `setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/searchd`\n\n* Add `AmbientCapabilities=CAP_NET_BIND_SERVICE` to Manticore's systemd unit and reload the daemon (`systemctl daemon-reload`).\n\n#### Technical details about Sphinx API protocol and TFO\n\n\n\nLegacy Sphinx protocol has 2 phases: handshake exchanging and data flow. The handshake consists of a packet of 4 bytes from the client, and a packet of 4 bytes from the daemon with only one purpose - the client determines that the remote is a real Sphinx daemon, the daemon determines that the remote is a real Sphinx client. The main dataflow is quite simple: let's both sides declare their handshakes, and the opposite check them. That exchange with short packets implies using special `TCP_NODELAY` flag, which switches off Nagle's TCP algorithm and declares that the TCP connection will be performed as a dialogue of small packages.\n\nHowever, it is not strictly defined who speaks first in this negotiation. Historically, all clients that use the binary API speak first: send handshake, then read 4 bytes from a daemon, then send a request and read an answer from the daemon.\n\nWhen we improved Sphinx protocol compatibility, we considered these things:\n\n1. Usually, master-agent communication is established from a known client to a known host on a known port. So, it is quite not possible that the endpoint will provide a wrong handshake. So, we may implicitly assume that both sides are valid and really speak in Sphinx proto.\n\n2. Given this assumption, we can 'glue' a handshake to the real request and send it in one packet. If the backend is a legacy Sphinx daemon, it will just read this glued packet as 4 bytes of a handshake, then request body. Since they both came in one packet, the backend socket has -1 RTT, and the frontend buffer still works despite that fact usual way.\n\n3. Continuing the assumption: since the 'query' packet is quite small, and the handshake is even smaller, let's send both in the initial 'SYN' TCP package using modern TFO (tcp-fast-open) technique. That is: we connect to a remote node with the glued handshake + body package. The daemon accepts the connection and immediately has both the handshake and the body in a socket buffer, as they came in the very first TCP 'SYN' packet. That eliminates another one RTT.\n\n4. Finally, teach the daemon to accept this improvement. Actually, from the application, it implies NOT to use `TCP_NODELAY`. And, from the system side, it implies to ensure that on the daemon side, accepting TFO is activated, and on the client side, sending TFO is also activated. By default, in modern systems, client TFO is already activated by default, so you only have to tune the server TFO for all things to work.\n\nAll these improvements without actually changing the protocol itself allowed us to eliminate 1.5 RTT of the TCP protocol from the connection. Which is, if the query and answer are capable of being placed in a single TCP package, decreases the whole binary API session from 3.5 RTT to 2 RTT - which makes network negotiation about 2 times faster.\n\nSo, all our improvements are stated around an initially undefined statement: 'who speaks first.' If a client speaks first, we may apply all these optimizations and effectively process connect + handshake + query in a single TFO package. Moreover, we can look at the beginning of the received package and determine a real protocol. That is why you can connect to one and the same port via API/http/https. If the daemon has to speak first, all these optimizations are impossible, and the multiprotocol is also impossible. That is why we have a dedicated port for MySQL and did not unify it with all the other protocols into a same port. Suddenly, among all clients, one was written implying that daemon should send a handshake first. That is - no possibility to all the described improvements. That is SphinxSE plugin for mysql/mariadb. So, specially for this single client we dedicated `sphinx` proto definition to work most legacy way. Namely: both sides activate `TCP_NODELAY` and exchange with small packages. The daemon sends its handshake on connect, then the client sends its, and then everything works usual way. That is not very optimal, but just works. If you use SphinxSE to connect to Manticore - you have to dedicate a listener with explicitly stated `sphinx` proto. For another clients - avoid to use this listener as it is slower. If you use another legacy Sphinx API clients - check first, if they are able to work with non-dedicated multiprotocol port. For master-agent linkage using the non-dedicated (multiprotocol) port and enabling client and server TFO works well and will definitely make working of network backend faster, especially if you have very light and fast queries.\n\n \n\n### listen_tfo\n\nThis setting allows the TCP_FASTOPEN flag for all listeners. By default, it is managed by the system but may be explicitly switched off by setting it to '0'.",
+ "translations": {
+ "chinese": "##### 示例：\n\n\n\nCODE_BLOCK_32\n\n\n\n可以有多个 `listen` 指令。`searchd` 将在所有指定的端口和套接字上监听客户端连接。Manticore 软件包中提供的默认配置定义了监听以下端口：\n\n* `9308` 和 `9312` 用于来自远程代理和非 MySQL 客户端的连接\n\n* 以及端口 `9306` 用于 MySQL 连接。\n\n如果您在配置中根本没有指定任何 `listen`，Manticore 将等待以下连接：\n\n* `127.0.0.1:9306` 用于 MySQL 客户端\n\n* `127.0.0.1:9312` 用于 HTTP/HTTPS 以及来自其他 Manticore 节点和基于 Manticore 二进制 API 的客户端的连接。\n\n#### 监听特权端口\n\n默认情况下，Linux 不允许您让 Manticore 监听 1024 以下的端口（例如 `listen = 127.0.0.1:80:http` 或 `listen = 127.0.0.1:443:https`），除非您以 root 身份运行 searchd。如果您仍然希望能够以非 root 用户启动 Manticore，使其监听 < 1024 的端口，请考虑执行以下操作之一（任意一个都应该有效）：\n\n* 运行命令 `setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/searchd`\n\n* 在 Manticore 的 systemd 单元中添加 `AmbientCapabilities=CAP_NET_BIND_SERVICE` 并重新加载守护进程（`systemctl daemon-reload`）。\n\n#### 关于 Sphinx API 协议和 TFO 的技术细节\n\n\n\n传统的 Sphinx 协议有两个阶段：握手交换和数据流。握手由客户端发送的 4 字节数据包和守护进程发送的 4 字节数据包组成，唯一目的就是客户端确定远程是一个真实的 Sphinx 守护进程，守护进程确定远程是一个真实的 Sphinx 客户端。主要数据流非常简单：双方都声明它们的握手，另一方进行检查。该短包交换意味着使用特殊的 `TCP_NODELAY` 标志，该标志关闭 Nagle 的 TCP 算法，并声明 TCP 连接将作为小包对话进行。\n\n然而，谁先发言在此协商中并没有严格定义。历史上，所有使用二进制 API 的客户端都是先发言：先发送握手，然后读取守护进程的 4 字节，再发送请求并读取守护进程的响应。\n\n当我们改进 Sphinx 协议兼容性时，考虑了以下几点：\n\n1. 通常，主代理通信是从已知客户端到已知主机的已知端口建立的。因此，端点提供错误握手的可能性很小。所以，我们可以隐式假设双方都是有效的并且确实使用 Sphinx 协议通信。\n\n2. 基于此假设，我们可以将握手“粘合”到真实请求中并一次性发送。如果后端是传统的 Sphinx 守护进程，它会先读取这粘合包的前 4 字节作为握手，然后读取请求体。由于它们都在一个包中，后端套接字减少了 1 个 RTT，前端缓冲区仍然正常工作。\n\n3. 继续假设：由于“查询”包相当小，握手更小，我们可以使用现代 TFO（tcp-fast-open）技术在初始的 TCP “SYN” 包中发送握手和请求体。也就是说，我们用粘合的握手 + 请求体包连接远程节点。守护进程接受连接后，立即在套接字缓冲区中拥有握手和请求体，因为它们都在第一个 TCP “SYN” 包中。这消除了另一个 RTT。\n\n4. 最后，教守护进程接受此改进。实际上，从应用层看，这意味着不使用 `TCP_NODELAY`。从系统层面看，这意味着确保守护进程端启用 TFO，客户端端也启用发送 TFO。默认情况下，现代系统客户端 TFO 已默认启用，因此您只需调整服务器端 TFO 即可使一切正常工作。\n\n所有这些改进在不实际更改协议本身的情况下，允许我们从连接中消除 1.5 个 TCP 协议的 RTT。如果查询和响应能够放入单个 TCP 包中，则将整个二进制 API 会话从 3.5 RTT 降低到 2 RTT —— 这使网络协商速度提高约 2 倍。\n\n因此，我们所有的改进都基于一个最初未定义的声明：“谁先发言”。如果客户端先发言，我们可以应用所有这些优化，有效地在单个 TFO 包中处理连接 + 握手 + 查询。此外，我们可以查看接收包的开头并确定真实协议。这就是为什么您可以通过 API/http/https 连接到同一个端口。如果守护进程必须先发言，所有这些优化都不可能实现，多协议也不可能实现。这就是为什么我们为 MySQL 设置了专用端口，而没有将其与所有其他协议统一到同一端口。突然之间，在所有客户端中，有一个客户端设计为守护进程应先发送握手。那就是 mysql/mariadb 的 SphinxSE 插件。因此，专门为这个单一客户端，我们专门定义了 `sphinx` 协议以最传统的方式工作。即：双方都启用 `TCP_NODELAY` 并交换小包。守护进程在连接时发送握手，然后客户端发送握手，然后一切照常工作。这不是很优化，但能正常工作。如果您使用 SphinxSE 连接 Manticore —— 您必须专门为其指定一个明确声明 `sphinx` 协议的监听器。对于其他客户端 —— 避免使用此监听器，因为它较慢。如果您使用其他传统 Sphinx API 客户端 —— 首先检查它们是否能在非专用多协议端口上工作。对于主代理链接，使用非专用（多协议）端口并启用客户端和服务器 TFO 工作良好，且肯定会使网络后端工作更快，尤其是当您有非常轻量且快速的查询时。\n\n \n\n### listen_tfo\n\n此设置允许为所有监听器启用 TCP_FASTOPEN 标志。默认情况下，由系统管理，但可以通过设置为 '0' 明确关闭。",
+ "russian": "##### Пример:\n\n\n\nCODE_BLOCK_32\n\n\n\nМожет быть несколько директив `listen`. `searchd` будет слушать подключения клиентов на всех указанных портах и сокетах. Конфигурация по умолчанию, предоставляемая в пакетах Manticore, определяет прослушивание на портах:\n\n* `9308` и `9312` для подключений от удалённых агентов и клиентов, не основанных на MySQL\n\n* и на порту `9306` для MySQL подключений.\n\nЕсли вы вообще не указываете `listen` в конфигурации, Manticore будет ждать подключения на:\n\n* `127.0.0.1:9306` для MySQL клиентов\n\n* `127.0.0.1:9312` для HTTP/HTTPS и подключений от других узлов Manticore и клиентов, основанных на бинарном API Manticore.\n\n#### Прослушивание привилегированных портов\n\nПо умолчанию Linux не позволит Manticore слушать порт ниже 1024 (например, `listen = 127.0.0.1:80:http` или `listen = 127.0.0.1:443:https`), если вы не запускаете searchd от root. Если вы всё же хотите запускать Manticore так, чтобы он слушал порты < 1024 под непривилегированным пользователем, рассмотрите один из следующих вариантов (любой из них должен работать):\n\n* Выполните команду `setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/searchd`\n\n* Добавьте `AmbientCapabilities=CAP_NET_BIND_SERVICE` в systemd-юнит Manticore и перезагрузите демон (`systemctl daemon-reload`).\n\n#### Технические детали протокола Sphinx API и TFO\n\n\n\nУстаревший протокол Sphinx имеет 2 фазы: обмен рукопожатием и поток данных. Рукопожатие состоит из пакета в 4 байта от клиента и пакета в 4 байта от демона с единственной целью — клиент определяет, что удалённый узел — настоящий демон Sphinx, демон определяет, что удалённый узел — настоящий клиент Sphinx. Основной поток данных довольно прост: обе стороны объявляют свои рукопожатия, а противоположная сторона их проверяет. Такой обмен короткими пакетами подразумевает использование специального флага `TCP_NODELAY`, который отключает алгоритм Нейгла TCP и объявляет, что TCP-соединение будет выполняться как диалог маленьких пакетов.\n\nОднако не строго определено, кто говорит первым в этом согласовании. Исторически все клиенты, использующие бинарный API, говорят первыми: отправляют рукопожатие, затем читают 4 байта от демона, затем отправляют запрос и читают ответ от демона.\n\nКогда мы улучшали совместимость протокола Sphinx, мы учли следующее:\n\n1. Обычно связь мастер-агент устанавливается от известного клиента к известному хосту на известном порту. Поэтому маловероятно, что конечная точка предоставит неправильное рукопожатие. Следовательно, мы можем неявно предположить, что обе стороны валидны и действительно говорят на протоколе Sphinx.\n\n2. Исходя из этого предположения, мы можем «склеить» рукопожатие с реальным запросом и отправить их в одном пакете. Если бэкенд — устаревший демон Sphinx, он просто прочитает этот склеенный пакет как 4 байта рукопожатия, затем тело запроса. Поскольку они пришли в одном пакете, у бэкенда сокет имеет -1 RTT, а буфер фронтенда всё ещё работает обычным способом.\n\n3. Продолжая предположение: поскольку пакет «запроса» довольно маленький, а рукопожатие ещё меньше, давайте отправим оба в начальном TCP-пакете «SYN» с использованием современной техники TFO (tcp-fast-open). То есть: мы подключаемся к удалённому узлу с пакетом, склеенным из рукопожатия + тела. Демон принимает соединение и сразу имеет и рукопожатие, и тело в буфере сокета, так как они пришли в самом первом TCP-пакете «SYN». Это устраняет ещё один RTT.\n\n4. Наконец, обучаем демон принимать это улучшение. На уровне приложения это означает НЕ использовать `TCP_NODELAY`. А на уровне системы — обеспечить, чтобы на стороне демона было активировано принятие TFO, а на стороне клиента — отправка TFO. По умолчанию в современных системах клиентский TFO уже активирован, так что вам нужно только настроить серверный TFO, чтобы всё работало.\n\nВсе эти улучшения без фактического изменения протокола позволили нам устранить 1.5 RTT TCP-протокола при соединении. Если запрос и ответ помещаются в один TCP-пакет, это уменьшает всю сессию бинарного API с 3.5 RTT до 2 RTT — что делает сетевое согласование примерно в 2 раза быстрее.\n\nТаким образом, все наши улучшения основаны на изначально неопределённом вопросе: «кто говорит первым». Если клиент говорит первым, мы можем применить все эти оптимизации и эффективно обработать соединение + рукопожатие + запрос в одном TFO-пакете. Более того, мы можем посмотреть в начало полученного пакета и определить реальный протокол. Поэтому вы можете подключаться к одному и тому же порту через API/http/https. Если демон должен говорить первым, все эти оптимизации невозможны, и мультипротокол тоже невозможен. Поэтому у нас есть выделенный порт для MySQL, и мы не объединили его со всеми другими протоколами в один порт. Вдруг среди всех клиентов один был написан с предположением, что демон должен отправлять рукопожатие первым. Это — плагин SphinxSE для mysql/mariadb. Специально для этого единственного клиента мы выделили определение протокола `sphinx`, чтобы работать максимально по-старому. А именно: обе стороны активируют `TCP_NODELAY` и обмениваются маленькими пакетами. Демон отправляет своё рукопожатие при подключении, затем клиент отправляет своё, и затем всё работает обычным способом. Это не очень оптимально, но просто работает. Если вы используете SphinxSE для подключения к Manticore — вам нужно выделить слушатель с явно указанным протоколом `sphinx`. Для других клиентов — избегайте использования этого слушателя, так как он медленнее. Если вы используете других устаревших клиентов Sphinx API — сначала проверьте, могут ли они работать с невыделенным мультипротокольным портом. Для связи мастер-агент использование невыделенного (мультипротокольного) порта и включение TFO на клиенте и сервере работает хорошо и определённо ускорит работу сетевого бэкенда, особенно если у вас очень лёгкие и быстрые запросы.\n\n \n\n### listen_tfo\n\nЭтот параметр позволяет включить флаг TCP_FASTOPEN для всех слушателей. По умолчанию он управляется системой, но может быть явно отключён установкой значения '0'."
+ },
+ "is_code_or_comment": false
+ },
+ "6eb0b831524ef0bae8fb6d1895d2a175b7e675a72051a40031b3cbb4d13b100b": {
+ "original": "This setting is an integer in milliseconds (or [special_suffixes](../Server_settings/Special_suffixes.md)) that specifies the delay before Manticore retries querying a remote node in case of failure during replication. This value is only relevant when a non-zero value is specified. The default value is 500.\n\n### qcache_max_bytes\n\n\n\nThis configuration sets the maximum amount of RAM allocated for cached result sets in bytes. The default value is 16777216, which is equivalent to 16 megabytes. If the value is set to 0, the query cache is disabled. For more information about the query cache, please refer to the [query cache](../Searching/Query_cache.md) for details.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_55\n\n\n\n### qcache_thresh_msec\n\nInteger, in milliseconds. The minimum wall time threshold for a query result to be cached. Defaults to 3000, or 3 seconds. 0 means cache everything. Refer to [query cache](../Searching/Query_cache.md) for details. This value also may be expressed with time [special_suffixes](../Server_settings/Special_suffixes.md), but use it with care and don't confuse yourself with the name of the value itself, containing '_msec'.\n\n### qcache_ttl_sec\n\nInteger, in seconds. The expiration period for a cached result set. Defaults to 60, or 1 minute. The minimum possible value is 1 second. Refer to [query cache](../Searching/Query_cache.md) for details. This value also may be expressed with time [special_suffixes](../Server_settings/Special_suffixes.md), but use it with care and don't confuse yourself with the name of the value itself, containing '_sec'.\n\n### query_log_format\n\n\n\nQuery log format. Optional, allowed values are `plain` and `sphinxql`, default is `sphinxql`.\n\nThe `sphinxql` mode logs valid SQL statements. The `plain` mode logs queries in a plain text format (mostly suitable for purely full-text use cases). This directive allows you to switch between the two formats on search server startup. The log format can also be altered on the fly, using `SET GLOBAL query_log_format=sphinxql` syntax. Refer to [Query logging](../Logging/Query_logging.md) for more details.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_56\n\n\n\n### query_log_min_msec\n\nLimit (in milliseconds) that prevents the query from being written to the query log. Optional, default is 0 (all queries are written to the query log). This directive specifies that only queries with execution times that exceed the specified limit will be logged (this value also may be expressed with time [special_suffixes](../Server_settings/Special_suffixes.md), but use it with care and don't confuse yourself with the name of the value itself, containing `_msec`).\n\n### query_log\n\n\n\nQuery log file name. Optional, default is empty (do not log queries). All search queries (such as SELECT ... but not INSERT/REPLACE/UPDATE queries) will be logged in this file. The format is described in [Query logging](../Logging/Query_logging.md). In case of 'plain' format, you can use 'syslog' as the path to the log file. In this case, all search queries will be sent to the syslog daemon with `LOG_INFO` priority, prefixed with '[query]' instead of timestamp. To use the syslog option, Manticore must be configured with `-–with-syslog` on building.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_57\n\n\n\n### query_log_mode\n\n\n\nThe query_log_mode directive allows you to set a different permission for the searchd and query log files. By default, these log files are created with 600 permission, meaning that only the user under which the server runs and root users can read the log files.\n\nThis directive can be handy if you want to allow other users to read the log files, for example, monitoring solutions running on non-root users.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_58\n\n\n\n### read_buffer_docs\n\n\n\nThe read_buffer_docs directive controls the per-keyword read buffer size for document lists. For every keyword occurrence in every search query, there are two associated read buffers: one for the document list and one for the hit list. This setting lets you control the document list buffer size.\n\nA larger buffer size might increase per-query RAM use, but it could possibly decrease I/O time. It makes sense to set larger values for slow storage, but for storage capable of high IOPS, experimenting should be done in the low values area.\n\nThe default value is 256K, and the minimal value is 8K. You may also set [read_buffer_docs](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#read_buffer_docs) on a per-table basis, which will override anything set on the server's config level.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_59\n\n\n\n### read_buffer_hits\n\n\n\nThe read_buffer_hits directive specifies the per-keyword read buffer size for hit lists in search queries. By default, the size is 256K and the minimum value is 8K. For every keyword occurrence in a search query, there are two associated read buffers, one for the document list and one for the hit list. Increasing the buffer size can increase per-query RAM use but decrease I/O time. For slow storage, larger buffer sizes make sense, while for storage capable of high IOPS, experimenting should be done in the low values area.\n\nThis setting can also be specified on a per-table basis using the read_buffer_hits option in [read_buffer_hits](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#read_buffer_hits) which will override the server-level setting.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_60\n\n\n\n### read_unhinted\n\n\n\nUnhinted read size. Optional, default is 32K, minimal 1K",
+ "translations": {
+ "chinese": "此设置为以毫秒为单位的整数（或[special_suffixes](../Server_settings/Special_suffixes.md)），指定在复制过程中发生故障时，Manticore 重试查询远程节点的延迟时间。仅当指定非零值时，此值才有意义。默认值为500。\n\n### qcache_max_bytes\n\n\n\n此配置设置用于缓存结果集的最大RAM量，单位为字节。默认值为16777216，相当于16兆字节。如果值设置为0，则禁用查询缓存。有关查询缓存的更多信息，请参阅[查询缓存](../Searching/Query_cache.md)。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_55\n\n\n\n### qcache_thresh_msec\n\n整数，单位为毫秒。查询结果被缓存的最小墙时间阈值。默认值为3000，即3秒。0表示缓存所有内容。详情请参阅[查询缓存](../Searching/Query_cache.md)。此值也可以用时间[special_suffixes](../Server_settings/Special_suffixes.md)表示，但请谨慎使用，不要与值名中包含的'_msec'混淆。\n\n### qcache_ttl_sec\n\n整数，单位为秒。缓存结果集的过期时间。默认值为60，即1分钟。最小可能值为1秒。详情请参阅[查询缓存](../Searching/Query_cache.md)。此值也可以用时间[special_suffixes](../Server_settings/Special_suffixes.md)表示，但请谨慎使用，不要与值名中包含的'_sec'混淆。\n\n### query_log_format\n\n\n\n查询日志格式。可选，允许的值为`plain`和`sphinxql`，默认是`sphinxql`。\n\n`sphinxql`模式记录有效的SQL语句。`plain`模式以纯文本格式记录查询（主要适用于纯全文本用例）。此指令允许您在搜索服务器启动时切换两种格式。日志格式也可以动态更改，使用`SET GLOBAL query_log_format=sphinxql`语法。详情请参阅[查询日志](../Logging/Query_logging.md)。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_56\n\n\n\n### query_log_min_msec\n\n限制（以毫秒为单位），防止查询被写入查询日志。可选，默认值为0（所有查询都写入查询日志）。此指令指定只有执行时间超过指定限制的查询才会被记录（此值也可以用时间[special_suffixes](../Server_settings/Special_suffixes.md)表示，但请谨慎使用，不要与值名中包含的`_msec`混淆）。\n\n### query_log\n\n\n\n查询日志文件名。可选，默认为空（不记录查询）。所有搜索查询（如SELECT ...，但不包括INSERT/REPLACE/UPDATE查询）将记录在此文件中。格式详见[查询日志](../Logging/Query_logging.md)。在'plain'格式下，可以使用'syslog'作为日志文件路径。在这种情况下，所有搜索查询将以`LOG_INFO`优先级发送到syslog守护进程，前缀为'[query]'，而非时间戳。要使用syslog选项，Manticore必须在构建时配置`-–with-syslog`。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_57\n\n\n\n### query_log_mode\n\n\n\nquery_log_mode指令允许您为searchd和查询日志文件设置不同的权限。默认情况下，这些日志文件以600权限创建，意味着只有运行服务器的用户和root用户可以读取日志文件。\n\n如果您想允许其他用户读取日志文件，例如运行在非root用户上的监控解决方案，此指令非常有用。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_58\n\n\n\n### read_buffer_docs\n\n\n\nread_buffer_docs指令控制文档列表的每个关键字读取缓冲区大小。对于每个搜索查询中的每个关键字出现，有两个相关的读取缓冲区：一个用于文档列表，一个用于命中列表。此设置允许您控制文档列表缓冲区大小。\n\n较大的缓冲区大小可能增加每个查询的RAM使用，但可能减少I/O时间。对于慢速存储，设置较大值是合理的，但对于能够高IOPS的存储，应在较低值区域进行实验。\n\n默认值为256K，最小值为8K。您也可以在每个表级别设置[read_buffer_docs](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#read_buffer_docs)，这将覆盖服务器配置级别的设置。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_59\n\n\n\n### read_buffer_hits\n\n\n\nread_buffer_hits指令指定搜索查询中命中列表的每个关键字读取缓冲区大小。默认大小为256K，最小值为8K。对于搜索查询中的每个关键字出现，有两个相关的读取缓冲区，一个用于文档列表，一个用于命中列表。增加缓冲区大小可以增加每个查询的RAM使用，但减少I/O时间。对于慢速存储，较大的缓冲区大小是合理的，而对于能够高IOPS的存储，应在较低值区域进行实验。\n\n此设置也可以通过[read_buffer_hits](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#read_buffer_hits)在每个表级别指定，这将覆盖服务器级别的设置。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_60\n\n\n\n### read_unhinted\n\n\n\n无提示读取大小。可选，默认值为32K，最小为1K",
+ "russian": "Этот параметр является целым числом в миллисекундах (или [special_suffixes](../Server_settings/Special_suffixes.md)), который задает задержку перед повторной попыткой Manticore выполнить запрос к удаленному узлу в случае сбоя во время репликации. Это значение имеет значение только при указании ненулевого значения. Значение по умолчанию — 500.\n\n### qcache_max_bytes\n\n\n\nЭта настройка задает максимальный объем оперативной памяти, выделяемой для кэшированных наборов результатов в байтах. Значение по умолчанию — 16777216, что эквивалентно 16 мегабайтам. Если значение установлено в 0, кэш запросов отключается. Для получения дополнительной информации о кэше запросов, пожалуйста, обратитесь к разделу [query cache](../Searching/Query_cache.md).\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_55\n\n\n\n### qcache_thresh_msec\n\nЦелое число, в миллисекундах. Минимальный порог времени выполнения запроса для кэширования результата. По умолчанию 3000, или 3 секунды. 0 означает кэшировать всё. Подробности смотрите в разделе [query cache](../Searching/Query_cache.md). Это значение также может быть выражено с помощью временных [special_suffixes](../Server_settings/Special_suffixes.md), но используйте это с осторожностью и не путайте с названием самого параметра, содержащим '_msec'.\n\n### qcache_ttl_sec\n\nЦелое число, в секундах. Период истечения срока действия кэшированного набора результатов. По умолчанию 60, или 1 минута. Минимально возможное значение — 1 секунда. Подробности смотрите в разделе [query cache](../Searching/Query_cache.md). Это значение также может быть выражено с помощью временных [special_suffixes](../Server_settings/Special_suffixes.md), но используйте это с осторожностью и не путайте с названием самого параметра, содержащим '_sec'.\n\n### query_log_format\n\n\n\nФормат журнала запросов. Необязательно, допустимые значения — `plain` и `sphinxql`, по умолчанию `sphinxql`.\n\nРежим `sphinxql` записывает валидные SQL-запросы. Режим `plain` записывает запросы в простом текстовом формате (в основном подходит для чисто полнотекстовых случаев использования). Эта директива позволяет переключаться между двумя форматами при запуске поискового сервера. Формат журнала также можно изменить на лету, используя синтаксис `SET GLOBAL query_log_format=sphinxql`. Подробности смотрите в разделе [Query logging](../Logging/Query_logging.md).\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_56\n\n\n\n### query_log_min_msec\n\nЛимит (в миллисекундах), который предотвращает запись запроса в журнал запросов. Необязательно, по умолчанию 0 (все запросы записываются в журнал запросов). Эта директива указывает, что в журнал будут записываться только запросы с временем выполнения, превышающим указанный лимит (это значение также может быть выражено с помощью временных [special_suffixes](../Server_settings/Special_suffixes.md), но используйте это с осторожностью и не путайте с названием самого параметра, содержащим `_msec`).\n\n### query_log\n\n\n\nИмя файла журнала запросов. Необязательно, по умолчанию пусто (запросы не логируются). Все поисковые запросы (например, SELECT ... но не INSERT/REPLACE/UPDATE) будут записываться в этот файл. Формат описан в разделе [Query logging](../Logging/Query_logging.md). В случае формата 'plain' можно использовать 'syslog' в качестве пути к файлу журнала. В этом случае все поисковые запросы будут отправлены демону syslog с приоритетом `LOG_INFO`, с префиксом '[query]' вместо временной метки. Для использования опции syslog Manticore должен быть собран с опцией `-–with-syslog`.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_57\n\n\n\n### query_log_mode\n\n\n\nДиректива query_log_mode позволяет задать разные права доступа для файлов searchd и журнала запросов. По умолчанию эти файлы создаются с правами 600, что означает, что читать их могут только пользователь, под которым запущен сервер, и пользователи root.\n\nЭта директива может быть полезна, если вы хотите разрешить другим пользователям читать журналы, например, решениям для мониторинга, работающим под непривилегированными пользователями.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_58\n\n\n\n### read_buffer_docs\n\n\n\nДиректива read_buffer_docs управляет размером буфера чтения на ключевое слово для списков документов. Для каждого вхождения ключевого слова в каждом поисковом запросе существует два связанных буфера чтения: один для списка документов и один для списка попаданий. Эта настройка позволяет контролировать размер буфера списка документов.\n\nБольший размер буфера может увеличить использование оперативной памяти на запрос, но возможно уменьшит время ввода-вывода. Имеет смысл устанавливать большие значения для медленных хранилищ, а для хранилищ с высокой производительностью IOPS экспериментировать следует в области низких значений.\n\nЗначение по умолчанию — 256K, минимальное значение — 8K. Вы также можете установить [read_buffer_docs](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#read_buffer_docs) для каждой таблицы отдельно, что переопределит настройки на уровне сервера.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_59\n\n\n\n### read_buffer_hits\n\n\n\nДиректива read_buffer_hits задает размер буфера чтения на ключевое слово для списков попаданий в поисковых запросах. По умолчанию размер 256K, минимальное значение 8K. Для каждого вхождения ключевого слова в поисковом запросе существует два связанных буфера чтения: один для списка документов и один для списка попаданий. Увеличение размера буфера может увеличить использование оперативной памяти на запрос, но уменьшить время ввода-вывода. Для медленных хранилищ имеет смысл использовать большие размеры буфера, а для хранилищ с высокой производительностью IOPS экспериментировать следует в области низких значений.\n\nЭта настройка также может быть задана для каждой таблицы отдельно с помощью опции read_buffer_hits в [read_buffer_hits](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#read_buffer_hits), что переопределит настройку на уровне сервера.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_60\n\n\n\n### read_unhinted\n\n\n\nРазмер чтения без подсказок. Необязательно, по умолчанию 32K, минимальное 1K"
+ },
+ "is_code_or_comment": false
+ },
+ "c6a41f42bd27647311b0cc7071d127743ed4b51ed48f681b59ad593d36170c4b": {
+ "original": "The purpose of this file is to enable Manticore to perform various internal tasks, such as checking whether there is already a running instance of `searchd`, stopping `searchd`, and notifying it that it should rotate the tables. The file can also be used for external automation scripts.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_48\n\n\n\n### predicted_time_costs\n\n\n\nCosts for the query time prediction model, in nanoseconds. Optional, the default is `doc=64, hit=48, skip=2048, match=64`.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_49\n\n\n\n\n\nTerminating queries before completion based on their execution time (with the max query time setting) is a nice safety net, but it comes with an inherent drawback: indeterministic (unstable) results. That is, if you repeat the very same (complex) search query with a time limit several times, the time limit will be hit at different stages, and you will get *different* result sets.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\nThere is an option, [SELECT … OPTION max_predicted_time](../Searching/Options.md#max_predicted_time), that lets you limit the query time *and* get stable, repeatable results. Instead of regularly checking the actual current time while evaluating the query, which is indeterministic, it predicts the current running time using a simple linear model instead:\n\nCODE_BLOCK_52\n\nThe query is then terminated early when the `predicted_time` reaches a given limit.\n\nOf course, this is not a hard limit on the actual time spent (it is, however, a hard limit on the amount of *processing* work done), and a simple linear model is in no way an ideally precise one. So the wall clock time *may* be either below or over the target limit. However, the error margins are quite acceptable: for instance, in our experiments with a 100 msec target limit, the majority of the test queries fell into a 95 to 105 msec range, and *all* the queries were in an 80 to 120 msec range. Also, as a nice side effect, using the modeled query time instead of measuring the actual run time results in somewhat fewer gettimeofday() calls, too.\n\nNo two server makes and models are identical, so the `predicted_time_costs` directive lets you configure the costs for the model above. For convenience, they are integers, counted in nanoseconds. (The limit in max_predicted_time is counted in milliseconds, and having to specify cost values as 0.000128 ms instead of 128 ns is somewhat more error-prone.) It is not necessary to specify all four costs at once, as the missed ones will take the default values. However, we strongly suggest specifying all of them for readability.\n\n### preopen_tables\n\n\n\nThe preopen_tables configuration directive specifies whether to forcibly preopen all tables on startup. The default value is 1, which means that all tables will be preopened regardless of the per-table [preopen](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Other-performance-related-settings) setting. If set to 0, the per-table settings can take effect, and they will default to 0.\n\nPre-opening tables can prevent races between search queries and rotations that can cause queries to fail occasionally. However, it also uses more file handles. In most scenarios, it is recommended to preopen tables.\n\nHere's an example configuration:\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_53\n\n\n\n### pseudo_sharding\n\n\n\nThe pseudo_sharding configuration option enables parallelization of search queries to local plain and real-time tables, regardless of whether they are queried directly or through a distributed table. This feature will automatically parallelize queries to up to the number of threads specified in `searchd.threads` # of threads.\n\nNote that if your worker threads are already busy, because you have:\n\n* high query concurrency\n\n* physical sharding of any kind:\n\n - distributed table of multiple plain/real-time tables\n\n - real-time table consisting of too many disk chunks\n\nthen enabling pseudo_sharding may not provide any benefits and may even result in a slight decrease in throughput. If you prioritize higher throughput over lower latency, it's recommended to disable this option.\n\nEnabled by default.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_54\n\n\n\n### replication_connect_timeout\n\nThe `replication_connect_timeout` directive defines the timeout for connecting to a remote node. By default, the value is assumed to be in milliseconds, but it can have [another suffix](../Server_settings/Special_suffixes.md). The default value is 1000 (1 second).\n\nWhen connecting to a remote node, Manticore will wait for this amount of time at most to complete the connection successfully. If the timeout is reached but the connection has not been established, and `retries` are enabled, a retry will be initiated.\n\n### replication_query_timeout\n\nThe `replication_query_timeout` sets the amount of time that searchd will wait for a remote node to complete a query. The default value is 3000 milliseconds (3 seconds), but can be `suffixed` to indicate a different unit of time.\n\nAfter establishing a connection, Manticore will wait for a maximum of `replication_query_timeout` for the remote node to complete. Note that this timeout is separate from the `replication_connect_timeout`, and the total possible delay caused by a remote node will be the sum of both values.\n\n### replication_retry_count\n\nThis setting is an integer that specifies how many times Manticore will attempt to connect and query a remote node during replication before reporting a fatal query error. The default value is 3.\n\n### replication_retry_delay",
+ "translations": {
+ "chinese": "该文件的目的是使 Manticore 能够执行各种内部任务，例如检查是否已有正在运行的 `searchd` 实例，停止 `searchd`，并通知其应旋转表。该文件也可用于外部自动化脚本。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_48\n\n\n\n### predicted_time_costs\n\n\n\n查询时间预测模型的成本，单位为纳秒。可选，默认值为 `doc=64, hit=48, skip=2048, match=64`。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_49\n\n\n\n\n\n基于执行时间（使用最大查询时间设置）在查询完成前终止查询是一个很好的安全网，但它有一个固有缺点：结果不确定（不稳定）。也就是说，如果你多次重复执行完全相同的（复杂）搜索查询并设置时间限制，时间限制将在不同阶段被触发，你将得到*不同*的结果集。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n有一个选项，[SELECT … OPTION max_predicted_time](../Searching/Options.md#max_predicted_time)，它允许你限制查询时间*并*获得稳定、可重复的结果。它不是在评估查询时定期检查实际当前时间（这具有不确定性），而是使用一个简单的线性模型来预测当前运行时间：\n\nCODE_BLOCK_52\n\n当 `predicted_time` 达到给定限制时，查询将被提前终止。\n\n当然，这并不是对实际花费时间的硬限制（但确实是对*处理*工作量的硬限制），而且简单的线性模型绝非理想精确模型。因此，实际的墙钟时间*可能*低于或超过目标限制。然而，误差范围相当可接受：例如，在我们以 100 毫秒为目标限制的实验中，大多数测试查询落在 95 到 105 毫秒范围内，*所有*查询都在 80 到 120 毫秒范围内。此外，作为一个不错的副作用，使用模型化的查询时间而非测量实际运行时间也减少了 gettimeofday() 调用次数。\n\n没有两台服务器的制造商和型号是完全相同的，因此 `predicted_time_costs` 指令允许你配置上述模型的成本。为了方便，它们是整数，单位为纳秒。（max_predicted_time 中的限制以毫秒计，若要以 0.000128 毫秒而非 128 纳秒指定成本值，容易出错。）不必一次指定所有四个成本，缺失的将采用默认值。但我们强烈建议为可读性指定全部。\n\n### preopen_tables\n\n\n\npreopen_tables 配置指令指定是否在启动时强制预打开所有表。默认值为 1，表示无论每个表的 [preopen](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Other-performance-related-settings) 设置如何，都会预打开所有表。若设置为 0，则每个表的设置生效，且默认值为 0。\n\n预打开表可以防止搜索查询与旋转之间的竞争，避免查询偶尔失败。但它也会使用更多文件句柄。在大多数场景下，建议预打开表。\n\n示例配置如下：\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_53\n\n\n\n### pseudo_sharding\n\n\n\npseudo_sharding 配置选项启用对本地普通表和实时表的搜索查询并行化，无论是直接查询还是通过分布式表查询。此功能将自动并行化查询，最多达到 `searchd.threads` 指定的线程数。\n\n请注意，如果你的工作线程已经很忙，因为你有：\n\n* 高查询并发\n\n* 任何形式的物理分片：\n\n - 多个普通/实时表的分布式表\n\n - 由过多磁盘块组成的实时表\n\n那么启用 pseudo_sharding 可能不会带来任何好处，甚至可能导致吞吐量略有下降。如果你优先考虑更高吞吐量而非更低延迟，建议禁用此选项。\n\n默认启用。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_54\n\n\n\n### replication_connect_timeout\n\n`replication_connect_timeout` 指令定义连接远程节点的超时时间。默认值单位为毫秒，但可以使用[其他后缀](../Server_settings/Special_suffixes.md)。默认值为 1000（1 秒）。\n\n连接远程节点时，Manticore 最多等待此时间以成功完成连接。如果超时但连接未建立，且启用了 `retries`，则会发起重试。\n\n### replication_query_timeout\n\n`replication_query_timeout` 设置 searchd 等待远程节点完成查询的时间。默认值为 3000 毫秒（3 秒），但可以使用后缀表示不同时间单位。\n\n建立连接后，Manticore 将最多等待 `replication_query_timeout` 时间以完成远程节点的查询。请注意，此超时与 `replication_connect_timeout` 分开，远程节点可能导致的总延迟为两者之和。\n\n### replication_retry_count\n\n此设置为整数，指定 Manticore 在复制期间尝试连接和查询远程节点的次数，超过后报告致命查询错误。默认值为 3。\n\n### replication_retry_delay",
+ "russian": "Цель этого файла — позволить Manticore выполнять различные внутренние задачи, такие как проверка, запущен ли уже экземпляр `searchd`, остановка `searchd` и уведомление его о необходимости ротировать таблицы. Файл также может использоваться для внешних автоматизированных скриптов.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_48\n\n\n\n### predicted_time_costs\n\n\n\nЗатраты для модели предсказания времени запроса, в наносекундах. Необязательно, по умолчанию `doc=64, hit=48, skip=2048, match=64`.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_49\n\n\n\n\n\nПрерывание запросов до их завершения на основе времени выполнения (с помощью настройки максимального времени запроса) — это хороший страховочный механизм, но он имеет присущий недостаток: неопределённые (нестабильные) результаты. То есть, если вы несколько раз повторите один и тот же (сложный) поисковый запрос с ограничением по времени, лимит времени будет достигнут на разных этапах, и вы получите *разные* наборы результатов.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\nСуществует опция, [SELECT … OPTION max_predicted_time](../Searching/Options.md#max_predicted_time), которая позволяет ограничить время запроса *и* получить стабильные, повторяемые результаты. Вместо регулярной проверки текущего времени во время выполнения запроса, что является неопределённым, она предсказывает текущее время выполнения с помощью простой линейной модели:\n\nCODE_BLOCK_52\n\nЗапрос затем прерывается досрочно, когда `predicted_time` достигает заданного лимита.\n\nКонечно, это не жёсткое ограничение на фактическое затраченное время (однако это жёсткое ограничение на количество выполненной *обработки*), и простая линейная модель ни в коем случае не является идеально точной. Поэтому реальное время по часам *может* быть как ниже, так и выше целевого лимита. Однако погрешности вполне приемлемы: например, в наших экспериментах с целевым лимитом 100 мс большинство тестовых запросов попадали в диапазон от 95 до 105 мс, а *все* запросы — в диапазон от 80 до 120 мс. Также, приятным побочным эффектом является то, что использование смоделированного времени запроса вместо измерения фактического времени выполнения приводит к некоторому уменьшению количества вызовов gettimeofday().\n\nНет двух одинаковых моделей и производителей серверов, поэтому директива `predicted_time_costs` позволяет настроить затраты для вышеуказанной модели. Для удобства они заданы целыми числами, считающимися в наносекундах. (Лимит в max_predicted_time считается в миллисекундах, и указывать значения затрат как 0.000128 мс вместо 128 нс более подвержено ошибкам.) Не обязательно указывать все четыре значения затрат сразу, пропущенные примут значения по умолчанию. Однако мы настоятельно рекомендуем указывать все для удобочитаемости.\n\n### preopen_tables\n\n\n\nДиректива конфигурации preopen_tables указывает, следует ли принудительно предварительно открывать все таблицы при запуске. Значение по умолчанию — 1, что означает, что все таблицы будут предварительно открыты независимо от настройки [preopen](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Other-performance-related-settings) для каждой таблицы. Если установлено в 0, будут применяться настройки для каждой таблицы, которые по умолчанию равны 0.\n\nПредварительное открытие таблиц может предотвратить гонки между поисковыми запросами и ротациями, которые иногда могут приводить к сбоям запросов. Однако это также использует больше дескрипторов файлов. В большинстве сценариев рекомендуется предварительно открывать таблицы.\n\nВот пример конфигурации:\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_53\n\n\n\n### pseudo_sharding\n\n\n\nОпция конфигурации pseudo_sharding включает параллелизацию поисковых запросов к локальным обычным и реальным таблицам, независимо от того, запрашиваются ли они напрямую или через распределённую таблицу. Эта функция автоматически параллелит запросы до количества потоков, указанного в `searchd.threads` # потоков.\n\nОбратите внимание, что если ваши рабочие потоки уже заняты, потому что у вас:\n\n* высокая конкуренция запросов\n\n* физическое шардинг любого типа:\n\n - распределённая таблица из нескольких обычных/реальных таблиц\n\n - реальная таблица, состоящая из слишком большого количества дисковых чанков\n\nто включение pseudo_sharding может не дать никаких преимуществ и даже привести к небольшому снижению пропускной способности. Если вы отдаёте приоритет более высокой пропускной способности над меньшей задержкой, рекомендуется отключить эту опцию.\n\nВключено по умолчанию.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_54\n\n\n\n### replication_connect_timeout\n\nДиректива `replication_connect_timeout` определяет тайм-аут для подключения к удалённому узлу. По умолчанию значение предполагается в миллисекундах, но может иметь [другой суффикс](../Server_settings/Special_suffixes.md). Значение по умолчанию — 1000 (1 секунда).\n\nПри подключении к удалённому узлу Manticore будет ждать не более этого времени для успешного установления соединения. Если тайм-аут достигнут, но соединение не установлено, и включены `retries`, будет предпринята повторная попытка.\n\n### replication_query_timeout\n\n`replication_query_timeout` задаёт время, в течение которого searchd будет ждать завершения запроса от удалённого узла. Значение по умолчанию — 3000 миллисекунд (3 секунды), но может иметь `суффикс` для указания другой единицы времени.\n\nПосле установления соединения Manticore будет ждать максимум `replication_query_timeout` для завершения удалённым узлом. Обратите внимание, что этот тайм-аут отличается от `replication_connect_timeout`, и общая возможная задержка, вызванная удалённым узлом, будет суммой обоих значений.\n\n### replication_retry_count\n\nЭтот параметр — целое число, указывающее, сколько раз Manticore попытается подключиться и выполнить запрос к удалённому узлу во время репликации, прежде чем сообщить о фатальной ошибке запроса. Значение по умолчанию — 3.\n\n### replication_retry_delay"
+ },
+ "is_code_or_comment": false
+ },
+ "5caecabc19ea8972e0757262166b27e57b6ccdb6886f0f383d4105905bd7b115": {
+ "original": "This option specifies the size of the block cache used by secondary indexes. It is optional, with a default of 8 MB. When secondary indexes work with filters that contain many values (e.g., IN() filters), they read and process metadata blocks for these values.\n\nIn joined queries, this process is repeated for each batch of rows from the left table, and each batch may reread the same metadata within a single joined query. This can severely affect performance. The metadata block cache keeps these blocks in memory so they\n\ncan be reused by subsequent batches.\n\nThe cache is only used in joined queries and has no effect on non-joined queries. Note that the cache size limit applies per attribute and per secondary index. Each attribute within each disk chunk operates within this limit. In the worst case, the total memory\n\nusage can be estimated by multiplying the limit by the number of disk chunks and the number of attributes used in joined queries.\n\nSetting `secondary_index_block_cache = 0` disables the cache.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_67\n\n\n\n### secondary_indexes\n\n\n\nThis option enables/disables the use of secondary indexes for search queries. It is optional, and the default is 1 (enabled). Note that you don't need to enable it for indexing as it is always enabled as long as the [Manticore Columnar Library](https://github.com/manticoresoftware/columnar) is installed. The latter is also required for using the indexes when searching. There are three modes available:\n\n* `0`: Disable the use of secondary indexes on search. They can be enabled for individual queries using [analyzer hints](../Searching/Options.md#Query-optimizer-hints)\n\n* `1`: Enable the use of secondary indexes on search. They can be disabled for individual queries using [analyzer hints](../Searching/Options.md#Query-optimizer-hints)\n\n* `force`: Same as enable, but any errors during the loading of secondary indexes will be reported, and the whole index will not be loaded into the daemon.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_68\n\n\n\n### server_id\n\n\n\nInteger number that serves as a server identifier used as a seed to generate a unique short UUID for nodes that are part of a replication cluster. The server_id must be unique across the nodes of a cluster and in the range from 0 to 127. If server_id is not set, it is calculated as a hash of the MAC address and the path to the PID file or a random number will be used as a seed for the short UUID.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_69\n\n\n\n### shutdown_timeout\n\n\n\n`searchd --stopwait` waiting time, in seconds (or [special_suffixes](../Server_settings/Special_suffixes.md)). Optional, default is 60 seconds.\n\nWhen you run `searchd --stopwait` your server needs to perform some activities before stopping, such as finishing queries, flushing RT RAM chunks, flushing attributes, and updating the binlog. These tasks require some time. `searchd --stopwait` will wait up to `shutdown_time` seconds for the server to finish its jobs. The suitable time depends on your table size and load.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_70\n\n\n\n### shutdown_token\n\nSHA1 hash of the password required to invoke the 'shutdown' command from a VIP Manticore SQL connection. Without it,[debug](../Reporting_bugs.md#DEBUG) 'shutdown' subcommand will never cause the server to stop. Note that such simple hashing should not be considered strong protection, as we don't use a salted hash or any kind of modern hash function. It is intended as a fool-proof measure for housekeeping daemons in a local network.\n\n### snippets_file_prefix\n\n\n\nA prefix to prepend to the local file names when generating snippets. Optional, default is the current working folder.\n\nThis prefix can be used in distributed snippets generation along with `load_files` or `load_files_scattered` options.\n\nNote that this is a prefix and **not** a path! This means that if a prefix is set to \"server1\" and the request refers to \"file23\", `searchd` will attempt to open \"server1file23\" (all of that without quotes). So, if you need it to be a path, you have to include the trailing slash.\n\nAfter constructing the final file path, the server unwinds all relative dirs and compares the final result with the value of `snippet_file_prefix`. If the result does not begin with the prefix, such a file will be rejected with an error message.\n\nFor example, if you set it to `/mnt/data` and someone calls snippet generation with the file `../../../etc/passwd` as the source, they will get the error message:\n\n`File '/mnt/data/../../../etc/passwd' escapes '/mnt/data/' scope`\n\ninstead of the content of the file.\n\nAlso, with a non-set parameter and reading `/etc/passwd`, it will actually read /daemon/working/folder/etc/passwd since the default for the parameter is the server's working folder.\n\nNote also that this is a local option; it does not affect the agents in any way. So you can safely set a prefix on a master server. The requests routed to the agents will not be affected by the master's setting. They will, however, be affected by the agent's own settings.\n\nThis might be useful, for instance, when the document storage locations (whether local storage or NAS mountpoints) are inconsistent across the servers.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_71\n\n\n\n> **WARNING:** If you still want to access files from the FS root, you have to explicitly set `snippets_file_prefix` to empty value (by `snippets_file_prefix=` line), or to root (by `snippets_file_prefix=/`).\n\n### sphinxql_state\n\n\n\nPath to a file where the current SQL state will be serialized.",
+ "translations": {
+ "chinese": "此选项指定二级索引使用的块缓存大小。此项为可选，默认值为8 MB。当二级索引处理包含多个值的过滤器（例如，IN()过滤器）时，它们会读取并处理这些值的元数据块。\n\n在联接查询中，此过程会针对左表的每个行批次重复执行，并且每个批次可能在单个联接查询中重新读取相同的元数据。这会严重影响性能。元数据块缓存将这些块保存在内存中，以便\n\n后续批次可以重用。\n\n该缓存仅在联接查询中使用，对非联接查询无影响。请注意，缓存大小限制是针对每个属性和每个二级索引的。每个磁盘块中的每个属性都在此限制内运行。在最坏情况下，总内存\n\n使用量可通过将限制乘以磁盘块数量和联接查询中使用的属性数量来估算。\n\n设置 `secondary_index_block_cache = 0` 可禁用缓存。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_67\n\n\n\n### secondary_indexes\n\n\n\n此选项启用/禁用搜索查询中二级索引的使用。此项为可选，默认值为1（启用）。请注意，索引不需要启用此选项，因为只要安装了 [Manticore Columnar Library](https://github.com/manticoresoftware/columnar)，它始终处于启用状态。后者也是搜索时使用索引的前提。共有三种模式可用：\n\n* `0`：禁用搜索时使用二级索引。可以通过[分析器提示](../Searching/Options.md#Query-optimizer-hints)为单个查询启用。\n\n* `1`：启用搜索时使用二级索引。可以通过[分析器提示](../Searching/Options.md#Query-optimizer-hints)为单个查询禁用。\n\n* `force`：与启用相同，但在加载二级索引时出现任何错误都会被报告，且整个索引不会加载到守护进程中。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_68\n\n\n\n### server_id\n\n\n\n整数编号，作为服务器标识符，用作生成复制集群中节点唯一短UUID的种子。server_id必须在集群节点中唯一，且范围为0到127。如果未设置server_id，则会根据MAC地址和PID文件路径的哈希计算，或者使用随机数作为短UUID的种子。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_69\n\n\n\n### shutdown_timeout\n\n\n\n`searchd --stopwait` 的等待时间，单位为秒（或[特殊后缀](../Server_settings/Special_suffixes.md)）。可选，默认值为60秒。\n\n当您运行 `searchd --stopwait` 时，服务器需要在停止前执行一些操作，例如完成查询、刷新RT RAM块、刷新属性和更新binlog。这些任务需要一定时间。`searchd --stopwait` 会等待最多 `shutdown_time` 秒，以便服务器完成其任务。合适的时间取决于您的表大小和负载。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_70\n\n\n\n### shutdown_token\n\n调用VIP Manticore SQL连接的 'shutdown' 命令所需的密码的SHA1哈希值。没有它，[debug](../Reporting_bugs.md#DEBUG) 的 'shutdown' 子命令永远不会导致服务器停止。请注意，这种简单的哈希不应被视为强保护，因为我们没有使用加盐哈希或任何现代哈希函数。它旨在作为本地网络中维护守护进程的防呆措施。\n\n### snippets_file_prefix\n\n\n\n生成片段时要添加到本地文件名之前的前缀。可选，默认是当前工作文件夹。\n\n此前缀可与 `load_files` 或 `load_files_scattered` 选项一起用于分布式片段生成。\n\n请注意，这只是一个前缀，**不是**路径！这意味着如果前缀设置为 \"server1\"，请求引用 \"file23\"，`searchd` 会尝试打开 \"server1file23\"（不带引号）。因此，如果您需要它作为路径，必须包含尾部斜杠。\n\n构造最终文件路径后，服务器会展开所有相对目录，并将最终结果与 `snippet_file_prefix` 的值进行比较。如果结果不以该前缀开头，则该文件将被拒绝并显示错误消息。\n\n例如，如果设置为 `/mnt/data`，有人调用片段生成时以文件 `../../../etc/passwd` 作为源，则会收到错误消息：\n\n`File '/mnt/data/../../../etc/passwd' escapes '/mnt/data/' scope`\n\n而不是文件内容。\n\n此外，如果参数未设置且读取 `/etc/passwd`，实际上会读取 /daemon/working/folder/etc/passwd，因为该参数的默认值是服务器的工作文件夹。\n\n还请注意，这是本地选项；不会以任何方式影响代理。因此，您可以安全地在主服务器上设置前缀。路由到代理的请求不会受主服务器设置的影响，但会受代理自身设置的影响。\n\n这在文档存储位置（无论是本地存储还是NAS挂载点）在服务器间不一致时可能非常有用。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_71\n\n\n\n> **警告：** 如果您仍想访问文件系统根目录的文件，必须显式将 `snippets_file_prefix` 设置为空值（通过 `snippets_file_prefix=` 行），或设置为根目录（通过 `snippets_file_prefix=/`）。\n\n### sphinxql_state\n\n\n\n当前SQL状态序列化的文件路径。",
+ "russian": "Этот параметр задает размер кэш-блока, используемого вторичными индексами. Он является необязательным, по умолчанию — 8 МБ. Когда вторичные индексы работают с фильтрами, содержащими много значений (например, фильтры IN()), они читают и обрабатывают метаданные блоков для этих значений.\n\nВ объединённых запросах этот процесс повторяется для каждой партии строк из левой таблицы, и каждая партия может повторно читать одни и те же метаданные в рамках одного объединённого запроса. Это может значительно повлиять на производительность. Кэш метаданных блоков хранит эти блоки в памяти, чтобы\n\nих можно было повторно использовать последующими партиями.\n\nКэш используется только в объединённых запросах и не влияет на не объединённые запросы. Обратите внимание, что ограничение размера кэша применяется на каждый атрибут и на каждый вторичный индекс. Каждый атрибут в каждом дисковом чанке работает в рамках этого ограничения. В худшем случае общее использование\n\nпамяти можно оценить, умножив ограничение на количество дисковых чанков и количество атрибутов, используемых в объединённых запросах.\n\nУстановка `secondary_index_block_cache = 0` отключает кэш.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_67\n\n\n\n### secondary_indexes\n\n\n\nЭтот параметр включает/отключает использование вторичных индексов для поисковых запросов. Он необязателен, по умолчанию — 1 (включено). Обратите внимание, что включать его для индексации не нужно, так как он всегда включен, если установлена [Manticore Columnar Library](https://github.com/manticoresoftware/columnar). Последняя также требуется для использования индексов при поиске. Доступны три режима:\n\n* `0`: Отключить использование вторичных индексов при поиске. Их можно включить для отдельных запросов с помощью [подсказок анализатора](../Searching/Options.md#Query-optimizer-hints)\n\n* `1`: Включить использование вторичных индексов при поиске. Их можно отключить для отдельных запросов с помощью [подсказок анализатора](../Searching/Options.md#Query-optimizer-hints)\n\n* `force`: То же, что и включение, но любые ошибки при загрузке вторичных индексов будут зафиксированы, и весь индекс не будет загружен в демон.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_68\n\n\n\n### server_id\n\n\n\nЦелое число, служащее идентификатором сервера, используемое как зерно для генерации уникального короткого UUID для узлов, входящих в кластер репликации. server_id должен быть уникальным среди узлов кластера и находиться в диапазоне от 0 до 127. Если server_id не установлен, он вычисляется как хэш MAC-адреса и пути к PID-файлу или используется случайное число в качестве зерна для короткого UUID.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_69\n\n\n\n### shutdown_timeout\n\n\n\nВремя ожидания `searchd --stopwait` в секундах (или [special_suffixes](../Server_settings/Special_suffixes.md)). Необязательно, по умолчанию 60 секунд.\n\nКогда вы запускаете `searchd --stopwait`, серверу нужно выполнить некоторые действия перед остановкой, такие как завершение запросов, сброс RT RAM чанков, сброс атрибутов и обновление binlog. Эти задачи требуют времени. `searchd --stopwait` будет ждать до `shutdown_time` секунд, пока сервер не завершит работу. Подходящее время зависит от размера таблицы и нагрузки.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_70\n\n\n\n### shutdown_token\n\nSHA1-хэш пароля, необходимого для вызова команды 'shutdown' из VIP Manticore SQL соединения. Без него,[debug](../Reporting_bugs.md#DEBUG) подкоманда 'shutdown' никогда не остановит сервер. Обратите внимание, что такое простое хеширование не следует считать надежной защитой, так как мы не используем соль или современные хеш-функции. Это предназначено как мера предосторожности для управляющих демонов в локальной сети.\n\n### snippets_file_prefix\n\n\n\nПрефикс, который добавляется к локальным именам файлов при генерации сниппетов. Необязательно, по умолчанию — текущая рабочая папка.\n\nЭтот префикс можно использовать при распределённой генерации сниппетов вместе с опциями `load_files` или `load_files_scattered`.\n\nОбратите внимание, что это префикс, а **не** путь! Это означает, что если префикс установлен в \"server1\", а запрос ссылается на \"file23\", `searchd` попытается открыть \"server1file23\" (всё это без кавычек). Поэтому, если нужен путь, необходимо включить завершающий слэш.\n\nПосле построения окончательного пути к файлу сервер разворачивает все относительные каталоги и сравнивает результат с значением `snippet_file_prefix`. Если результат не начинается с префикса, такой файл будет отклонён с сообщением об ошибке.\n\nНапример, если установить `/mnt/data` и кто-то вызовет генерацию сниппетов с файлом `../../../etc/passwd` в качестве источника, он получит сообщение об ошибке:\n\n`File '/mnt/data/../../../etc/passwd' escapes '/mnt/data/' scope`\n\nвместо содержимого файла.\n\nТакже, если параметр не установлен и читается `/etc/passwd`, фактически будет прочитан /daemon/working/folder/etc/passwd, так как по умолчанию параметр равен рабочей папке сервера.\n\nОбратите внимание, что это локальная опция; она никак не влияет на агенты. Поэтому можно безопасно установить префикс на мастер-сервере. Запросы, направленные агентам, не будут затронуты настройкой мастера. Однако они будут затронуты собственными настройками агента.\n\nЭто может быть полезно, например, когда расположения хранилищ документов (локальное хранилище или точки монтирования NAS) различаются на серверах.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_71\n\n\n\n> **ВНИМАНИЕ:** Если вы всё же хотите получить доступ к файлам из корня файловой системы, необходимо явно установить `snippets_file_prefix` в пустое значение (строкой `snippets_file_prefix=`) или в корень (строкой `snippets_file_prefix=/`).\n\n### sphinxql_state\n\n\n\nПуть к файлу, в котором будет сериализовано текущее состояние SQL."
+ },
+ "is_code_or_comment": false
+ },
+ "4cbb86123ea9e181e046d6b04e61f1a1eb5bd67f93f6bf9c7aa847eabaa6f597": {
+ "original": "On server startup, this file gets replayed. On eligible state changes (e.g., SET GLOBAL), this file gets rewritten automatically. This can prevent a hard-to-diagnose problem: If you load UDF functions but Manticore crashes, when it gets (automatically) restarted, your UDF and global variables will no longer be available. Using persistent state helps ensure a graceful recovery with no such surprises.\n\n`sphinxql_state` cannot be used to execute arbitrary commands, such as `CREATE TABLE`.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_72\n\n\n\n### sphinxql_timeout\n\n\n\nMaximum time to wait between requests (in seconds, or [special_suffixes](../Server_settings/Special_suffixes.md)) when using the SQL interface. Optional, default is 15 minutes.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_73\n\n\n\n### ssl_ca\n\n\n\nPath to the SSL Certificate Authority (CA) certificate file (also known as root certificate). Optional, default is empty. When not empty, the certificate in `ssl_cert` should be signed by this root certificate.\n\nThe server uses the CA file to verify the signature on the certificate. The file must be in PEM format.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_74\n\n\n\n### ssl_cert\n\n\n\nPath to the server's SSL certificate. Optional, default is empty.\n\nThe server uses this certificate as a self-signed public key to encrypt HTTP traffic over SSL. The file must be in PEM format.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_75\n\n\n\n### ssl_key\n\n\n\nPath to the SSL certificate key. Optional, default is empty.\n\nThe server uses this private key to encrypt HTTP traffic over SSL. The file must be in PEM format.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_76\n\n\n\n### subtree_docs_cache\n\n\n\nMax common subtree document cache size, per-query. Optional, default is 0 (disabled).\n\nThis setting limits the RAM usage of a common subtree optimizer (see [multi-queries](../Searching/Multi-queries.md)). At most, this much RAM will be spent to cache document entries for each query. Setting the limit to 0 disables the optimizer.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_77\n\n\n\n### subtree_hits_cache\n\n\n\nMax common subtree hit cache size, per-query. Optional, default is 0 (disabled).\n\nThis setting limits the RAM usage of a common subtree optimizer (see [multi-queries](../Searching/Multi-queries.md)). At most, this much RAM will be spent to cache keyword occurrences (hits) for each query. Setting the limit to 0 disables the optimizer.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_78\n\n\n\n### threads\n\n\n\nNumber of working threads (or, size of thread pool) for the Manticore daemon. Manticore creates this number of OS threads on start, and they perform all jobs inside the daemon, such as executing queries, creating snippets, etc. Some operations may be split into sub-tasks and executed in parallel, for example:\n\n* Search in a real-time table\n\n* Search in a distributed table consisting of local tables\n\n* Percolate query call\n\n* and others\n\nBy default, it's set to the number of CPU cores on the server. Manticore creates the threads on start and keeps them until it's stopped. Each sub-task can use one of the threads when it needs it. When the sub-task finishes, it releases the thread so another sub-task can use it.\n\nIn the case of intensive I/O type of load, it might make sense to set the value higher than the number of CPU cores.\n\n\n\nCODE_BLOCK_79\n\n\n\n### thread_stack\n\n\n\nMaximum stack size for a job (coroutine, one search query may cause multiple jobs/coroutines). Optional, default is 128K.\n\nEach job has its own stack of 128K. When you run a query, it's checked for how much stack it requires. If the default 128K is enough, it's just processed. If it needs more, another job with an increased stack is scheduled, which continues processing. The maximum size of such an advanced stack is limited by this setting.\n\nSetting the value to a reasonably high rate will help with processing very deep queries without implying that overall RAM consumption will grow too high. For example, setting it to 1G does not imply that every new job will take 1G of RAM, but if we see that it requires, let's say, 100M stack, we just allocate 100M for the job. Other jobs at the same time will be running with their default 128K stack. The same way, we can run even more complex queries that need 500M. And only if we **see** internally that the job requires more than 1G of stack, we will fail and report about too low thread_stack.\n\nHowever, in practice, even a query which needs 16M of stack is often too complex for parsing and consumes too much time and resources to be processed. So, the daemon will process it, but limiting such queries by the `thread_stack` setting looks quite reasonable.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_80\n\n\n\n### unlink_old\n\n\n\nDetermines whether to unlink `.old` table copies on successful rotation. Optional, default is 1 (do unlink).\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_81\n\n\n\n### watchdog\n\n\n\nThreaded server watchdog. Optional, default is 1 (watchdog enabled).\n\nWhen a Manticore query crashes, it can take down the entire server. With the watchdog feature enabled, `searchd` also maintains a separate lightweight process that monitors the main server process and automatically restarts it in case of abnormal termination. The watchdog is enabled by default.\n\n\n\nCODE_BLOCK_82\n\n\n\n",
+ "translations": {
+ "chinese": "服务器启动时，会重放此文件。在符合条件的状态更改（例如，SET GLOBAL）时，此文件会自动重写。这可以防止一个难以诊断的问题：如果您加载了UDF函数但Manticore崩溃，当它（自动）重启时，您的UDF和全局变量将不再可用。使用持久状态有助于确保优雅恢复，避免此类意外。\n\n`sphinxql_state` 不能用于执行任意命令，例如 `CREATE TABLE`。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_72\n\n\n\n### sphinxql_timeout\n\n\n\n使用SQL接口时，请求之间的最大等待时间（以秒为单位，或使用 [special_suffixes](../Server_settings/Special_suffixes.md)）。可选，默认值为15分钟。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_73\n\n\n\n### ssl_ca\n\n\n\nSSL证书颁发机构（CA）证书文件的路径（也称为根证书）。可选，默认值为空。当不为空时，`ssl_cert` 中的证书应由此根证书签名。\n\n服务器使用CA文件来验证证书上的签名。该文件必须是PEM格式。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_74\n\n\n\n### ssl_cert\n\n\n\n服务器SSL证书的路径。可选，默认值为空。\n\n服务器使用此证书作为自签名公钥，通过SSL加密HTTP流量。该文件必须是PEM格式。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_75\n\n\n\n### ssl_key\n\n\n\nSSL证书密钥的路径。可选，默认值为空。\n\n服务器使用此私钥通过SSL加密HTTP流量。该文件必须是PEM格式。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_76\n\n\n\n### subtree_docs_cache\n\n\n\n每个查询的最大公共子树文档缓存大小。可选，默认值为0（禁用）。\n\n此设置限制公共子树优化器的RAM使用量（参见 [multi-queries](../Searching/Multi-queries.md)）。每个查询最多使用这么多RAM来缓存文档条目。将限制设置为0将禁用优化器。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_77\n\n\n\n### subtree_hits_cache\n\n\n\n每个查询的最大公共子树命中缓存大小。可选，默认值为0（禁用）。\n\n此设置限制公共子树优化器的RAM使用量（参见 [multi-queries](../Searching/Multi-queries.md)）。每个查询最多使用这么多RAM来缓存关键字出现（命中）。将限制设置为0将禁用优化器。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_78\n\n\n\n### threads\n\n\n\nManticore守护进程的工作线程数（或线程池大小）。Manticore启动时创建此数量的操作系统线程，它们执行守护进程内的所有任务，如执行查询、创建摘要等。一些操作可能被拆分为子任务并并行执行，例如：\n\n* 在实时表中搜索\n\n* 在由本地表组成的分布式表中搜索\n\n* 反向查询调用\n\n* 其他\n\n默认情况下，设置为服务器上的CPU核心数。Manticore启动时创建线程并保持运行直到停止。每个子任务在需要时可以使用其中一个线程。子任务完成后释放线程，供其他子任务使用。\n\n在I/O密集型负载情况下，设置的值高于CPU核心数可能更合理。\n\n\n\nCODE_BLOCK_79\n\n\n\n### thread_stack\n\n\n\n作业的最大栈大小（协程，一个搜索查询可能导致多个作业/协程）。可选，默认值为128K。\n\n每个作业有自己的128K栈。运行查询时，会检查其所需栈大小。如果默认的128K足够，则直接处理。如果需要更多，则调度另一个具有更大栈的作业继续处理。此高级栈的最大大小受此设置限制。\n\n将此值设置为合理较高的数值，有助于处理非常深的查询，而不会导致整体RAM消耗过高。例如，设置为1G并不意味着每个新作业都会占用1G RAM，但如果发现作业需要100M栈，则只为该作业分配100M。其他作业同时使用默认的128K栈。以此类推，可以运行需要500M的更复杂查询。只有当内部检测到作业需要超过1G栈时，才会失败并报告thread_stack过低。\n\n然而，实际上，即使需要16M栈的查询通常也过于复杂，解析耗时且资源消耗大。因此，守护进程会处理它，但通过`thread_stack`限制此类查询是合理的。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_80\n\n\n\n### unlink_old\n\n\n\n确定是否在成功轮换时取消链接 `.old` 表副本。可选，默认值为1（执行取消链接）。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_81\n\n\n\n### watchdog\n\n\n\n线程化服务器看门狗。可选，默认值为1（启用看门狗）。\n\n当Manticore查询崩溃时，可能导致整个服务器宕机。启用看门狗功能后，`searchd` 还维护一个轻量级的独立进程，监控主服务器进程，并在异常终止时自动重启。看门狗默认启用。\n\n\n\nCODE_BLOCK_82\n\n\n\n",
+ "russian": "При запуске сервера этот файл воспроизводится. При подходящих изменениях состояния (например, SET GLOBAL) этот файл автоматически перезаписывается. Это может предотвратить трудно диагностируемую проблему: если вы загружаете UDF-функции, но Manticore аварийно завершается, при (автоматическом) перезапуске ваши UDF и глобальные переменные больше не будут доступны. Использование постоянного состояния помогает обеспечить плавное восстановление без таких сюрпризов.\n\n`sphinxql_state` нельзя использовать для выполнения произвольных команд, таких как `CREATE TABLE`.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_72\n\n\n\n### sphinxql_timeout\n\n\n\nМаксимальное время ожидания между запросами (в секундах или с [специальными суффиксами](../Server_settings/Special_suffixes.md)) при использовании SQL-интерфейса. Необязательно, по умолчанию 15 минут.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_73\n\n\n\n### ssl_ca\n\n\n\nПуть к файлу сертификата удостоверяющего центра SSL (CA) (также известного как корневой сертификат). Необязательно, по умолчанию пусто. Если не пусто, сертификат в `ssl_cert` должен быть подписан этим корневым сертификатом.\n\nСервер использует файл CA для проверки подписи на сертификате. Файл должен быть в формате PEM.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_74\n\n\n\n### ssl_cert\n\n\n\nПуть к SSL-сертификату сервера. Необязательно, по умолчанию пусто.\n\nСервер использует этот сертификат как самоподписанный открытый ключ для шифрования HTTP-трафика по SSL. Файл должен быть в формате PEM.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_75\n\n\n\n### ssl_key\n\n\n\nПуть к ключу SSL-сертификата. Необязательно, по умолчанию пусто.\n\nСервер использует этот приватный ключ для шифрования HTTP-трафика по SSL. Файл должен быть в формате PEM.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_76\n\n\n\n### subtree_docs_cache\n\n\n\nМаксимальный размер кэша документов общего поддерева на запрос. Необязательно, по умолчанию 0 (отключено).\n\nЭтот параметр ограничивает использование ОЗУ оптимизатором общего поддерева (см. [мультизапросы](../Searching/Multi-queries.md)). Максимум столько ОЗУ будет потрачено на кэширование записей документов для каждого запроса. Установка лимита в 0 отключает оптимизатор.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_77\n\n\n\n### subtree_hits_cache\n\n\n\nМаксимальный размер кэша попаданий общего поддерева на запрос. Необязательно, по умолчанию 0 (отключено).\n\nЭтот параметр ограничивает использование ОЗУ оптимизатором общего поддерева (см. [мультизапросы](../Searching/Multi-queries.md)). Максимум столько ОЗУ будет потрачено на кэширование вхождений ключевых слов (попаданий) для каждого запроса. Установка лимита в 0 отключает оптимизатор.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_78\n\n\n\n### threads\n\n\n\nКоличество рабочих потоков (или размер пула потоков) для демона Manticore. Manticore создаёт это количество потоков ОС при запуске, и они выполняют все задачи внутри демона, такие как выполнение запросов, создание сниппетов и т.д. Некоторые операции могут быть разбиты на подзадачи и выполняться параллельно, например:\n\n* Поиск в таблице реального времени\n\n* Поиск в распределённой таблице, состоящей из локальных таблиц\n\n* Вызов перколяции запроса\n\n* и другие\n\nПо умолчанию установлено в количество ядер ЦП на сервере. Manticore создаёт потоки при запуске и сохраняет их до остановки. Каждая подзадача может использовать один из потоков, когда это необходимо. Когда подзадача завершается, она освобождает поток, чтобы другая подзадача могла его использовать.\n\nВ случае интенсивной нагрузки типа ввода-вывода может иметь смысл установить значение выше количества ядер ЦП.\n\n\n\nCODE_BLOCK_79\n\n\n\n### thread_stack\n\n\n\nМаксимальный размер стека для задачи (корутина, один поисковый запрос может вызвать несколько задач/корутин). Необязательно, по умолчанию 128K.\n\nКаждая задача имеет свой собственный стек размером 128K. При выполнении запроса проверяется, сколько стека он требует. Если стандартных 128K достаточно, запрос просто обрабатывается. Если требуется больше, планируется другая задача с увеличенным стеком, которая продолжает обработку. Максимальный размер такого расширенного стека ограничен этим параметром.\n\nУстановка значения на разумно высоком уровне поможет обрабатывать очень глубокие запросы без значительного увеличения общего потребления ОЗУ. Например, установка 1G не означает, что каждая новая задача будет занимать 1G ОЗУ, но если мы видим, что требуется, скажем, 100M стека, мы просто выделяем 100M для задачи. Другие задачи в это время будут работать со стандартным стеком 128K. Аналогично, можно запускать ещё более сложные запросы, которым нужно 500M. И только если мы **увидим** внутренне, что задача требует более 1G стека, мы завершимся с ошибкой и сообщим о слишком низком thread_stack.\n\nОднако на практике даже запрос, требующий 16M стека, часто слишком сложен для парсинга и занимает слишком много времени и ресурсов для обработки. Поэтому демон обработает его, но ограничение таких запросов настройкой `thread_stack` выглядит вполне разумным.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_80\n\n\n\n### unlink_old\n\n\n\nОпределяет, следует ли удалять копии таблиц с расширением `.old` при успешной ротации. Необязательно, по умолчанию 1 (удалять).\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_81\n\n\n\n### watchdog\n\n\n\nПоточный сторож сервера. Необязательно, по умолчанию 1 (сторож включён).\n\nКогда запрос Manticore аварийно завершается, он может привести к падению всего сервера. При включённой функции сторожа `searchd` также поддерживает отдельный лёгкий процесс, который контролирует основной процесс сервера и автоматически перезапускает его в случае ненормального завершения. Сторож включён по умолчанию.\n\n\n\nCODE_BLOCK_82\n\n\n\n"
+ },
+ "is_code_or_comment": false
+ },
+ "49799d830879f4dc97d1b34eef10928d6a9b0fbfbb526126d52a8d494e14ccac": {
+ "original": "When querying, some reads know in advance exactly how much data is there to be read, but some currently do not. Most prominently, hit list size is not currently known in advance. This setting lets you control how much data to read in such cases. It impacts hit list I/O time, reducing it for lists larger than unhinted read size, but raising it for smaller lists. It does **not** affect RAM usage because the read buffer will already be allocated. So it should not be greater than read_buffer.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_61\n\n\n\n### reset_network_timeout_on_packet\n\n\n\nRefines the behavior of networking timeouts (such as `network_timeout` and `agent_query_timeout`).\n\nWhen set to 0, timeouts limit the maximum time for sending the entire request/query.\n\nWhen set to 1 (default), timeouts limit the maximum time between network activities.\n\nWith replication, a node may need to send a large file (for example, 100GB) to another node. Assume the network can transfer data at 1GB/s, with a series of packets of 4-5MB each. To transfer the entire file, you would need 100 seconds. A default timeout of 5 seconds would only allow the transfer of 5GB before the connection is dropped. Increasing the timeout could be a workaround, but it is not scalable (for instance, the next file might be 150GB, leading to failure again). However, with the default `reset_network_timeout_on_packet` set to 1, the timeout is applied not to the entire transfer but to individual packets. As long as the transfer is in progress (and data is actually being received over the network during the timeout period), it is kept alive. If the transfer gets stuck, such that a timeout occurs between packets, it will be dropped.\n\nNote that if you set up a distributed table, each node — both master and agents — should be tuned. On the master side, `agent_query_timeout` is affected; on agents, `network_timeout` is relevant.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_62\n\n\n\n### rt_flush_period\n\n\n\nRT tables RAM chunk flush check period, in seconds (or [special_suffixes](../Server_settings/Special_suffixes.md)). Optional, default is 10 hours.\n\nActively updated RT tables that fully fit in RAM chunks can still result in ever-growing binlogs, impacting disk use and crash recovery time. With this directive, the search server performs periodic flush checks, and eligible RAM chunks can be saved, enabling consequential binlog cleanup. See [Binary logging](../Logging/Binary_logging.md) for more details.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_63\n\n\n\n### rt_merge_iops\n\n\n\nA maximum number of I/O operations (per second) that the RT chunks merge thread is allowed to start. Optional, default is 0 (no limit).\n\nThis directive lets you throttle down the I/O impact arising from the `OPTIMIZE` statements. It is guaranteed that all RT optimization activities will not generate more disk IOPS (I/Os per second) than the configured limit. Limiting rt_merge_iops can reduce search performance degradation caused by merging.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_64\n\n\n\n### rt_merge_maxiosize\n\n\n\nA maximum size of an I/O operation that the RT chunks merge thread is allowed to start. Optional, default is 0 (no limit).\n\nThis directive lets you throttle down the I/O impact arising from the `OPTIMIZE` statements. I/Os larger than this limit will be broken down into two or more I/Os, which will then be accounted for as separate I/Os with regards to the [rt_merge_iops](../Server_settings/Searchd.md#rt_merge_iops) limit. Thus, it is guaranteed that all optimization activities will not generate more than (rt_merge_iops * rt_merge_maxiosize) bytes of disk I/O per second.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_65\n\n\n\n### seamless_rotate\n\n\n\nPrevents `searchd` stalls while rotating tables with huge amounts of data to precache. Optional, default is 1 (enable seamless rotation). On Windows systems, seamless rotation is disabled by default.\n\nTables may contain some data that needs to be precached in RAM. At the moment, `.spa`, `.spb`, `.spi`, and `.spm` files are fully precached (they contain attribute data, blob attribute data, keyword table, and killed row map, respectively.) Without seamless rotate, rotating a table tries to use as little RAM as possible and works as follows:\n\n1. New queries are temporarily rejected (with \"retry\" error code);\n\n2. `searchd` waits for all currently running queries to finish;\n\n3. The old table is deallocated, and its files are renamed;\n\n4. New table files are renamed, and required RAM is allocated;\n\n5. New table attribute and dictionary data are preloaded to RAM;\n\n6. `searchd` resumes serving queries from the new table.\n\nHowever, if there's a lot of attribute or dictionary data, then the preloading step could take a noticeable amount of time - up to several minutes in the case of preloading 1-5+ GB files.\n\nWith seamless rotate enabled, rotation works as follows:\n\n1. New table RAM storage is allocated;\n\n2. New table attribute and dictionary data are asynchronously preloaded to RAM;\n\n3. On success, the old table is deallocated, and both tables' files are renamed;\n\n4. On failure, the new table is deallocated;\n\n5. At any given moment, queries are served either from the old or new table copy.\n\nSeamless rotate comes at the cost of higher peak memory usage during the rotation (because both old and new copies of `.spa/.spb/.spi/.spm` data need to be in RAM while preloading the new copy). Average usage remains the same.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_66\n\n\n\n### secondary_index_block_cache\n\n",
+ "translations": {
+ "chinese": "当查询时，有些读取操作事先就知道要读取的数据量，但有些目前还不知道。最显著的是，命中列表的大小目前是未知的。此设置允许您控制在这种情况下读取多少数据。它影响命中列表的I/O时间，对于大于未提示读取大小的列表，能减少I/O时间，但对于较小的列表则会增加I/O时间。它**不会**影响内存使用，因为读取缓冲区已经被分配。因此，它不应大于read_buffer。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_61\n\n\n\n### reset_network_timeout_on_packet\n\n\n\n细化网络超时行为（例如`network_timeout`和`agent_query_timeout`）。\n\n设置为0时，超时限制发送整个请求/查询的最大时间。\n\n设置为1（默认）时，超时限制网络活动之间的最大时间。\n\n在复制时，节点可能需要向另一个节点发送一个大文件（例如100GB）。假设网络传输速率为1GB/s，数据包大小为4-5MB。传输整个文件需要100秒。默认的5秒超时只允许传输5GB数据，之后连接会被断开。增加超时可以作为一种解决方法，但不可扩展（例如，下一个文件可能是150GB，仍会失败）。然而，默认`reset_network_timeout_on_packet`设置为1时，超时应用于单个数据包，而非整个传输。只要传输在进行中（且在超时期间网络上实际接收数据），连接就保持活跃。如果传输卡住，导致数据包间发生超时，则连接会被断开。\n\n注意，如果设置了分布式表，主节点和代理节点都应进行调优。主节点影响`agent_query_timeout`，代理节点影响`network_timeout`。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_62\n\n\n\n### rt_flush_period\n\n\n\nRT表RAM块刷新检查周期，单位为秒（或[special_suffixes](../Server_settings/Special_suffixes.md)）。可选，默认值为10小时。\n\n完全适合RAM块的主动更新RT表仍可能导致不断增长的二进制日志，影响磁盘使用和崩溃恢复时间。通过此指令，搜索服务器执行周期性刷新检查，符合条件的RAM块可以被保存，从而实现后续的二进制日志清理。详情见[二进制日志](../Logging/Binary_logging.md)。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_63\n\n\n\n### rt_merge_iops\n\n\n\nRT块合并线程允许启动的最大I/O操作数（每秒）。可选，默认值为0（无限制）。\n\n此指令允许您限制由`OPTIMIZE`语句引起的I/O影响。保证所有RT优化活动产生的磁盘IOPS（每秒I/O次数）不会超过配置的限制。限制rt_merge_iops可以减少合并导致的搜索性能下降。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_64\n\n\n\n### rt_merge_maxiosize\n\n\n\nRT块合并线程允许启动的最大I/O操作大小。可选，默认值为0（无限制）。\n\n此指令允许您限制由`OPTIMIZE`语句引起的I/O影响。超过此限制的I/O将被拆分成两个或更多I/O操作，这些操作将作为独立I/O计入[rt_merge_iops](../Server_settings/Searchd.md#rt_merge_iops)限制。因此，保证所有优化活动每秒产生的磁盘I/O不超过(rt_merge_iops * rt_merge_maxiosize)字节。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_65\n\n\n\n### seamless_rotate\n\n\n\n防止在旋转包含大量数据以进行预缓存的表时，`searchd`发生停顿。可选，默认值为1（启用无缝旋转）。在Windows系统上，默认禁用无缝旋转。\n\n表可能包含需要预缓存到RAM中的数据。目前，`.spa`、`.spb`、`.spi`和`.spm`文件会被完全预缓存（它们分别包含属性数据、blob属性数据、关键字表和已删除行映射）。没有无缝旋转时，旋转表尽量少用RAM，过程如下：\n\n1. 临时拒绝新查询（返回“重试”错误码）；\n\n2. `searchd`等待所有当前运行的查询完成；\n\n3. 旧表被释放，其文件被重命名；\n\n4. 新表文件被重命名，分配所需RAM；\n\n5. 新表的属性和字典数据预加载到RAM；\n\n6. `searchd`恢复从新表服务查询。\n\n然而，如果属性或字典数据量大，预加载步骤可能耗时显著——预加载1-5GB以上文件时可能需要几分钟。\n\n启用无缝旋转时，旋转过程如下：\n\n1. 分配新表的RAM存储；\n\n2. 异步预加载新表的属性和字典数据到RAM；\n\n3. 成功时，释放旧表，重命名两个表的文件；\n\n4. 失败时，释放新表；\n\n5. 任何时刻，查询要么从旧表，要么从新表副本服务。\n\n无缝旋转的代价是旋转期间峰值内存使用更高（因为预加载新副本时，旧副本和新副本的`.spa/.spb/.spi/.spm`数据都需在RAM中）。平均使用量保持不变。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_66\n\n\n\n### secondary_index_block_cache\n\n",
+ "russian": "При выполнении запроса некоторые чтения заранее точно знают, сколько данных нужно прочитать, но некоторые пока не знают. Наиболее заметно, что размер списка попаданий (hit list) в настоящее время заранее не известен. Этот параметр позволяет контролировать, сколько данных читать в таких случаях. Он влияет на время ввода-вывода списка попаданий, уменьшая его для списков, больших, чем размер чтения без подсказки, но увеличивая для меньших списков. Он **не** влияет на использование ОЗУ, поскольку буфер чтения уже будет выделен. Поэтому он не должен быть больше, чем read_buffer.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_61\n\n\n\n### reset_network_timeout_on_packet\n\n\n\nУточняет поведение сетевых таймаутов (таких как `network_timeout` и `agent_query_timeout`).\n\nЕсли установлено в 0, таймауты ограничивают максимальное время на отправку всего запроса/запроса.\n\nЕсли установлено в 1 (по умолчанию), таймауты ограничивают максимальное время между сетевой активностью.\n\nПри репликации узлу может потребоваться отправить большой файл (например, 100 ГБ) другому узлу. Предположим, что сеть может передавать данные со скоростью 1 ГБ/с, с серией пакетов по 4-5 МБ каждый. Для передачи всего файла потребуется 100 секунд. Таймаут по умолчанию в 5 секунд позволит передать только 5 ГБ, прежде чем соединение будет разорвано. Увеличение таймаута может быть обходным решением, но оно не масштабируется (например, следующий файл может быть 150 ГБ, что снова приведет к сбою). Однако при установленном по умолчанию `reset_network_timeout_on_packet` в 1 таймаут применяется не ко всей передаче, а к отдельным пакетам. Пока передача продолжается (и данные действительно принимаются по сети в течение периода таймаута), соединение поддерживается. Если передача застревает, и происходит таймаут между пакетами, соединение будет разорвано.\n\nОбратите внимание, что если вы настраиваете распределённую таблицу, каждый узел — как мастер, так и агенты — должен быть настроен. На стороне мастера влияет `agent_query_timeout`; на агентах — `network_timeout`.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_62\n\n\n\n### rt_flush_period\n\n\n\nПериод проверки сброса чанков ОЗУ RT-таблиц, в секундах (или [special_suffixes](../Server_settings/Special_suffixes.md)). Необязательно, по умолчанию 10 часов.\n\nАктивно обновляемые RT-таблицы, полностью помещающиеся в чанки ОЗУ, всё равно могут приводить к постоянно растущим бинарным журналам, что влияет на использование диска и время восстановления после сбоев. С помощью этой директивы поисковый сервер выполняет периодические проверки сброса, и подходящие чанки ОЗУ могут быть сохранены, что позволяет последующую очистку бинарных журналов. Подробнее см. в разделе [Binary logging](../Logging/Binary_logging.md).\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_63\n\n\n\n### rt_merge_iops\n\n\n\nМаксимальное количество операций ввода-вывода (в секунду), которые поток слияния чанков RT может начать. Необязательно, по умолчанию 0 (без ограничений).\n\nЭта директива позволяет ограничить влияние ввода-вывода, возникающее из-за операторов `OPTIMIZE`. Гарантируется, что все операции оптимизации RT не будут генерировать больше дисковых IOPS (операций ввода-вывода в секунду), чем заданный лимит. Ограничение rt_merge_iops может уменьшить деградацию производительности поиска, вызванную слиянием.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_64\n\n\n\n### rt_merge_maxiosize\n\n\n\nМаксимальный размер операции ввода-вывода, которую поток слияния чанков RT может начать. Необязательно, по умолчанию 0 (без ограничений).\n\nЭта директива позволяет ограничить влияние ввода-вывода, возникающее из-за операторов `OPTIMIZE`. Операции ввода-вывода, превышающие этот лимит, будут разбиты на две или более операций, которые затем будут учитываться как отдельные операции ввода-вывода в отношении лимита [rt_merge_iops](../Server_settings/Searchd.md#rt_merge_iops). Таким образом, гарантируется, что все операции оптимизации не будут генерировать более (rt_merge_iops * rt_merge_maxiosize) байт дискового ввода-вывода в секунду.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_65\n\n\n\n### seamless_rotate\n\n\n\nПредотвращает зависания `searchd` при ротации таблиц с огромным объёмом данных для предварительного кэширования. Необязательно, по умолчанию 1 (включена бесшовная ротация). В системах Windows бесшовная ротация по умолчанию отключена.\n\nТаблицы могут содержать данные, которые нужно предварительно кэшировать в ОЗУ. В настоящее время файлы `.spa`, `.spb`, `.spi` и `.spm` полностью предварительно кэшируются (они содержат данные атрибутов, данные блоб-атрибутов, таблицу ключевых слов и карту удалённых строк соответственно). Без бесшовной ротации ротация таблицы пытается использовать как можно меньше ОЗУ и работает следующим образом:\n\n1. Новые запросы временно отклоняются (с кодом ошибки \"retry\");\n\n2. `searchd` ждёт завершения всех текущих запросов;\n\n3. Старая таблица освобождается, и её файлы переименовываются;\n\n4. Файлы новой таблицы переименовываются, и выделяется необходимая ОЗУ;\n\n5. Данные атрибутов и словаря новой таблицы предварительно загружаются в ОЗУ;\n\n6. `searchd` возобновляет обслуживание запросов из новой таблицы.\n\nОднако если данных атрибутов или словаря много, этап предварительной загрузки может занять заметное время — до нескольких минут при загрузке файлов размером 1-5+ ГБ.\n\nПри включённой бесшовной ротации ротация работает так:\n\n1. Выделяется ОЗУ для хранения новой таблицы;\n\n2. Данные атрибутов и словаря новой таблицы асинхронно предварительно загружаются в ОЗУ;\n\n3. При успешной загрузке старая таблица освобождается, и файлы обеих таблиц переименовываются;\n\n4. При неудаче новая таблица освобождается;\n\n5. В любой момент запросы обслуживаются либо из старой, либо из новой копии таблицы.\n\nБесшовная ротация требует большего пикового использования памяти во время ротации (поскольку обе копии данных `.spa/.spb/.spi/.spm` должны находиться в ОЗУ во время предварительной загрузки новой копии). Среднее использование остаётся прежним.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_66\n\n\n\n### secondary_index_block_cache\n\n"
+ },
+ "is_code_or_comment": false
+ },
+ "02b8da0ada4fc956eba7d9a6b778c1ef03f186a401aea5b54b165864fb7c3cf3": {
+ "original": "Several picky MySQL client libraries depend on a particular version number format used by MySQL, and moreover, sometimes choose a different execution path based on the reported version number (rather than the indicated capabilities flags). For instance, Python MySQLdb 1.2.2 throws an exception when the version number is not in X.Y.ZZ format; MySQL .NET connector 6.3.x fails internally on version numbers 1.x along with a certain combination of flags, etc. To work around that, you can use the `mysql_version_string` directive and have `searchd` report a different version to clients connecting over the MySQL protocol. (By default, it reports its own version.)\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_42\n\n\n\n### net_workers\n\nNumber of network threads, the default is 1.\n\nThis setting is useful for extremely high query rates when just one thread is not enough to manage all the incoming queries.\n\n### net_wait_tm\n\nControls the busy loop interval of the network thread. The default is -1, and it can be set to -1, 0, or a positive integer.\n\nIn cases where the server is configured as a pure master and just routes requests to agents, it is important to handle requests without delays and not allow the network thread to sleep. There is a busy loop for that. After an incoming request, the network thread uses CPU poll for `10 * net_wait_tm` milliseconds if `net_wait_tm` is a positive number or polls only with the CPU if `net_wait_tm` is `0`. Also, the busy loop can be disabled with `net_wait_tm = -1` - in this case, the poller sets the timeout to the actual agent's timeouts on the system polling call.\n\n> **WARNING:** A CPU busy loop actually loads the CPU core, so setting this value to any non-default value will cause noticeable CPU usage even with an idle server.\n\n### net_throttle_accept\n\nDefines how many clients are accepted on each iteration of the network loop. Default is 0 (unlimited), which should be fine for most users. This is a fine-tuning option to control the throughput of the network loop in high load scenarios.\n\n### net_throttle_action\n\nDefines how many requests are processed on each iteration of the network loop. The default is 0 (unlimited), which should be fine for most users. This is a fine-tuning option to control the throughput of the network loop in high load scenarios.\n\n### network_timeout\n\n\n\nNetwork client request read/write timeout, in seconds (or [special_suffixes](../Server_settings/Special_suffixes.md)). Optional, the default is 5 seconds. `searchd` will forcibly close a client connection which fails to send a query or read a result within this timeout.\n\nNote also the [reset_network_timeout_on_packet](../Server_settings/Searchd.md#reset_network_timeout_on_packet) parameter. This parameter alters the behavior of `network_timeout` from applying to the entire `query` or `result` to individual packets instead. Typically, a query/result fits within one or two packets. However, in cases where a large amount of data is required, this parameter can be invaluable in maintaining active operations.\n\n\n\nCODE_BLOCK_43\n\n\n\n### node_address\n\n\n\nThis setting allows you to specify the network address of the node. By default, it is set to the replication [listen](../Server_settings/Searchd.md#listen) address. This is correct in most cases; however, there are situations where you have to specify it manually:\n\n* Node behind a firewall\n\n* Network address translation enabled (NAT)\n\n* Container deployments, such as Docker or cloud deployments\n\n* Clusters with nodes in more than one region\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_44\n\n\n\n### not_terms_only_allowed\n\n\n\nThis setting determines whether to allow queries with only the [negation](../Searching/Full_text_matching/Operators.md#Negation-operator) full-text operator. Optional, the default is 0 (fail queries with only the NOT operator).\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_45\n\n\n\n### optimize_cutoff\n\n\n\nSets the default table compaction threshold. Read more here - [Number of optimized disk chunks](../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks). This setting can be overridden with the per-query option [cutoff](../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks). It can also be changed dynamically via [SET GLOBAL](../Server_settings/Setting_variables_online.md#SET).\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_46\n\n\n\n### persistent_connections_limit\n\n\n\nThis setting determines the maximum number of simultaneous persistent connections to remote [persistent agents](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md). Each time an agent defined under `agent_persistent` is connected, we try to reuse an existing connection (if any), or connect and save the connection for future use. However, in some cases, it makes sense to limit the number of such persistent connections. This directive defines the limit. It affects the number of connections to each agent's host across all distributed tables.\n\nIt is reasonable to set the value equal to or less than the [max_connections](../Server_settings/Searchd.md#max_connections) option in the agent's config.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_47\n\n\n\n### pid_file\n\n\n\npid_file is a mandatory configuration option in Manticore search that specifies the path of the file where the process ID of the `searchd` server is stored.\n\nThe searchd process ID file is re-created and locked on startup, and contains the head server process ID while the server is running. It is unlinked on server shutdown.",
+ "translations": {
+ "chinese": "Several picky MySQL client libraries depend on a particular version number format used by MySQL, and moreover, sometimes choose a different execution path based on the reported version number (rather than the indicated capabilities flags). For instance, Python MySQLdb 1.2.2 throws an exception when the version number is not in X.Y.ZZ format; MySQL .NET connector 6.3.x fails internally on version numbers 1.x along with a certain combination of flags, etc. To work around that, you can use the `mysql_version_string` directive and have `searchd` report a different version to clients connecting over the MySQL protocol. (By default, it reports its own version.)\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_42\n\n\n\n### net_workers\n\n网络线程数，默认值为1。\n\n当查询速率极高且单线程无法处理所有传入查询时，此设置非常有用。\n\n### net_wait_tm\n\n控制网络线程的忙循环间隔。默认值为-1，可以设置为-1、0或正整数。\n\n在服务器配置为纯主节点且仅将请求路由到代理的情况下，重要的是无延迟地处理请求，不允许网络线程休眠。为此有一个忙循环。在收到请求后，如果`net_wait_tm`为正数，网络线程会使用CPU轮询`10 * net_wait_tm`毫秒；如果`net_wait_tm`为`0`，则仅使用CPU轮询。此外，可以通过设置`net_wait_tm = -1`禁用忙循环——在这种情况下，轮询器在系统轮询调用中将超时设置为实际代理的超时。\n\n> **警告：** CPU忙循环实际上会占用CPU核心，因此将此值设置为非默认值即使在服务器空闲时也会导致明显的CPU使用率。\n\n### net_throttle_accept\n\n定义每次网络循环迭代中接受的客户端数量。默认值为0（无限制），对大多数用户来说足够。此为微调选项，用于在高负载场景下控制网络循环的吞吐量。\n\n### net_throttle_action\n\n定义每次网络循环迭代中处理的请求数量。默认值为0（无限制），对大多数用户来说足够。此为微调选项，用于在高负载场景下控制网络循环的吞吐量。\n\n### network_timeout\n\n\n\n网络客户端请求读写超时时间，单位为秒（或 [special_suffixes](../Server_settings/Special_suffixes.md)）。可选，默认值为5秒。`searchd`将在客户端未能在此超时内发送查询或读取结果时强制关闭连接。\n\n另请注意参数 [reset_network_timeout_on_packet](../Server_settings/Searchd.md#reset_network_timeout_on_packet)。该参数将`network_timeout`的行为从应用于整个`query`或`result`改为应用于单个数据包。通常，查询/结果适合一个或两个数据包。然而，在需要大量数据的情况下，该参数对于保持操作活跃非常有用。\n\n\n\nCODE_BLOCK_43\n\n\n\n### node_address\n\n\n\n此设置允许您指定节点的网络地址。默认情况下，它设置为复制的[listen](../Server_settings/Searchd.md#listen)地址。在大多数情况下这是正确的；但在以下情况下需要手动指定：\n\n* 节点位于防火墙后面\n\n* 启用了网络地址转换（NAT）\n\n* 容器部署，如Docker或云部署\n\n* 集群中节点分布在多个区域\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_44\n\n\n\n### not_terms_only_allowed\n\n\n\n此设置决定是否允许仅包含[否定](../Searching/Full_text_matching/Operators.md#Negation-operator)全文操作符的查询。可选，默认值为0（不允许仅含NOT操作符的查询）。\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_45\n\n\n\n### optimize_cutoff\n\n\n\n设置默认的表压缩阈值。详情请参阅 - [优化的磁盘块数量](../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks)。此设置可被每查询选项[cutoff](../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks)覆盖。也可以通过[SET GLOBAL](../Server_settings/Setting_variables_online.md#SET)动态更改。\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_46\n\n\n\n### persistent_connections_limit\n\n\n\n此设置决定到远程[persistent agents](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)的最大同时持久连接数。每次连接定义在`agent_persistent`下的代理时，都会尝试重用现有连接（如果有），或连接并保存该连接以供将来使用。然而，在某些情况下，限制此类持久连接数是合理的。此指令定义了该限制。它影响所有分布式表中到每个代理主机的连接数。\n\n合理的做法是将该值设置为不大于代理配置中的[max_connections](../Server_settings/Searchd.md#max_connections)选项。\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_47\n\n\n\n### pid_file\n\n\n\npid_file是Manticore搜索中的一个必需配置选项，指定存储`searchd`服务器进程ID的文件路径。\n\nsearchd进程ID文件在启动时被重新创建并锁定，服务器运行时包含主服务器进程ID。服务器关闭时该文件被删除。",
+ "russian": "Несколько придирчивых клиентских библиотек MySQL зависят от определённого формата номера версии, используемого MySQL, и более того, иногда выбирают другой путь выполнения на основе сообщаемого номера версии (а не указанных флагов возможностей). Например, Python MySQLdb 1.2.2 выбрасывает исключение, если номер версии не в формате X.Y.ZZ; MySQL .NET connector 6.3.x внутренне не работает с номерами версий 1.x вместе с определённой комбинацией флагов и т.д. Чтобы обойти это, вы можете использовать директиву `mysql_version_string` и заставить `searchd` сообщать клиентам, подключающимся по протоколу MySQL, другую версию. (По умолчанию он сообщает свою собственную версию.)\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_42\n\n\n\n### net_workers\n\nКоличество сетевых потоков, по умолчанию 1.\n\nЭтот параметр полезен при чрезвычайно высоких скоростях запросов, когда одного потока недостаточно для обработки всех входящих запросов.\n\n### net_wait_tm\n\nУправляет интервалом busy loop сетевого потока. По умолчанию -1, может быть установлен в -1, 0 или положительное целое число.\n\nВ случаях, когда сервер настроен как чистый мастер и просто маршрутизирует запросы к агентам, важно обрабатывать запросы без задержек и не позволять сетевому потоку засыпать. Для этого существует busy loop. После входящего запроса сетевой поток использует CPU poll в течение `10 * net_wait_tm` миллисекунд, если `net_wait_tm` положительное число, или опрашивает только CPU, если `net_wait_tm` равен `0`. Также busy loop можно отключить с помощью `net_wait_tm = -1` — в этом случае poller устанавливает таймауты, соответствующие реальным таймаутам агентов в системном вызове опроса.\n\n> **ВНИМАНИЕ:** Busy loop загружает ядро CPU, поэтому установка этого значения в любое не стандартное значение приведёт к заметному использованию CPU даже при простое сервера.\n\n### net_throttle_accept\n\nОпределяет, сколько клиентов принимается на каждой итерации сетевого цикла. По умолчанию 0 (без ограничений), что подходит большинству пользователей. Это параметр тонкой настройки для контроля пропускной способности сетевого цикла при высокой нагрузке.\n\n### net_throttle_action\n\nОпределяет, сколько запросов обрабатывается на каждой итерации сетевого цикла. По умолчанию 0 (без ограничений), что подходит большинству пользователей. Это параметр тонкой настройки для контроля пропускной способности сетевого цикла при высокой нагрузке.\n\n### network_timeout\n\n\n\nТаймаут чтения/записи запроса клиента сети, в секундах (или с использованием [special_suffixes](../Server_settings/Special_suffixes.md)). Необязательно, по умолчанию 5 секунд. `searchd` принудительно закроет соединение клиента, если тот не отправит запрос или не прочитает результат в течение этого таймаута.\n\nОбратите внимание также на параметр [reset_network_timeout_on_packet](../Server_settings/Searchd.md#reset_network_timeout_on_packet). Этот параметр изменяет поведение `network_timeout` с применения к всему `query` или `result` на применение к отдельным пакетам. Обычно запрос/результат помещается в один или два пакета. Однако в случаях, когда требуется большой объём данных, этот параметр может быть незаменим для поддержания активных операций.\n\n\n\nCODE_BLOCK_43\n\n\n\n### node_address\n\n\n\nЭтот параметр позволяет указать сетевой адрес узла. По умолчанию он установлен в адрес репликации [listen](../Server_settings/Searchd.md#listen). Это правильно в большинстве случаев; однако бывают ситуации, когда его нужно указать вручную:\n\n* Узел за файрволом\n\n* Включён сетевой транслятор адресов (NAT)\n\n* Развёртывания в контейнерах, таких как Docker или облачные развёртывания\n\n* Кластеры с узлами в более чем одном регионе\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_44\n\n\n\n### not_terms_only_allowed\n\n\n\nЭтот параметр определяет, разрешать ли запросы, содержащие только оператор [отрицания](../Searching/Full_text_matching/Operators.md#Negation-operator) полнотекстового поиска. Необязательно, по умолчанию 0 (запрещать запросы с только оператором NOT).\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_45\n\n\n\n### optimize_cutoff\n\n\n\nУстанавливает порог сжатия таблицы по умолчанию. Подробнее здесь — [Number of optimized disk chunks](../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks). Этот параметр можно переопределить с помощью опции запроса [cutoff](../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks). Также его можно изменить динамически через [SET GLOBAL](../Server_settings/Setting_variables_online.md#SET).\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_46\n\n\n\n### persistent_connections_limit\n\n\n\nЭтот параметр определяет максимальное количество одновременных постоянных соединений с удалёнными [persistent agents](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md). Каждый раз, когда агент, определённый в `agent_persistent`, подключается, мы пытаемся повторно использовать существующее соединение (если оно есть) или подключиться и сохранить соединение для будущего использования. Однако в некоторых случаях имеет смысл ограничить количество таких постоянных соединений. Эта директива задаёт лимит. Она влияет на количество соединений с хостом каждого агента во всех распределённых таблицах.\n\nРекомендуется установить значение равным или меньше опции [max_connections](../Server_settings/Searchd.md#max_connections) в конфигурации агента.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_47\n\n\n\n### pid_file\n\n\n\npid_file — обязательный параметр конфигурации в Manticore search, который указывает путь к файлу, где хранится идентификатор процесса сервера `searchd`.\n\nФайл с идентификатором процесса searchd пересоздаётся и блокируется при запуске, содержит идентификатор главного процесса сервера во время работы сервера. При остановке сервера файл удаляется."
+ },
+ "is_code_or_comment": false
+ },
+ "9a5a764258c6876b5ee2dba0591bf7322fbdedcd6c4f3b316e771ef109377275": {
+ "original": "For general knowledge about the TCP Fast Open extension, please consult with [Wikipedia](https://en.wikipedia.org/wiki/TCP_Fast_Open). In short, it allows the elimination of one TCP round-trip when establishing a connection.\n\nIn practice, using TFO in many situations may optimize client-agent network efficiency, as if [persistent agents](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md) are in play, but without holding active connections, and also without limitation for the maximum num of connections.\n\nOn modern OS, TFO support is usually switched 'on' at the system level, but this is just a 'capability', not the rule. Linux (as the most progressive) has supported it since 2011, on kernels starting from 3.7 (for the server-side). Windows has supported it from some builds of Windows 10. Other operating systems (FreeBSD, MacOS) are also in the game.\n\nFor Linux system server checks variable `/proc/sys/net/ipv4/tcp_fastopen` and behaves according to it. Bit 0 manages client side, bit 1 rules listeners. By default, the system has this parameter set to 1, i.e., clients enabled, listeners disabled.\n\n### log\n\n\n\nThe log setting specifies the name of the log file where all `searchd` run time events will be logged. If not specified, the default name is 'searchd.log'.\n\nAlternatively, you can use the 'syslog' as the file name. In this case, the events will be sent to the syslog daemon. To use the syslog option, you need to configure Manticore with the `-–with-syslog` option during building.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_33\n\n\n\n### max_batch_queries\n\n\n\nLimits the amount of queries per batch. Optional, default is 32.\n\nMakes searchd perform a sanity check of the amount of queries submitted in a single batch when using [multi-queries](../Searching/Multi-queries.md). Set it to 0 to skip the check.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_34\n\n\n\n### max_connections\n\n\n\nMaximum number of simultaneous client connections. Unlimited by default. That is usually noticeable only when using any kind of persistent connections, like cli mysql sessions or persistent remote connections from remote distributed tables. When the limit is exceeded you can still connect to the server using the [VIP connection](../Connecting_to_the_server/MySQL_protocol.md#VIP-connection). VIP connections are not counted towards the limit.\n\n\n\nCODE_BLOCK_35\n\n\n\n### max_threads_per_query\n\n\n\nInstance-wide limit of threads one operation can use. By default, appropriate operations can occupy all CPU cores, leaving no room for other operations. For example, `call pq` against a considerably large percolate table can utilize all threads for tens of seconds. Setting `max_threads_per_query` to, say, half of [threads](../Server_settings/Searchd.md#threads) will ensure that you can run a couple of such `call pq` operations in parallel.\n\nYou can also set this setting as a session or a global variable during runtime.\n\nAdditionally, you can control the behavior on a per-query basis with the help of the [threads OPTION](../Searching/Options.md#threads).\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_36\n\n\n\n### max_filters\n\n\n\nMaximum allowed per-query filter count. This setting is only used for internal sanity checks and does not directly affect RAM usage or performance. Optional, the default is 256.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_37\n\n\n\n### max_filter_values\n\n\n\nMaximum allowed per-filter values count. This setting is only used for internal sanity checks and does not directly affect RAM usage or performance. Optional, the default is 4096.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_38\n\n\n\n### max_open_files\n\n\n\nThe maximum number of files that the server is allowed to open is called the \"soft limit\". Note that serving large fragmented real-time tables may require this limit to be set high, as each disk chunk may occupy a dozen or more files. For example, a real-time table with 1000 chunks may require thousands of files to be opened simultaneously. If you encounter the error 'Too many open files' in the logs, try adjusting this option, as it may help resolve the issue.\n\nThere is also a \"hard limit\" that cannot be exceeded by the option. This limit is defined by the system and can be changed in the file `/etc/security/limits.conf` on Linux. Other operating systems may have different approaches, so consult your manuals for more information.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_39\n\n\n\n\n\nApart from direct numeric values, you can use the magic word 'max' to set the limit equal to the available current hard limit.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_40\n\n\n\n### max_packet_size\n\n\n\nMaximum allowed network packet size. This setting limits both query packets from clients and response packets from remote agents in a distributed environment. Only used for internal sanity checks, it does not directly affect RAM usage or performance. Optional, the default is 128M.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_41\n\n\n\n### mysql_version_string\n\n\n\nA server version string to return via the MySQL protocol. Optional, the default is empty (returns the Manticore version).",
+ "translations": {
+ "chinese": "有关TCP快速打开扩展的一般知识，请参阅[维基百科](https://en.wikipedia.org/wiki/TCP_Fast_Open)。简而言之，它允许在建立连接时消除一次TCP往返。\n\n在实际应用中，在许多情况下使用TFO可以优化客户端代理的网络效率，就像使用[持久代理](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)一样，但无需保持活动连接，也没有最大连接数的限制。\n\n在现代操作系统中，TFO支持通常在系统级别被默认开启，但这只是一个“能力”，而非规则。Linux（作为最先进的系统）自2011年起支持它，内核版本从3.7开始（针对服务器端）。Windows从某些Windows 10版本开始支持。其他操作系统（FreeBSD、MacOS）也支持该功能。\n\n对于Linux系统服务器，会检查变量`/proc/sys/net/ipv4/tcp_fastopen`并根据其值进行行为调整。第0位控制客户端，第1位控制监听器。默认情况下，系统将此参数设置为1，即客户端启用，监听器禁用。\n\n### log\n\n\n\nlog设置指定了所有`searchd`运行时事件将被记录的日志文件名。如果未指定，默认名称为'searchd.log'。\n\n或者，您可以使用'syslog'作为文件名。在这种情况下，事件将发送到syslog守护进程。要使用syslog选项，您需要在构建时使用`-–with-syslog`选项配置Manticore。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_33\n\n\n\n### max_batch_queries\n\n\n\n限制每批查询的数量。可选，默认值为32。\n\n使searchd在使用[多查询](../Searching/Multi-queries.md)时对单批提交的查询数量进行合理性检查。设置为0可跳过检查。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_34\n\n\n\n### max_connections\n\n\n\n最大同时客户端连接数。默认无限制。通常只有在使用任何类型的持久连接时才会明显，比如cli mysql会话或来自远程分布式表的持久远程连接。当超过限制时，您仍然可以使用[VIP连接](../Connecting_to_the_server/MySQL_protocol.md#VIP-connection)连接服务器。VIP连接不计入限制。\n\n\n\nCODE_BLOCK_35\n\n\n\n### max_threads_per_query\n\n\n\n单个操作可使用的线程实例范围限制。默认情况下，适当的操作可以占用所有CPU核心，不留给其他操作空间。例如，对一个相当大的percolate表执行`call pq`可能会占用所有线程数十秒。将`max_threads_per_query`设置为例如[threads](../Server_settings/Searchd.md#threads)的一半，将确保您可以并行运行几个这样的`call pq`操作。\n\n您也可以在运行时将此设置作为会话或全局变量设置。\n\n此外，您可以借助[threads选项](../Searching/Options.md#threads)按查询控制行为。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_36\n\n\n\n### max_filters\n\n\n\n每个查询允许的最大过滤器数量。此设置仅用于内部合理性检查，不直接影响内存使用或性能。可选，默认值为256。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_37\n\n\n\n### max_filter_values\n\n\n\n每个过滤器允许的最大值数量。此设置仅用于内部合理性检查，不直接影响内存使用或性能。可选，默认值为4096。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_38\n\n\n\n### max_open_files\n\n\n\n服务器允许打开的最大文件数称为“软限制”。请注意，服务大型碎片化实时表可能需要将此限制设置得较高，因为每个磁盘块可能占用十几个或更多文件。例如，一个有1000个块的实时表可能需要同时打开数千个文件。如果您在日志中遇到“Too many open files”错误，请尝试调整此选项，这可能有助于解决问题。\n\n还有一个“硬限制”，该限制不能被此选项超越。此限制由系统定义，可在Linux的`/etc/security/limits.conf`文件中更改。其他操作系统可能有不同的方法，请查阅相关手册获取更多信息。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_39\n\n\n\n\n\n除了直接的数值，您还可以使用魔法词“max”将限制设置为当前可用的硬限制。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_40\n\n\n\n### max_packet_size\n\n\n\n允许的最大网络数据包大小。此设置限制客户端的查询包和分布式环境中远程代理的响应包。仅用于内部合理性检查，不直接影响内存使用或性能。可选，默认值为128M。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_41\n\n\n\n### mysql_version_string\n\n\n\n通过MySQL协议返回的服务器版本字符串。可选，默认为空（返回Manticore版本）。",
+ "russian": "Для общего ознакомления с расширением TCP Fast Open, пожалуйста, обратитесь к [Wikipedia](https://en.wikipedia.org/wiki/TCP_Fast_Open). Кратко, оно позволяет исключить один круговой обмен TCP при установлении соединения.\n\nНа практике использование TFO во многих ситуациях может оптимизировать сетевую эффективность клиента-агента, как если бы использовались [постоянные агенты](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md), но без удержания активных соединений, а также без ограничения максимального количества соединений.\n\nНа современных ОС поддержка TFO обычно включена на уровне системы, но это всего лишь «возможность», а не правило. Linux (как самая прогрессивная) поддерживает его с 2011 года, начиная с ядер 3.7 (для серверной стороны). Windows поддерживает его с некоторых сборок Windows 10. Другие операционные системы (FreeBSD, MacOS) также участвуют.\n\nДля проверки на сервере Linux используется переменная `/proc/sys/net/ipv4/tcp_fastopen` и система ведет себя согласно ей. Бит 0 управляет клиентской стороной, бит 1 — слушателями. По умолчанию параметр установлен в 1, то есть клиенты включены, слушатели отключены.\n\n### log\n\n\n\nПараметр log указывает имя файла журнала, в который будут записываться все события времени выполнения `searchd`. Если не указано, по умолчанию используется имя 'searchd.log'.\n\nВ качестве альтернативы можно использовать 'syslog' в качестве имени файла. В этом случае события будут отправляться демону syslog. Для использования опции syslog необходимо собрать Manticore с опцией `-–with-syslog`.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_33\n\n\n\n### max_batch_queries\n\n\n\nОграничивает количество запросов в одном пакете. Необязательно, по умолчанию 32.\n\nЗаставляет searchd выполнять проверку разумности количества запросов, отправленных в одном пакете при использовании [мультизапросов](../Searching/Multi-queries.md). Установите в 0, чтобы пропустить проверку.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_34\n\n\n\n### max_connections\n\n\n\nМаксимальное количество одновременных клиентских соединений. По умолчанию неограничено. Обычно это заметно только при использовании каких-либо постоянных соединений, например, cli mysql сессий или постоянных удалённых соединений из удалённых распределённых таблиц. При превышении лимита вы всё равно можете подключиться к серверу, используя [VIP соединение](../Connecting_to_the_server/MySQL_protocol.md#VIP-connection). VIP соединения не учитываются в лимите.\n\n\n\nCODE_BLOCK_35\n\n\n\n### max_threads_per_query\n\n\n\nГлобальное ограничение количества потоков, которые может использовать одна операция. По умолчанию соответствующие операции могут занимать все ядра CPU, не оставляя места для других операций. Например, `call pq` по достаточно большой percolate таблице может использовать все потоки в течение десятков секунд. Установка `max_threads_per_query` в, скажем, половину от [threads](../Server_settings/Searchd.md#threads) обеспечит возможность запуска нескольких таких `call pq` операций параллельно.\n\nТакже эту настройку можно задать как сессионную или глобальную переменную во время работы.\n\nКроме того, поведение можно контролировать для каждого запроса отдельно с помощью [OPTION threads](../Searching/Options.md#threads).\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_36\n\n\n\n### max_filters\n\n\n\nМаксимально допустимое количество фильтров на запрос. Эта настройка используется только для внутренних проверок и не влияет напрямую на использование ОЗУ или производительность. Необязательно, по умолчанию 256.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_37\n\n\n\n### max_filter_values\n\n\n\nМаксимально допустимое количество значений в фильтре. Эта настройка используется только для внутренних проверок и не влияет напрямую на использование ОЗУ или производительность. Необязательно, по умолчанию 4096.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_38\n\n\n\n### max_open_files\n\n\n\nМаксимальное количество файлов, которые сервер может открыть, называется «мягким лимитом». Обратите внимание, что обслуживание больших фрагментированных таблиц реального времени может требовать установки этого лимита на высоком уровне, так как каждый дискованный кусок может занимать десятки и более файлов. Например, таблица реального времени с 1000 кусочков может требовать открытия тысяч файлов одновременно. Если в логах появляется ошибка 'Too many open files', попробуйте изменить эту опцию, это может помочь решить проблему.\n\nСуществует также «жесткий лимит», который нельзя превысить с помощью этой опции. Этот лимит задаётся системой и может быть изменён в файле `/etc/security/limits.conf` на Linux. Другие ОС могут иметь другие подходы, поэтому обратитесь к документации.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_39\n\n\n\n\n\nПомимо прямых числовых значений, можно использовать магическое слово 'max', чтобы установить лимит равным текущему доступному жесткому лимиту.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_40\n\n\n\n### max_packet_size\n\n\n\nМаксимально допустимый размер сетевого пакета. Эта настройка ограничивает как пакеты запросов от клиентов, так и пакеты ответов от удалённых агентов в распределённой среде. Используется только для внутренних проверок и не влияет напрямую на использование ОЗУ или производительность. Необязательно, по умолчанию 128M.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_41\n\n\n\n### mysql_version_string\n\n\n\nСтрока версии сервера, возвращаемая через протокол MySQL. Необязательно, по умолчанию пусто (возвращается версия Manticore)."
+ },
+ "is_code_or_comment": false
}
}
diff --git a/manual/chinese/Server_settings/Searchd.md b/manual/chinese/Server_settings/Searchd.md
index 8a5b1c37d9..1baa21d5a4 100644
--- a/manual/chinese/Server_settings/Searchd.md
+++ b/manual/chinese/Server_settings/Searchd.md
@@ -507,18 +507,26 @@ expansion_phrase_warning = 1
此设置指定 API 和 SQL 中的时间分组是按本地时区还是 UTC 计算。此项为可选，默认值为 0（表示“本地时区”）。
-默认情况下，所有“按时间分组”表达式（如 API 中的按天、周、月和年分组，以及 SQL 中的按天、月、年、年月、年月日分组）均使用本地时间进行。例如，如果您有属性时间为 `13:00 utc` 和 `15:00 utc` 的文档，在分组时，它们都会根据您的本地时区设置归入相应的设施组。如果您所在时区为 `utc`，则它们属于同一天，但如果您所在时区为 `utc+10`，则这些文档会被匹配到不同的“按天分组”设施组（因为 UTC+10 时区的 13:00 utc 是本地时间 23:00，而 15:00 是第二天的 01:00）。有时这种行为是不可接受的，且希望使时间分组不依赖于时区。您可以通过设置全局 TZ 环境变量来运行服务器，但这不仅会影响分组，还会影响日志中的时间戳，这可能也是不希望的。开启此选项（无论是在配置中还是使用 SQL 中的 [SET global](../Server_settings/Setting_variables_online.md#SET) 语句）将使所有时间分组表达式以 UTC 计算，而其他依赖时间的函数（例如服务器日志记录）仍使用本地时区。
+默认情况下，所有“按时间分组”表达式（如 API 中的按天、周、月和年分组，以及 SQL 中的按天、月、年、年月、年月日分组）均使用为时间函数配置的时区（参见 `timezone` 设置或 `TZ` 环境变量）进行。例如，如果您有属性时间为 `13:00 utc` 和 `15:00 utc` 的文档，在分组时，它们都会根据您的时区设置归入相应的分组。如果您所在时区是 `utc`，则它们属于同一天，但如果您所在时区是 `utc+10`，那么这些文档将被匹配到不同的“按天分组”中（因为 UTC+10 时区的 13:00 utc 是当地时间 23:00，而 15:00 是第二天的 01:00）。有时这种行为是不可接受的，且希望时间分组不依赖于时区。开启此选项（无论是在配置中还是使用 SQL 中的 [SET global](../Server_settings/Setting_variables_online.md#SET) 语句）将导致所有时间分组表达式均以 UTC 计算，而不管时区设置如何。
+
+**注意：** 日志记录始终使用实际的系统本地时区（在类 Unix 系统中从 `/etc/localtime` 确定），无论 `TZ` 环境变量或 `timezone` 配置设置为何。这确保日志时间戳反映实际系统时间，有助于调试和监控。
### timezone
-此设置指定日期/时间相关函数使用的时区。默认情况下，使用本地时区，但您可以指定 IANA 格式的其他时区（例如，`Europe/Amsterdam`）。
+此设置指定日期/时间相关函数（如 `NOW()`、`CURTIME()`、`FROM_UNIXTIME()` 等）使用的时区。默认情况下，使用系统本地时区，但您可以指定 IANA 格式的其他时区（例如 `Europe/Amsterdam` 或 `Asia/Singapore`）。
-请注意，此设置不会影响日志记录，日志始终使用本地时区。
+**时区解析顺序：**
+1. 如果显式设置了 `timezone` 配置，则优先使用。
+2. 否则，如果设置了 `TZ` 环境变量，则使用该变量。
+3. 如果两者都未设置，则使用系统本地时区（类 Unix 系统中从 `/etc/localtime` 获取）。
-另外，请注意，如果使用了 `grouping_in_utc`，则“按时间分组”函数仍将使用 UTC，而其他日期/时间相关函数将使用指定的时区。总体而言，不建议混合使用 `grouping_in_utc` 和 `timezone`。
+**重要说明：**
+- **日志记录**：日志始终使用实际的系统本地时区（从 `/etc/localtime` 确定），无论 `TZ` 环境变量或 `timezone` 配置为何。这确保日志时间戳反映实际系统时间，有助于调试和监控。
+- **时间函数**：日期/时间相关函数遵循 `timezone` 配置或 `TZ` 环境变量（如果设置），否则使用系统本地时区。
+- **分组**：如果启用 `grouping_in_utc`，则“按时间分组”功能将使用 UTC，而其他日期/时间相关函数将使用此设置指定的时区。总体而言，不建议混用 `grouping_in_utc` 和 `timezone`。
-您可以在配置中设置此选项，或通过 SQL 中的 [SET global](../Server_settings/Setting_variables_online.md#SET) 语句进行配置。
+您可以在配置中设置此选项，或使用 SQL 中的 [SET global](../Server_settings/Setting_variables_online.md#SET) 语句进行配置。
### ha_period_karma
@@ -526,9 +534,9 @@ expansion_phrase_warning = 1
此设置指定代理镜像统计窗口大小，单位为秒（或 [special_suffixes](../Server_settings/Special_suffixes.md)）。此项为可选，默认值为 60 秒。
-对于包含代理镜像的分布式表（详见 [agent](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)），主节点跟踪多个不同的每镜像计数器。这些计数器随后用于故障转移和平衡（主节点根据计数器选择最佳镜像）。计数器以 `ha_period_karma` 秒为块进行累积。
+对于包含代理镜像的分布式表（详见 [agent](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)），主节点跟踪多个不同的每镜像计数器。这些计数器用于故障转移和平衡（主节点根据计数器选择最佳镜像）。计数器以 `ha_period_karma` 秒为块进行累积。
-开始新块后，主节点可能仍会使用前一个块的累积值，直到新块填充到一半。因此，任何之前的历史最多在 1.5 倍 ha_period_karma 秒后停止影响镜像选择。
+开始新块后，主节点可能仍使用前一块的累积值，直到新块填充到一半。因此，任何之前的历史最多在 1.5 倍 ha_period_karma 秒后停止影响镜像选择。
尽管最多使用两个块进行镜像选择，但最多存储最近 15 个块以供监控使用。可以使用 [SHOW AGENT STATUS](../Node_info_and_management/Node_status.md#SHOW-AGENT-STATUS) 语句查看这些块。
@@ -549,7 +557,7 @@ ha_period_karma = 2m
此设置配置代理镜像之间的 ping 间隔，单位为毫秒（或 [special_suffixes](../Server_settings/Special_suffixes.md)）。此项为可选，默认值为 1000 毫秒。
-对于包含代理镜像的分布式表（详见 [agent](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)），主节点在空闲期间向所有镜像发送 ping 命令，以跟踪当前代理状态（存活或死亡、网络往返时间等）。此指令定义了 ping 之间的间隔。要禁用 ping，请将 ha_ping_interval 设置为 0。
+对于包含代理镜像的分布式表（详见 [agent](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)），主节点在空闲期间向所有镜像发送 ping 命令，以跟踪当前代理状态（存活或死亡、网络往返时间等）。此指令定义了 ping 之间的间隔。要禁用 ping，将 ha_ping_interval 设置为 0。
@@ -565,21 +573,21 @@ ha_ping_interval = 3s
### hostname_lookup
-`hostname_lookup` 选项定义了主机名更新策略。默认情况下，代理主机名的 IP 地址在服务器启动时缓存，以避免频繁访问 DNS。但在某些情况下，IP 可能动态变化（例如云托管），此时可能希望不缓存 IP。将此选项设置为 `request` 会禁用缓存，并在每次查询时查询 DNS。IP 地址也可以通过 `FLUSH HOSTNAMES` 命令手动更新。
+`hostname_lookup` 选项定义了主机名更新策略。默认情况下，代理主机名的 IP 地址在服务器启动时缓存，以避免频繁访问 DNS。但在某些情况下，IP 可能动态变化（例如云托管），此时可能希望不缓存 IP。将此选项设置为 `request` 可禁用缓存，并在每次查询时查询 DNS。IP 地址也可以通过 `FLUSH HOSTNAMES` 命令手动更新。
### jobs_queue_size
jobs_queue_size 设置定义了队列中可以同时存在多少“作业”。默认情况下无限制。
-在大多数情况下，“作业”指的是对单个本地表（普通表或实时表的磁盘分片）的一次查询。例如，如果您有一个由 2 个本地表组成的分布式表，或一个有 2 个磁盘分片的实时表，对它们的搜索查询通常会在队列中放入 2 个作业。然后，线程池（其大小由 [threads](../Server_settings/Searchd.md#threads) 定义）处理这些作业。但在某些情况下，如果查询过于复杂，可能会创建更多作业。当 [max_connections](../Server_settings/Searchd.md#max_connections) 和 [threads](../Server_settings/Searchd.md#threads) 无法平衡所需性能时，建议调整此设置。
+在大多数情况下，“作业”指的是对单个本地表（普通表或实时表的磁盘块）的一次查询。例如，如果您有一个由2个本地表组成的分布式表，或者一个有2个磁盘块的实时表，对其中任意一个的搜索查询通常会在队列中放入2个作业。然后，线程池（其大小由[threads](../Server_settings/Searchd.md#threads)定义）将处理它们。然而，在某些情况下，如果查询过于复杂，可能会创建更多作业。当[max_connections](../Server_settings/Searchd.md#max_connections)和[threads](../Server_settings/Searchd.md#threads)不足以在期望的性能之间找到平衡时，建议更改此设置。
### join_batch_size
-表连接通过累积一批匹配项来工作，这些匹配项是对左表执行查询的结果。然后将此批次作为单个查询在右表上处理。
+表连接通过累积一批匹配项来工作，这些匹配项是对左表执行查询的结果。然后，这批数据作为单个查询在右表上处理。
-此选项允许您调整批次大小。默认值为 `1000`，将此选项设置为 `0` 可禁用批处理。
+此选项允许您调整批处理大小。默认值为`1000`，将此选项设置为`0`则禁用批处理。
-较大的批次大小可能提升性能；但对于某些查询，可能导致内存消耗过大。
+较大的批处理大小可能提高性能；但是，对于某些查询，可能导致过度的内存消耗。
##### 示例：
@@ -593,11 +601,11 @@ join_batch_size = 2000
### join_cache_size
-对右表执行的每个查询由特定的 JOIN ON 条件定义，这些条件决定了从右表检索的结果集。
+对右表执行的每个查询由特定的JOIN ON条件定义，这些条件决定了从右表检索的结果集。
-如果只有少数几个唯一的 JOIN ON 条件，重用结果集比反复执行右表查询更高效。为此，结果集会被存储在缓存中。
+如果只有少数唯一的JOIN ON条件，重用结果比反复执行右表查询更高效。为启用此功能，结果集存储在缓存中。
-此选项允许您配置该缓存的大小。默认值为 `20 MB`，将此选项设置为 0 则禁用缓存。
+此选项允许您配置此缓存的大小。默认值为`20 MB`，将此选项设置为0则禁用缓存。
请注意，每个线程维护自己的缓存，因此在估算总内存使用时应考虑执行查询的线程数。
@@ -614,8 +622,8 @@ join_cache_size = 10M
### listen_backlog
-listen_backlog 设置决定了 TCP 监听队列的长度，用于传入连接。这对于逐个处理请求的 Windows 版本尤为重要。当连接队列达到限制时，新传入的连接将被拒绝。
-对于非 Windows 版本，默认值通常适用，通常无需调整此设置。
+listen_backlog设置确定传入连接的TCP监听队列长度。这对于逐个处理请求的Windows版本尤为重要。当连接队列达到其限制时，新传入的连接将被拒绝。
+对于非Windows版本，默认值通常适用，通常无需调整此设置。
@@ -631,9 +639,9 @@ listen_backlog = 20
### kibana_version_string
-返回给 Kibana 或 OpenSearch Dashboards 的服务器版本字符串。可选 — 默认设置为 `7.6.0`。
+返回给Kibana或OpenSearch Dashboards的服务器版本字符串。可选——默认设置为`7.6.0`。
-某些版本的 Kibana 和 OpenSearch Dashboards 期望服务器报告特定的版本号，且可能根据版本号表现不同。为解决此类问题，您可以使用此设置，使 Manticore 向 Kibana 或 OpenSearch Dashboards 报告自定义版本。
+某些版本的Kibana和OpenSearch Dashboards期望服务器报告特定的版本号，并可能根据版本号表现不同。为解决此类问题，您可以使用此设置，使Manticore向Kibana或OpenSearch Dashboards报告自定义版本。
##### 示例：
@@ -648,39 +656,39 @@ kibana_version_string = 1.2.3
### listen
-此设置允许您指定 Manticore 接受连接的 IP 地址和端口，或 Unix 域套接字路径。
+此设置允许您指定Manticore将接受连接的IP地址和端口，或Unix域套接字路径。
-`listen` 的通用语法为：
+`listen`的一般语法为：
```ini
listen = ( address ":" port | port | path | address ":" port start - port end ) [ ":" protocol [ "_vip" ] [ "_readonly" ] ]
```
您可以指定：
-* IP 地址（或主机名）和端口号
+* IP地址（或主机名）和端口号
* 或仅端口号
-* 或 Unix 套接字路径（Windows 不支持）
-* 或 IP 地址和端口范围
+* 或Unix套接字路径（Windows不支持）
+* 或IP地址和端口范围
-如果指定端口号但未指定地址，`searchd` 将监听所有网络接口。Unix 路径以斜杠开头。端口范围仅可用于复制协议。
+如果指定端口号但未指定地址，`searchd`将监听所有网络接口。Unix路径以斜杠开头。端口范围仅可用于复制协议。
您还可以为此套接字上的连接指定协议处理程序（监听器）。监听器包括：
-* **未指定** - Manticore 将在此端口接受来自：
- - 其他 Manticore 代理（即远程分布式表）
- - 通过 HTTP 和 HTTPS 的客户端
- - [Manticore Buddy](https://manticoresearch.com/blog/manticoresearch-buddy-intro/)。**确保您有此类监听器（或下文提到的 `http` 监听器），以避免 Manticore 功能受限。**
-* `mysql` MySQL 协议，用于 MySQL 客户端连接。注意：
+* **未指定** - Manticore将在此端口接受来自：
+ - 其他Manticore代理（即远程分布式表）
+ - 通过HTTP和HTTPS的客户端
+ - [Manticore Buddy](https://manticoresearch.com/blog/manticoresearch-buddy-intro/)。**确保您有此类监听器（或下面提到的`http`监听器），以避免Manticore功能受限。**
+* `mysql` MySQL协议，用于MySQL客户端连接。注意：
- 也支持压缩协议。
- - 如果启用了 [SSL](../Security/SSL.md#SSL)，可以建立加密连接。
-* `replication` - 用于节点通信的复制协议。更多细节见 [复制](../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md) 部分。您可以指定多个复制监听器，但它们必须监听同一 IP，端口可以不同。当您定义带端口范围的复制监听器（例如 `listen = 192.168.0.1:9320-9328:replication`）时，Manticore 不会立即开始监听这些端口。只有在开始使用复制时，才会从指定范围中随机选择空闲端口。复制正常工作至少需要范围内有 2 个端口。
-* `http` - 与 **未指定** 相同。Manticore 将在此端口接受来自远程代理和通过 HTTP、HTTPS 的客户端连接。
-* `https` - HTTPS 协议。Manticore 仅在此端口接受 HTTPS 连接。更多细节见 [SSL](../Security/SSL.md) 部分。
-* `sphinx` - 传统二进制协议。用于服务来自远程 [SphinxSE](../Extensions/SphinxSE.md) 客户端的连接。一些 Sphinx API 客户端实现（例如 Java 版本）需要显式声明监听器。
+ - 如果启用了[SSL](../Security/SSL.md#SSL)，可以建立加密连接。
+* `replication` - 用于节点通信的复制协议。更多细节见[复制](../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md)部分。您可以指定多个复制监听器，但它们必须监听相同IP；端口可以不同。当您定义带端口范围的复制监听器（例如`listen = 192.168.0.1:9320-9328:replication`）时，Manticore不会立即开始监听这些端口。只有在开始使用复制时，才会从指定范围中随机选择空闲端口。复制正常工作至少需要2个端口。
+* `http` - 与**未指定**相同。Manticore将在此端口接受来自远程代理和通过HTTP及HTTPS的客户端连接。
+* `https` - HTTPS协议。Manticore将在此端口**仅**接受HTTPS连接。更多细节见[SSL](../Security/SSL.md)部分。
+* `sphinx` - 传统二进制协议。用于服务来自远程[SphinxSE](../Extensions/SphinxSE.md)客户端的连接。一些Sphinx API客户端实现（例如Java客户端）需要显式声明监听器。
-在客户端协议后添加后缀 `_vip`（即除 `replication` 外的所有协议，如 `mysql_vip`、`http_vip` 或仅 `_vip`）会强制为连接创建专用线程，以绕过各种限制。这在服务器严重过载时进行节点维护非常有用，否则服务器可能会停滞或无法通过常规端口连接。
+在客户端协议后添加后缀`_vip`（即除`replication`外的所有协议，如`mysql_vip`、`http_vip`或仅`_vip`）会强制为连接创建专用线程，以绕过各种限制。这在服务器严重过载时进行节点维护非常有用，否则服务器可能会停滞或不允许通过常规端口连接。
-后缀 `_readonly` 为监听器设置[只读模式](../Security/Read_only.md)，限制其仅接受读取查询。
+后缀`_readonly`为监听器设置[只读模式](../Security/Read_only.md)，并限制其仅接受读取查询。
##### 示例：
@@ -703,54 +711,54 @@ listen = 127.0.0.1:9312:sphinx # listen for legacy Sphinx requests (e.g. from Sp
```
-可以有多个 `listen` 指令。`searchd` 会在所有指定的端口和套接字上监听客户端连接。Manticore 软件包中提供的默认配置定义了监听端口：
-* `9308` 和 `9312`，用于来自远程代理和非 MySQL 客户端的连接
-* 以及端口 `9306`，用于 MySQL 连接。
+可以有多个 `listen` 指令。`searchd` 将在所有指定的端口和套接字上监听客户端连接。Manticore 软件包中提供的默认配置定义了监听以下端口：
+* `9308` 和 `9312` 用于来自远程代理和非 MySQL 客户端的连接
+* 以及端口 `9306` 用于 MySQL 连接。
-如果配置中完全未指定任何 `listen`，Manticore 将等待以下连接：
-* `127.0.0.1:9306`，用于 MySQL 客户端
-* `127.0.0.1:9312`，用于 HTTP/HTTPS 以及来自其他 Manticore 节点和基于 Manticore 二进制 API 的客户端的连接。
+如果您在配置中根本没有指定任何 `listen`，Manticore 将等待以下连接：
+* `127.0.0.1:9306` 用于 MySQL 客户端
+* `127.0.0.1:9312` 用于 HTTP/HTTPS 以及来自其他 Manticore 节点和基于 Manticore 二进制 API 的客户端的连接。
#### 监听特权端口
-默认情况下，Linux 不允许 Manticore 监听 1024 以下的端口（例如 `listen = 127.0.0.1:80:http` 或 `listen = 127.0.0.1:443:https`），除非以 root 用户运行 searchd。如果您仍希望在非 root 用户下启动 Manticore 并监听 <1024 端口，请考虑以下任一方法（任一方法均可）：
+默认情况下，Linux 不允许您让 Manticore 监听 1024 以下的端口（例如 `listen = 127.0.0.1:80:http` 或 `listen = 127.0.0.1:443:https`），除非您以 root 身份运行 searchd。如果您仍然希望能够以非 root 用户启动 Manticore，使其监听 < 1024 的端口，请考虑执行以下操作之一（任意一个都应该有效）：
* 运行命令 `setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/searchd`
* 在 Manticore 的 systemd 单元中添加 `AmbientCapabilities=CAP_NET_BIND_SERVICE` 并重新加载守护进程（`systemctl daemon-reload`）。
#### 关于 Sphinx API 协议和 TFO 的技术细节
-Legacy Sphinx 协议有两个阶段：握手交换和数据流。握手包括客户端发送的4字节数据包，以及守护进程发送的4字节数据包，唯一目的——客户端确定远程是一个真实的 Sphinx 守护进程，守护进程确定远程是一个真实的 Sphinx 客户端。主要数据流非常简单：双方都声明它们的握手，另一方进行验证。使用短包交换意味着使用特殊的 `TCP_NODELAY` 标志，该标志关闭 Nagle 的 TCP 算法，并声明 TCP 连接将作为小包对话进行。
-然而，谁先发言在此协商中并没有严格定义。历史上，所有使用二进制 API 的客户端都是先发言：先发送握手，然后读取守护进程的4字节，再发送请求并读取守护进程的响应。
+传统的 Sphinx 协议有两个阶段：握手交换和数据流。握手由客户端发送的 4 字节数据包和守护进程发送的 4 字节数据包组成，唯一目的就是客户端确定远程是一个真实的 Sphinx 守护进程，守护进程确定远程是一个真实的 Sphinx 客户端。主要数据流非常简单：双方都声明它们的握手，另一方进行检查。该短包交换意味着使用特殊的 `TCP_NODELAY` 标志，该标志关闭 Nagle 的 TCP 算法，并声明 TCP 连接将作为小包对话进行。
+然而，谁先发言在此协商中并没有严格定义。历史上，所有使用二进制 API 的客户端都是先发言：先发送握手，然后读取守护进程的 4 字节，再发送请求并读取守护进程的响应。
当我们改进 Sphinx 协议兼容性时，考虑了以下几点：
-1. 通常，主代理通信是从已知客户端到已知主机的已知端口建立的。因此，端点提供错误握手的可能性很小。所以，我们可以隐式假设双方都是有效的，并且确实使用 Sphinx 协议通信。
-2. 基于此假设，我们可以将握手“粘合”到真实请求中，并在一个数据包中发送。如果后端是传统的 Sphinx 守护进程，它会将这个粘合的数据包读取为4字节握手，然后是请求体。由于它们都在一个包中，后端套接字减少了1个往返时间（RTT），前端缓冲区仍然正常工作。
-3. 继续假设：由于“查询”包相当小，握手更小，我们可以使用现代的 TFO（tcp-fast-open）技术，在初始的 TCP “SYN” 包中发送握手和请求体。也就是说：我们用粘合的握手+请求体包连接远程节点。守护进程接受连接后，立即在套接字缓冲区中拥有握手和请求体，因为它们都在第一个 TCP “SYN” 包中。这消除了另一个 RTT。
-4. 最后，教守护进程接受此改进。实际上，从应用角度看，这意味着不使用 `TCP_NODELAY`。从系统角度看，这意味着确保守护进程端启用 TFO 接受，客户端启用 TFO 发送。现代系统中，客户端 TFO 默认已启用，因此只需调整服务器端 TFO 即可使所有功能正常。
+1. 通常，主代理通信是从已知客户端到已知主机的已知端口建立的。因此，端点提供错误握手的可能性很小。所以，我们可以隐式假设双方都是有效的并且确实使用 Sphinx 协议通信。
+2. 基于此假设，我们可以将握手“粘合”到真实请求中并一次性发送。如果后端是传统的 Sphinx 守护进程，它会先读取这粘合包的前 4 字节作为握手，然后读取请求体。由于它们都在一个包中，后端套接字减少了 1 个 RTT，前端缓冲区仍然正常工作。
+3. 继续假设：由于“查询”包相当小，握手更小，我们可以使用现代 TFO（tcp-fast-open）技术在初始的 TCP “SYN” 包中发送握手和请求体。也就是说，我们用粘合的握手 + 请求体包连接远程节点。守护进程接受连接后，立即在套接字缓冲区中拥有握手和请求体，因为它们都在第一个 TCP “SYN” 包中。这消除了另一个 RTT。
+4. 最后，教守护进程接受此改进。实际上，从应用层看，这意味着不使用 `TCP_NODELAY`。从系统层面看，这意味着确保守护进程端启用 TFO，客户端端也启用发送 TFO。默认情况下，现代系统客户端 TFO 已默认启用，因此您只需调整服务器端 TFO 即可使一切正常工作。
-所有这些改进在不实际更改协议本身的情况下，允许我们从连接中消除 1.5 RTT 的 TCP 协议时间。如果查询和响应能够放入单个 TCP 包，则将整个二进制 API 会话从 3.5 RTT 降低到 2 RTT——这使网络协商速度提高约两倍。
+所有这些改进在不实际更改协议本身的情况下，允许我们从连接中消除 1.5 个 TCP 协议的 RTT。如果查询和响应能够放入单个 TCP 包中，则将整个二进制 API 会话从 3.5 RTT 降低到 2 RTT —— 这使网络协商速度提高约 2 倍。
-因此，我们所有的改进都基于一个最初未定义的声明：“谁先发言”。如果客户端先发言，我们可以应用所有这些优化，有效地在单个 TFO 包中处理连接 + 握手 + 查询。此外，我们可以查看接收包的开头，确定真实协议。这就是为什么你可以通过 API/http/https 连接到同一个端口。如果守护进程必须先发言，所有这些优化都不可能实现，多协议也不可能实现。这就是为什么我们为 MySQL 设置了专用端口，而没有将其与所有其他协议统一到同一端口。突然之间，在所有客户端中，有一个客户端是设计为守护进程先发送握手的。那就是 mysql/mariadb 的 SphinxSE 插件。因此，专门为这个单一客户端，我们专门定义了 `sphinx` 协议以最传统的方式工作。具体来说：双方都启用 `TCP_NODELAY` 并交换小包。守护进程在连接时发送握手，然后客户端发送握手，之后一切照常工作。这不是很优化，但能正常工作。如果你使用 SphinxSE 连接 Manticore——你必须专门为其指定一个明确声明为 `sphinx` 协议的监听器。对于其他客户端——避免使用此监听器，因为它较慢。如果你使用其他传统 Sphinx API 客户端——首先检查它们是否能在非专用多协议端口上工作。对于主代理链接，使用非专用（多协议）端口并启用客户端和服务器 TFO 工作良好，肯定会加快网络后端的工作速度，尤其是当你有非常轻量且快速的查询时。
+因此，我们所有的改进都基于一个最初未定义的声明：“谁先发言”。如果客户端先发言，我们可以应用所有这些优化，有效地在单个 TFO 包中处理连接 + 握手 + 查询。此外，我们可以查看接收包的开头并确定真实协议。这就是为什么您可以通过 API/http/https 连接到同一个端口。如果守护进程必须先发言，所有这些优化都不可能实现，多协议也不可能实现。这就是为什么我们为 MySQL 设置了专用端口，而没有将其与所有其他协议统一到同一端口。突然之间，在所有客户端中，有一个客户端设计为守护进程应先发送握手。那就是 mysql/mariadb 的 SphinxSE 插件。因此，专门为这个单一客户端，我们专门定义了 `sphinx` 协议以最传统的方式工作。即：双方都启用 `TCP_NODELAY` 并交换小包。守护进程在连接时发送握手，然后客户端发送握手，然后一切照常工作。这不是很优化，但能正常工作。如果您使用 SphinxSE 连接 Manticore —— 您必须专门为其指定一个明确声明 `sphinx` 协议的监听器。对于其他客户端 —— 避免使用此监听器，因为它较慢。如果您使用其他传统 Sphinx API 客户端 —— 首先检查它们是否能在非专用多协议端口上工作。对于主代理链接，使用非专用（多协议）端口并启用客户端和服务器 TFO 工作良好，且肯定会使网络后端工作更快，尤其是当您有非常轻量且快速的查询时。
### listen_tfo
此设置允许为所有监听器启用 TCP_FASTOPEN 标志。默认情况下，由系统管理，但可以通过设置为 '0' 明确关闭。
-关于 TCP Fast Open 扩展的一般知识，请参考 [Wikipedia](https://en.wikipedia.org/wiki/TCP_Fast_Open)。简而言之，它允许在建立连接时消除一次 TCP 往返。
+有关TCP快速打开扩展的一般知识，请参阅[维基百科](https://en.wikipedia.org/wiki/TCP_Fast_Open)。简而言之，它允许在建立连接时消除一次TCP往返。
-实际上，在许多情况下使用 TFO 可以优化客户端-代理的网络效率，就像 [持久代理](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md) 一样，但无需保持活动连接，也没有最大连接数限制。
+在实际应用中，在许多情况下使用TFO可以优化客户端代理的网络效率，就像使用[持久代理](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)一样，但无需保持活动连接，也没有最大连接数的限制。
-在现代操作系统中，TFO 支持通常在系统级别默认开启，但这只是“能力”，而非规则。Linux（作为最先进的系统）自2011年起支持，内核版本从3.7开始（服务器端）。Windows 从某些 Windows 10 版本开始支持。其他操作系统（FreeBSD、MacOS）也支持。
+在现代操作系统中，TFO支持通常在系统级别被默认开启，但这只是一个“能力”，而非规则。Linux（作为最先进的系统）自2011年起支持它，内核版本从3.7开始（针对服务器端）。Windows从某些Windows 10版本开始支持。其他操作系统（FreeBSD、MacOS）也支持该功能。
-对于 Linux 系统，服务器检查变量 `/proc/sys/net/ipv4/tcp_fastopen` 并据此行为。第0位控制客户端，第1位控制监听器。默认系统设置为1，即客户端启用，监听器禁用。
+对于Linux系统服务器，会检查变量`/proc/sys/net/ipv4/tcp_fastopen`并根据其值进行行为调整。第0位控制客户端，第1位控制监听器。默认情况下，系统将此参数设置为1，即客户端启用，监听器禁用。
### log
-log 设置指定日志文件名，所有 `searchd` 运行时事件将记录于此文件。如果未指定，默认文件名为 'searchd.log'。
+log设置指定了所有`searchd`运行时事件将被记录的日志文件名。如果未指定，默认名称为'searchd.log'。
-或者，您可以使用 'syslog' 作为文件名。在这种情况下，事件将被发送到 syslog 守护进程。要使用 syslog 选项，您需要在构建时使用 `-–with-syslog` 选项配置 Manticore。
+或者，您可以使用'syslog'作为文件名。在这种情况下，事件将发送到syslog守护进程。要使用syslog选项，您需要在构建时使用`-–with-syslog`选项配置Manticore。
@@ -767,9 +775,9 @@ log = /var/log/searchd.log
### max_batch_queries
-限制每批查询的数量。可选，默认值为 32。
+限制每批查询的数量。可选，默认值为32。
-当使用 [多查询](../Searching/Multi-queries.md) 时，使 searchd 对单个批次中提交的查询数量进行合理性检查。设置为 0 可跳过检查。
+使searchd在使用[多查询](../Searching/Multi-queries.md)时对单批提交的查询数量进行合理性检查。设置为0可跳过检查。
@@ -785,7 +793,7 @@ max_batch_queries = 256
### max_connections
-最大同时客户端连接数。默认无限制。通常只有在使用任何类型的持久连接时才会注意到，比如 cli mysql 会话或来自远程分布式表的持久远程连接。当超过限制时，您仍然可以使用 [VIP 连接](../Connecting_to_the_server/MySQL_protocol.md#VIP-connection) 连接服务器。VIP 连接不计入限制。
+最大同时客户端连接数。默认无限制。通常只有在使用任何类型的持久连接时才会明显，比如cli mysql会话或来自远程分布式表的持久远程连接。当超过限制时，您仍然可以使用[VIP连接](../Connecting_to_the_server/MySQL_protocol.md#VIP-connection)连接服务器。VIP连接不计入限制。
```ini
@@ -797,11 +805,11 @@ max_connections = 10
### max_threads_per_query
-单个操作可使用的线程实例范围限制。默认情况下，适当的操作可以占用所有 CPU 核心，不留给其他操作空间。例如，对相当大的 percolate 表执行 `call pq` 可能会利用所有线程持续数十秒。将 `max_threads_per_query` 设置为例如 [threads](../Server_settings/Searchd.md#threads) 的一半，将确保您可以并行运行几个这样的 `call pq` 操作。
+单个操作可使用的线程实例范围限制。默认情况下，适当的操作可以占用所有CPU核心，不留给其他操作空间。例如，对一个相当大的percolate表执行`call pq`可能会占用所有线程数十秒。将`max_threads_per_query`设置为例如[threads](../Server_settings/Searchd.md#threads)的一半，将确保您可以并行运行几个这样的`call pq`操作。
您也可以在运行时将此设置作为会话或全局变量设置。
-此外，您可以借助 [threads 选项](../Searching/Options.md#threads) 按查询控制行为。
+此外，您可以借助[threads选项](../Searching/Options.md#threads)按查询控制行为。
##### 示例：
@@ -816,7 +824,7 @@ max_threads_per_query = 4
### max_filters
-每个查询允许的最大过滤器数量。此设置仅用于内部合理性检查，不直接影响内存使用或性能。可选，默认值为 256。
+每个查询允许的最大过滤器数量。此设置仅用于内部合理性检查，不直接影响内存使用或性能。可选，默认值为256。
@@ -833,7 +841,7 @@ max_filters = 1024
### max_filter_values
-每个过滤器允许的最大值数量。此设置仅用于内部合理性检查，不直接影响内存使用或性能。可选，默认值为 4096。
+每个过滤器允许的最大值数量。此设置仅用于内部合理性检查，不直接影响内存使用或性能。可选，默认值为4096。
@@ -850,9 +858,9 @@ max_filter_values = 16384
### max_open_files
-服务器允许打开的最大文件数称为“软限制”。请注意，服务大型碎片化实时表可能需要将此限制设置得较高，因为每个磁盘块可能占用十几个或更多文件。例如，一个有 1000 个块的实时表可能需要同时打开数千个文件。如果您在日志中遇到“打开的文件过多”错误，请尝试调整此选项，这可能有助于解决问题。
+服务器允许打开的最大文件数称为“软限制”。请注意，服务大型碎片化实时表可能需要将此限制设置得较高，因为每个磁盘块可能占用十几个或更多文件。例如，一个有1000个块的实时表可能需要同时打开数千个文件。如果您在日志中遇到“Too many open files”错误，请尝试调整此选项，这可能有助于解决问题。
-还有一个“硬限制”，该限制不能被此选项超越。此限制由系统定义，可在 Linux 的 `/etc/security/limits.conf` 文件中更改。其他操作系统可能有不同的方法，请查阅您的手册以获取更多信息。
+还有一个“硬限制”，该限制不能被此选项超越。此限制由系统定义，可在Linux的`/etc/security/limits.conf`文件中更改。其他操作系统可能有不同的方法，请查阅相关手册获取更多信息。
##### 示例：
@@ -865,7 +873,7 @@ max_open_files = 10000
-除了直接的数字值，您还可以使用魔法词 'max' 将限制设置为当前可用的硬限制。
+除了直接的数值，您还可以使用魔法词“max”将限制设置为当前可用的硬限制。
##### 示例：
@@ -881,7 +889,7 @@ max_open_files = max
### max_packet_size
-允许的最大网络数据包大小。此设置限制来自客户端的查询包和分布式环境中远程代理的响应包。仅用于内部合理性检查，不直接影响内存使用或性能。可选，默认值为 128M。
+允许的最大网络数据包大小。此设置限制客户端的查询包和分布式环境中远程代理的响应包。仅用于内部合理性检查，不直接影响内存使用或性能。可选，默认值为128M。
@@ -898,13 +906,13 @@ max_packet_size = 32M
### mysql_version_string
-通过 MySQL 协议返回的服务器版本字符串。可选，默认为空（返回 Manticore 版本）。
+通过MySQL协议返回的服务器版本字符串。可选，默认为空（返回Manticore版本）。
-一些挑剔的 MySQL 客户端库依赖于 MySQL 使用的特定版本号格式，而且有时会根据报告的版本号（而非指示的功能标志）选择不同的执行路径。例如，Python MySQLdb 1.2.2 在版本号不是 X.Y.ZZ 格式时会抛出异常；MySQL .NET 连接器 6.3.x 在版本号为 1.x 且某些标志组合时内部失败等。为了解决这个问题，您可以使用 `mysql_version_string` 指令，让 `searchd` 向通过 MySQL 协议连接的客户端报告不同的版本。（默认情况下，它报告自己的版本。）
+Several picky MySQL client libraries depend on a particular version number format used by MySQL, and moreover, sometimes choose a different execution path based on the reported version number (rather than the indicated capabilities flags). For instance, Python MySQLdb 1.2.2 throws an exception when the version number is not in X.Y.ZZ format; MySQL .NET connector 6.3.x fails internally on version numbers 1.x along with a certain combination of flags, etc. To work around that, you can use the `mysql_version_string` directive and have `searchd` report a different version to clients connecting over the MySQL protocol. (By default, it reports its own version.)
-##### 示例：
+##### Example:
@@ -916,35 +924,35 @@ mysql_version_string = 5.0.37
### net_workers
-网络线程数，默认值为 1。
+网络线程数，默认值为1。
-当查询率极高且单线程无法管理所有传入查询时，此设置非常有用。
+当查询速率极高且单线程无法处理所有传入查询时，此设置非常有用。
### net_wait_tm
-控制网络线程的忙循环间隔。默认值为 -1，可设置为 -1、0 或正整数。
+控制网络线程的忙循环间隔。默认值为-1，可以设置为-1、0或正整数。
-在服务器配置为纯主服务器并仅将请求路由到代理的情况下，重要的是要无延迟地处理请求，不允许网络线程进入休眠状态。为此有一个忙循环。在收到请求后，如果 `net_wait_tm` 是正数，网络线程会使用 CPU 轮询 `10 * net_wait_tm` 毫秒；如果 `net_wait_tm` 是 `0`，则只用 CPU 轮询。 另外，可以通过设置 `net_wait_tm = -1` 来禁用忙循环——在这种情况下，轮询器会在系统轮询调用中将超时设置为实际代理的超时。
+在服务器配置为纯主节点且仅将请求路由到代理的情况下，重要的是无延迟地处理请求，不允许网络线程休眠。为此有一个忙循环。在收到请求后，如果`net_wait_tm`为正数，网络线程会使用CPU轮询`10 * net_wait_tm`毫秒；如果`net_wait_tm`为`0`，则仅使用CPU轮询。此外，可以通过设置`net_wait_tm = -1`禁用忙循环——在这种情况下，轮询器在系统轮询调用中将超时设置为实际代理的超时。
-> **警告：** CPU 忙循环实际上会占用 CPU 核心，因此将此值设置为任何非默认值都会导致即使服务器空闲时也会有明显的 CPU 使用率。
+> **警告：** CPU忙循环实际上会占用CPU核心，因此将此值设置为非默认值即使在服务器空闲时也会导致明显的CPU使用率。
### net_throttle_accept
-定义每次网络循环迭代中接受的客户端数量。默认值为 0（无限制），这对大多数用户来说是合适的。这是一个微调选项，用于在高负载场景下控制网络循环的吞吐量。
+定义每次网络循环迭代中接受的客户端数量。默认值为0（无限制），对大多数用户来说足够。此为微调选项，用于在高负载场景下控制网络循环的吞吐量。
### net_throttle_action
-定义每次网络循环迭代中处理的请求数量。默认值为 0（无限制），这对大多数用户来说是合适的。这是一个微调选项，用于在高负载场景下控制网络循环的吞吐量。
+定义每次网络循环迭代中处理的请求数量。默认值为0（无限制），对大多数用户来说足够。此为微调选项，用于在高负载场景下控制网络循环的吞吐量。
### network_timeout
-网络客户端请求读写超时，单位为秒（或 [special_suffixes](../Server_settings/Special_suffixes.md)）。可选，默认值为 5 秒。`searchd` 会强制关闭在此超时内未能发送查询或读取结果的客户端连接。
+网络客户端请求读写超时时间，单位为秒（或 [special_suffixes](../Server_settings/Special_suffixes.md)）。可选，默认值为5秒。`searchd`将在客户端未能在此超时内发送查询或读取结果时强制关闭连接。
-另请注意 [reset_network_timeout_on_packet](../Server_settings/Searchd.md#reset_network_timeout_on_packet) 参数。该参数将 `network_timeout` 的行为从应用于整个 `query` 或 `result` 改为应用于单个数据包。通常，一个查询/结果包含一到两个数据包。然而，在需要大量数据的情况下，该参数对于保持操作活跃非常有用。
+另请注意参数 [reset_network_timeout_on_packet](../Server_settings/Searchd.md#reset_network_timeout_on_packet)。该参数将`network_timeout`的行为从应用于整个`query`或`result`改为应用于单个数据包。通常，查询/结果适合一个或两个数据包。然而，在需要大量数据的情况下，该参数对于保持操作活跃非常有用。
@@ -956,16 +964,16 @@ network_timeout = 10s
### node_address
-此设置允许您指定节点的网络地址。默认情况下，它设置为复制的 [listen](../Server_settings/Searchd.md#listen) 地址。在大多数情况下这是正确的；但是，在某些情况下，您必须手动指定：
+此设置允许您指定节点的网络地址。默认情况下，它设置为复制的[listen](../Server_settings/Searchd.md#listen)地址。在大多数情况下这是正确的；但在以下情况下需要手动指定：
* 节点位于防火墙后面
* 启用了网络地址转换（NAT）
-* 容器部署，如 Docker 或云部署
+* 容器部署，如Docker或云部署
* 集群中节点分布在多个区域
-##### 示例：
+##### Example:
@@ -977,11 +985,11 @@ node_address = 10.101.0.10
### not_terms_only_allowed
-此设置决定是否允许仅包含 [否定](../Searching/Full_text_matching/Operators.md#Negation-operator) 全文操作符的查询。可选，默认值为 0（不允许仅含 NOT 操作符的查询）。
+此设置决定是否允许仅包含[否定](../Searching/Full_text_matching/Operators.md#Negation-operator)全文操作符的查询。可选，默认值为0（不允许仅含NOT操作符的查询）。
-##### 示例：
+##### Example:
@@ -993,10 +1001,10 @@ not_terms_only_allowed = 1
### optimize_cutoff
-设置默认的表压缩阈值。详细信息请参见 - [优化的磁盘块数量](../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks)。此设置可以被每个查询的选项 [cutoff](../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks) 覆盖。也可以通过 [SET GLOBAL](../Server_settings/Setting_variables_online.md#SET) 动态更改。
+设置默认的表压缩阈值。详情请参阅 - [优化的磁盘块数量](../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks)。此设置可被每查询选项[cutoff](../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks)覆盖。也可以通过[SET GLOBAL](../Server_settings/Setting_variables_online.md#SET)动态更改。
-##### 示例：
+##### Example:
@@ -1008,12 +1016,12 @@ optimize_cutoff = 4
### persistent_connections_limit
-此设置决定与远程 [持久代理](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md) 的最大同时持久连接数。每次连接到 `agent_persistent` 下定义的代理时，我们会尝试重用现有连接（如果有），或者连接并保存该连接以供将来使用。然而，在某些情况下，限制此类持久连接的数量是合理的。此指令定义了该限制。它影响所有分布式表中与每个代理主机的连接数。
+此设置决定到远程[persistent agents](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)的最大同时持久连接数。每次连接定义在`agent_persistent`下的代理时，都会尝试重用现有连接（如果有），或连接并保存该连接以供将来使用。然而，在某些情况下，限制此类持久连接数是合理的。此指令定义了该限制。它影响所有分布式表中到每个代理主机的连接数。
-合理的做法是将该值设置为代理配置中 [max_connections](../Server_settings/Searchd.md#max_connections) 选项的值或更小。
+合理的做法是将该值设置为不大于代理配置中的[max_connections](../Server_settings/Searchd.md#max_connections)选项。
-##### 示例：
+##### Example:
@@ -1026,10 +1034,10 @@ persistent_connections_limit = 29 # assume that each host of agents has max_conn
### pid_file
-pid_file 是 Manticore 搜索中的一个必需配置选项，指定存储 `searchd` 服务器进程 ID 的文件路径。
+pid_file是Manticore搜索中的一个必需配置选项，指定存储`searchd`服务器进程ID的文件路径。
-searchd 进程 ID 文件在启动时被重新创建并锁定，服务器运行时包含主服务器进程 ID。服务器关闭时该文件被删除。
-该文件的目的是使 Manticore 能执行各种内部任务，例如检查是否已有运行的 `searchd` 实例、停止 `searchd` 以及通知其应轮换表。该文件也可用于外部自动化脚本。
+searchd进程ID文件在启动时被重新创建并锁定，服务器运行时包含主服务器进程ID。服务器关闭时该文件被删除。
+该文件的目的是使 Manticore 能够执行各种内部任务，例如检查是否已有正在运行的 `searchd` 实例，停止 `searchd`，并通知其应旋转表。该文件也可用于外部自动化脚本。
@@ -1059,7 +1067,7 @@ predicted_time_costs = doc=128, hit=96, skip=4096, match=128
-基于执行时间（使用最大查询时间设置）在查询完成前终止查询是一个不错的安全网，但它有一个固有缺点：结果不确定（不稳定）。也就是说，如果多次重复相同的（复杂）搜索查询并设置时间限制，时间限制会在不同阶段被触发，您将得到*不同*的结果集。
+基于执行时间（使用最大查询时间设置）在查询完成前终止查询是一个很好的安全网，但它有一个固有缺点：结果不确定（不稳定）。也就是说，如果你多次重复执行完全相同的（复杂）搜索查询并设置时间限制，时间限制将在不同阶段被触发，你将得到*不同*的结果集。
##### SQL:
@@ -1076,7 +1084,7 @@ SetMaxQueryTime()
```
-有一个选项，[SELECT … OPTION max_predicted_time](../Searching/Options.md#max_predicted_time)，它允许你限制查询时间*并且*获得稳定、可重复的结果。它不是在评估查询时定期检查实际当前时间（这是不确定的），而是使用一个简单的线性模型来预测当前运行时间：
+有一个选项，[SELECT … OPTION max_predicted_time](../Searching/Options.md#max_predicted_time)，它允许你限制查询时间*并*获得稳定、可重复的结果。它不是在评估查询时定期检查实际当前时间（这具有不确定性），而是使用一个简单的线性模型来预测当前运行时间：
```ini
predicted_time =
@@ -1086,21 +1094,21 @@ predicted_time =
match_cost * found_matches
```
-当`predicted_time`达到给定限制时，查询会被提前终止。
+当 `predicted_time` 达到给定限制时，查询将被提前终止。
-当然，这并不是对实际花费时间的硬限制（但确实是对*处理*工作量的硬限制），而且简单的线性模型绝非理想的精确模型。因此，实际的墙钟时间*可能*低于或超过目标限制。不过误差范围是相当可接受的：例如，在我们以100毫秒为目标限制的实验中，大多数测试查询落在95到105毫秒范围内，*所有*查询都在80到120毫秒范围内。此外，作为一个不错的副作用，使用模型预测的查询时间而非测量实际运行时间，也减少了gettimeofday()调用的次数。
+当然，这并不是对实际花费时间的硬限制（但确实是对*处理*工作量的硬限制），而且简单的线性模型绝非理想精确模型。因此，实际的墙钟时间*可能*低于或超过目标限制。然而，误差范围相当可接受：例如，在我们以 100 毫秒为目标限制的实验中，大多数测试查询落在 95 到 105 毫秒范围内，*所有*查询都在 80 到 120 毫秒范围内。此外，作为一个不错的副作用，使用模型化的查询时间而非测量实际运行时间也减少了 gettimeofday() 调用次数。
-没有两台服务器的品牌和型号是完全相同的，因此`predicted_time_costs`指令允许你配置上述模型的成本。为了方便，它们是以纳秒为单位的整数。（max_predicted_time中的限制以毫秒计，必须以0.000128毫秒而非128纳秒来指定成本值会更容易出错。）不必一次指定所有四个成本，缺失的将采用默认值。不过，我们强烈建议全部指定以提高可读性。
+没有两台服务器的制造商和型号是完全相同的，因此 `predicted_time_costs` 指令允许你配置上述模型的成本。为了方便，它们是整数，单位为纳秒。（max_predicted_time 中的限制以毫秒计，若要以 0.000128 毫秒而非 128 纳秒指定成本值，容易出错。）不必一次指定所有四个成本，缺失的将采用默认值。但我们强烈建议为可读性指定全部。
### preopen_tables
-preopen_tables配置指令指定是否在启动时强制预打开所有表。默认值为1，表示无论每个表的[preopen](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Other-performance-related-settings)设置如何，都会预打开所有表。如果设置为0，则每个表的设置生效，且默认值为0。
+preopen_tables 配置指令指定是否在启动时强制预打开所有表。默认值为 1，表示无论每个表的 [preopen](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Other-performance-related-settings) 设置如何，都会预打开所有表。若设置为 0，则每个表的设置生效，且默认值为 0。
-预打开表可以防止搜索查询和轮换之间的竞争条件，避免查询偶尔失败。但它也会使用更多的文件句柄。在大多数场景下，建议预打开表。
+预打开表可以防止搜索查询与旋转之间的竞争，避免查询偶尔失败。但它也会使用更多文件句柄。在大多数场景下，建议预打开表。
-下面是一个示例配置：
+示例配置如下：
##### 示例：
@@ -1115,7 +1123,7 @@ preopen_tables = 1
### pseudo_sharding
-pseudo_sharding配置选项启用对本地普通表和实时表的搜索查询并行化，无论是直接查询还是通过分布式表查询。此功能会自动将查询并行化到`searchd.threads`指定的线程数。
+pseudo_sharding 配置选项启用对本地普通表和实时表的搜索查询并行化，无论是直接查询还是通过分布式表查询。此功能将自动并行化查询，最多达到 `searchd.threads` 指定的线程数。
请注意，如果你的工作线程已经很忙，因为你有：
* 高查询并发
@@ -1123,7 +1131,7 @@ pseudo_sharding配置选项启用对本地普通表和实时表的搜索查询
- 多个普通/实时表的分布式表
- 由过多磁盘块组成的实时表
-那么启用pseudo_sharding可能不会带来任何好处，甚至可能导致吞吐量略有下降。如果你优先考虑更高吞吐量而非更低延迟，建议禁用此选项。
+那么启用 pseudo_sharding 可能不会带来任何好处，甚至可能导致吞吐量略有下降。如果你优先考虑更高吞吐量而非更低延迟，建议禁用此选项。
默认启用。
@@ -1140,31 +1148,31 @@ pseudo_sharding = 0
### replication_connect_timeout
-`replication_connect_timeout`指令定义连接远程节点的超时时间。默认值假定为毫秒，但可以使用[其他后缀](../Server_settings/Special_suffixes.md)。默认值为1000（1秒）。
+`replication_connect_timeout` 指令定义连接远程节点的超时时间。默认值单位为毫秒，但可以使用[其他后缀](../Server_settings/Special_suffixes.md)。默认值为 1000（1 秒）。
-连接远程节点时，Manticore最多等待此时间以成功完成连接。如果超时但连接未建立，且启用了`retries`，则会发起重试。
+连接远程节点时，Manticore 最多等待此时间以成功完成连接。如果超时但连接未建立，且启用了 `retries`，则会发起重试。
### replication_query_timeout
-`replication_query_timeout`设置searchd等待远程节点完成查询的时间。默认值为3000毫秒（3秒），但可以使用后缀表示不同时间单位。
+`replication_query_timeout` 设置 searchd 等待远程节点完成查询的时间。默认值为 3000 毫秒（3 秒），但可以使用后缀表示不同时间单位。
-建立连接后，Manticore将最多等待`replication_query_timeout`时间以完成远程节点的查询。注意此超时与`replication_connect_timeout`分开，远程节点可能导致的总延迟是两者之和。
+建立连接后，Manticore 将最多等待 `replication_query_timeout` 时间以完成远程节点的查询。请注意，此超时与 `replication_connect_timeout` 分开，远程节点可能导致的总延迟为两者之和。
### replication_retry_count
-此设置为整数，指定Manticore在复制期间尝试连接和查询远程节点的次数，超过后报告致命查询错误。默认值为3。
+此设置为整数，指定 Manticore 在复制期间尝试连接和查询远程节点的次数，超过后报告致命查询错误。默认值为 3。
### replication_retry_delay
-此设置为以毫秒为单位的整数（或[特殊后缀](../Server_settings/Special_suffixes.md)），指定复制期间查询远程节点失败后重试前的延迟时间。仅当指定非零值时生效。默认值为500。
+此设置为以毫秒为单位的整数（或[special_suffixes](../Server_settings/Special_suffixes.md)），指定在复制过程中发生故障时，Manticore 重试查询远程节点的延迟时间。仅当指定非零值时，此值才有意义。默认值为500。
### qcache_max_bytes
-此配置设置用于缓存结果集的最大RAM字节数。默认值为16777216，相当于16兆字节。如果设置为0，则禁用查询缓存。有关查询缓存的更多信息，请参阅[查询缓存](../Searching/Query_cache.md)。
+此配置设置用于缓存结果集的最大RAM量，单位为字节。默认值为16777216，相当于16兆字节。如果值设置为0，则禁用查询缓存。有关查询缓存的更多信息，请参阅[查询缓存](../Searching/Query_cache.md)。
@@ -1180,12 +1188,12 @@ qcache_max_bytes = 16777216
### qcache_thresh_msec
-整数，单位为毫秒。查询结果被缓存的最小墙钟时间阈值。默认值为3000，即3秒。0表示缓存所有。详情请参阅[查询缓存](../Searching/Query_cache.md)。此值也可以用时间[特殊后缀](../Server_settings/Special_suffixes.md)表示，但请谨慎使用，避免与值名中包含的'_msec'混淆。
+整数，单位为毫秒。查询结果被缓存的最小墙时间阈值。默认值为3000，即3秒。0表示缓存所有内容。详情请参阅[查询缓存](../Searching/Query_cache.md)。此值也可以用时间[special_suffixes](../Server_settings/Special_suffixes.md)表示，但请谨慎使用，不要与值名中包含的'_msec'混淆。
### qcache_ttl_sec
-整数，单位为秒。缓存结果集的过期时间。默认值为60秒，即1分钟。最小可能值为1秒。详情请参阅[查询缓存](../Searching/Query_cache.md)。该值也可以用时间[特殊后缀](../Server_settings/Special_suffixes.md)表示，但请谨慎使用，不要与值本身包含的“_sec”混淆。
+整数，单位为秒。缓存结果集的过期时间。默认值为60，即1分钟。最小可能值为1秒。详情请参阅[查询缓存](../Searching/Query_cache.md)。此值也可以用时间[special_suffixes](../Server_settings/Special_suffixes.md)表示，但请谨慎使用，不要与值名中包含的'_sec'混淆。
### query_log_format
@@ -1193,7 +1201,7 @@ qcache_max_bytes = 16777216
查询日志格式。可选，允许的值为`plain`和`sphinxql`，默认是`sphinxql`。
-`sphinxql`模式记录有效的SQL语句。`plain`模式以纯文本格式记录查询（主要适用于纯全文搜索场景）。此指令允许您在搜索服务器启动时切换这两种格式。日志格式也可以动态更改，使用`SET GLOBAL query_log_format=sphinxql`语法。详情请参阅[查询日志](../Logging/Query_logging.md)。
+`sphinxql`模式记录有效的SQL语句。`plain`模式以纯文本格式记录查询（主要适用于纯全文本用例）。此指令允许您在搜索服务器启动时切换两种格式。日志格式也可以动态更改，使用`SET GLOBAL query_log_format=sphinxql`语法。详情请参阅[查询日志](../Logging/Query_logging.md)。
@@ -1208,12 +1216,12 @@ query_log_format = sphinxql
### query_log_min_msec
-限制（以毫秒为单位），防止查询被写入查询日志。可选，默认值为0（所有查询都会写入查询日志）。此指令指定只有执行时间超过指定限制的查询才会被记录（该值也可以用时间[特殊后缀](../Server_settings/Special_suffixes.md)表示，但请谨慎使用，不要与值本身包含的“_msec”混淆）。
+限制（以毫秒为单位），防止查询被写入查询日志。可选，默认值为0（所有查询都写入查询日志）。此指令指定只有执行时间超过指定限制的查询才会被记录（此值也可以用时间[special_suffixes](../Server_settings/Special_suffixes.md)表示，但请谨慎使用，不要与值名中包含的`_msec`混淆）。
### query_log
-查询日志文件名。可选，默认为空（不记录查询）。所有搜索查询（如SELECT ...，但不包括INSERT/REPLACE/UPDATE查询）都会记录在此文件中。格式详见[查询日志](../Logging/Query_logging.md)。在“plain”格式下，可以使用“syslog”作为日志文件路径。在这种情况下，所有搜索查询将以`LOG_INFO`优先级发送到syslog守护进程，前缀为“[query]”而非时间戳。要使用syslog选项，Manticore必须在构建时配置`-–with-syslog`。
+查询日志文件名。可选，默认为空（不记录查询）。所有搜索查询（如SELECT ...，但不包括INSERT/REPLACE/UPDATE查询）将记录在此文件中。格式详见[查询日志](../Logging/Query_logging.md)。在'plain'格式下，可以使用'syslog'作为日志文件路径。在这种情况下，所有搜索查询将以`LOG_INFO`优先级发送到syslog守护进程，前缀为'[query]'，而非时间戳。要使用syslog选项，Manticore必须在构建时配置`-–with-syslog`。
@@ -1230,8 +1238,8 @@ query_log = /var/log/query.log
### query_log_mode
-query_log_mode指令允许您为searchd和查询日志文件设置不同的权限。默认情况下，这些日志文件的权限为600，意味着只有运行服务器的用户和root用户可以读取日志文件。
-如果您想允许其他用户读取日志文件，例如运行在非root用户下的监控解决方案，此指令非常有用。
+query_log_mode指令允许您为searchd和查询日志文件设置不同的权限。默认情况下，这些日志文件以600权限创建，意味着只有运行服务器的用户和root用户可以读取日志文件。
+如果您想允许其他用户读取日志文件，例如运行在非root用户上的监控解决方案，此指令非常有用。
##### 示例：
@@ -1248,7 +1256,7 @@ query_log_mode = 666
read_buffer_docs指令控制文档列表的每个关键字读取缓冲区大小。对于每个搜索查询中的每个关键字出现，有两个相关的读取缓冲区：一个用于文档列表，一个用于命中列表。此设置允许您控制文档列表缓冲区大小。
-较大的缓冲区大小可能会增加每个查询的RAM使用，但可能减少I/O时间。对于慢速存储，设置较大值是合理的，但对于能够提供高IOPS的存储，应在较低值区域进行实验。
+较大的缓冲区大小可能增加每个查询的RAM使用，但可能减少I/O时间。对于慢速存储，设置较大值是合理的，但对于能够高IOPS的存储，应在较低值区域进行实验。
默认值为256K，最小值为8K。您也可以在每个表级别设置[read_buffer_docs](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#read_buffer_docs)，这将覆盖服务器配置级别的设置。
@@ -1267,9 +1275,9 @@ read_buffer_docs = 128K
### read_buffer_hits
-read_buffer_hits指令指定搜索查询中命中列表的每个关键字读取缓冲区大小。默认大小为256K，最小值为8K。对于搜索查询中的每个关键字出现，有两个相关的读取缓冲区，一个用于文档列表，一个用于命中列表。增加缓冲区大小可以增加每个查询的RAM使用，但减少I/O时间。对于慢速存储，较大的缓冲区大小是合理的，而对于能够提供高IOPS的存储，应在较低值区域进行实验。
+read_buffer_hits指令指定搜索查询中命中列表的每个关键字读取缓冲区大小。默认大小为256K，最小值为8K。对于搜索查询中的每个关键字出现，有两个相关的读取缓冲区，一个用于文档列表，一个用于命中列表。增加缓冲区大小可以增加每个查询的RAM使用，但减少I/O时间。对于慢速存储，较大的缓冲区大小是合理的，而对于能够高IOPS的存储，应在较低值区域进行实验。
-此设置也可以通过在每个表级别使用read_buffer_hits选项在[read_buffer_hits](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#read_buffer_hits)中指定，这将覆盖服务器级别的设置。
+此设置也可以通过[read_buffer_hits](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#read_buffer_hits)在每个表级别指定，这将覆盖服务器级别的设置。
##### 示例：
@@ -1284,9 +1292,9 @@ read_buffer_hits = 128K
### read_unhinted
-未提示读取大小。可选，默认值为32K，最小值为1K。
+无提示读取大小。可选，默认值为32K，最小为1K
-在查询时，有些读取操作事先知道确切的数据量，但有些则不知道。最明显的是，命中列表大小目前无法预先知道。此设置允许您控制在这种情况下读取的数据量。它影响命中列表的I/O时间，对于大于未提示读取大小的列表减少I/O时间，但对于较小的列表则增加I/O时间。它**不**影响RAM使用，因为读取缓冲区已经分配。因此，它不应大于read_buffer。
+当查询时，有些读取操作事先就知道要读取的数据量，但有些目前还不知道。最显著的是，命中列表的大小目前是未知的。此设置允许您控制在这种情况下读取多少数据。它影响命中列表的I/O时间，对于大于未提示读取大小的列表，能减少I/O时间，但对于较小的列表则会增加I/O时间。它**不会**影响内存使用，因为读取缓冲区已经被分配。因此，它不应大于read_buffer。
@@ -1302,14 +1310,14 @@ read_unhinted = 32K
### reset_network_timeout_on_packet
-细化网络超时（如`network_timeout`和`agent_query_timeout`）的行为。
+细化网络超时行为（例如`network_timeout`和`agent_query_timeout`）。
设置为0时，超时限制发送整个请求/查询的最大时间。
设置为1（默认）时，超时限制网络活动之间的最大时间。
-通过复制，节点可能需要将一个大文件（例如，100GB）发送到另一个节点。假设网络传输速率为1GB/s，数据包大小为4-5MB。传输整个文件需要100秒。默认的5秒超时只允许传输5GB数据，之后连接会被断开。增加超时可以作为一种解决方法，但这不可扩展（例如，下一个文件可能是150GB，仍会导致失败）。然而，默认情况下 `reset_network_timeout_on_packet` 设置为1，超时应用于单个数据包而非整个传输。只要传输正在进行中（且在超时期间网络上实际接收到了数据），连接就会保持活跃。如果传输卡住，导致数据包之间发生超时，则连接会被断开。
+在复制时，节点可能需要向另一个节点发送一个大文件（例如100GB）。假设网络传输速率为1GB/s，数据包大小为4-5MB。传输整个文件需要100秒。默认的5秒超时只允许传输5GB数据，之后连接会被断开。增加超时可以作为一种解决方法，但不可扩展（例如，下一个文件可能是150GB，仍会失败）。然而，默认`reset_network_timeout_on_packet`设置为1时，超时应用于单个数据包，而非整个传输。只要传输在进行中（且在超时期间网络上实际接收数据），连接就保持活跃。如果传输卡住，导致数据包间发生超时，则连接会被断开。
-请注意，如果设置了分布式表，主节点和代理节点都应进行调优。主节点影响的是 `agent_query_timeout`；代理节点则相关于 `network_timeout`。
+注意，如果设置了分布式表，主节点和代理节点都应进行调优。主节点影响`agent_query_timeout`，代理节点影响`network_timeout`。
@@ -1329,7 +1337,7 @@ reset_network_timeout_on_packet = 0
RT表RAM块刷新检查周期，单位为秒（或[special_suffixes](../Server_settings/Special_suffixes.md)）。可选，默认值为10小时。
-完全适合RAM块的主动更新RT表仍可能导致binlog不断增长，影响磁盘使用和崩溃恢复时间。通过此指令，搜索服务器执行周期性刷新检查，符合条件的RAM块可以被保存，从而实现后续binlog清理。详情见[二进制日志](../Logging/Binary_logging.md)。
+完全适合RAM块的主动更新RT表仍可能导致不断增长的二进制日志，影响磁盘使用和崩溃恢复时间。通过此指令，搜索服务器执行周期性刷新检查，符合条件的RAM块可以被保存，从而实现后续的二进制日志清理。详情见[二进制日志](../Logging/Binary_logging.md)。
##### 示例：
@@ -1347,7 +1355,7 @@ rt_flush_period = 3600 # 1 hour
RT块合并线程允许启动的最大I/O操作数（每秒）。可选，默认值为0（无限制）。
-此指令允许限制由 `OPTIMIZE` 语句引起的I/O影响。保证所有RT优化活动产生的磁盘IOPS（每秒I/O次数）不会超过配置的限制。限制rt_merge_iops可以减少合并导致的搜索性能下降。
+此指令允许您限制由`OPTIMIZE`语句引起的I/O影响。保证所有RT优化活动产生的磁盘IOPS（每秒I/O次数）不会超过配置的限制。限制rt_merge_iops可以减少合并导致的搜索性能下降。
##### 示例：
@@ -1364,7 +1372,7 @@ rt_merge_iops = 40
RT块合并线程允许启动的最大I/O操作大小。可选，默认值为0（无限制）。
-此指令允许限制由 `OPTIMIZE` 语句引起的I/O影响。超过此限制的I/O操作将被拆分成两个或更多I/O操作，这些操作将作为独立I/O计入[rt_merge_iops](../Server_settings/Searchd.md#rt_merge_iops)限制。因此，保证所有优化活动每秒产生的磁盘I/O不超过 (rt_merge_iops * rt_merge_maxiosize) 字节。
+此指令允许您限制由`OPTIMIZE`语句引起的I/O影响。超过此限制的I/O将被拆分成两个或更多I/O操作，这些操作将作为独立I/O计入[rt_merge_iops](../Server_settings/Searchd.md#rt_merge_iops)限制。因此，保证所有优化活动每秒产生的磁盘I/O不超过(rt_merge_iops * rt_merge_maxiosize)字节。
@@ -1381,28 +1389,28 @@ rt_merge_maxiosize = 1M
### seamless_rotate
-防止在旋转包含大量数据以进行预缓存的表时，`searchd` 停顿。可选，默认值为1（启用无缝旋转）。在Windows系统上，默认禁用无缝旋转。
+防止在旋转包含大量数据以进行预缓存的表时，`searchd`发生停顿。可选，默认值为1（启用无缝旋转）。在Windows系统上，默认禁用无缝旋转。
-表可能包含需要预缓存到RAM中的数据。目前，`.spa`、`.spb`、`.spi` 和 `.spm` 文件会被完全预缓存（它们分别包含属性数据、blob属性数据、关键字表和已删除行映射）。无无缝旋转时，旋转表尽量少用RAM，流程如下：
+表可能包含需要预缓存到RAM中的数据。目前，`.spa`、`.spb`、`.spi`和`.spm`文件会被完全预缓存（它们分别包含属性数据、blob属性数据、关键字表和已删除行映射）。没有无缝旋转时，旋转表尽量少用RAM，过程如下：
1. 临时拒绝新查询（返回“重试”错误码）；
-2. `searchd` 等待所有正在运行的查询完成；
+2. `searchd`等待所有当前运行的查询完成；
3. 旧表被释放，其文件被重命名；
4. 新表文件被重命名，分配所需RAM；
-5. 新表属性和字典数据预加载到RAM；
-6. `searchd` 恢复从新表服务查询。
+5. 新表的属性和字典数据预加载到RAM；
+6. `searchd`恢复从新表服务查询。
-但如果属性或字典数据量大，预加载步骤可能耗时显著——预加载1-5GB以上文件时可能需要几分钟。
+然而，如果属性或字典数据量大，预加载步骤可能耗时显著——预加载1-5GB以上文件时可能需要几分钟。
-启用无缝旋转后，旋转流程如下：
+启用无缝旋转时，旋转过程如下：
-1. 分配新表RAM存储；
-2. 异步预加载新表属性和字典数据到RAM；
+1. 分配新表的RAM存储；
+2. 异步预加载新表的属性和字典数据到RAM；
3. 成功时，释放旧表，重命名两个表的文件；
4. 失败时，释放新表；
5. 任何时刻，查询要么从旧表，要么从新表副本服务。
-无缝旋转代价是旋转期间峰值内存使用增加（因为预加载新副本时，旧副本和新副本的 `.spa/.spb/.spi/.spm` 数据都需在RAM中）。平均使用量保持不变。
+无缝旋转的代价是旋转期间峰值内存使用更高（因为预加载新副本时，旧副本和新副本的`.spa/.spb/.spi/.spm`数据都需在RAM中）。平均使用量保持不变。
@@ -1418,320 +1426,320 @@ seamless_rotate = 1
### secondary_index_block_cache
-此选项指定二级索引使用的块缓存大小。可选，默认8MB。当二级索引处理包含大量值的过滤器（例如IN()过滤器）时，会读取并处理这些值的元数据块。
-在连接查询中，这一过程会对左表的每个批次重复执行，每个批次可能在单个连接查询内重复读取相同元数据。这会严重影响性能。元数据块缓存将这些块保存在内存中，以便后续批次重用。
-缓存仅在连接查询中使用，对非连接查询无影响。注意，缓存大小限制是针对每个属性和每个二级索引的。每个磁盘块中的每个属性都在此限制内运行。最坏情况下，总内存使用量可估算为限制乘以磁盘块数和连接查询中使用的属性数。
+此选项指定二级索引使用的块缓存大小。此项为可选，默认值为8 MB。当二级索引处理包含多个值的过滤器（例如，IN()过滤器）时，它们会读取并处理这些值的元数据块。
+在联接查询中，此过程会针对左表的每个行批次重复执行，并且每个批次可能在单个联接查询中重新读取相同的元数据。这会严重影响性能。元数据块缓存将这些块保存在内存中，以便
+后续批次可以重用。
-设置 `secondary_index_block_cache = 0` 可禁用缓存。
-##### 示例：
+该缓存仅在联接查询中使用，对非联接查询无影响。请注意，缓存大小限制是针对每个属性和每个二级索引的。每个磁盘块中的每个属性都在此限制内运行。在最坏情况下，总内存
+使用量可通过将限制乘以磁盘块数量和联接查询中使用的属性数量来估算。
-secondary_index_block_cache = 16M
+设置 `secondary_index_block_cache = 0` 可禁用缓存。
-### secondary_indexes
+##### 示例：
```ini
-This option enables/disables the use of secondary indexes for search queries. It is optional, and the default is 1 (enabled). Note that you don't need to enable it for indexing as it is always enabled as long as the [Manticore Columnar Library](https://github.com/manticoresoftware/columnar) is installed. The latter is also required for using the indexes when searching. There are three modes available:
+secondary_index_block_cache = 16M
```
-* `0`: Disable the use of secondary indexes on search. They can be enabled for individual queries using [analyzer hints](../Searching/Options.md#Query-optimizer-hints)
+### secondary_indexes
-* `1`: Enable the use of secondary indexes on search. They can be disabled for individual queries using [analyzer hints](../Searching/Options.md#Query-optimizer-hints)
+此选项启用/禁用搜索查询中二级索引的使用。此项为可选，默认值为1（启用）。请注意，索引不需要启用此选项，因为只要安装了 [Manticore Columnar Library](https://github.com/manticoresoftware/columnar)，它始终处于启用状态。后者也是搜索时使用索引的前提。共有三种模式可用：
-* `force`: Same as enable, but any errors during the loading of secondary indexes will be reported, and the whole index will not be loaded into the daemon.
-##### Example:
-secondary_indexes = 1
+* `0`：禁用搜索时使用二级索引。可以通过[分析器提示](../Searching/Options.md#Query-optimizer-hints)为单个查询启用。
+* `1`：启用搜索时使用二级索引。可以通过[分析器提示](../Searching/Options.md#Query-optimizer-hints)为单个查询禁用。
+* `force`：与启用相同，但在加载二级索引时出现任何错误都会被报告，且整个索引不会加载到守护进程中。
-### server_id
+##### 示例：
```ini
-Integer number that serves as a server identifier used as a seed to generate a unique short UUID for nodes that are part of a replication cluster. The server_id must be unique across the nodes of a cluster and in the range from 0 to 127. If server_id is not set, it is calculated as a hash of the MAC address and the path to the PID file or a random number will be used as a seed for the short UUID.
+secondary_indexes = 1
```
-##### Example:
+### server_id
-server_id = 1
+整数编号，作为服务器标识符，用作生成复制集群中节点唯一短UUID的种子。server_id必须在集群节点中唯一，且范围为0到127。如果未设置server_id，则会根据MAC地址和PID文件路径的哈希计算，或者使用随机数作为短UUID的种子。
-### shutdown_timeout
+##### 示例：
```ini
-`searchd --stopwait` waiting time, in seconds (or [special_suffixes](../Server_settings/Special_suffixes.md)). Optional, default is 60 seconds.
+server_id = 1
```
-When you run `searchd --stopwait` your server needs to perform some activities before stopping, such as finishing queries, flushing RT RAM chunks, flushing attributes, and updating the binlog. These tasks require some time. `searchd --stopwait` will wait up to `shutdown_time` seconds for the server to finish its jobs. The suitable time depends on your table size and load.
+### shutdown_timeout
-##### Example:
+`searchd --stopwait` 的等待时间，单位为秒（或[特殊后缀](../Server_settings/Special_suffixes.md)）。可选，默认值为60秒。
-shutdown_timeout = 3m # wait for up to 3 minutes
+当您运行 `searchd --stopwait` 时，服务器需要在停止前执行一些操作，例如完成查询、刷新RT RAM块、刷新属性和更新binlog。这些任务需要一定时间。`searchd --stopwait` 会等待最多 `shutdown_time` 秒，以便服务器完成其任务。合适的时间取决于您的表大小和负载。
-### shutdown_token
+##### 示例：
```ini
-SHA1 hash of the password required to invoke the 'shutdown' command from a VIP Manticore SQL connection. Without it,[debug](../Reporting_bugs.md#DEBUG) 'shutdown' subcommand will never cause the server to stop. Note that such simple hashing should not be considered strong protection, as we don't use a salted hash or any kind of modern hash function. It is intended as a fool-proof measure for housekeeping daemons in a local network.
+shutdown_timeout = 3m # wait for up to 3 minutes
```
-### snippets_file_prefix
+### shutdown_token
-A prefix to prepend to the local file names when generating snippets. Optional, default is the current working folder.
+调用VIP Manticore SQL连接的 'shutdown' 命令所需的密码的SHA1哈希值。没有它，[debug](../Reporting_bugs.md#DEBUG) 的 'shutdown' 子命令永远不会导致服务器停止。请注意，这种简单的哈希不应被视为强保护，因为我们没有使用加盐哈希或任何现代哈希函数。它旨在作为本地网络中维护守护进程的防呆措施。
-This prefix can be used in distributed snippets generation along with `load_files` or `load_files_scattered` options.
+### snippets_file_prefix
-Note that this is a prefix and **not** a path! This means that if a prefix is set to "server1" and the request refers to "file23", `searchd` will attempt to open "server1file23" (all of that without quotes). So, if you need it to be a path, you have to include the trailing slash.
+生成片段时要添加到本地文件名之前的前缀。可选，默认是当前工作文件夹。
-After constructing the final file path, the server unwinds all relative dirs and compares the final result with the value of `snippet_file_prefix`. If the result does not begin with the prefix, such a file will be rejected with an error message.
+此前缀可与 `load_files` 或 `load_files_scattered` 选项一起用于分布式片段生成。
-For example, if you set it to `/mnt/data` and someone calls snippet generation with the file `../../../etc/passwd` as the source, they will get the error message:
+请注意，这只是一个前缀，**不是**路径！这意味着如果前缀设置为 "server1"，请求引用 "file23"，`searchd` 会尝试打开 "server1file23"（不带引号）。因此，如果您需要它作为路径，必须包含尾部斜杠。
-`File '/mnt/data/../../../etc/passwd' escapes '/mnt/data/' scope`
+构造最终文件路径后，服务器会展开所有相对目录，并将最终结果与 `snippet_file_prefix` 的值进行比较。如果结果不以该前缀开头，则该文件将被拒绝并显示错误消息。
-instead of the content of the file.
+例如，如果设置为 `/mnt/data`，有人调用片段生成时以文件 `../../../etc/passwd` 作为源，则会收到错误消息：
-Also, with a non-set parameter and reading `/etc/passwd`, it will actually read /daemon/working/folder/etc/passwd since the default for the parameter is the server's working folder.
+`File '/mnt/data/../../../etc/passwd' escapes '/mnt/data/' scope`
-Note also that this is a local option; it does not affect the agents in any way. So you can safely set a prefix on a master server. The requests routed to the agents will not be affected by the master's setting. They will, however, be affected by the agent's own settings.
+而不是文件内容。
-This might be useful, for instance, when the document storage locations (whether local storage or NAS mountpoints) are inconsistent across the servers.
+此外，如果参数未设置且读取 `/etc/passwd`，实际上会读取 /daemon/working/folder/etc/passwd，因为该参数的默认值是服务器的工作文件夹。
-##### Example:
+还请注意，这是本地选项；不会以任何方式影响代理。因此，您可以安全地在主服务器上设置前缀。路由到代理的请求不会受主服务器设置的影响，但会受代理自身设置的影响。
-snippets_file_prefix = /mnt/common/server1/
+这在文档存储位置（无论是本地存储还是NAS挂载点）在服务器间不一致时可能非常有用。
-> **WARNING:** If you still want to access files from the FS root, you have to explicitly set `snippets_file_prefix` to empty value (by `snippets_file_prefix=` line), or to root (by `snippets_file_prefix=/`).
+##### 示例：
```ini
-### sphinxql_state
+snippets_file_prefix = /mnt/common/server1/
```
-Path to a file where the current SQL state will be serialized.
+> **警告：** 如果您仍想访问文件系统根目录的文件，必须显式将 `snippets_file_prefix` 设置为空值（通过 `snippets_file_prefix=` 行），或设置为根目录（通过 `snippets_file_prefix=/`）。
-On server startup, this file gets replayed. On eligible state changes (e.g., SET GLOBAL), this file gets rewritten automatically. This can prevent a hard-to-diagnose problem: If you load UDF functions but Manticore crashes, when it gets (automatically) restarted, your UDF and global variables will no longer be available. Using persistent state helps ensure a graceful recovery with no such surprises.
+### sphinxql_state
-`sphinxql_state` cannot be used to execute arbitrary commands, such as `CREATE TABLE`.
+当前SQL状态序列化的文件路径。
-##### Example:
+服务器启动时，会重放此文件。在符合条件的状态更改（例如，SET GLOBAL）时，此文件会自动重写。这可以防止一个难以诊断的问题：如果您加载了UDF函数但Manticore崩溃，当它（自动）重启时，您的UDF和全局变量将不再可用。使用持久状态有助于确保优雅恢复，避免此类意外。
-sphinxql_state = uservars.sql
+`sphinxql_state` 不能用于执行任意命令，例如 `CREATE TABLE`。
-### sphinxql_timeout
+##### 示例：
```ini
-Maximum time to wait between requests (in seconds, or [special_suffixes](../Server_settings/Special_suffixes.md)) when using the SQL interface. Optional, default is 15 minutes.
+sphinxql_state = uservars.sql
```
-##### Example:
+### sphinxql_timeout
-sphinxql_timeout = 15m
+使用SQL接口时，请求之间的最大等待时间（以秒为单位，或使用 [special_suffixes](../Server_settings/Special_suffixes.md)）。可选，默认值为15分钟。
-### ssl_ca
+##### 示例：
```ini
-Path to the SSL Certificate Authority (CA) certificate file (also known as root certificate). Optional, default is empty. When not empty, the certificate in `ssl_cert` should be signed by this root certificate.
+sphinxql_timeout = 15m
```
-服务器使用 CA 文件来验证证书上的签名。该文件必须是 PEM 格式。
+### ssl_ca
-##### 示例：
+SSL证书颁发机构（CA）证书文件的路径（也称为根证书）。可选，默认值为空。当不为空时，`ssl_cert` 中的证书应由此根证书签名。
-ssl_ca = keys/ca-cert.pem
+服务器使用CA文件来验证证书上的签名。该文件必须是PEM格式。
-### ssl_cert
+##### 示例：
```ini
-服务器 SSL 证书的路径。可选，默认值为空。
+ssl_ca = keys/ca-cert.pem
```
-服务器使用此证书作为自签名公钥，通过 SSL 加密 HTTP 流量。该文件必须是 PEM 格式。
+### ssl_cert
-##### 示例：
+服务器SSL证书的路径。可选，默认值为空。
-ssl_cert = keys/server-cert.pem
+服务器使用此证书作为自签名公钥，通过SSL加密HTTP流量。该文件必须是PEM格式。
-### ssl_key
+##### 示例：
```ini
-SSL 证书密钥的路径。可选，默认值为空。
+ssl_cert = keys/server-cert.pem
```
-服务器使用此私钥通过 SSL 加密 HTTP 流量。该文件必须是 PEM 格式。
+### ssl_key
-##### 示例：
+SSL证书密钥的路径。可选，默认值为空。
-ssl_key = keys/server-key.pem
+服务器使用此私钥通过SSL加密HTTP流量。该文件必须是PEM格式。
-### subtree_docs_cache
+##### 示例：
```ini
-每个查询的最大公共子树文档缓存大小。可选，默认值为 0（禁用）。
+ssl_key = keys/server-key.pem
```
-此设置限制公共子树优化器的内存使用（参见 [multi-queries](../Searching/Multi-queries.md)）。最多将使用这么多内存来缓存每个查询的文档条目。将限制设置为 0 会禁用优化器。
+### subtree_docs_cache
-##### 示例：
+每个查询的最大公共子树文档缓存大小。可选，默认值为0（禁用）。
-subtree_docs_cache = 8M
+此设置限制公共子树优化器的RAM使用量（参见 [multi-queries](../Searching/Multi-queries.md)）。每个查询最多使用这么多RAM来缓存文档条目。将限制设置为0将禁用优化器。
-### subtree_hits_cache
+##### 示例：
```ini
-每个查询的最大公共子树命中缓存大小。可选，默认值为 0（禁用）。
+subtree_docs_cache = 8M
```
-此设置限制公共子树优化器的内存使用（参见 [multi-queries](../Searching/Multi-queries.md)）。最多将使用这么多内存来缓存每个查询的关键字出现（命中）。将限制设置为 0 会禁用优化器。
+### subtree_hits_cache
-##### 示例：
+每个查询的最大公共子树命中缓存大小。可选，默认值为0（禁用）。
-subtree_hits_cache = 16M
+此设置限制公共子树优化器的RAM使用量（参见 [multi-queries](../Searching/Multi-queries.md)）。每个查询最多使用这么多RAM来缓存关键字出现（命中）。将限制设置为0将禁用优化器。
-### threads
+##### 示例：
```ini
-Manticore 守护进程的工作线程数（或线程池大小）。Manticore 启动时创建此数量的操作系统线程，这些线程执行守护进程内的所有任务，如执行查询、创建摘要等。一些操作可能被拆分为子任务并行执行，例如：
+subtree_hits_cache = 16M
```
-* 在实时表中搜索
+### threads
+Manticore守护进程的工作线程数（或线程池大小）。Manticore启动时创建此数量的操作系统线程，它们执行守护进程内的所有任务，如执行查询、创建摘要等。一些操作可能被拆分为子任务并并行执行，例如：
+
+* 在实时表中搜索
* 在由本地表组成的分布式表中搜索
+* 反向查询调用
+* 其他
-* 轮询查询调用
-* 以及其他
-默认情况下，线程数设置为服务器的 CPU 核心数。Manticore 启动时创建线程并保持运行直到停止。每个子任务在需要时可以使用其中一个线程。子任务完成后释放线程，供其他子任务使用。
-在密集 I/O 类型负载的情况下，设置的线程数高于 CPU 核心数可能更合理。
+默认情况下，设置为服务器上的CPU核心数。Manticore启动时创建线程并保持运行直到停止。每个子任务在需要时可以使用其中一个线程。子任务完成后释放线程，供其他子任务使用。
-threads = 10
-
-### thread_stack
+在I/O密集型负载情况下，设置的值高于CPU核心数可能更合理。
```ini
-作业的最大栈大小（协程，一个搜索查询可能导致多个作业/协程）。可选，默认值为 128K。
+threads = 10
```
-每个作业有自己的 128K 栈。运行查询时，会检查所需的栈大小。如果默认的 128K 足够，则直接处理。如果需要更多，则调度另一个具有更大栈的作业继续处理。此设置限制了此类扩展栈的最大大小。
+### thread_stack
-将此值设置为合理较高的数值，有助于处理非常深的查询，而不会导致整体内存消耗过高。例如，设置为 1G 并不意味着每个新作业都会占用 1G 内存，而是如果发现作业需要 100M 栈，则只分配 100M。其他作业同时使用默认的 128K 栈。以此类推，我们可以运行需要 500M 的更复杂查询。只有当内部检测到作业需要超过 1G 栈时，才会失败并报告 thread_stack 设置过低。
+作业的最大栈大小（协程，一个搜索查询可能导致多个作业/协程）。可选，默认值为128K。
-然而，实际上，即使是需要 16M 栈的查询通常也过于复杂，解析耗时且资源消耗大。因此，守护进程会处理它，但通过 `thread_stack` 设置限制此类查询是合理的。
+每个作业有自己的128K栈。运行查询时，会检查其所需栈大小。如果默认的128K足够，则直接处理。如果需要更多，则调度另一个具有更大栈的作业继续处理。此高级栈的最大大小受此设置限制。
-##### 示例：
+将此值设置为合理较高的数值，有助于处理非常深的查询，而不会导致整体RAM消耗过高。例如，设置为1G并不意味着每个新作业都会占用1G RAM，但如果发现作业需要100M栈，则只为该作业分配100M。其他作业同时使用默认的128K栈。以此类推，可以运行需要500M的更复杂查询。只有当内部检测到作业需要超过1G栈时，才会失败并报告thread_stack过低。
-thread_stack = 8M
+然而，实际上，即使需要16M栈的查询通常也过于复杂，解析耗时且资源消耗大。因此，守护进程会处理它，但通过`thread_stack`限制此类查询是合理的。
-### unlink_old
+##### 示例：
```ini
-确定是否在成功轮换后取消链接 `.old` 表副本。可选，默认值为 1（执行取消链接）。
+thread_stack = 8M
```
-##### 示例：
+### unlink_old
-unlink_old = 0
+确定是否在成功轮换时取消链接 `.old` 表副本。可选，默认值为1（执行取消链接）。
-### watchdog
+##### 示例：
```ini
-线程化服务器看门狗。可选，默认值为 1（启用看门狗）。
+unlink_old = 0
```
-当 Manticore 查询崩溃时，可能导致整个服务器宕机。启用看门狗功能后，`searchd` 还维护一个独立的轻量级进程，监控主服务器进程，并在异常终止时自动重启。看门狗默认启用。
+### watchdog
-watchdog = 0 # disable watchdog
+线程化服务器看门狗。可选，默认值为1（启用看门狗）。
-When a Manticore query crashes, it can take down the entire server. With the watchdog feature enabled, `searchd` also maintains a separate lightweight process that monitors the main server process and automatically restarts it in case of abnormal termination. The watchdog is enabled by default.
+当Manticore查询崩溃时，可能导致整个服务器宕机。启用看门狗功能后，`searchd` 还维护一个轻量级的独立进程，监控主服务器进程，并在异常终止时自动重启。看门狗默认启用。
diff --git a/manual/english/Server_settings/Searchd.md b/manual/english/Server_settings/Searchd.md
index 83dc8593a4..da29ba33aa 100755
--- a/manual/english/Server_settings/Searchd.md
+++ b/manual/english/Server_settings/Searchd.md
@@ -507,16 +507,24 @@ expansion_phrase_warning = 1
This setting specifies whether timed grouping in API and SQL will be calculated in the local timezone or in UTC. It is optional, with a default value of 0 (meaning 'local timezone').
-By default, all 'group by time' expressions (like group by day, week, month, and year in API, also group by day, month, year, yearmonth, yearmonthday in SQL) are done using local time. For example, if you have documents with attributes timed `13:00 utc` and `15:00 utc`, in the case of grouping, they both will fall into facility groups according to your local timezone setting. If you live in `utc`, it will be one day, but if you live in `utc+10`, then these documents will be matched into different `group by day` facility groups (since 13:00 utc in UTC+10 timezone is 23:00 local time, but 15:00 is 01:00 of the next day). Sometimes such behavior is unacceptable, and it is desirable to make time grouping not dependent on timezone. You can run the server with a defined global TZ environment variable, but it will affect not only grouping but also timestamping in the logs, which may be undesirable as well. Switching 'on' this option (either in config or using [SET global](../Server_settings/Setting_variables_online.md#SET) statement in SQL) will cause all time grouping expressions to be calculated in UTC, leaving the rest of time-depentend functions (i.e. logging of the server) in local TZ.
+By default, all 'group by time' expressions (like group by day, week, month, and year in API, also group by day, month, year, yearmonth, yearmonthday in SQL) are done using the timezone configured for time functions (see the `timezone` setting or `TZ` environment variable). For example, if you have documents with attributes timed `13:00 utc` and `15:00 utc`, in the case of grouping, they both will fall into facility groups according to your timezone setting. If you live in `utc`, it will be one day, but if you live in `utc+10`, then these documents will be matched into different `group by day` facility groups (since 13:00 utc in UTC+10 timezone is 23:00 local time, but 15:00 is 01:00 of the next day). Sometimes such behavior is unacceptable, and it is desirable to make time grouping not dependent on timezone. Switching 'on' this option (either in config or using [SET global](../Server_settings/Setting_variables_online.md#SET) statement in SQL) will cause all time grouping expressions to be calculated in UTC, regardless of the timezone setting.
+
+**Note:** Logging always uses the actual system local timezone (determined from `/etc/localtime` on Unix-like systems), regardless of the `TZ` environment variable or the `timezone` config setting. This ensures that log timestamps reflect the actual system time, which is useful for debugging and monitoring.
### timezone
-This setting specifies the timezone to be used by date/time-related functions. By default, the local timezone is used, but you can specify a different timezone in IANA format (e.g., `Europe/Amsterdam`).
+This setting specifies the timezone to be used by date/time-related functions (such as `NOW()`, `CURTIME()`, `FROM_UNIXTIME()`, etc.). By default, the system's local timezone is used, but you can specify a different timezone in IANA format (e.g., `Europe/Amsterdam` or `Asia/Singapore`).
-Note that this setting has no impact on logging, which always operates in the local timezone.
+**Timezone resolution order:**
+1. If the `timezone` config setting is explicitly set, it takes precedence.
+2. Otherwise, if the `TZ` environment variable is set, it is used.
+3. If neither is set, the system's local timezone (from `/etc/localtime` on Unix-like systems) is used.
-Also, note that if `grouping_in_utc` is used, the 'group by time' function will still use UTC, while other date/time-related functions will use the specified timezone. Overall, it is not recommended to mix `grouping_in_utc` and `timezone`.
+**Important notes:**
+- **Logging**: Logging always uses the actual system local timezone (determined from `/etc/localtime`), regardless of the `TZ` environment variable or the `timezone` config setting. This ensures that log timestamps reflect the actual system time, which is useful for debugging and monitoring.
+- **Time functions**: Date/time-related functions respect the `timezone` config setting or `TZ` environment variable if set, otherwise they use the system local timezone.
+- **Grouping**: If `grouping_in_utc` is enabled, the 'group by time' function will use UTC, while other date/time-related functions will use the timezone specified by this setting. Overall, it is not recommended to mix `grouping_in_utc` and `timezone`.
You can configure this option either in the config or by using the [SET global](../Server_settings/Setting_variables_online.md#SET) statement in SQL.
diff --git a/manual/russian/Server_settings/Searchd.md b/manual/russian/Server_settings/Searchd.md
index 11ef699152..e8b270db00 100644
--- a/manual/russian/Server_settings/Searchd.md
+++ b/manual/russian/Server_settings/Searchd.md
@@ -507,16 +507,24 @@ expansion_phrase_warning = 1
Эта настройка определяет, будет ли группировка по времени в API и SQL рассчитываться в локальном часовом поясе или в UTC. Опционально, значение по умолчанию — 0 (означает «локальный часовой пояс»).
-По умолчанию все выражения 'group by time' (например, group by day, week, month и year в API, а также group by day, month, year, yearmonth, yearmonthday в SQL) выполняются с использованием локального времени. Например, если у вас есть документы с атрибутами времени `13:00 utc` и `15:00 utc`, при группировке они оба попадут в группы по объектам в соответствии с вашей локальной настройкой часового пояса. Если вы живёте в `utc`, это будет один день, но если вы живёте в `utc+10`, то эти документы будут отнесены к разным группам `group by day` (поскольку 13:00 utc в часовом поясе UTC+10 — это 23:00 местного времени, а 15:00 — это 01:00 следующего дня). Иногда такое поведение неприемлемо, и желательно сделать группировку времени независимой от часового пояса. Вы можете запустить сервер с определённой глобальной переменной окружения TZ, но это повлияет не только на группировку, но и на отметки времени в логах, что также может быть нежелательно. Включение этой опции (либо в конфиге, либо с помощью оператора [SET global](../Server_settings/Setting_variables_online.md#SET) в SQL) приведёт к тому, что все выражения группировки времени будут вычисляться в UTC, при этом остальные функции, зависящие от времени (например, логирование сервера), останутся в локальном часовом поясе.
+По умолчанию все выражения 'group by time' (например, group by day, week, month и year в API, а также group by day, month, year, yearmonth, yearmonthday в SQL) выполняются с использованием часового пояса, настроенного для временных функций (см. настройку `timezone` или переменную окружения `TZ`). Например, если у вас есть документы с атрибутами времени `13:00 utc` и `15:00 utc`, при группировке они оба попадут в группы по объектам в соответствии с вашей настройкой часового пояса. Если вы находитесь в `utc`, это будет один день, но если вы находитесь в `utc+10`, то эти документы будут отнесены к разным группам `group by day` (поскольку 13:00 utc в часовом поясе UTC+10 — это 23:00 местного времени, а 15:00 — это 01:00 следующего дня). Иногда такое поведение неприемлемо, и желательно сделать группировку времени независимой от часового пояса. Включение этой опции (либо в конфиге, либо с помощью оператора [SET global](../Server_settings/Setting_variables_online.md#SET) в SQL) приведет к тому, что все выражения группировки времени будут вычисляться в UTC, независимо от настройки часового пояса.
+
+**Примечание:** Логирование всегда использует фактический локальный системный часовой пояс (определяемый из `/etc/localtime` в системах, подобных Unix), независимо от переменной окружения `TZ` или настройки `timezone`. Это гарантирует, что временные метки в логах отражают фактическое системное время, что полезно для отладки и мониторинга.
### timezone
-Этот параметр задаёт часовой пояс, который будет использоваться функциями, связанными с датой и временем. По умолчанию используется локальный часовой пояс, но вы можете указать другой часовой пояс в формате IANA (например, `Europe/Amsterdam`).
+Эта настройка указывает часовой пояс, который будет использоваться функциями, связанными с датой и временем (такими как `NOW()`, `CURTIME()`, `FROM_UNIXTIME()` и др.). По умолчанию используется локальный часовой пояс системы, но вы можете указать другой часовой пояс в формате IANA (например, `Europe/Amsterdam` или `Asia/Singapore`).
-Обратите внимание, что этот параметр не влияет на логирование, которое всегда работает в локальном часовом поясе.
+**Порядок определения часового пояса:**
+1. Если явно задана настройка `timezone` в конфиге, она имеет приоритет.
+2. В противном случае, если установлена переменная окружения `TZ`, используется она.
+3. Если ни одна из них не установлена, используется локальный часовой пояс системы (из `/etc/localtime` в системах, подобных Unix).
-Также обратите внимание, что если используется `grouping_in_utc`, функция 'group by time' всё равно будет использовать UTC, в то время как другие функции, связанные с датой и временем, будут использовать указанный часовой пояс. В целом не рекомендуется смешивать `grouping_in_utc` и `timezone`.
+**Важные замечания:**
+- **Логирование**: Логирование всегда использует фактический локальный системный часовой пояс (определяемый из `/etc/localtime`), независимо от переменной окружения `TZ` или настройки `timezone`. Это гарантирует, что временные метки в логах отражают фактическое системное время, что полезно для отладки и мониторинга.
+- **Временные функции**: Функции, связанные с датой и временем, учитывают настройку `timezone` или переменную окружения `TZ`, если они заданы, иначе используют локальный часовой пояс системы.
+- **Группировка**: Если включена опция `grouping_in_utc`, функция 'group by time' будет использовать UTC, в то время как другие функции, связанные с датой и временем, будут использовать часовой пояс, указанный в этой настройке. В целом не рекомендуется смешивать `grouping_in_utc` и `timezone`.
Вы можете настроить эту опцию либо в конфиге, либо с помощью оператора [SET global](../Server_settings/Setting_variables_online.md#SET) в SQL.
@@ -524,11 +532,11 @@ expansion_phrase_warning = 1
### ha_period_karma
-Этот параметр задаёт размер окна статистики зеркал агентов в секундах (или с использованием [special_suffixes](../Server_settings/Special_suffixes.md)). Он необязателен, значение по умолчанию — 60 секунд.
+Эта настройка задает размер окна статистики зеркал агента в секундах (или с использованием [special_suffixes](../Server_settings/Special_suffixes.md)). Она необязательна, значение по умолчанию — 60 секунд.
-Для распределённой таблицы с зеркалами агентов (подробнее см. в [agent](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)) мастер отслеживает несколько различных счётчиков для каждого зеркала. Эти счётчики затем используются для переключения и балансировки (мастер выбирает лучшее зеркало на основе счётчиков). Счётчики накапливаются блоками по `ha_period_karma` секунд.
+Для распределенной таблицы с зеркалами агента (подробнее см. в [agent](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)) мастер отслеживает несколько различных счетчиков для каждого зеркала. Эти счетчики затем используются для переключения и балансировки (мастер выбирает лучшее зеркало на основе счетчиков). Счетчики накапливаются блоками по `ha_period_karma` секунд.
-После начала нового блока мастер может продолжать использовать накопленные значения из предыдущего блока, пока новый блок не заполнится наполовину. В результате, любая предыдущая история перестаёт влиять на выбор зеркала максимум через 1.5 раза `ha_period_karma` секунд.
+После начала нового блока мастер может продолжать использовать накопленные значения из предыдущего блока, пока новый блок не заполнится наполовину. В результате любая предыдущая история перестает влиять на выбор зеркала максимум через 1.5 раза `ha_period_karma` секунд.
Хотя для выбора зеркала используется максимум два блока, до 15 последних блоков сохраняются для целей инструментирования. Эти блоки можно просмотреть с помощью оператора [SHOW AGENT STATUS](../Node_info_and_management/Node_status.md#SHOW-AGENT-STATUS).
@@ -547,9 +555,9 @@ ha_period_karma = 2m
### ha_ping_interval
-Этот параметр задаёт интервал между пингами зеркал агентов в миллисекундах (или с использованием [special_suffixes](../Server_settings/Special_suffixes.md)). Он необязателен, значение по умолчанию — 1000 миллисекунд.
+Эта настройка задает интервал между пингами зеркал агента в миллисекундах (или с использованием [special_suffixes](../Server_settings/Special_suffixes.md)). Она необязательна, значение по умолчанию — 1000 миллисекунд.
-Для распределённой таблицы с зеркалами агентов (подробнее см. в [agent](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)) мастер отправляет всем зеркалам команду пинга в периоды простоя. Это необходимо для отслеживания текущего статуса агента (жив или мёртв, время сетевого отклика и т.д.). Интервал между такими пингами определяется этой директивой. Чтобы отключить пинги, установите ha_ping_interval в 0.
+Для распределенной таблицы с зеркалами агента (подробнее см. в [agent](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)) мастер отправляет всем зеркалам команду пинга в периоды простоя. Это необходимо для отслеживания текущего статуса агента (активен или нет, время сетевого отклика и т.д.). Интервал между такими пингами определяется этой директивой. Чтобы отключить пинги, установите `ha_ping_interval` в 0.
@@ -565,19 +573,19 @@ ha_ping_interval = 3s
### hostname_lookup
-Опция `hostname_lookup` определяет стратегию обновления имён хостов. По умолчанию IP-адреса имён хостов агентов кэшируются при запуске сервера, чтобы избежать чрезмерных обращений к DNS. Однако в некоторых случаях IP может динамически меняться (например, в облачном хостинге), и может быть желательно не кэшировать IP. Установка этой опции в значение `request` отключает кэширование и выполняет запросы к DNS при каждом запросе. IP-адреса также можно обновить вручную с помощью команды `FLUSH HOSTNAMES`.
+Опция `hostname_lookup` определяет стратегию обновления имен хостов. По умолчанию IP-адреса имен хостов агентов кэшируются при запуске сервера, чтобы избежать чрезмерных обращений к DNS. Однако в некоторых случаях IP может динамически меняться (например, в облачном хостинге), и может быть желательно не кэшировать IP. Установка этой опции в значение `request` отключает кэширование и выполняет запросы к DNS при каждом запросе. IP-адреса также можно обновить вручную с помощью команды `FLUSH HOSTNAMES`.
### jobs_queue_size
-Параметр jobs_queue_size определяет, сколько "заданий" может находиться в очереди одновременно. По умолчанию ограничений нет.
+Настройка `jobs_queue_size` определяет, сколько "заданий" может находиться в очереди одновременно. По умолчанию ограничений нет.
-В большинстве случаев "задание" означает один запрос к одной локальной таблице (обычной таблице или дисковому чанку таблицы реального времени). Например, если у вас есть распределённая таблица, состоящая из 2 локальных таблиц, или таблица реального времени с 2 дисковыми чанками, поисковый запрос к любой из них обычно создаст 2 задания в очереди. Затем пул потоков (размер которого задаётся параметром [threads](../Server_settings/Searchd.md#threads)) обрабатывает их. Однако в некоторых случаях, если запрос слишком сложный, может создаваться больше заданий. Рекомендуется изменять этот параметр, когда [max_connections](../Server_settings/Searchd.md#max_connections) и [threads](../Server_settings/Searchd.md#threads) недостаточны для достижения баланса между желаемой производительностью.
+В большинстве случаев "задача" означает один запрос к одной локальной таблице (обычной таблице или дисковому чанку таблицы реального времени). Например, если у вас есть распределённая таблица, состоящая из 2 локальных таблиц, или таблица реального времени с 2 дисковыми чанками, поисковый запрос к любой из них в основном поставит в очередь 2 задачи. Затем пул потоков (размер которого определяется параметром [threads](../Server_settings/Searchd.md#threads)) будет их обрабатывать. Однако в некоторых случаях, если запрос слишком сложный, может быть создано больше задач. Рекомендуется изменить этот параметр, когда [max_connections](../Server_settings/Searchd.md#max_connections) и [threads](../Server_settings/Searchd.md#threads) недостаточны для достижения баланса между желаемой производительностью.
### join_batch_size
Объединения таблиц работают путём накопления партии совпадений, которые являются результатами запроса, выполненного по левой таблице. Эта партия затем обрабатывается как единый запрос к правой таблице.
-Эта опция позволяет настроить размер партии. Значение по умолчанию — `1000`, установка этого параметра в `0` отключает пакетную обработку.
+Этот параметр позволяет настроить размер партии. Значение по умолчанию — `1000`, а установка этого параметра в `0` отключает пакетную обработку.
Больший размер партии может улучшить производительность; однако для некоторых запросов это может привести к чрезмерному потреблению памяти.
@@ -595,11 +603,11 @@ join_batch_size = 2000
Каждый запрос, выполняемый по правой таблице, определяется конкретными условиями JOIN ON, которые определяют набор результатов, извлекаемых из правой таблицы.
-Если существует всего несколько уникальных условий JOIN ON, повторное использование результатов может быть более эффективным, чем многократное выполнение запросов к правой таблице. Для этого наборы результатов сохраняются в кэше.
+Если уникальных условий JOIN ON немного, повторное использование результатов может быть более эффективным, чем многократное выполнение запросов к правой таблице. Для этого наборы результатов сохраняются в кэше.
Этот параметр позволяет настроить размер этого кэша. Значение по умолчанию — `20 MB`, а установка этого параметра в 0 отключает кэширование.
-Обратите внимание, что каждый поток поддерживает свой собственный кэш, поэтому при оценке общего использования памяти следует учитывать количество потоков, выполняющих запросы.
+Обратите внимание, что каждый поток поддерживает собственный кэш, поэтому при оценке общего потребления памяти следует учитывать количество потоков, выполняющих запросы.
##### Пример:
@@ -614,8 +622,8 @@ join_cache_size = 10M
### listen_backlog
-Параметр listen_backlog определяет длину очереди TCP listen backlog для входящих соединений. Это особенно актуально для сборок под Windows, которые обрабатывают запросы по одному. Когда очередь соединений достигает предела, новые входящие соединения будут отклоняться.
-Для сборок не под Windows значение по умолчанию обычно подходит, и обычно нет необходимости настраивать этот параметр.
+Параметр listen_backlog определяет длину очереди TCP для входящих соединений. Это особенно актуально для сборок под Windows, которые обрабатывают запросы по одному. Когда очередь соединений достигает своего предела, новые входящие соединения будут отклоняться.
+Для сборок не под Windows значение по умолчанию обычно подходит, и обычно нет необходимости изменять этот параметр.
@@ -662,23 +670,23 @@ listen = ( address ":" port | port | path | address ":" port start - port end )
* либо путь к Unix-сокету (не поддерживается в Windows)
* либо IP-адрес и диапазон портов
-Если вы указываете номер порта, но не адрес, `searchd` будет слушать на всех сетевых интерфейсах. Путь Unix определяется ведущим слэшем. Диапазон портов можно задать только для протокола репликации.
+Если вы указываете номер порта, но не адрес, `searchd` будет слушать на всех сетевых интерфейсах. Путь Unix-сокета определяется ведущим слэшем. Диапазон портов можно задать только для протокола репликации.
Вы также можете указать обработчик протокола (listener), который будет использоваться для соединений на этом сокете. Слушатели:
* **Не указан** — Manticore будет принимать соединения на этом порту от:
- - других агентов Manticore (например, удалённой распределённой таблицы)
+ - других агентов Manticore (то есть удалённой распределённой таблицы)
- клиентов через HTTP и HTTPS
- [Manticore Buddy](https://manticoresearch.com/blog/manticoresearch-buddy-intro/). **Убедитесь, что у вас есть слушатель такого типа (или `http` слушатель, как указано ниже), чтобы избежать ограничений в функциональности Manticore.**
-* `mysql` — протокол MySQL для соединений от клиентов MySQL. Обратите внимание:
+* `mysql` — протокол MySQL для соединений от MySQL-клиентов. Обратите внимание:
- Поддерживается также сжатый протокол.
- Если включён [SSL](../Security/SSL.md#SSL), можно установить зашифрованное соединение.
-* `replication` — протокол репликации, используемый для связи узлов. Подробнее см. в разделе [репликация](../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md). Можно указать несколько слушателей репликации, но они все должны слушать на одном IP; различаться могут только порты. При определении слушателя репликации с диапазоном портов (например, `listen = 192.168.0.1:9320-9328:replication`) Manticore не начинает слушать эти порты сразу. Вместо этого он будет брать случайные свободные порты из указанного диапазона только при начале использования репликации. Для корректной работы репликации в диапазоне должно быть не менее 2 портов.
+* `replication` — протокол репликации, используемый для связи между узлами. Подробнее см. в разделе [репликация](../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md). Можно указать несколько слушателей репликации, но все они должны слушать на одном IP; различаться могут только порты. При определении слушателя репликации с диапазоном портов (например, `listen = 192.168.0.1:9320-9328:replication`) Manticore не начинает сразу слушать эти порты. Вместо этого он будет брать случайные свободные порты из указанного диапазона только при начале использования репликации. Для корректной работы репликации в диапазоне должно быть не менее 2 портов.
* `http` — то же, что и **Не указан**. Manticore будет принимать соединения на этом порту от удалённых агентов и клиентов через HTTP и HTTPS.
* `https` — протокол HTTPS. Manticore будет принимать **только** HTTPS-соединения на этом порту. Подробнее см. в разделе [SSL](../Security/SSL.md).
* `sphinx` — устаревший бинарный протокол. Используется для обслуживания соединений от удалённых клиентов [SphinxSE](../Extensions/SphinxSE.md). Некоторые реализации клиентов Sphinx API (например, Java) требуют явного указания слушателя.
-Добавление суффикса `_vip` к протоколам клиентов (то есть ко всем, кроме `replication`, например `mysql_vip` или `http_vip` или просто `_vip`) заставляет создавать выделенный поток для соединения, чтобы обойти различные ограничения. Это полезно для обслуживания узла в случае сильной перегрузки, когда сервер в противном случае либо зависнет, либо не позволит подключиться через обычный порт.
+Добавление суффикса `_vip` к протоколам клиентов (то есть ко всем, кроме `replication`, например `mysql_vip` или `http_vip` или просто `_vip`) заставляет создавать выделенный поток для соединения, чтобы обойти различные ограничения. Это полезно для обслуживания узла в случае серьёзной перегрузки, когда сервер в противном случае либо зависнет, либо не позволит подключиться через обычный порт.
Суффикс `_readonly` устанавливает [режим только для чтения](../Security/Read_only.md) для слушателя и ограничивает его приём только запросами на чтение.
@@ -703,58 +711,58 @@ listen = 127.0.0.1:9312:sphinx # listen for legacy Sphinx requests (e.g. from Sp
```
-Может быть несколько директив `listen`. `searchd` будет слушать клиентские соединения на всех указанных портах и сокетах. Конфигурация по умолчанию, поставляемая в пакетах Manticore, определяет прослушивание на портах:
-* `9308` и `9312` для соединений от удалённых агентов и клиентов, не основанных на MySQL
-* и на порту `9306` для MySQL-соединений.
+Может быть несколько директив `listen`. `searchd` будет слушать подключения клиентов на всех указанных портах и сокетах. Конфигурация по умолчанию, предоставляемая в пакетах Manticore, определяет прослушивание на портах:
+* `9308` и `9312` для подключений от удалённых агентов и клиентов, не основанных на MySQL
+* и на порту `9306` для MySQL подключений.
-Если вы вообще не укажете `listen` в конфигурации, Manticore будет ждать соединений на:
-* `127.0.0.1:9306` для клиентов MySQL
-* `127.0.0.1:9312` для HTTP/HTTPS и соединений от других узлов Manticore и клиентов, основанных на бинарном API Manticore.
+Если вы вообще не указываете `listen` в конфигурации, Manticore будет ждать подключения на:
+* `127.0.0.1:9306` для MySQL клиентов
+* `127.0.0.1:9312` для HTTP/HTTPS и подключений от других узлов Manticore и клиентов, основанных на бинарном API Manticore.
#### Прослушивание привилегированных портов
-По умолчанию Linux не позволит Manticore слушать порт ниже 1024 (например, `listen = 127.0.0.1:80:http` или `listen = 127.0.0.1:443:https`), если вы не запускаете searchd от root. Если вы всё же хотите запускать Manticore, чтобы он слушал порты < 1024 под обычным пользователем, рассмотрите один из следующих вариантов (любой из них должен работать):
+По умолчанию Linux не позволит Manticore слушать порт ниже 1024 (например, `listen = 127.0.0.1:80:http` или `listen = 127.0.0.1:443:https`), если вы не запускаете searchd от root. Если вы всё же хотите запускать Manticore так, чтобы он слушал порты < 1024 под непривилегированным пользователем, рассмотрите один из следующих вариантов (любой из них должен работать):
* Выполните команду `setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/searchd`
* Добавьте `AmbientCapabilities=CAP_NET_BIND_SERVICE` в systemd-юнит Manticore и перезагрузите демон (`systemctl daemon-reload`).
-#### Технические детали о протоколе Sphinx API и TFO
+#### Технические детали протокола Sphinx API и TFO
-Legacy Sphinx protocol has 2 phases: handshake exchanging and data flow. The handshake consists of a packet of 4 bytes from the client, and a packet of 4 bytes from the daemon with only one purpose - the client determines that the remote is a real Sphinx daemon, the daemon determines that the remote is a real Sphinx client. The main dataflow is quite simple: let's both sides declare their handshakes, and the opposite check them. That exchange with short packets implies using special `TCP_NODELAY` flag, which switches off Nagle's TCP algorithm and declares that the TCP connection will be performed as a dialogue of small packages.
-However, it is not strictly defined who speaks first in this negotiation. Historically, all clients that use the binary API speak first: send handshake, then read 4 bytes from a daemon, then send a request and read an answer from the daemon.
-When we improved Sphinx protocol compatibility, we considered these things:
+Устаревший протокол Sphinx имеет 2 фазы: обмен рукопожатием и поток данных. Рукопожатие состоит из пакета в 4 байта от клиента и пакета в 4 байта от демона с единственной целью — клиент определяет, что удалённый узел — настоящий демон Sphinx, демон определяет, что удалённый узел — настоящий клиент Sphinx. Основной поток данных довольно прост: обе стороны объявляют свои рукопожатия, а противоположная сторона их проверяет. Такой обмен короткими пакетами подразумевает использование специального флага `TCP_NODELAY`, который отключает алгоритм Нейгла TCP и объявляет, что TCP-соединение будет выполняться как диалог маленьких пакетов.
+Однако не строго определено, кто говорит первым в этом согласовании. Исторически все клиенты, использующие бинарный API, говорят первыми: отправляют рукопожатие, затем читают 4 байта от демона, затем отправляют запрос и читают ответ от демона.
+Когда мы улучшали совместимость протокола Sphinx, мы учли следующее:
-1. Usually, master-agent communication is established from a known client to a known host on a known port. So, it is quite not possible that the endpoint will provide a wrong handshake. So, we may implicitly assume that both sides are valid and really speak in Sphinx proto.
-2. Given this assumption, we can 'glue' a handshake to the real request and send it in one packet. If the backend is a legacy Sphinx daemon, it will just read this glued packet as 4 bytes of a handshake, then request body. Since they both came in one packet, the backend socket has -1 RTT, and the frontend buffer still works despite that fact usual way.
-3. Continuing the assumption: since the 'query' packet is quite small, and the handshake is even smaller, let's send both in the initial 'SYN' TCP package using modern TFO (tcp-fast-open) technique. That is: we connect to a remote node with the glued handshake + body package. The daemon accepts the connection and immediately has both the handshake and the body in a socket buffer, as they came in the very first TCP 'SYN' packet. That eliminates another one RTT.
-4. Finally, teach the daemon to accept this improvement. Actually, from the application, it implies NOT to use `TCP_NODELAY`. And, from the system side, it implies to ensure that on the daemon side, accepting TFO is activated, and on the client side, sending TFO is also activated. By default, in modern systems, client TFO is already activated by default, so you only have to tune the server TFO for all things to work.
+1. Обычно связь мастер-агент устанавливается от известного клиента к известному хосту на известном порту. Поэтому маловероятно, что конечная точка предоставит неправильное рукопожатие. Следовательно, мы можем неявно предположить, что обе стороны валидны и действительно говорят на протоколе Sphinx.
+2. Исходя из этого предположения, мы можем «склеить» рукопожатие с реальным запросом и отправить их в одном пакете. Если бэкенд — устаревший демон Sphinx, он просто прочитает этот склеенный пакет как 4 байта рукопожатия, затем тело запроса. Поскольку они пришли в одном пакете, у бэкенда сокет имеет -1 RTT, а буфер фронтенда всё ещё работает обычным способом.
+3. Продолжая предположение: поскольку пакет «запроса» довольно маленький, а рукопожатие ещё меньше, давайте отправим оба в начальном TCP-пакете «SYN» с использованием современной техники TFO (tcp-fast-open). То есть: мы подключаемся к удалённому узлу с пакетом, склеенным из рукопожатия + тела. Демон принимает соединение и сразу имеет и рукопожатие, и тело в буфере сокета, так как они пришли в самом первом TCP-пакете «SYN». Это устраняет ещё один RTT.
+4. Наконец, обучаем демон принимать это улучшение. На уровне приложения это означает НЕ использовать `TCP_NODELAY`. А на уровне системы — обеспечить, чтобы на стороне демона было активировано принятие TFO, а на стороне клиента — отправка TFO. По умолчанию в современных системах клиентский TFO уже активирован, так что вам нужно только настроить серверный TFO, чтобы всё работало.
-All these improvements without actually changing the protocol itself allowed us to eliminate 1.5 RTT of the TCP protocol from the connection. Which is, if the query and answer are capable of being placed in a single TCP package, decreases the whole binary API session from 3.5 RTT to 2 RTT - which makes network negotiation about 2 times faster.
+Все эти улучшения без фактического изменения протокола позволили нам устранить 1.5 RTT TCP-протокола при соединении. Если запрос и ответ помещаются в один TCP-пакет, это уменьшает всю сессию бинарного API с 3.5 RTT до 2 RTT — что делает сетевое согласование примерно в 2 раза быстрее.
-So, all our improvements are stated around an initially undefined statement: 'who speaks first.' If a client speaks first, we may apply all these optimizations and effectively process connect + handshake + query in a single TFO package. Moreover, we can look at the beginning of the received package and determine a real protocol. That is why you can connect to one and the same port via API/http/https. If the daemon has to speak first, all these optimizations are impossible, and the multiprotocol is also impossible. That is why we have a dedicated port for MySQL and did not unify it with all the other protocols into a same port. Suddenly, among all clients, one was written implying that daemon should send a handshake first. That is - no possibility to all the described improvements. That is SphinxSE plugin for mysql/mariadb. So, specially for this single client we dedicated `sphinx` proto definition to work most legacy way. Namely: both sides activate `TCP_NODELAY` and exchange with small packages. The daemon sends its handshake on connect, then the client sends its, and then everything works usual way. That is not very optimal, but just works. If you use SphinxSE to connect to Manticore - you have to dedicate a listener with explicitly stated `sphinx` proto. For another clients - avoid to use this listener as it is slower. If you use another legacy Sphinx API clients - check first, if they are able to work with non-dedicated multiprotocol port. For master-agent linkage using the non-dedicated (multiprotocol) port and enabling client and server TFO works well and will definitely make working of network backend faster, especially if you have very light and fast queries.
+Таким образом, все наши улучшения основаны на изначально неопределённом вопросе: «кто говорит первым». Если клиент говорит первым, мы можем применить все эти оптимизации и эффективно обработать соединение + рукопожатие + запрос в одном TFO-пакете. Более того, мы можем посмотреть в начало полученного пакета и определить реальный протокол. Поэтому вы можете подключаться к одному и тому же порту через API/http/https. Если демон должен говорить первым, все эти оптимизации невозможны, и мультипротокол тоже невозможен. Поэтому у нас есть выделенный порт для MySQL, и мы не объединили его со всеми другими протоколами в один порт. Вдруг среди всех клиентов один был написан с предположением, что демон должен отправлять рукопожатие первым. Это — плагин SphinxSE для mysql/mariadb. Специально для этого единственного клиента мы выделили определение протокола `sphinx`, чтобы работать максимально по-старому. А именно: обе стороны активируют `TCP_NODELAY` и обмениваются маленькими пакетами. Демон отправляет своё рукопожатие при подключении, затем клиент отправляет своё, и затем всё работает обычным способом. Это не очень оптимально, но просто работает. Если вы используете SphinxSE для подключения к Manticore — вам нужно выделить слушатель с явно указанным протоколом `sphinx`. Для других клиентов — избегайте использования этого слушателя, так как он медленнее. Если вы используете других устаревших клиентов Sphinx API — сначала проверьте, могут ли они работать с невыделенным мультипротокольным портом. Для связи мастер-агент использование невыделенного (мультипротокольного) порта и включение TFO на клиенте и сервере работает хорошо и определённо ускорит работу сетевого бэкенда, особенно если у вас очень лёгкие и быстрые запросы.
### listen_tfo
-This setting allows the TCP_FASTOPEN flag for all listeners. By default, it is managed by the system but may be explicitly switched off by setting it to '0'.
+Этот параметр позволяет включить флаг TCP_FASTOPEN для всех слушателей. По умолчанию он управляется системой, но может быть явно отключён установкой значения '0'.
-For general knowledge about the TCP Fast Open extension, please consult with [Wikipedia](https://en.wikipedia.org/wiki/TCP_Fast_Open). In short, it allows the elimination of one TCP round-trip when establishing a connection.
+Для общего ознакомления с расширением TCP Fast Open, пожалуйста, обратитесь к [Wikipedia](https://en.wikipedia.org/wiki/TCP_Fast_Open). Кратко, оно позволяет исключить один круговой обмен TCP при установлении соединения.
-In practice, using TFO in many situations may optimize client-agent network efficiency, as if [persistent agents](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md) are in play, but without holding active connections, and also without limitation for the maximum num of connections.
+На практике использование TFO во многих ситуациях может оптимизировать сетевую эффективность клиента-агента, как если бы использовались [постоянные агенты](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md), но без удержания активных соединений, а также без ограничения максимального количества соединений.
-On modern OS, TFO support is usually switched 'on' at the system level, but this is just a 'capability', not the rule. Linux (as the most progressive) has supported it since 2011, on kernels starting from 3.7 (for the server-side). Windows has supported it from some builds of Windows 10. Other operating systems (FreeBSD, MacOS) are also in the game.
+На современных ОС поддержка TFO обычно включена на уровне системы, но это всего лишь «возможность», а не правило. Linux (как самая прогрессивная) поддерживает его с 2011 года, начиная с ядер 3.7 (для серверной стороны). Windows поддерживает его с некоторых сборок Windows 10. Другие операционные системы (FreeBSD, MacOS) также участвуют.
-For Linux system server checks variable `/proc/sys/net/ipv4/tcp_fastopen` and behaves according to it. Bit 0 manages client side, bit 1 rules listeners. By default, the system has this parameter set to 1, i.e., clients enabled, listeners disabled.
+Для проверки на сервере Linux используется переменная `/proc/sys/net/ipv4/tcp_fastopen` и система ведет себя согласно ей. Бит 0 управляет клиентской стороной, бит 1 — слушателями. По умолчанию параметр установлен в 1, то есть клиенты включены, слушатели отключены.
### log
-The log setting specifies the name of the log file where all `searchd` run time events will be logged. If not specified, the default name is 'searchd.log'.
+Параметр log указывает имя файла журнала, в который будут записываться все события времени выполнения `searchd`. Если не указано, по умолчанию используется имя 'searchd.log'.
-Alternatively, you can use the 'syslog' as the file name. In this case, the events will be sent to the syslog daemon. To use the syslog option, you need to configure Manticore with the `-–with-syslog` option during building.
+В качестве альтернативы можно использовать 'syslog' в качестве имени файла. В этом случае события будут отправляться демону syslog. Для использования опции syslog необходимо собрать Manticore с опцией `-–with-syslog`.
-##### Example:
+##### Пример:
@@ -773,7 +781,7 @@ log = /var/log/searchd.log
-##### Example:
+##### Пример:
@@ -785,7 +793,7 @@ max_batch_queries = 256
### max_connections
-Максимальное количество одновременных клиентских подключений. По умолчанию неограничено. Обычно это заметно только при использовании любых видов постоянных подключений, таких как cli mysql сессии или постоянные удалённые подключения из удалённых распределённых таблиц. При превышении лимита вы всё ещё можете подключиться к серверу, используя [VIP-подключение](../Connecting_to_the_server/MySQL_protocol.md#VIP-connection). VIP-подключения не учитываются в лимит.
+Максимальное количество одновременных клиентских соединений. По умолчанию неограничено. Обычно это заметно только при использовании каких-либо постоянных соединений, например, cli mysql сессий или постоянных удалённых соединений из удалённых распределённых таблиц. При превышении лимита вы всё равно можете подключиться к серверу, используя [VIP соединение](../Connecting_to_the_server/MySQL_protocol.md#VIP-connection). VIP соединения не учитываются в лимите.
```ini
@@ -797,14 +805,14 @@ max_connections = 10
### max_threads_per_query
-Глобальное ограничение количества потоков, которые может использовать одна операция. По умолчанию соответствующие операции могут занимать все ядра CPU, не оставляя места для других операций. Например, `call pq` к достаточно большой таблице percolate может использовать все потоки в течение десятков секунд. Установка `max_threads_per_query` в, скажем, половину от значения [threads](../Server_settings/Searchd.md#threads) обеспечит возможность запуска нескольких таких операций `call pq` параллельно.
+Глобальное ограничение количества потоков, которые может использовать одна операция. По умолчанию соответствующие операции могут занимать все ядра CPU, не оставляя места для других операций. Например, `call pq` по достаточно большой percolate таблице может использовать все потоки в течение десятков секунд. Установка `max_threads_per_query` в, скажем, половину от [threads](../Server_settings/Searchd.md#threads) обеспечит возможность запуска нескольких таких `call pq` операций параллельно.
-Вы также можете установить этот параметр как переменную сессии или глобальную переменную во время выполнения.
+Также эту настройку можно задать как сессионную или глобальную переменную во время работы.
-Кроме того, вы можете управлять поведением для каждого запроса с помощью опции [threads OPTION](../Searching/Options.md#threads).
+Кроме того, поведение можно контролировать для каждого запроса отдельно с помощью [OPTION threads](../Searching/Options.md#threads).
-##### Example:
+##### Пример:
```ini
@@ -816,11 +824,11 @@ max_threads_per_query = 4
### max_filters
-Максимально допустимое количество фильтров на запрос. Этот параметр используется только для внутренних проверок и не влияет напрямую на использование ОЗУ или производительность. Необязательно, по умолчанию 256.
+Максимально допустимое количество фильтров на запрос. Эта настройка используется только для внутренних проверок и не влияет напрямую на использование ОЗУ или производительность. Необязательно, по умолчанию 256.
-##### Example:
+##### Пример:
@@ -833,11 +841,11 @@ max_filters = 1024
### max_filter_values
-Максимально допустимое количество значений в фильтре. Этот параметр используется только для внутренних проверок и не влияет напрямую на использование ОЗУ или производительность. Необязательно, по умолчанию 4096.
+Максимально допустимое количество значений в фильтре. Эта настройка используется только для внутренних проверок и не влияет напрямую на использование ОЗУ или производительность. Необязательно, по умолчанию 4096.
-##### Example:
+##### Пример:
@@ -850,12 +858,12 @@ max_filter_values = 16384
### max_open_files
-Максимальное количество файлов, которые сервер может открыть, называется "мягким лимитом". Обратите внимание, что обслуживание больших фрагментированных таблиц реального времени может требовать установки этого лимита на высоком уровне, так как каждый диск-чанк может занимать десятки и более файлов. Например, таблица реального времени с 1000 чанков может требовать открытия тысяч файлов одновременно. Если в логах появляется ошибка 'Too many open files', попробуйте изменить этот параметр, это может помочь решить проблему.
+Максимальное количество файлов, которые сервер может открыть, называется «мягким лимитом». Обратите внимание, что обслуживание больших фрагментированных таблиц реального времени может требовать установки этого лимита на высоком уровне, так как каждый дискованный кусок может занимать десятки и более файлов. Например, таблица реального времени с 1000 кусочков может требовать открытия тысяч файлов одновременно. Если в логах появляется ошибка 'Too many open files', попробуйте изменить эту опцию, это может помочь решить проблему.
-Существует также "жёсткий лимит", который нельзя превысить с помощью этой опции. Этот лимит определяется системой и может быть изменён в файле `/etc/security/limits.conf` на Linux. Другие операционные системы могут иметь другие подходы, поэтому обратитесь к документации для получения дополнительной информации.
+Существует также «жесткий лимит», который нельзя превысить с помощью этой опции. Этот лимит задаётся системой и может быть изменён в файле `/etc/security/limits.conf` на Linux. Другие ОС могут иметь другие подходы, поэтому обратитесь к документации.
-##### Example:
+##### Пример:
@@ -865,10 +873,10 @@ max_open_files = 10000
-Помимо прямых числовых значений, вы можете использовать магическое слово 'max', чтобы установить лимит равным текущему доступному жёсткому лимиту.
+Помимо прямых числовых значений, можно использовать магическое слово 'max', чтобы установить лимит равным текущему доступному жесткому лимиту.
-##### Example:
+##### Пример:
@@ -881,11 +889,11 @@ max_open_files = max
### max_packet_size
-Максимально допустимый размер сетевого пакета. Этот параметр ограничивает как пакеты запросов от клиентов, так и пакеты ответов от удалённых агентов в распределённой среде. Используется только для внутренних проверок и не влияет напрямую на использование ОЗУ или производительность. Необязательно, по умолчанию 128M.
+Максимально допустимый размер сетевого пакета. Эта настройка ограничивает как пакеты запросов от клиентов, так и пакеты ответов от удалённых агентов в распределённой среде. Используется только для внутренних проверок и не влияет напрямую на использование ОЗУ или производительность. Необязательно, по умолчанию 128M.
-##### Example:
+##### Пример:
@@ -898,13 +906,13 @@ max_packet_size = 32M
### mysql_version_string
-Строка версии сервера, возвращаемая через протокол MySQL. Необязательно, по умолчанию пусто (возвращает версию Manticore).
+Строка версии сервера, возвращаемая через протокол MySQL. Необязательно, по умолчанию пусто (возвращается версия Manticore).
-Некоторые придирчивые библиотеки клиентов MySQL зависят от определённого формата номера версии, используемого MySQL, и более того, иногда выбирают другой путь выполнения на основе сообщаемого номера версии (а не на основе указанных флагов возможностей). Например, Python MySQLdb 1.2.2 выбрасывает исключение, если номер версии не в формате X.Y.ZZ; MySQL .NET connector 6.3.x внутренне падает на номерах версий 1.x вместе с определённой комбинацией флагов и т.д. Чтобы обойти это, вы можете использовать директиву `mysql_version_string` и заставить `searchd` сообщать другую версию клиентам, подключающимся по протоколу MySQL. (По умолчанию он сообщает свою собственную версию.)
+Несколько придирчивых клиентских библиотек MySQL зависят от определённого формата номера версии, используемого MySQL, и более того, иногда выбирают другой путь выполнения на основе сообщаемого номера версии (а не указанных флагов возможностей). Например, Python MySQLdb 1.2.2 выбрасывает исключение, если номер версии не в формате X.Y.ZZ; MySQL .NET connector 6.3.x внутренне не работает с номерами версий 1.x вместе с определённой комбинацией флагов и т.д. Чтобы обойти это, вы можете использовать директиву `mysql_version_string` и заставить `searchd` сообщать клиентам, подключающимся по протоколу MySQL, другую версию. (По умолчанию он сообщает свою собственную версию.)
-##### Example:
+##### Пример:
@@ -925,26 +933,26 @@ mysql_version_string = 5.0.37
Управляет интервалом busy loop сетевого потока. По умолчанию -1, может быть установлен в -1, 0 или положительное целое число.
-В случаях, когда сервер настроен как чистый мастер и просто маршрутизирует запросы к агентам, важно обрабатывать запросы без задержек и не допускать, чтобы сетевой поток засыпал. Для этого существует busy loop. После входящего запроса сетевой поток использует CPU poll в течение `10 * net_wait_tm` миллисекунд, если `net_wait_tm` положительное число, или опрашивает только с помощью CPU, если `net_wait_tm` равен `0`. Также busy loop можно отключить с помощью `net_wait_tm = -1` — в этом случае poller устанавливает таймауты, соответствующие фактическим таймаутам агента в системном вызове опроса.
+В случаях, когда сервер настроен как чистый мастер и просто маршрутизирует запросы к агентам, важно обрабатывать запросы без задержек и не позволять сетевому потоку засыпать. Для этого существует busy loop. После входящего запроса сетевой поток использует CPU poll в течение `10 * net_wait_tm` миллисекунд, если `net_wait_tm` положительное число, или опрашивает только CPU, если `net_wait_tm` равен `0`. Также busy loop можно отключить с помощью `net_wait_tm = -1` — в этом случае poller устанавливает таймауты, соответствующие реальным таймаутам агентов в системном вызове опроса.
-> **ВНИМАНИЕ:** Busy loop загружает ядро CPU, поэтому установка этого значения в любое не стандартное значение приведет к заметному использованию CPU даже при простое сервера.
+> **ВНИМАНИЕ:** Busy loop загружает ядро CPU, поэтому установка этого значения в любое не стандартное значение приведёт к заметному использованию CPU даже при простое сервера.
### net_throttle_accept
-Определяет, сколько клиентов принимается на каждой итерации сетевого цикла. По умолчанию 0 (без ограничений), что подходит для большинства пользователей. Это опция тонкой настройки для контроля пропускной способности сетевого цикла в условиях высокой нагрузки.
+Определяет, сколько клиентов принимается на каждой итерации сетевого цикла. По умолчанию 0 (без ограничений), что подходит большинству пользователей. Это параметр тонкой настройки для контроля пропускной способности сетевого цикла при высокой нагрузке.
### net_throttle_action
-Определяет, сколько запросов обрабатывается на каждой итерации сетевого цикла. По умолчанию 0 (без ограничений), что подходит для большинства пользователей. Это опция тонкой настройки для контроля пропускной способности сетевого цикла в условиях высокой нагрузки.
+Определяет, сколько запросов обрабатывается на каждой итерации сетевого цикла. По умолчанию 0 (без ограничений), что подходит большинству пользователей. Это параметр тонкой настройки для контроля пропускной способности сетевого цикла при высокой нагрузке.
### network_timeout
Таймаут чтения/записи запроса клиента сети, в секундах (или с использованием [special_suffixes](../Server_settings/Special_suffixes.md)). Необязательно, по умолчанию 5 секунд. `searchd` принудительно закроет соединение клиента, если тот не отправит запрос или не прочитает результат в течение этого таймаута.
-Обратите внимание также на параметр [reset_network_timeout_on_packet](../Server_settings/Searchd.md#reset_network_timeout_on_packet). Этот параметр изменяет поведение `network_timeout` с применения к всему `query` или `result` на применение к отдельным пакетам. Обычно запрос/результат помещается в один или два пакета. Однако в случаях, когда требуется большой объем данных, этот параметр может быть незаменим для поддержания активных операций.
+Обратите внимание также на параметр [reset_network_timeout_on_packet](../Server_settings/Searchd.md#reset_network_timeout_on_packet). Этот параметр изменяет поведение `network_timeout` с применения к всему `query` или `result` на применение к отдельным пакетам. Обычно запрос/результат помещается в один или два пакета. Однако в случаях, когда требуется большой объём данных, этот параметр может быть незаменим для поддержания активных операций.
@@ -959,8 +967,8 @@ network_timeout = 10s
Этот параметр позволяет указать сетевой адрес узла. По умолчанию он установлен в адрес репликации [listen](../Server_settings/Searchd.md#listen). Это правильно в большинстве случаев; однако бывают ситуации, когда его нужно указать вручную:
* Узел за файрволом
-* Включен сетевой транслятор адресов (NAT)
-* Развертывания в контейнерах, таких как Docker или облачные развертывания
+* Включён сетевой транслятор адресов (NAT)
+* Развёртывания в контейнерах, таких как Docker или облачные развёртывания
* Кластеры с узлами в более чем одном регионе
@@ -977,7 +985,7 @@ node_address = 10.101.0.10
### not_terms_only_allowed
-Этот параметр определяет, разрешать ли запросы, содержащие только оператор [отрицания](../Searching/Full_text_matching/Operators.md#Negation-operator) полнотекстового поиска. Необязательно, по умолчанию 0 (запросы с только оператором NOT считаются ошибочными).
+Этот параметр определяет, разрешать ли запросы, содержащие только оператор [отрицания](../Searching/Full_text_matching/Operators.md#Negation-operator) полнотекстового поиска. Необязательно, по умолчанию 0 (запрещать запросы с только оператором NOT).
@@ -993,7 +1001,7 @@ not_terms_only_allowed = 1
### optimize_cutoff
-Устанавливает порог сжатия таблицы по умолчанию. Подробнее здесь — [Number of optimized disk chunks](../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks). Этот параметр можно переопределить с помощью опции на запрос [cutoff](../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks). Также его можно динамически изменить через [SET GLOBAL](../Server_settings/Setting_variables_online.md#SET).
+Устанавливает порог сжатия таблицы по умолчанию. Подробнее здесь — [Number of optimized disk chunks](../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks). Этот параметр можно переопределить с помощью опции запроса [cutoff](../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks). Также его можно изменить динамически через [SET GLOBAL](../Server_settings/Setting_variables_online.md#SET).
##### Пример:
@@ -1010,7 +1018,7 @@ optimize_cutoff = 4
Этот параметр определяет максимальное количество одновременных постоянных соединений с удалёнными [persistent agents](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md). Каждый раз, когда агент, определённый в `agent_persistent`, подключается, мы пытаемся повторно использовать существующее соединение (если оно есть) или подключиться и сохранить соединение для будущего использования. Однако в некоторых случаях имеет смысл ограничить количество таких постоянных соединений. Эта директива задаёт лимит. Она влияет на количество соединений с хостом каждого агента во всех распределённых таблицах.
-Рекомендуется установить значение равным или меньше опции [max_connections](../Server_settings/Searchd.md#max_connections) в конфиге агента.
+Рекомендуется установить значение равным или меньше опции [max_connections](../Server_settings/Searchd.md#max_connections) в конфигурации агента.
##### Пример:
@@ -1028,8 +1036,8 @@ persistent_connections_limit = 29 # assume that each host of agents has max_conn
pid_file — обязательный параметр конфигурации в Manticore search, который указывает путь к файлу, где хранится идентификатор процесса сервера `searchd`.
-Файл с идентификатором процесса searchd пересоздаётся и блокируется при запуске, и содержит идентификатор главного процесса сервера, пока сервер работает. При остановке сервера файл удаляется.
-Назначение этого файла — позволить Manticore выполнять различные внутренние задачи, такие как проверка, запущен ли уже экземпляр `searchd`, остановка `searchd` и уведомление о необходимости ротации таблиц. Файл также может использоваться внешними скриптами автоматизации.
+Файл с идентификатором процесса searchd пересоздаётся и блокируется при запуске, содержит идентификатор главного процесса сервера во время работы сервера. При остановке сервера файл удаляется.
+Цель этого файла — позволить Manticore выполнять различные внутренние задачи, такие как проверка, запущен ли уже экземпляр `searchd`, остановка `searchd` и уведомление его о необходимости ротировать таблицы. Файл также может использоваться для внешних автоматизированных скриптов.
@@ -1046,7 +1054,7 @@ pid_file = /run/manticore/searchd.pid
### predicted_time_costs
-Затраты для модели предсказания времени выполнения запроса, в наносекундах. Необязательно, по умолчанию `doc=64, hit=48, skip=2048, match=64`.
+Затраты для модели предсказания времени запроса, в наносекундах. Необязательно, по умолчанию `doc=64, hit=48, skip=2048, match=64`.
##### Пример:
@@ -1059,7 +1067,7 @@ predicted_time_costs = doc=128, hit=96, skip=4096, match=128
-Прерывание запросов до их завершения на основе времени выполнения (с помощью настройки максимального времени запроса) — это хорошая страховка, но она имеет свой недостаток: неопределённые (нестабильные) результаты. То есть, если повторить один и тот же (сложный) поисковый запрос с ограничением по времени несколько раз, ограничение времени будет достигаться на разных этапах, и вы получите *разные* наборы результатов.
+Прерывание запросов до их завершения на основе времени выполнения (с помощью настройки максимального времени запроса) — это хороший страховочный механизм, но он имеет присущий недостаток: неопределённые (нестабильные) результаты. То есть, если вы несколько раз повторите один и тот же (сложный) поисковый запрос с ограничением по времени, лимит времени будет достигнут на разных этапах, и вы получите *разные* наборы результатов.
##### SQL:
@@ -1076,7 +1084,7 @@ SetMaxQueryTime()
```
-Существует опция, [SELECT … OPTION max_predicted_time](../Searching/Options.md#max_predicted_time), которая позволяет ограничить время выполнения запроса *и* получить стабильные, повторяемые результаты. Вместо того чтобы регулярно проверять текущее фактическое время во время выполнения запроса, что является неопределённым, она предсказывает текущее время выполнения с помощью простой линейной модели:
+Существует опция, [SELECT … OPTION max_predicted_time](../Searching/Options.md#max_predicted_time), которая позволяет ограничить время запроса *и* получить стабильные, повторяемые результаты. Вместо регулярной проверки текущего времени во время выполнения запроса, что является неопределённым, она предсказывает текущее время выполнения с помощью простой линейной модели:
```ini
predicted_time =
@@ -1086,19 +1094,19 @@ predicted_time =
match_cost * found_matches
```
-Запрос затем прерывается досрочно, когда `predicted_time` достигает заданного предела.
+Запрос затем прерывается досрочно, когда `predicted_time` достигает заданного лимита.
-Конечно, это не жёсткое ограничение на фактическое затраченное время (однако это жёсткое ограничение на количество выполненной *обработки*), и простая линейная модель ни в коем случае не является идеально точной. Поэтому реальное время по часам *может* быть как ниже, так и выше целевого предела. Тем не менее, погрешности вполне приемлемы: например, в наших экспериментах с целевым лимитом 100 мс большинство тестовых запросов попадали в диапазон от 95 до 105 мс, и *все* запросы были в диапазоне от 80 до 120 мс. Также, в качестве приятного побочного эффекта, использование смоделированного времени запроса вместо измерения фактического времени выполнения приводит к некоторому уменьшению количества вызовов gettimeofday().
+Конечно, это не жёсткое ограничение на фактическое затраченное время (однако это жёсткое ограничение на количество выполненной *обработки*), и простая линейная модель ни в коем случае не является идеально точной. Поэтому реальное время по часам *может* быть как ниже, так и выше целевого лимита. Однако погрешности вполне приемлемы: например, в наших экспериментах с целевым лимитом 100 мс большинство тестовых запросов попадали в диапазон от 95 до 105 мс, а *все* запросы — в диапазон от 80 до 120 мс. Также, приятным побочным эффектом является то, что использование смоделированного времени запроса вместо измерения фактического времени выполнения приводит к некоторому уменьшению количества вызовов gettimeofday().
-Нет двух одинаковых моделей и марок серверов, поэтому директива `predicted_time_costs` позволяет настроить затраты для вышеуказанной модели. Для удобства они заданы целыми числами, измеряемыми в наносекундах. (Лимит в max_predicted_time считается в миллисекундах, и указывать значения затрат как 0.000128 мс вместо 128 нс более подвержено ошибкам.) Не обязательно указывать все четыре значения затрат сразу, так как пропущенные будут иметь значения по умолчанию. Однако мы настоятельно рекомендуем указывать все для удобочитаемости.
+Нет двух одинаковых моделей и производителей серверов, поэтому директива `predicted_time_costs` позволяет настроить затраты для вышеуказанной модели. Для удобства они заданы целыми числами, считающимися в наносекундах. (Лимит в max_predicted_time считается в миллисекундах, и указывать значения затрат как 0.000128 мс вместо 128 нс более подвержено ошибкам.) Не обязательно указывать все четыре значения затрат сразу, пропущенные примут значения по умолчанию. Однако мы настоятельно рекомендуем указывать все для удобочитаемости.
### preopen_tables
-Директива конфигурации preopen_tables указывает, следует ли принудительно предварительно открывать все таблицы при запуске. Значение по умолчанию — 1, что означает, что все таблицы будут предварительно открыты независимо от настройки [preopen](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Other-performance-related-settings) для каждой таблицы. Если установлено в 0, то могут применяться настройки для каждой таблицы, которые по умолчанию равны 0.
+Директива конфигурации preopen_tables указывает, следует ли принудительно предварительно открывать все таблицы при запуске. Значение по умолчанию — 1, что означает, что все таблицы будут предварительно открыты независимо от настройки [preopen](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Other-performance-related-settings) для каждой таблицы. Если установлено в 0, будут применяться настройки для каждой таблицы, которые по умолчанию равны 0.
-Предварительное открытие таблиц может предотвратить гонки между поисковыми запросами и ротациями, которые могут иногда приводить к сбоям запросов. Однако это также использует больше дескрипторов файлов. В большинстве сценариев рекомендуется предварительно открывать таблицы.
+Предварительное открытие таблиц может предотвратить гонки между поисковыми запросами и ротациями, которые иногда могут приводить к сбоям запросов. Однако это также использует больше дескрипторов файлов. В большинстве сценариев рекомендуется предварительно открывать таблицы.
Вот пример конфигурации:
@@ -1115,13 +1123,13 @@ preopen_tables = 1
### pseudo_sharding
-Опция конфигурации pseudo_sharding включает параллелизацию поисковых запросов к локальным plain и real-time таблицам, независимо от того, запрашиваются ли они напрямую или через распределённую таблицу. Эта функция автоматически параллелит запросы до количества потоков, указанного в `searchd.threads` # потоков.
+Опция конфигурации pseudo_sharding включает параллелизацию поисковых запросов к локальным обычным и реальным таблицам, независимо от того, запрашиваются ли они напрямую или через распределённую таблицу. Эта функция автоматически параллелит запросы до количества потоков, указанного в `searchd.threads` # потоков.
Обратите внимание, что если ваши рабочие потоки уже заняты, потому что у вас:
* высокая конкуренция запросов
* физическое шардинг любого типа:
- - распределённая таблица из нескольких plain/real-time таблиц
- - real-time таблица, состоящая из слишком большого количества дисковых чанков
+ - распределённая таблица из нескольких обычных/реальных таблиц
+ - реальная таблица, состоящая из слишком большого количества дисковых чанков
то включение pseudo_sharding может не дать никаких преимуществ и даже привести к небольшому снижению пропускной способности. Если вы отдаёте приоритет более высокой пропускной способности над меньшей задержкой, рекомендуется отключить эту опцию.
@@ -1140,9 +1148,9 @@ pseudo_sharding = 0
### replication_connect_timeout
-Директива `replication_connect_timeout` задаёт тайм-аут подключения к удалённому узлу. По умолчанию значение предполагается в миллисекундах, но может иметь [другой суффикс](../Server_settings/Special_suffixes.md). Значение по умолчанию — 1000 (1 секунда).
+Директива `replication_connect_timeout` определяет тайм-аут для подключения к удалённому узлу. По умолчанию значение предполагается в миллисекундах, но может иметь [другой суффикс](../Server_settings/Special_suffixes.md). Значение по умолчанию — 1000 (1 секунда).
-При подключении к удалённому узлу Manticore будет ждать не более этого времени для успешного завершения подключения. Если тайм-аут достигнут, но соединение не установлено, и включены `retries`, будет выполнена повторная попытка.
+При подключении к удалённому узлу Manticore будет ждать не более этого времени для успешного установления соединения. Если тайм-аут достигнут, но соединение не установлено, и включены `retries`, будет предпринята повторная попытка.
### replication_query_timeout
@@ -1159,12 +1167,12 @@ pseudo_sharding = 0
### replication_retry_delay
-Этот параметр — целое число в миллисекундах (или [special_suffixes](../Server_settings/Special_suffixes.md)), задающее задержку перед повторной попыткой запроса к удалённому узлу в случае сбоя во время репликации. Это значение актуально только при ненулевом значении. Значение по умолчанию — 500.
+Этот параметр является целым числом в миллисекундах (или [special_suffixes](../Server_settings/Special_suffixes.md)), который задает задержку перед повторной попыткой Manticore выполнить запрос к удаленному узлу в случае сбоя во время репликации. Это значение имеет значение только при указании ненулевого значения. Значение по умолчанию — 500.
### qcache_max_bytes
-Эта конфигурация задаёт максимальный объём оперативной памяти, выделяемой для кэшированных наборов результатов в байтах. Значение по умолчанию — 16777216, что эквивалентно 16 мегабайтам. Если значение установлено в 0, кэш запросов отключается. Для получения дополнительной информации о кэше запросов смотрите [query cache](../Searching/Query_cache.md).
+Эта настройка задает максимальный объем оперативной памяти, выделяемой для кэшированных наборов результатов в байтах. Значение по умолчанию — 16777216, что эквивалентно 16 мегабайтам. Если значение установлено в 0, кэш запросов отключается. Для получения дополнительной информации о кэше запросов, пожалуйста, обратитесь к разделу [query cache](../Searching/Query_cache.md).
@@ -1180,12 +1188,12 @@ qcache_max_bytes = 16777216
### qcache_thresh_msec
-Целое число в миллисекундах. Минимальный порог времени выполнения запроса, при котором результат будет кэшироваться. По умолчанию 3000, или 3 секунды. 0 означает кэшировать всё. Подробнее см. [query cache](../Searching/Query_cache.md). Это значение также может быть выражено с помощью временных [special_suffixes](../Server_settings/Special_suffixes.md), но используйте их с осторожностью и не путайте с названием самого параметра, содержащим '_msec'.
+Целое число, в миллисекундах. Минимальный порог времени выполнения запроса для кэширования результата. По умолчанию 3000, или 3 секунды. 0 означает кэшировать всё. Подробности смотрите в разделе [query cache](../Searching/Query_cache.md). Это значение также может быть выражено с помощью временных [special_suffixes](../Server_settings/Special_suffixes.md), но используйте это с осторожностью и не путайте с названием самого параметра, содержащим '_msec'.
### qcache_ttl_sec
-Целое число, в секундах. Период истечения срока действия для кэшированного набора результатов. По умолчанию 60, или 1 минута. Минимально возможное значение — 1 секунда. Подробности см. в разделе [query cache](../Searching/Query_cache.md). Это значение также может быть выражено с помощью временных [special_suffixes](../Server_settings/Special_suffixes.md), но используйте это с осторожностью и не путайте с названием самого значения, содержащим '_sec'.
+Целое число, в секундах. Период истечения срока действия кэшированного набора результатов. По умолчанию 60, или 1 минута. Минимально возможное значение — 1 секунда. Подробности смотрите в разделе [query cache](../Searching/Query_cache.md). Это значение также может быть выражено с помощью временных [special_suffixes](../Server_settings/Special_suffixes.md), но используйте это с осторожностью и не путайте с названием самого параметра, содержащим '_sec'.
### query_log_format
@@ -1193,7 +1201,7 @@ qcache_max_bytes = 16777216
Формат журнала запросов. Необязательно, допустимые значения — `plain` и `sphinxql`, по умолчанию `sphinxql`.
-Режим `sphinxql` записывает действительные SQL-запросы. Режим `plain` записывает запросы в простом текстовом формате (в основном подходит для чисто полнотекстовых случаев использования). Эта директива позволяет переключаться между двумя форматами при запуске поискового сервера. Формат журнала также можно изменить на лету, используя синтаксис `SET GLOBAL query_log_format=sphinxql`. Подробности см. в разделе [Query logging](../Logging/Query_logging.md).
+Режим `sphinxql` записывает валидные SQL-запросы. Режим `plain` записывает запросы в простом текстовом формате (в основном подходит для чисто полнотекстовых случаев использования). Эта директива позволяет переключаться между двумя форматами при запуске поискового сервера. Формат журнала также можно изменить на лету, используя синтаксис `SET GLOBAL query_log_format=sphinxql`. Подробности смотрите в разделе [Query logging](../Logging/Query_logging.md).
@@ -1208,12 +1216,12 @@ query_log_format = sphinxql
### query_log_min_msec
-Лимит (в миллисекундах), который предотвращает запись запроса в журнал запросов. Необязательно, по умолчанию 0 (все запросы записываются в журнал запросов). Эта директива указывает, что в журнал будут записываться только запросы с временем выполнения, превышающим указанный лимит (это значение также может быть выражено с помощью временных [special_suffixes](../Server_settings/Special_suffixes.md), но используйте это с осторожностью и не путайте с названием самого значения, содержащим `_msec`).
+Лимит (в миллисекундах), который предотвращает запись запроса в журнал запросов. Необязательно, по умолчанию 0 (все запросы записываются в журнал запросов). Эта директива указывает, что в журнал будут записываться только запросы с временем выполнения, превышающим указанный лимит (это значение также может быть выражено с помощью временных [special_suffixes](../Server_settings/Special_suffixes.md), но используйте это с осторожностью и не путайте с названием самого параметра, содержащим `_msec`).
### query_log
-Имя файла журнала запросов. Необязательно, по умолчанию пусто (не вести журнал запросов). Все поисковые запросы (например, SELECT ... но не INSERT/REPLACE/UPDATE запросы) будут записываться в этот файл. Формат описан в разделе [Query logging](../Logging/Query_logging.md). В случае формата 'plain' можно использовать 'syslog' в качестве пути к файлу журнала. В этом случае все поисковые запросы будут отправлены демону syslog с приоритетом `LOG_INFO`, с префиксом '[query]' вместо временной метки. Для использования опции syslog Manticore должен быть собран с опцией `-–with-syslog`.
+Имя файла журнала запросов. Необязательно, по умолчанию пусто (запросы не логируются). Все поисковые запросы (например, SELECT ... но не INSERT/REPLACE/UPDATE) будут записываться в этот файл. Формат описан в разделе [Query logging](../Logging/Query_logging.md). В случае формата 'plain' можно использовать 'syslog' в качестве пути к файлу журнала. В этом случае все поисковые запросы будут отправлены демону syslog с приоритетом `LOG_INFO`, с префиксом '[query]' вместо временной метки. Для использования опции syslog Manticore должен быть собран с опцией `-–with-syslog`.
@@ -1230,8 +1238,8 @@ query_log = /var/log/query.log
### query_log_mode
-Директива query_log_mode позволяет установить разные права доступа для файлов журнала searchd и журнала запросов. По умолчанию эти файлы журнала создаются с правами 600, что означает, что читать их могут только пользователь, под которым запущен сервер, и пользователи root.
-Эта директива может быть полезна, если вы хотите разрешить другим пользователям читать файлы журнала, например, решениям для мониторинга, работающим под не-root пользователями.
+Директива query_log_mode позволяет задать разные права доступа для файлов searchd и журнала запросов. По умолчанию эти файлы создаются с правами 600, что означает, что читать их могут только пользователь, под которым запущен сервер, и пользователи root.
+Эта директива может быть полезна, если вы хотите разрешить другим пользователям читать журналы, например, решениям для мониторинга, работающим под непривилегированными пользователями.
##### Пример:
@@ -1248,7 +1256,7 @@ query_log_mode = 666
Директива read_buffer_docs управляет размером буфера чтения на ключевое слово для списков документов. Для каждого вхождения ключевого слова в каждом поисковом запросе существует два связанных буфера чтения: один для списка документов и один для списка попаданий. Эта настройка позволяет контролировать размер буфера списка документов.
-Больший размер буфера может увеличить использование ОЗУ на запрос, но возможно уменьшит время ввода-вывода. Имеет смысл устанавливать большие значения для медленных хранилищ, но для хранилищ с высокой производительностью IOPS следует экспериментировать с малыми значениями.
+Больший размер буфера может увеличить использование оперативной памяти на запрос, но возможно уменьшит время ввода-вывода. Имеет смысл устанавливать большие значения для медленных хранилищ, а для хранилищ с высокой производительностью IOPS экспериментировать следует в области низких значений.
Значение по умолчанию — 256K, минимальное значение — 8K. Вы также можете установить [read_buffer_docs](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#read_buffer_docs) для каждой таблицы отдельно, что переопределит настройки на уровне сервера.
@@ -1267,7 +1275,7 @@ read_buffer_docs = 128K
### read_buffer_hits
-Директива read_buffer_hits задает размер буфера чтения на ключевое слово для списков попаданий в поисковых запросах. По умолчанию размер 256K, минимальное значение 8K. Для каждого вхождения ключевого слова в поисковом запросе существует два связанных буфера чтения: один для списка документов и один для списка попаданий. Увеличение размера буфера может увеличить использование ОЗУ на запрос, но уменьшить время ввода-вывода. Для медленных хранилищ имеет смысл использовать большие размеры буфера, а для хранилищ с высокой производительностью IOPS следует экспериментировать с малыми значениями.
+Директива read_buffer_hits задает размер буфера чтения на ключевое слово для списков попаданий в поисковых запросах. По умолчанию размер 256K, минимальное значение 8K. Для каждого вхождения ключевого слова в поисковом запросе существует два связанных буфера чтения: один для списка документов и один для списка попаданий. Увеличение размера буфера может увеличить использование оперативной памяти на запрос, но уменьшить время ввода-вывода. Для медленных хранилищ имеет смысл использовать большие размеры буфера, а для хранилищ с высокой производительностью IOPS экспериментировать следует в области низких значений.
Эта настройка также может быть задана для каждой таблицы отдельно с помощью опции read_buffer_hits в [read_buffer_hits](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#read_buffer_hits), что переопределит настройку на уровне сервера.
@@ -1286,7 +1294,7 @@ read_buffer_hits = 128K
Размер чтения без подсказок. Необязательно, по умолчанию 32K, минимальное 1K
-При выполнении запросов некоторые чтения заранее точно знают, сколько данных нужно прочитать, а некоторые — нет. Наиболее заметно, что размер списка попаданий в настоящее время заранее не известен. Эта настройка позволяет контролировать, сколько данных читать в таких случаях. Она влияет на время ввода-вывода списка попаданий, уменьшая его для списков, больших, чем размер чтения без подсказок, но увеличивая для меньших списков. Она **не** влияет на использование ОЗУ, так как буфер чтения уже будет выделен. Поэтому она не должна быть больше, чем read_buffer.
+При выполнении запроса некоторые чтения заранее точно знают, сколько данных нужно прочитать, но некоторые пока не знают. Наиболее заметно, что размер списка попаданий (hit list) в настоящее время заранее не известен. Этот параметр позволяет контролировать, сколько данных читать в таких случаях. Он влияет на время ввода-вывода списка попаданий, уменьшая его для списков, больших, чем размер чтения без подсказки, но увеличивая для меньших списков. Он **не** влияет на использование ОЗУ, поскольку буфер чтения уже будет выделен. Поэтому он не должен быть больше, чем read_buffer.
@@ -1304,12 +1312,12 @@ read_unhinted = 32K
Уточняет поведение сетевых таймаутов (таких как `network_timeout` и `agent_query_timeout`).
-Если установлено в 0, таймауты ограничивают максимальное время отправки всего запроса/запроса.
+Если установлено в 0, таймауты ограничивают максимальное время на отправку всего запроса/запроса.
Если установлено в 1 (по умолчанию), таймауты ограничивают максимальное время между сетевой активностью.
-При репликации узлу может потребоваться отправить большой файл (например, 100 ГБ) другому узлу. Предположим, что сеть может передавать данные со скоростью 1 ГБ/с, с серией пакетов по 4-5 МБ каждый. Для передачи всего файла потребуется 100 секунд. Таймаут по умолчанию в 5 секунд позволит передать только 5 ГБ, после чего соединение будет разорвано. Увеличение таймаута могло бы быть обходным решением, но это не масштабируемо (например, следующий файл может быть 150 ГБ, что снова приведет к сбою). Однако при установленном по умолчанию `reset_network_timeout_on_packet` в 1 таймаут применяется не ко всей передаче, а к отдельным пакетам. Пока передача продолжается (и данные действительно принимаются по сети в течение периода таймаута), соединение поддерживается. Если передача застревает, и таймаут происходит между пакетами, соединение будет разорвано.
+При репликации узлу может потребоваться отправить большой файл (например, 100 ГБ) другому узлу. Предположим, что сеть может передавать данные со скоростью 1 ГБ/с, с серией пакетов по 4-5 МБ каждый. Для передачи всего файла потребуется 100 секунд. Таймаут по умолчанию в 5 секунд позволит передать только 5 ГБ, прежде чем соединение будет разорвано. Увеличение таймаута может быть обходным решением, но оно не масштабируется (например, следующий файл может быть 150 ГБ, что снова приведет к сбою). Однако при установленном по умолчанию `reset_network_timeout_on_packet` в 1 таймаут применяется не ко всей передаче, а к отдельным пакетам. Пока передача продолжается (и данные действительно принимаются по сети в течение периода таймаута), соединение поддерживается. Если передача застревает, и происходит таймаут между пакетами, соединение будет разорвано.
-Обратите внимание, что если вы настраиваете распределенную таблицу, каждый узел — как мастер, так и агенты — должен быть настроен. На стороне мастера влияет `agent_query_timeout`; на агентах — `network_timeout`.
+Обратите внимание, что если вы настраиваете распределённую таблицу, каждый узел — как мастер, так и агенты — должен быть настроен. На стороне мастера влияет `agent_query_timeout`; на агентах — `network_timeout`.
@@ -1327,9 +1335,9 @@ reset_network_timeout_on_packet = 0
### rt_flush_period
-Период проверки сброса чанков RAM RT-таблиц, в секундах (или [special_suffixes](../Server_settings/Special_suffixes.md)). Необязательно, по умолчанию 10 часов.
+Период проверки сброса чанков ОЗУ RT-таблиц, в секундах (или [special_suffixes](../Server_settings/Special_suffixes.md)). Необязательно, по умолчанию 10 часов.
-Активно обновляемые RT-таблицы, полностью помещающиеся в чанки RAM, могут приводить к постоянно растущим бинлогам, что влияет на использование диска и время восстановления после сбоев. С помощью этой директивы поисковый сервер выполняет периодические проверки сброса, и подходящие чанки RAM могут быть сохранены, что позволяет последующую очистку бинлогов. Подробнее см. в разделе [Binary logging](../Logging/Binary_logging.md).
+Активно обновляемые RT-таблицы, полностью помещающиеся в чанки ОЗУ, всё равно могут приводить к постоянно растущим бинарным журналам, что влияет на использование диска и время восстановления после сбоев. С помощью этой директивы поисковый сервер выполняет периодические проверки сброса, и подходящие чанки ОЗУ могут быть сохранены, что позволяет последующую очистку бинарных журналов. Подробнее см. в разделе [Binary logging](../Logging/Binary_logging.md).
##### Пример:
@@ -1347,7 +1355,7 @@ rt_flush_period = 3600 # 1 hour
Максимальное количество операций ввода-вывода (в секунду), которые поток слияния чанков RT может начать. Необязательно, по умолчанию 0 (без ограничений).
-Эта директива позволяет ограничить влияние операций ввода-вывода, возникающих из-за операторов `OPTIMIZE`. Гарантируется, что все операции оптимизации RT не будут генерировать больше дисковых IOPS (операций ввода-вывода в секунду), чем заданный лимит. Ограничение rt_merge_iops может уменьшить деградацию производительности поиска, вызванную слиянием.
+Эта директива позволяет ограничить влияние ввода-вывода, возникающее из-за операторов `OPTIMIZE`. Гарантируется, что все операции оптимизации RT не будут генерировать больше дисковых IOPS (операций ввода-вывода в секунду), чем заданный лимит. Ограничение rt_merge_iops может уменьшить деградацию производительности поиска, вызванную слиянием.
##### Пример:
@@ -1364,7 +1372,7 @@ rt_merge_iops = 40
Максимальный размер операции ввода-вывода, которую поток слияния чанков RT может начать. Необязательно, по умолчанию 0 (без ограничений).
-Эта директива позволяет ограничить влияние операций ввода-вывода, возникающих из-за операторов `OPTIMIZE`. Операции ввода-вывода, превышающие этот лимит, будут разбиты на две или более операций, которые затем будут учитываться как отдельные операции в рамках лимита [rt_merge_iops](../Server_settings/Searchd.md#rt_merge_iops). Таким образом, гарантируется, что все операции оптимизации не будут генерировать более (rt_merge_iops * rt_merge_maxiosize) байт дискового ввода-вывода в секунду.
+Эта директива позволяет ограничить влияние ввода-вывода, возникающее из-за операторов `OPTIMIZE`. Операции ввода-вывода, превышающие этот лимит, будут разбиты на две или более операций, которые затем будут учитываться как отдельные операции ввода-вывода в отношении лимита [rt_merge_iops](../Server_settings/Searchd.md#rt_merge_iops). Таким образом, гарантируется, что все операции оптимизации не будут генерировать более (rt_merge_iops * rt_merge_maxiosize) байт дискового ввода-вывода в секунду.
@@ -1381,28 +1389,28 @@ rt_merge_maxiosize = 1M
### seamless_rotate
-Предотвращает зависания `searchd` при ротации таблиц с огромным объемом данных для предварительного кэширования. Необязательно, по умолчанию 1 (включена бесшовная ротация). В системах Windows бесшовная ротация по умолчанию отключена.
+Предотвращает зависания `searchd` при ротации таблиц с огромным объёмом данных для предварительного кэширования. Необязательно, по умолчанию 1 (включена бесшовная ротация). В системах Windows бесшовная ротация по умолчанию отключена.
-Таблицы могут содержать данные, которые необходимо предварительно кэшировать в RAM. В настоящее время файлы `.spa`, `.spb`, `.spi` и `.spm` полностью предварительно кэшируются (они содержат данные атрибутов, данные блоб-атрибутов, таблицу ключевых слов и карту удаленных строк соответственно). Без бесшовной ротации ротация таблицы старается использовать как можно меньше RAM и работает следующим образом:
+Таблицы могут содержать данные, которые нужно предварительно кэшировать в ОЗУ. В настоящее время файлы `.spa`, `.spb`, `.spi` и `.spm` полностью предварительно кэшируются (они содержат данные атрибутов, данные блоб-атрибутов, таблицу ключевых слов и карту удалённых строк соответственно). Без бесшовной ротации ротация таблицы пытается использовать как можно меньше ОЗУ и работает следующим образом:
1. Новые запросы временно отклоняются (с кодом ошибки "retry");
-2. `searchd` ожидает завершения всех текущих запросов;
-3. Старая таблица освобождается, и ее файлы переименовываются;
-4. Файлы новой таблицы переименовываются, и выделяется необходимая RAM;
-5. Данные атрибутов и словаря новой таблицы предварительно загружаются в RAM;
+2. `searchd` ждёт завершения всех текущих запросов;
+3. Старая таблица освобождается, и её файлы переименовываются;
+4. Файлы новой таблицы переименовываются, и выделяется необходимая ОЗУ;
+5. Данные атрибутов и словаря новой таблицы предварительно загружаются в ОЗУ;
6. `searchd` возобновляет обслуживание запросов из новой таблицы.
Однако если данных атрибутов или словаря много, этап предварительной загрузки может занять заметное время — до нескольких минут при загрузке файлов размером 1-5+ ГБ.
-При включенной бесшовной ротации ротация работает следующим образом:
+При включённой бесшовной ротации ротация работает так:
-1. Выделяется RAM для хранения новой таблицы;
-2. Данные атрибутов и словаря новой таблицы асинхронно предварительно загружаются в RAM;
+1. Выделяется ОЗУ для хранения новой таблицы;
+2. Данные атрибутов и словаря новой таблицы асинхронно предварительно загружаются в ОЗУ;
3. При успешной загрузке старая таблица освобождается, и файлы обеих таблиц переименовываются;
4. При неудаче новая таблица освобождается;
5. В любой момент запросы обслуживаются либо из старой, либо из новой копии таблицы.
-Бесшовная ротация требует большего пикового использования памяти во время ротации (поскольку обе копии данных `.spa/.spb/.spi/.spm` — старая и новая — должны находиться в RAM во время предварительной загрузки новой копии). Среднее использование памяти остается прежним.
+Бесшовная ротация требует большего пикового использования памяти во время ротации (поскольку обе копии данных `.spa/.spb/.spi/.spm` должны находиться в ОЗУ во время предварительной загрузки новой копии). Среднее использование остаётся прежним.
@@ -1418,12 +1426,12 @@ seamless_rotate = 1
### secondary_index_block_cache
-Этот параметр задает размер кэша блоков, используемого вторичными индексами. Необязательно, по умолчанию 8 МБ. Когда вторичные индексы работают с фильтрами, содержащими много значений (например, фильтры IN()), они читают и обрабатывают метаданные блоков для этих значений.
-В объединенных запросах этот процесс повторяется для каждой партии строк из левой таблицы, и каждая партия может повторно читать одни и те же метаданные в рамках одного объединенного запроса. Это может значительно повлиять на производительность. Кэш метаданных блоков хранит эти блоки в памяти, чтобы они
-могли быть повторно использованы последующими партиями.
+Этот параметр задает размер кэш-блока, используемого вторичными индексами. Он является необязательным, по умолчанию — 8 МБ. Когда вторичные индексы работают с фильтрами, содержащими много значений (например, фильтры IN()), они читают и обрабатывают метаданные блоков для этих значений.
+В объединённых запросах этот процесс повторяется для каждой партии строк из левой таблицы, и каждая партия может повторно читать одни и те же метаданные в рамках одного объединённого запроса. Это может значительно повлиять на производительность. Кэш метаданных блоков хранит эти блоки в памяти, чтобы
+их можно было повторно использовать последующими партиями.
-Кэш используется только в объединенных запросах и не влияет на не объединенные запросы. Обратите внимание, что ограничение размера кэша применяется на каждый атрибут и на каждый вторичный индекс. Каждый атрибут в каждом дисковом чанке работает в рамках этого ограничения. В худшем случае общее использование памяти
-можно оценить, умножив ограничение на количество дисковых чанков и количество атрибутов, используемых в объединенных запросах.
+Кэш используется только в объединённых запросах и не влияет на не объединённые запросы. Обратите внимание, что ограничение размера кэша применяется на каждый атрибут и на каждый вторичный индекс. Каждый атрибут в каждом дисковом чанке работает в рамках этого ограничения. В худшем случае общее использование
+памяти можно оценить, умножив ограничение на количество дисковых чанков и количество атрибутов, используемых в объединённых запросах.
Установка `secondary_index_block_cache = 0` отключает кэш.
@@ -1441,14 +1449,14 @@ secondary_index_block_cache = 16M
### secondary_indexes
-This option enables/disables the use of secondary indexes for search queries. It is optional, and the default is 1 (enabled). Note that you don't need to enable it for indexing as it is always enabled as long as the [Manticore Columnar Library](https://github.com/manticoresoftware/columnar) is installed. The latter is also required for using the indexes when searching. There are three modes available:
+Этот параметр включает/отключает использование вторичных индексов для поисковых запросов. Он необязателен, по умолчанию — 1 (включено). Обратите внимание, что включать его для индексации не нужно, так как он всегда включен, если установлена [Manticore Columnar Library](https://github.com/manticoresoftware/columnar). Последняя также требуется для использования индексов при поиске. Доступны три режима:
-* `0`: Disable the use of secondary indexes on search. They can be enabled for individual queries using [analyzer hints](../Searching/Options.md#Query-optimizer-hints)
-* `1`: Enable the use of secondary indexes on search. They can be disabled for individual queries using [analyzer hints](../Searching/Options.md#Query-optimizer-hints)
-* `force`: Same as enable, but any errors during the loading of secondary indexes will be reported, and the whole index will not be loaded into the daemon.
+* `0`: Отключить использование вторичных индексов при поиске. Их можно включить для отдельных запросов с помощью [подсказок анализатора](../Searching/Options.md#Query-optimizer-hints)
+* `1`: Включить использование вторичных индексов при поиске. Их можно отключить для отдельных запросов с помощью [подсказок анализатора](../Searching/Options.md#Query-optimizer-hints)
+* `force`: То же, что и включение, но любые ошибки при загрузке вторичных индексов будут зафиксированы, и весь индекс не будет загружен в демон.
-##### Example:
+##### Пример:
@@ -1461,11 +1469,11 @@ secondary_indexes = 1
### server_id
-Integer number that serves as a server identifier used as a seed to generate a unique short UUID for nodes that are part of a replication cluster. The server_id must be unique across the nodes of a cluster and in the range from 0 to 127. If server_id is not set, it is calculated as a hash of the MAC address and the path to the PID file or a random number will be used as a seed for the short UUID.
+Целое число, служащее идентификатором сервера, используемое как зерно для генерации уникального короткого UUID для узлов, входящих в кластер репликации. server_id должен быть уникальным среди узлов кластера и находиться в диапазоне от 0 до 127. Если server_id не установлен, он вычисляется как хэш MAC-адреса и пути к PID-файлу или используется случайное число в качестве зерна для короткого UUID.
-##### Example:
+##### Пример:
@@ -1478,13 +1486,13 @@ server_id = 1
### shutdown_timeout
-`searchd --stopwait` waiting time, in seconds (or [special_suffixes](../Server_settings/Special_suffixes.md)). Optional, default is 60 seconds.
+Время ожидания `searchd --stopwait` в секундах (или [special_suffixes](../Server_settings/Special_suffixes.md)). Необязательно, по умолчанию 60 секунд.
-When you run `searchd --stopwait` your server needs to perform some activities before stopping, such as finishing queries, flushing RT RAM chunks, flushing attributes, and updating the binlog. These tasks require some time. `searchd --stopwait` will wait up to `shutdown_time` seconds for the server to finish its jobs. The suitable time depends on your table size and load.
+Когда вы запускаете `searchd --stopwait`, серверу нужно выполнить некоторые действия перед остановкой, такие как завершение запросов, сброс RT RAM чанков, сброс атрибутов и обновление binlog. Эти задачи требуют времени. `searchd --stopwait` будет ждать до `shutdown_time` секунд, пока сервер не завершит работу. Подходящее время зависит от размера таблицы и нагрузки.
-##### Example:
+##### Пример:
@@ -1496,34 +1504,34 @@ shutdown_timeout = 3m # wait for up to 3 minutes
### shutdown_token
-SHA1 hash of the password required to invoke the 'shutdown' command from a VIP Manticore SQL connection. Without it,[debug](../Reporting_bugs.md#DEBUG) 'shutdown' subcommand will never cause the server to stop. Note that such simple hashing should not be considered strong protection, as we don't use a salted hash or any kind of modern hash function. It is intended as a fool-proof measure for housekeeping daemons in a local network.
+SHA1-хэш пароля, необходимого для вызова команды 'shutdown' из VIP Manticore SQL соединения. Без него,[debug](../Reporting_bugs.md#DEBUG) подкоманда 'shutdown' никогда не остановит сервер. Обратите внимание, что такое простое хеширование не следует считать надежной защитой, так как мы не используем соль или современные хеш-функции. Это предназначено как мера предосторожности для управляющих демонов в локальной сети.
### snippets_file_prefix
-A prefix to prepend to the local file names when generating snippets. Optional, default is the current working folder.
+Префикс, который добавляется к локальным именам файлов при генерации сниппетов. Необязательно, по умолчанию — текущая рабочая папка.
-This prefix can be used in distributed snippets generation along with `load_files` or `load_files_scattered` options.
+Этот префикс можно использовать при распределённой генерации сниппетов вместе с опциями `load_files` или `load_files_scattered`.
-Note that this is a prefix and **not** a path! This means that if a prefix is set to "server1" and the request refers to "file23", `searchd` will attempt to open "server1file23" (all of that without quotes). So, if you need it to be a path, you have to include the trailing slash.
+Обратите внимание, что это префикс, а **не** путь! Это означает, что если префикс установлен в "server1", а запрос ссылается на "file23", `searchd` попытается открыть "server1file23" (всё это без кавычек). Поэтому, если нужен путь, необходимо включить завершающий слэш.
-After constructing the final file path, the server unwinds all relative dirs and compares the final result with the value of `snippet_file_prefix`. If the result does not begin with the prefix, such a file will be rejected with an error message.
+После построения окончательного пути к файлу сервер разворачивает все относительные каталоги и сравнивает результат с значением `snippet_file_prefix`. Если результат не начинается с префикса, такой файл будет отклонён с сообщением об ошибке.
-For example, if you set it to `/mnt/data` and someone calls snippet generation with the file `../../../etc/passwd` as the source, they will get the error message:
+Например, если установить `/mnt/data` и кто-то вызовет генерацию сниппетов с файлом `../../../etc/passwd` в качестве источника, он получит сообщение об ошибке:
`File '/mnt/data/../../../etc/passwd' escapes '/mnt/data/' scope`
-instead of the content of the file.
+вместо содержимого файла.
-Also, with a non-set parameter and reading `/etc/passwd`, it will actually read /daemon/working/folder/etc/passwd since the default for the parameter is the server's working folder.
+Также, если параметр не установлен и читается `/etc/passwd`, фактически будет прочитан /daemon/working/folder/etc/passwd, так как по умолчанию параметр равен рабочей папке сервера.
-Note also that this is a local option; it does not affect the agents in any way. So you can safely set a prefix on a master server. The requests routed to the agents will not be affected by the master's setting. They will, however, be affected by the agent's own settings.
+Обратите внимание, что это локальная опция; она никак не влияет на агенты. Поэтому можно безопасно установить префикс на мастер-сервере. Запросы, направленные агентам, не будут затронуты настройкой мастера. Однако они будут затронуты собственными настройками агента.
-This might be useful, for instance, when the document storage locations (whether local storage or NAS mountpoints) are inconsistent across the servers.
+Это может быть полезно, например, когда расположения хранилищ документов (локальное хранилище или точки монтирования NAS) различаются на серверах.
-##### Example:
+##### Пример:
@@ -1532,20 +1540,20 @@ snippets_file_prefix = /mnt/common/server1/
```
-> **WARNING:** If you still want to access files from the FS root, you have to explicitly set `snippets_file_prefix` to empty value (by `snippets_file_prefix=` line), or to root (by `snippets_file_prefix=/`).
+> **ВНИМАНИЕ:** Если вы всё же хотите получить доступ к файлам из корня файловой системы, необходимо явно установить `snippets_file_prefix` в пустое значение (строкой `snippets_file_prefix=`) или в корень (строкой `snippets_file_prefix=/`).
### sphinxql_state
-Path to a file where the current SQL state will be serialized.
+Путь к файлу, в котором будет сериализовано текущее состояние SQL.
-On server startup, this file gets replayed. On eligible state changes (e.g., SET GLOBAL), this file gets rewritten automatically. This can prevent a hard-to-diagnose problem: If you load UDF functions but Manticore crashes, when it gets (automatically) restarted, your UDF and global variables will no longer be available. Using persistent state helps ensure a graceful recovery with no such surprises.
+При запуске сервера этот файл воспроизводится. При подходящих изменениях состояния (например, SET GLOBAL) этот файл автоматически перезаписывается. Это может предотвратить трудно диагностируемую проблему: если вы загружаете UDF-функции, но Manticore аварийно завершается, при (автоматическом) перезапуске ваши UDF и глобальные переменные больше не будут доступны. Использование постоянного состояния помогает обеспечить плавное восстановление без таких сюрпризов.
-`sphinxql_state` cannot be used to execute arbitrary commands, such as `CREATE TABLE`.
+`sphinxql_state` нельзя использовать для выполнения произвольных команд, таких как `CREATE TABLE`.
-##### Example:
+##### Пример:
@@ -1558,11 +1566,11 @@ sphinxql_state = uservars.sql
### sphinxql_timeout
-Maximum time to wait between requests (in seconds, or [special_suffixes](../Server_settings/Special_suffixes.md)) when using the SQL interface. Optional, default is 15 minutes.
+Максимальное время ожидания между запросами (в секундах или с [специальными суффиксами](../Server_settings/Special_suffixes.md)) при использовании SQL-интерфейса. Необязательно, по умолчанию 15 минут.
-##### Example:
+##### Пример:
@@ -1575,7 +1583,7 @@ sphinxql_timeout = 15m
### ssl_ca
-Path to the SSL Certificate Authority (CA) certificate file (also known as root certificate). Optional, default is empty. When not empty, the certificate in `ssl_cert` should be signed by this root certificate.
+Путь к файлу сертификата удостоверяющего центра SSL (CA) (также известного как корневой сертификат). Необязательно, по умолчанию пусто. Если не пусто, сертификат в `ssl_cert` должен быть подписан этим корневым сертификатом.
Сервер использует файл CA для проверки подписи на сертификате. Файл должен быть в формате PEM.
@@ -1631,9 +1639,9 @@ ssl_key = keys/server-key.pem
### subtree_docs_cache
-Максимальный размер кеша документов общего поддерева, на запрос. Необязательно, по умолчанию 0 (отключено).
+Максимальный размер кэша документов общего поддерева на запрос. Необязательно, по умолчанию 0 (отключено).
-Эта настройка ограничивает использование ОЗУ оптимизатором общего поддерева (см. [multi-queries](../Searching/Multi-queries.md)). Максимум столько ОЗУ будет потрачено на кеширование записей документов для каждого запроса. Установка лимита в 0 отключает оптимизатор.
+Этот параметр ограничивает использование ОЗУ оптимизатором общего поддерева (см. [мультизапросы](../Searching/Multi-queries.md)). Максимум столько ОЗУ будет потрачено на кэширование записей документов для каждого запроса. Установка лимита в 0 отключает оптимизатор.
@@ -1650,9 +1658,9 @@ subtree_docs_cache = 8M
### subtree_hits_cache
-Максимальный размер кеша попаданий общего поддерева, на запрос. Необязательно, по умолчанию 0 (отключено).
+Максимальный размер кэша попаданий общего поддерева на запрос. Необязательно, по умолчанию 0 (отключено).
-Эта настройка ограничивает использование ОЗУ оптимизатором общего поддерева (см. [multi-queries](../Searching/Multi-queries.md)). Максимум столько ОЗУ будет потрачено на кеширование вхождений ключевых слов (попаданий) для каждого запроса. Установка лимита в 0 отключает оптимизатор.
+Этот параметр ограничивает использование ОЗУ оптимизатором общего поддерева (см. [мультизапросы](../Searching/Multi-queries.md)). Максимум столько ОЗУ будет потрачено на кэширование вхождений ключевых слов (попаданий) для каждого запроса. Установка лимита в 0 отключает оптимизатор.
@@ -1668,16 +1676,16 @@ subtree_hits_cache = 16M
### threads
-Количество рабочих потоков (или размер пула потоков) для демона Manticore. Manticore создаёт такое количество потоков ОС при запуске, и они выполняют все задачи внутри демона, такие как выполнение запросов, создание сниппетов и т.д. Некоторые операции могут быть разбиты на подзадачи и выполняться параллельно, например:
+Количество рабочих потоков (или размер пула потоков) для демона Manticore. Manticore создаёт это количество потоков ОС при запуске, и они выполняют все задачи внутри демона, такие как выполнение запросов, создание сниппетов и т.д. Некоторые операции могут быть разбиты на подзадачи и выполняться параллельно, например:
* Поиск в таблице реального времени
* Поиск в распределённой таблице, состоящей из локальных таблиц
* Вызов перколяции запроса
* и другие
-По умолчанию установлено количество ядер CPU на сервере. Manticore создаёт потоки при запуске и держит их до остановки. Каждая подзадача может использовать один из потоков, когда это необходимо. Когда подзадача завершается, она освобождает поток, чтобы другая подзадача могла его использовать.
+По умолчанию установлено в количество ядер ЦП на сервере. Manticore создаёт потоки при запуске и сохраняет их до остановки. Каждая подзадача может использовать один из потоков, когда это необходимо. Когда подзадача завершается, она освобождает поток, чтобы другая подзадача могла его использовать.
-В случае интенсивной нагрузки типа I/O может иметь смысл установить значение выше количества ядер CPU.
+В случае интенсивной нагрузки типа ввода-вывода может иметь смысл установить значение выше количества ядер ЦП.
```ini
@@ -1691,11 +1699,11 @@ threads = 10
Максимальный размер стека для задачи (корутина, один поисковый запрос может вызвать несколько задач/корутин). Необязательно, по умолчанию 128K.
-Каждая задача имеет свой собственный стек размером 128K. При запуске запроса проверяется, сколько стека он требует. Если стандартных 128K достаточно, запрос просто обрабатывается. Если требуется больше, планируется другая задача с увеличенным стеком, которая продолжает обработку. Максимальный размер такого расширенного стека ограничен этой настройкой.
+Каждая задача имеет свой собственный стек размером 128K. При выполнении запроса проверяется, сколько стека он требует. Если стандартных 128K достаточно, запрос просто обрабатывается. Если требуется больше, планируется другая задача с увеличенным стеком, которая продолжает обработку. Максимальный размер такого расширенного стека ограничен этим параметром.
-Установка значения на разумно высоком уровне поможет обрабатывать очень глубокие запросы без значительного увеличения общего потребления ОЗУ. Например, установка 1G не означает, что каждая новая задача будет занимать 1G ОЗУ, но если мы видим, что требуется, скажем, 100M стека, мы выделяем 100M для задачи. Другие задачи в это время будут работать со стандартным стеком 128K. Аналогично, можно запускать ещё более сложные запросы, которым нужен стек в 500M. И только если мы **увидим** внутренне, что задача требует более 1G стека, мы завершимся с ошибкой и сообщим о слишком низком thread_stack.
+Установка значения на разумно высоком уровне поможет обрабатывать очень глубокие запросы без значительного увеличения общего потребления ОЗУ. Например, установка 1G не означает, что каждая новая задача будет занимать 1G ОЗУ, но если мы видим, что требуется, скажем, 100M стека, мы просто выделяем 100M для задачи. Другие задачи в это время будут работать со стандартным стеком 128K. Аналогично, можно запускать ещё более сложные запросы, которым нужно 500M. И только если мы **увидим** внутренне, что задача требует более 1G стека, мы завершимся с ошибкой и сообщим о слишком низком thread_stack.
-Однако на практике даже запрос, требующий 16M стека, часто слишком сложен для парсинга и потребляет слишком много времени и ресурсов для обработки. Поэтому демон обработает его, но ограничение таких запросов настройкой `thread_stack` выглядит вполне разумным.
+Однако на практике даже запрос, требующий 16M стека, часто слишком сложен для парсинга и занимает слишком много времени и ресурсов для обработки. Поэтому демон обработает его, но ограничение таких запросов настройкой `thread_stack` выглядит вполне разумным.
@@ -1712,7 +1720,7 @@ thread_stack = 8M
### unlink_old
-Определяет, следует ли удалять копии таблиц с расширением `.old` после успешной ротации. Необязательно, по умолчанию 1 (удалять).
+Определяет, следует ли удалять копии таблиц с расширением `.old` при успешной ротации. Необязательно, по умолчанию 1 (удалять).
@@ -1731,7 +1739,7 @@ unlink_old = 0
Поточный сторож сервера. Необязательно, по умолчанию 1 (сторож включён).
-Когда запрос Manticore аварийно завершается, он может привести к падению всего сервера. При включённой функции сторожа `searchd` также поддерживает отдельный лёгкий процесс, который следит за основным процессом сервера и автоматически перезапускает его в случае ненормального завершения. Сторож включён по умолчанию.
+Когда запрос Manticore аварийно завершается, он может привести к падению всего сервера. При включённой функции сторожа `searchd` также поддерживает отдельный лёгкий процесс, который контролирует основной процесс сервера и автоматически перезапускает его в случае ненормального завершения. Сторож включён по умолчанию.
diff --git a/src/datetime.cpp b/src/datetime.cpp
index 13bbd669c3..c39f0ff780 100644
--- a/src/datetime.cpp
+++ b/src/datetime.cpp
@@ -10,14 +10,57 @@
#include "datetime.h"
#include "fileutils.h"
+#include "sphinxint.h"
#include "cctz/time_zone.h"
#include
+#include
static bool g_bIntialized = false;
static bool g_bTimeZoneUTC = false;
static bool g_bTimeZoneSet = false;
static cctz::time_zone g_hTimeZone, g_hTimeZoneLocal, g_hTimeZoneUTC;
+static CSphString g_sTimeZoneName; // cached timezone name when explicitly set
+
+
+// Calculate UTC offset string as fallback when timezone name cannot be determined
+// Returns format like "UTC+07" (whole hours) or "UTC+05:30" (with minutes)
+// Called only from GetTimeZoneName() which is invoked infrequently (startup log, SHOW VARIABLES)
+static CSphString GetUTCOffsetString()
+{
+ time_t t = time(nullptr);
+ struct tm local_tm;
+ localtime_r(&t, &local_tm);
+
+ char offset[16];
+ int iLen = strftime(offset, sizeof(offset), "%z", &local_tm);
+ if ( iLen > 0 && iLen == 5 && ( offset[0] == '+' || offset[0] == '-' ) )
+ {
+ // Parse standard format: "+0700" or "+0530" (sign + 4 digits)
+ int iHours = ( offset[1] - '0' ) * 10 + ( offset[2] - '0' );
+ int iMinutes = ( offset[3] - '0' ) * 10 + ( offset[4] - '0' );
+
+ // Return "UTC" if offset is zero
+ if ( iHours == 0 && iMinutes == 0 )
+ return "UTC";
+
+ if ( iMinutes == 0 )
+ return CSphString().SetSprintf("UTC%c%d", offset[0], iHours);
+ else
+ return CSphString().SetSprintf("UTC%c%d:%02d", offset[0], iHours, iMinutes);
+ }
+
+ // If format is different, check if it's zero offset
+ if ( iLen > 0 && ( offset[0] == '+' || offset[0] == '-' ) )
+ {
+ // If offset is "+0000" or "-0000" or similar, return "UTC"
+ if ( strcmp(offset, "+0000") == 0 || strcmp(offset, "-0000") == 0 || strcmp(offset, "+00:00") == 0 || strcmp(offset, "-00:00") == 0 )
+ return "UTC";
+ return CSphString().SetSprintf("UTC%s", offset);
+ }
+
+ return "";
+}
static void CheckForUTC()
@@ -26,7 +69,7 @@ static void CheckForUTC()
}
#if !_WIN32
-static CSphString DetermineLocalTimeZoneName ( CSphString & sWarning )
+static CSphString DetermineLocalTimeZoneName ( CSphString & sWarning, bool bUseSystemDir = false )
{
CSphString sPrefix = "Error resolving local time zone from";
CSphString sTimeZoneFile = "/etc/localtime";
@@ -34,23 +77,16 @@ static CSphString DetermineLocalTimeZoneName ( CSphString & sWarning )
if ( szTZDefault )
sTimeZoneFile = szTZDefault;
- const char * szTZ = getenv("TZ");
- if ( szTZ )
- {
- sPrefix.SetSprintf ( "%s TZ='%s'", sPrefix.cstr(), szTZ );
-
- if ( *szTZ==':' )
- ++szTZ;
-
- if ( *szTZ )
- sTimeZoneFile = szTZ;
- }
- else
- sPrefix.SetSprintf ( "%s '%s'", sPrefix.cstr(), sTimeZoneFile.cstr() );
+ // Note: We intentionally ignore TZ environment variable here because
+ // logging should always use the actual system local timezone, not TZ
+ // TZ is meant for application-level timezone overrides, not system timezone
+ sPrefix.SetSprintf ( "%s '%s'", sPrefix.cstr(), sTimeZoneFile.cstr() );
CSphString sTimeZoneDir = "/usr/share/zoneinfo/";
+ // When detecting system timezone (bUseSystemDir=true), always use system directory
+ // Otherwise, use TZDIR if set (for Manticore's tzdata)
const char * szTZDIR = getenv("TZDIR");
- if ( szTZDIR )
+ if ( !bUseSystemDir && szTZDIR )
{
sPrefix.SetSprintf ( "%s and TZDIR='%s'", sPrefix.cstr(), szTZDIR );
sTimeZoneDir = szTZDIR;
@@ -116,30 +152,47 @@ static void SetTimeZoneLocal ( StrVec_t & dWarnings )
CSphString sDirName;
sDirName.SetSprintf ( "%s/tzdata", GET_FULL_SHARE_DIR() );
+ // Save TZ env var before we potentially unset it (needed for time functions)
+ const char * szTZ = getenv("TZ");
+
#if _WIN32
_putenv_s ( "TZDIR", sDirName.cstr() );
-
- // use cctz's internal local time zone code
g_hTimeZoneLocal = cctz::local_time_zone();
#else
CSphString sWarning;
CSphString sZone = DetermineLocalTimeZoneName(sWarning);
if ( !sWarning.IsEmpty() )
dWarnings.Add(sWarning);
-
sZone = FixupZoneName(sZone);
+ // Get actual system local timezone for logging (ignore TZ env var)
+ // Temporarily unset TZ so cctz::local_time_zone() uses /etc/localtime, not TZ
+ if ( szTZ )
+ unsetenv("TZ");
+ g_hTimeZoneLocal = cctz::local_time_zone();
+ if ( szTZ )
+ setenv("TZ", szTZ, 1);
+
setenv ( "TZDIR", sDirName.cstr(), 1 );
+#endif
- if ( !cctz::load_time_zone ( sZone.cstr(), &g_hTimeZoneLocal ) )
+ // Configure timezone for time functions (NOW(), CURTIME(), etc.)
+ // Use TZ env var if set, otherwise use local timezone
+ // Note: logging always uses g_hTimeZoneLocal (actual system timezone)
+ if ( szTZ && *szTZ )
{
- sWarning.SetSprintf ( "Unable to load local time zone '%s' from '%s' dir", sZone.cstr(), sDirName.cstr() );
- dWarnings.Add(sWarning);
- g_hTimeZoneLocal = g_hTimeZoneUTC;
+ const char * szTZName = szTZ;
+ if ( *szTZName == ':' )
+ ++szTZName;
+ if ( *szTZName && cctz::load_time_zone ( szTZName, &g_hTimeZone ) )
+ g_sTimeZoneName = szTZName;
+ else
+ g_hTimeZone = g_hTimeZoneLocal;
+ }
+ else
+ {
+ g_hTimeZone = g_hTimeZoneLocal;
}
-#endif
-
- g_hTimeZone = g_hTimeZoneLocal;
CheckForUTC();
}
@@ -161,6 +214,7 @@ bool SetTimeZone ( const char * szTZ, CSphString & sError )
}
g_bTimeZoneSet = !g_hTimeZone.name().empty() && strcasecmp ( g_hTimeZone.name().c_str(), "UTC" );
+ g_sTimeZoneName = szTZ; // store the timezone name for display
CheckForUTC();
return true;
@@ -178,7 +232,39 @@ CSphString GetTimeZoneName()
if ( !g_bIntialized )
return "";
- return g_hTimeZone.name().c_str();
+ // Return explicitly set timezone name (from config or SET timezone)
+ // Check g_sTimeZoneName first, as it's set even when timezone is UTC
+ if ( !g_sTimeZoneName.IsEmpty() )
+ return g_sTimeZoneName;
+
+ // Get timezone name from cctz
+ CSphString sName = g_hTimeZone.name().c_str();
+
+#if !_WIN32
+ // If no explicit timezone was set, try to determine the actual local timezone name
+ // This handles cases where cctz returns a file path or an incorrect name
+ if ( sName.Begins("/") || sName == "UTC" || sName.IsEmpty() )
+ {
+ // Parse /etc/localtime symlink to get timezone name like "Asia/Singapore" or "Europe/London"
+ // Use system directory (not Manticore's TZDIR) to detect actual system timezone
+ CSphString sWarning;
+ CSphString sZone = DetermineLocalTimeZoneName(sWarning, true);
+ sZone = FixupZoneName(sZone);
+ // Return detected timezone name if successful (skip if detection failed and returned "UTC")
+ if ( sZone != "UTC" && !sZone.IsEmpty() )
+ return sZone;
+ }
+#endif
+
+ // If timezone name cannot be determined, calculate UTC offset as fallback
+ // This handles cases where detection fails or timezone is actually UTC
+ if ( sName == "UTC" || sName.IsEmpty() || sName.Begins("/") )
+ {
+ CSphString sOffset = GetUTCOffsetString();
+ return sOffset.IsEmpty() ? "UTC" : sOffset;
+ }
+
+ return sName;
}
diff --git a/test/clt-tests/test-configuration/timezone.rec b/test/clt-tests/test-configuration/timezone.rec
index 1c8ddd7e71..caa758218a 100644
--- a/test/clt-tests/test-configuration/timezone.rec
+++ b/test/clt-tests/test-configuration/timezone.rec
@@ -1,12 +1,17 @@
––– comment –––
Extended timezone test based on original test from documentation
+––– input –––
+ln -sf /usr/share/zoneinfo/America/Los_Angeles /etc/localtime
+echo "America/Los_Angeles" > /etc/timezone
+dpkg-reconfigure -f noninteractive tzdata > /dev/null 2>&1
+––– output –––
––– block: ../base/start-searchd –––
––– comment –––
Check initial timezone and basic SET GLOBAL functionality (original test)
––– input –––
-mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value
+mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value | awk '{print $2}'
––– output –––
- Value: #!/[0-9a-zA-Z]\w+/!#
+America/Los_Angeles
––– input –––
mysql -h0 -P9306 -e "select curtime()\G" | awk 'NR>1 {print $2}' > /tmp/utc.txt
––– output –––
@@ -26,9 +31,9 @@ mysql -h0 -P9306 -e "select now(), curtime(), curdate(), utc_time(), utc_timesta
mysql -h0 -P9306 -e "set global timezone='UTC';"
––– output –––
––– input –––
-mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value
+mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value | awk '{print $2}'
––– output –––
- Value: UTC
+UTC
––– input –––
mysql -h0 -P9306 -e "select now(), curtime(), curdate(), utc_time(), utc_timestamp();"
––– output –––
@@ -48,9 +53,9 @@ cat /tmp/bkk.txt
––– output –––
#!/\d+:\d+:\d+/!#
––– input –––
-mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value
+mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value | awk '{print $2}'
––– output –––
- Value: Asia/Bangkok
+Asia/Bangkok
––– input –––
mysql -h0 -P9306 -e "select now(), curtime(), curdate(), utc_time(), utc_timestamp();"
––– output –––
@@ -79,9 +84,9 @@ export TZ=Asia/Tokyo && searchd --config /etc/manticoresearch/manticore.conf > /
sleep 2
––– output –––
––– input –––
-mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value
+mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value | awk '{print $2}'
––– output –––
- Value: Asia/Tokyo
+Asia/Tokyo
––– input –––
mysql -h0 -P9306 -e "select hour(now()) as tokyo_hour\G" | grep "tokyo_hour:" | awk '{print $2}' > /tmp/tokyo_hour.txt
––– output –––
@@ -98,9 +103,9 @@ export TZ=UTC && searchd --config /etc/manticoresearch/manticore.conf > /dev/nul
sleep 2
––– output –––
––– input –––
-mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value
+mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value | awk '{print $2}'
––– output –––
- Value: UTC
+UTC
––– input –––
mysql -h0 -P9306 -e "select hour(now()) as utc_hour\G" | grep "utc_hour:" | awk '{print $2}' > /tmp/tz_utc_hour.txt
––– output –––
@@ -126,9 +131,9 @@ unset TZ && searchd --config /etc/manticoresearch/manticore.conf > /dev/null 2>&
sleep 2
––– output –––
––– input –––
-mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value
+mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value | awk '{print $2}'
––– output –––
- Value: Asia/Singapore
+Asia/Singapore
––– comment –––
Test Europe/London through system files (previously problematic)
––– input –––
@@ -145,9 +150,9 @@ searchd --config /etc/manticoresearch/manticore.conf > /dev/null 2>&1
sleep 2
––– output –––
––– input –––
-mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value
+mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value | awk '{print $2}'
––– output –––
- Value: Europe/London
+Europe/London
––– input –––
echo "Europe/London works correctly from system files"
––– output –––
@@ -172,9 +177,9 @@ searchd --config /tmp/manticore_tz.conf 2>&1 | head -2 | grep "Using time zone"
sleep 2
––– output –––
––– input –––
-mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value
+mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value | awk '{print $2}'
––– output –––
- Value: America/New_York
+America/New_York
––– comment –––
Test priority: config should override TZ and system files
––– input –––
@@ -195,9 +200,9 @@ searchd --config /tmp/manticore_tz.conf 2>&1 | head -2 | grep "Using time zone"
sleep 2
––– output –––
––– input –––
-mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value
+mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value | awk '{print $2}'
––– output –––
- Value: America/New_York
+America/New_York
––– input –––
echo "Priority test: Config (America/New_York) overrides TZ (Africa/Cairo) and system (Australia/Sydney)"
––– output –––
@@ -235,23 +240,23 @@ Test special timezone formats
mysql -h0 -P9306 -e "set global timezone='GMT';"
––– output –––
––– input –––
-mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value
+mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value | awk '{print $2}'
––– output –––
- Value: GMT
+GMT
––– input –––
mysql -h0 -P9306 -e "set global timezone='EST5EDT';"
––– output –––
––– input –––
-mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value
+mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value | awk '{print $2}'
––– output –––
- Value: EST5EDT
+EST5EDT
––– input –––
mysql -h0 -P9306 -e "set global timezone='Asia/Kolkata';"
––– output –––
––– input –––
-mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value
+mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value | awk '{print $2}'
––– output –––
- Value: Asia/Kolkata
+Asia/Kolkata
––– input –––
mysql -h0 -P9306 -e "select hour(now()) as kolkata_h, minute(now()) as kolkata_m\G" | grep -E "kolkata_h:|kolkata_m:" | awk '{print $2}' | tr '\n' ':' | sed 's/:$//' > /tmp/kolkata_time.txt
––– output –––
@@ -260,11 +265,15 @@ echo "Kolkata (UTC+5:30) time: $(cat /tmp/kolkata_time.txt)"
––– output –––
#!/Kolkata \(UTC\+5:30\) time: .*/!#
––– comment –––
-Cleanup and restore original configuration
+Cleanup: Remove config timezone setting before cleanup
––– input –––
-searchd --stopwait --config /tmp/manticore_tz.conf 2>&1 | grep "successfully sent SIGTERM"
+searchd --stopwait > /dev/null 2>&1
––– output –––
-[#!/[0-9a-zA-Z\:\.\s]+/!#] [#!/[0-9]+/!#] stop: successfully sent SIGTERM to pid %{NUMBER}
+––– input –––
+sed -i '/timezone=America\/New_York/d' /etc/manticoresearch/manticore.conf
+––– output –––
+––– comment –––
+Cleanup and restore original configuration
––– input –––
mv /tmp/localtime.backup /etc/localtime
––– output –––
@@ -277,3 +286,221 @@ mv /tmp/manticore.conf.backup /etc/manticoresearch/manticore.conf
––– input –––
rm -f /tmp/manticore_tz.conf /tmp/*.txt
––– output –––
+––– comment –––
+Test logging timezone vs time function timezone - Case 1: Default (no TZ, no config)
+Verify: Logs use local timezone, time functions use local timezone
+––– input –––
+date +%H:%M
+––– output –––
+#!/\d{2}:\d{2}/!#
+––– input –––
+searchd --stopwait > /dev/null 2>&1
+––– output –––
+––– input –––
+rm /var/log/manticore/*.log
+––– output –––
+––– input –––
+unset TZ && searchd > /dev/null 2>&1
+––– output –––
+––– input –––
+sleep 1
+––– output –––
+––– input –––
+mysql -P9306 -h0 -e "drop table if exists t; create table t; insert into t values(1); select hour(now()) as tz_hour from t"
+––– output –––
++---------+
+| tz_hour |
++---------+
+| #!/[0-9]+/!# |
++---------+
+––– input –––
+LOCAL_HOUR=$((10#$(date +%H))); ACTUAL_HOUR=$((10#$(mysql -P9306 -h0 -e "select hour(now()) from t" | awk 'NR==4 {print $2}'))); DIFF=$(( (ACTUAL_HOUR - LOCAL_HOUR + 24) % 24 )); [ $DIFF -le 1 ] && echo "Timezone precedence correct: hour=$ACTUAL_HOUR matches local hour=$LOCAL_HOUR (using system local timezone)" || echo "Timezone precedence FAILED: actual hour=$ACTUAL_HOUR, local hour=$LOCAL_HOUR"
+––– output –––
+Timezone precedence correct: hour=#!/[0-9]+/!# matches local hour=#!/[0-9]+/!# (using system local timezone)
+––– input –––
+LOG_TS=$(tail -n 1 /var/log/manticore/searchd.log | grep -oE '\[.*\]' | head -1); DATE_TS=$(date '+%a %b %d %H:%M'); LOG_HOUR=$((10#$(echo "$LOG_TS" | grep -oE '[0-9]{2}:[0-9]{2}:[0-9]{2}' | cut -d: -f1))); DATE_HOUR=$((10#$(date +%H))); DIFF=$(( (LOG_HOUR - DATE_HOUR + 24) % 24 )); [ $DIFF -le 1 ] && echo "Log timestamp is in local timezone (log hour: $LOG_HOUR, local hour: $DATE_HOUR)" || echo "Log timestamp timezone issue: log=$LOG_HOUR local=$DATE_HOUR"
+––– output –––
+Log timestamp is in local timezone (log hour: #!/[0-9]+/!#, local hour: #!/[0-9]+/!#)
+––– input –––
+QLOG_TS=$(tail -n 1 /var/log/manticore/query.log | grep -oE '/\* .* \*/'); QLOG_HOUR=$((10#$(echo "$QLOG_TS" | grep -oE '[0-9]{2}:[0-9]{2}:[0-9]{2}' | cut -d: -f1))); DATE_HOUR=$((10#$(date +%H))); DIFF=$(( (QLOG_HOUR - DATE_HOUR + 24) % 24 )); [ $DIFF -le 1 ] && echo "Query log timestamp is in local timezone (log hour: $QLOG_HOUR, local hour: $DATE_HOUR)" || echo "Query log timestamp timezone issue: log=$QLOG_HOUR local=$DATE_HOUR"
+––– output –––
+Query log timestamp is in local timezone (log hour: #!/[0-9]+/!#, local hour: #!/[0-9]+/!#)
+––– input –––
+mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value | awk '{print $2}'
+––– output –––
+America/Los_Angeles
+––– comment –––
+Test logging timezone vs time function timezone - Case 2: TZ environment variable
+Verify: Logs use local timezone (not TZ), time functions use TZ
+––– input –––
+date +%H:%M
+––– output –––
+#!/\d{2}:\d{2}/!#
+––– input –––
+searchd --stopwait > /dev/null 2>&1
+––– output –––
+––– input –––
+rm /var/log/manticore/*.log
+––– output –––
+––– input –––
+TZ=Europe/Berlin searchd > /dev/null 2>&1
+––– output –––
+––– input –––
+sleep 1
+––– output –––
+––– input –––
+mysql -P9306 -h0 -e "select hour(now()) as tz_hour from t"
+––– output –––
++---------+
+| tz_hour |
++---------+
+| #!/[0-9]+/!# |
++---------+
+––– input –––
+EXPECTED_TZ="Europe/Berlin"; EXPECTED_HOUR=$((10#$(TZ=$EXPECTED_TZ date +%H))); ACTUAL_HOUR=$((10#$(mysql -P9306 -h0 -e "select hour(now()) from t" | awk 'NR==4 {print $2}'))); [ $ACTUAL_HOUR -eq $EXPECTED_HOUR ] && echo "Timezone precedence correct: hour=$ACTUAL_HOUR matches expected $EXPECTED_TZ hour=$EXPECTED_HOUR" || echo "Timezone precedence FAILED: actual hour=$ACTUAL_HOUR, expected $EXPECTED_TZ hour=$EXPECTED_HOUR"
+––– output –––
+Timezone precedence correct: hour=#!/[0-9]+/!# matches expected Europe/Berlin hour=#!/[0-9]+/!#
+––– input –––
+LOG_TS=$(tail -n 1 /var/log/manticore/searchd.log | grep -oE '\[.*\]' | head -1); DATE_TS=$(date '+%a %b %d %H:%M'); LOG_HOUR=$((10#$(echo "$LOG_TS" | grep -oE '[0-9]{2}:[0-9]{2}:[0-9]{2}' | cut -d: -f1))); DATE_HOUR=$((10#$(date +%H))); DIFF=$(( (LOG_HOUR - DATE_HOUR + 24) % 24 )); [ $DIFF -le 1 ] && echo "Log timestamp is in local timezone (log hour: $LOG_HOUR, local hour: $DATE_HOUR)" || echo "Log timestamp timezone issue: log=$LOG_HOUR local=$DATE_HOUR"
+––– output –––
+Log timestamp is in local timezone (log hour: #!/[0-9]+/!#, local hour: #!/[0-9]+/!#)
+––– input –––
+QLOG_TS=$(tail -n 1 /var/log/manticore/query.log | grep -oE '/\* .* \*/'); QLOG_HOUR=$((10#$(echo "$QLOG_TS" | grep -oE '[0-9]{2}:[0-9]{2}:[0-9]{2}' | cut -d: -f1))); DATE_HOUR=$((10#$(date +%H))); DIFF=$(( (QLOG_HOUR - DATE_HOUR + 24) % 24 )); [ $DIFF -le 1 ] && echo "Query log timestamp is in local timezone (log hour: $QLOG_HOUR, local hour: $DATE_HOUR)" || echo "Query log timestamp timezone issue: log=$QLOG_HOUR local=$DATE_HOUR"
+––– output –––
+Query log timestamp is in local timezone (log hour: #!/[0-9]+/!#, local hour: #!/[0-9]+/!#)
+––– input –––
+mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value | awk '{print $2}'
+––– output –––
+Europe/Berlin
+––– comment –––
+Test logging timezone vs time function timezone - Case 3: Config timezone setting
+Verify: Logs use local timezone (not config), time functions use config
+––– input –––
+sed -i '$i timezone=America/New_York' /etc/manticoresearch/manticore.conf
+––– output –––
+––– input –––
+date
+––– output –––
+#!/.*/!#
+––– input –––
+searchd --stopwait > /dev/null 2>&1
+––– output –––
+––– input –––
+rm /var/log/manticore/*.log
+––– output –––
+––– input –––
+unset TZ && searchd > /dev/null 2>&1
+––– output –––
+––– input –––
+sleep 1
+––– output –––
+––– input –––
+mysql -P9306 -h0 -e "select hour(now()) as tz_hour from t"
+––– output –––
++---------+
+| tz_hour |
++---------+
+| #!/[0-9]+/!# |
++---------+
+––– input –––
+EXPECTED_TZ="America/New_York"; EXPECTED_HOUR=$((10#$(TZ=$EXPECTED_TZ date +%H))); ACTUAL_HOUR=$((10#$(mysql -P9306 -h0 -e "select hour(now()) from t" | awk 'NR==4 {print $2}'))); [ $ACTUAL_HOUR -eq $EXPECTED_HOUR ] && echo "Timezone precedence correct: hour=$ACTUAL_HOUR matches expected $EXPECTED_TZ hour=$EXPECTED_HOUR" || echo "Timezone precedence FAILED: actual hour=$ACTUAL_HOUR, expected $EXPECTED_TZ hour=$EXPECTED_HOUR"
+––– output –––
+Timezone precedence correct: hour=#!/[0-9]+/!# matches expected America/New_York hour=#!/[0-9]+/!#
+––– input –––
+LOG_TS=$(tail -n 1 /var/log/manticore/searchd.log | grep -oE '\[.*\]' | head -1); DATE_TS=$(date '+%a %b %d %H:%M'); LOG_HOUR=$((10#$(echo "$LOG_TS" | grep -oE '[0-9]{2}:[0-9]{2}:[0-9]{2}' | cut -d: -f1))); DATE_HOUR=$((10#$(date +%H))); DIFF=$(( (LOG_HOUR - DATE_HOUR + 24) % 24 )); [ $DIFF -le 1 ] && echo "Log timestamp is in local timezone (log hour: $LOG_HOUR, local hour: $DATE_HOUR)" || echo "Log timestamp timezone issue: log=$LOG_HOUR local=$DATE_HOUR"
+––– output –––
+Log timestamp is in local timezone (log hour: #!/[0-9]+/!#, local hour: #!/[0-9]+/!#)
+––– input –––
+QLOG_TS=$(tail -n 1 /var/log/manticore/query.log | grep -oE '/\* .* \*/'); QLOG_HOUR=$((10#$(echo "$QLOG_TS" | grep -oE '[0-9]{2}:[0-9]{2}:[0-9]{2}' | cut -d: -f1))); DATE_HOUR=$((10#$(date +%H))); DIFF=$(( (QLOG_HOUR - DATE_HOUR + 24) % 24 )); [ $DIFF -le 1 ] && echo "Query log timestamp is in local timezone (log hour: $QLOG_HOUR, local hour: $DATE_HOUR)" || echo "Query log timestamp timezone issue: log=$QLOG_HOUR local=$DATE_HOUR"
+––– output –––
+Query log timestamp is in local timezone (log hour: #!/[0-9]+/!#, local hour: #!/[0-9]+/!#)
+––– input –––
+mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value | awk '{print $2}'
+––– output –––
+America/New_York
+––– comment –––
+Test logging timezone vs time function timezone - Case 4: Config timezone with TZ env var (config should override)
+Verify: Logs use local timezone (not TZ or config), time functions use config (overrides TZ)
+––– input –––
+date +%H:%M
+––– output –––
+#!/\d{2}:\d{2}/!#
+––– input –––
+searchd --stopwait > /dev/null 2>&1
+––– output –––
+––– input –––
+rm /var/log/manticore/*.log
+––– output –––
+––– input –––
+TZ=Europe/Berlin searchd > /dev/null 2>&1
+––– output –––
+––– input –––
+sleep 1
+––– output –––
+––– input –––
+mysql -P9306 -h0 -e "select hour(now()) as tz_hour from t"
+––– output –––
++---------+
+| tz_hour |
++---------+
+| #!/[0-9]+/!# |
++---------+
+––– input –––
+EXPECTED_TZ="America/New_York"; EXPECTED_HOUR=$((10#$(TZ=$EXPECTED_TZ date +%H))); ACTUAL_HOUR=$((10#$(mysql -P9306 -h0 -e "select hour(now()) from t" | awk 'NR==4 {print $2}'))); [ $ACTUAL_HOUR -eq $EXPECTED_HOUR ] && echo "Timezone precedence correct: hour=$ACTUAL_HOUR matches expected $EXPECTED_TZ hour=$EXPECTED_HOUR (config overrides TZ)" || echo "Timezone precedence FAILED: actual hour=$ACTUAL_HOUR, expected $EXPECTED_TZ hour=$EXPECTED_HOUR"
+––– output –––
+Timezone precedence correct: hour=#!/[0-9]+/!# matches expected America/New_York hour=#!/[0-9]+/!# (config overrides TZ)
+––– input –––
+LOG_TS=$(tail -n 1 /var/log/manticore/searchd.log | grep -oE '\[.*\]' | head -1); DATE_TS=$(date '+%a %b %d %H:%M'); LOG_HOUR=$((10#$(echo "$LOG_TS" | grep -oE '[0-9]{2}:[0-9]{2}:[0-9]{2}' | cut -d: -f1))); DATE_HOUR=$((10#$(date +%H))); DIFF=$(( (LOG_HOUR - DATE_HOUR + 24) % 24 )); [ $DIFF -le 1 ] && echo "Log timestamp is in local timezone (log hour: $LOG_HOUR, local hour: $DATE_HOUR)" || echo "Log timestamp timezone issue: log=$LOG_HOUR local=$DATE_HOUR"
+––– output –––
+Log timestamp is in local timezone (log hour: #!/[0-9]+/!#, local hour: #!/[0-9]+/!#)
+––– input –––
+QLOG_TS=$(tail -n 1 /var/log/manticore/query.log | grep -oE '/\* .* \*/'); QLOG_HOUR=$((10#$(echo "$QLOG_TS" | grep -oE '[0-9]{2}:[0-9]{2}:[0-9]{2}' | cut -d: -f1))); DATE_HOUR=$((10#$(date +%H))); DIFF=$(( (QLOG_HOUR - DATE_HOUR + 24) % 24 )); [ $DIFF -le 1 ] && echo "Query log timestamp is in local timezone (log hour: $QLOG_HOUR, local hour: $DATE_HOUR)" || echo "Query log timestamp timezone issue: log=$QLOG_HOUR local=$DATE_HOUR"
+––– output –––
+Query log timestamp is in local timezone (log hour: #!/[0-9]+/!#, local hour: #!/[0-9]+/!#)
+––– input –––
+mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value | awk '{print $2}'
+––– output –––
+America/New_York
+––– comment –––
+Test logging timezone vs time function timezone - Case 5: TZ env var with SET GLOBAL timezone (SET GLOBAL should override)
+Verify: Logs use local timezone (not TZ or SET GLOBAL), time functions use SET GLOBAL (overrides TZ)
+––– input –––
+date +%H:%M
+––– output –––
+#!/\d{2}:\d{2}/!#
+––– input –––
+searchd --stopwait > /dev/null 2>&1
+––– output –––
+––– input –––
+rm /var/log/manticore/*.log
+––– output –––
+––– input –––
+TZ=Europe/Berlin searchd > /dev/null 2>&1
+––– output –––
+––– input –––
+sleep 1
+––– output –––
+––– input –––
+mysql -P9306 -h0 -e "set global timezone='Europe/Riga'; select hour(now()) as tz_hour from t"
+––– output –––
++---------+
+| tz_hour |
++---------+
+| #!/[0-9]+/!# |
++---------+
+––– input –––
+EXPECTED_TZ="Europe/Riga"; EXPECTED_HOUR=$((10#$(TZ=$EXPECTED_TZ date +%H))); ACTUAL_HOUR=$((10#$(mysql -P9306 -h0 -e "select hour(now()) from t" | awk 'NR==4 {print $2}'))); [ $ACTUAL_HOUR -eq $EXPECTED_HOUR ] && echo "Timezone precedence correct: hour=$ACTUAL_HOUR matches expected $EXPECTED_TZ hour=$EXPECTED_HOUR (SET GLOBAL overrides TZ)" || echo "Timezone precedence FAILED: actual hour=$ACTUAL_HOUR, expected $EXPECTED_TZ hour=$EXPECTED_HOUR"
+––– output –––
+Timezone precedence correct: hour=#!/[0-9]+/!# matches expected Europe/Riga hour=#!/[0-9]+/!# (SET GLOBAL overrides TZ)
+––– input –––
+LOG_TS=$(tail -n 1 /var/log/manticore/searchd.log | grep -oE '\[.*\]' | head -1); DATE_TS=$(date '+%a %b %d %H:%M'); LOG_HOUR=$((10#$(echo "$LOG_TS" | grep -oE '[0-9]{2}:[0-9]{2}:[0-9]{2}' | cut -d: -f1))); DATE_HOUR=$((10#$(date +%H))); DIFF=$(( (LOG_HOUR - DATE_HOUR + 24) % 24 )); [ $DIFF -le 1 ] && echo "Log timestamp is in local timezone (log hour: $LOG_HOUR, local hour: $DATE_HOUR)" || echo "Log timestamp timezone issue: log=$LOG_HOUR local=$DATE_HOUR"
+––– output –––
+Log timestamp is in local timezone (log hour: #!/[0-9]+/!#, local hour: #!/[0-9]+/!#)
+––– input –––
+QLOG_TS=$(tail -n 1 /var/log/manticore/query.log | grep -oE '/\* .* \*/'); QLOG_HOUR=$((10#$(echo "$QLOG_TS" | grep -oE '[0-9]{2}:[0-9]{2}:[0-9]{2}' | cut -d: -f1))); DATE_HOUR=$((10#$(date +%H))); DIFF=$(( (QLOG_HOUR - DATE_HOUR + 24) % 24 )); [ $DIFF -le 1 ] && echo "Query log timestamp is in local timezone (log hour: $QLOG_HOUR, local hour: $DATE_HOUR)" || echo "Query log timestamp timezone issue: log=$QLOG_HOUR local=$DATE_HOUR"
+––– output –––
+Query log timestamp is in local timezone (log hour: #!/[0-9]+/!#, local hour: #!/[0-9]+/!#)
+––– input –––
+mysql -h0 -P9306 -e "show variables like 'timezone'\G" | grep Value | awk '{print $2}'
+––– output –––
+Europe/Riga