可以通过在配置文件的 searchd 部分设置 query_log 指令来启用查询日志。

也可以通过将 syslog 设置为文件路径来将查询发送到 syslog。在这种情况下，所有搜索查询将以 LOG_INFO 优先级发送到 syslog 守护进程，前缀为 [query] 而不是时间戳。syslog 仅支持 plain 日志格式。

SQL 日志格式是默认设置。在此模式下，Manticore 会记录所有成功和失败的 select 查询。以 SQL 或通过二进制 API 发送的请求以 SQL 格式记录，但 JSON 查询按原样记录。此类日志仅适用于普通日志文件，不支持用于日志的 'syslog' 服务。

相比于plain 格式，Manticore SQL 日志格式的特性包括：

• 尽可能记录完整的语句数据。
• 记录错误和警告。
• 查询日志可被重放。
• 记录额外的性能计数器（目前为每个代理的分布式查询时间）。
• 每条日志条目都是有效的 Manticore SQL/JSON 语句，可重建完整请求，除非被记录的请求过大，出于性能原因需要缩短。
• JSON 请求作为注释记录，跳过元素之间的多余空白。
• 额外消息、计数器等作为注释记录。

使用 plain 日志格式时，Manticore 以简单文本格式记录所有成功执行的搜索查询。查询的非全文部分不会被记录。JSON 查询以单行条目记录。通过 Buddy 处理的查询不会被记录。

日志格式如下：

[query-date] real-time wall-time [match-mode/filters-count/sort-mode total-matches (offset,limit) @groupby-attr] [table-name] {perf-stats} query

其中：

• real-time 是从查询开始到结束的时间。
• wall-time 类似于 real-time，但不包括等待代理和合并代理结果集的时间。
• perf-stats 包含当 Manticore 用 --cpustats（或通过 SET GLOBAL cpustats=1 启用）和/或 --iostats（或通过 SET GLOBAL iostats=1 启用）启动时的 CPU/IO 统计信息：
  • ios 是完成的文件 I/O 操作次数；
  • kb 是从表文件读取的数据量（千字节）；
  • ms 是用于 I/O 操作的时间。
  • cpums 是处理查询所用的 CPU 时间（毫秒）。
• match-mode 可以是以下之一：
  • “all” 代表 SPH_MATCH_ALL 模式；
  • “any” 代表 SPH_MATCH_ANY 模式；
  • “phr” 代表 SPH_MATCH_PHRASE 模式；
  • “bool” 代表 SPH_MATCH_BOOLEAN 模式；
  • “ext” 代表 SPH_MATCH_EXTENDED 模式；
  • “ext2” 代表 SPH_MATCH_EXTENDED2 模式；
  • “scan” 如果使用了全扫描模式，或通过 SPH_MATCH_FULLSCAN 指定，或查询为空。
• sort-mode 可以是以下之一：
  • “rel” 代表 SPH_SORT_RELEVANCE 模式；
  • “attr-” 代表 SPH_SORT_ATTR_DESC 模式；
  • “attr+” 代表 SPH_SORT_ATTR_ASC 模式；
  • “tsegs” 代表 SPH_SORT_TIME_SEGMENTS 模式；
  • “ext” 代表 SPH_SORT_EXTENDED 模式。

注意：SPH* 模式特指 sphinx 旧接口。SQL 和 JSON 接口在大多数情况下会记录 ext2 作为 match-mode，以及 ext 和 rel 作为 sort-mode。

默认情况下，会记录所有查询。如果只想记录执行时间超过指定限制的查询，可以使用 query_log_min_msec 指令。

预期的单位是毫秒，但也可以使用时间后缀表达式。

默认情况下，searchd 和查询日志文件的权限为 600，因此只有运行 Manticore 的用户和 root 可以读取日志文件。query_log_mode 选项允许设置不同的权限。这有助于允许其他用户读取日志文件（例如，运行在非 root 用户下的监控解决方案）。

要全局禁用二进制日志，请在 searchd 配置中将 binlog_path 设置为空值。 禁用二进制日志需要重启守护进程，并且如果系统意外关闭，数据将面临风险。

您可以使用以下指令设置自定义路径：

为了更细粒度的控制，可以通过将实时表的 binlog 表参数设置为 0 来禁用该表的二进制日志。此选项不适用于 percolate 表。

对于已有的 RT 表，也可以通过修改 binlog 参数来禁用二进制日志。

如果之前禁用了二进制日志，可以通过将 binlog 参数重新设置为 1 来重新启用：

在正常操作期间，当记录的数据量达到一定限制（由 binlog_max_log_size 设置）时，会启动一个新的日志文件。旧的日志文件会保留，直到其中的所有更改都被完全处理并保存为磁盘块。如果该限制设置为 0，则日志文件会一直保留，直到系统正常关闭。默认情况下，这些文件的大小没有限制。

每个 binlog 文件的命名格式为带零填充的数字，如 binlog.0000、binlog.0001 等，通常显示四位数字。您可以通过设置 binlog_filename_digits 来更改数字的位数。如果 binlog 文件数量超过数字位数能容纳的范围，数字位数会自动增加以适应所有文件。

重要：要更改数字位数，必须先保存所有表数据并正常关闭系统。然后删除旧的日志文件并重启系统。

您可以选择两种管理二进制日志文件的方式，通过 binlog_common 指令设置：

• 每表单独文件（默认，0）：每个表将其更改保存到自己的日志文件中。如果您有许多表在不同时间更新，这种设置很合适。它允许表独立更新，无需等待其他表。此外，如果某个表的日志文件出现问题，不会影响其他表。
• 所有表共用单个文件（1）：所有表使用同一个二进制日志文件。这种方法使文件管理更简单，因为文件数量较少。然而，如果某个表仍需保存更新，文件可能会被保留时间较长。如果许多表同时需要更新，这种设置可能会降低性能，因为所有更改都必须等待写入同一个文件。

有四种不同的 binlog 刷新策略，由 binlog_flush 指令控制：

• 0 - 数据每秒写入磁盘（刷新），并且 Manticore 在刷新后立即启动将其安全写入磁盘的操作（同步）。此方法速度最快，但如果服务器或计算机突然崩溃，某些最近写入但尚未安全写入的数据可能会丢失。
• 1 - 数据在每个事务后立即写入 binlog 并同步。此方法最安全，确保每次更改立即被保存，但写入速度较慢。
• 2 - 每个事务后写入数据，并且每秒启动一次同步。此方法提供了一个平衡，定期且快速地写入数据。然而，如果计算机发生故障，某些正在保存的数据可能无法完成保存。此外，根据磁盘情况，同步可能需要超过一秒的时间。
• 3 - 类似于 2，但还确保在因超过 binlog_max_log_size 而关闭 binlog 文件之前进行同步。

默认模式是 2，它在每个事务后写入数据，并每秒开始同步，平衡了速度和安全性。

在使用 Galera 的集群设置中，节点恢复行为至关重要。通常，如果节点已正常关闭且其最后的序列号（seqno）已正确保存，Galera 会通过 IST（增量状态传输）处理节点不同步的情况。然而，在发生崩溃且 seqno 未被保存的情况下，Galera 将触发 SST（状态快照传输），这是一种资源密集型操作，可能由于高 I/O 活动显著减慢集群速度。

为了解决这个问题，引入了集群 binlog 支持。此功能扩展了现有的二进制日志功能，帮助减少 SST 的需求，使恢复节点能够从本地 binlog 重放缺失的事务，并以有效的 seqno 重新加入集群。

集群 binlog 默认对任何集群操作启用。但可以通过设置环境变量来禁用：

对完全适合于 RAM 块的小型 RT 表进行密集更新，可能导致 binlog 不断增长，直到干净关闭之前无法被删除。binlog 本质上是相对于磁盘上最后已知良好保存状态的追加式增量，除非 RAM 块被保存，否则无法删除。不断增长的 binlog 对磁盘使用和崩溃恢复时间都不理想。为了解决此问题，可以使用 rt_flush_period 指令配置 searchd 执行周期性 RAM 块刷新。启用周期性刷新后，searchd 将维护一个单独线程，检查 RT 表的 RAM 块是否需要写回磁盘。一旦发生，相关的 binlog 可以（且会被）安全删除。

默认的 RT 刷新周期设置为 10 小时。