查询日志可以通过在配置文件的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_flush 指令控制：

• 0 - 数据每秒写入磁盘（刷新），随后 Manticore 会立即启动将其安全保存在磁盘上（同步）。此方法最快，但如果服务器或计算机突然崩溃，可能会丢失一些尚未安全保存的最近写入数据。
• 1 - 数据在每次事务后写入 binlog 并立即同步。此方法最安全，因为它确保每次更改都被立即保存，但会降低写入速度。
• 2 - 数据在每次事务后写入，并且每秒启动一次同步。此方法在定期快速写入数据与安全性之间取得平衡。但如果计算机失败，某些正在保存的数据可能未完成保存。此外，根据磁盘情况，同步可能需要超过一秒钟的时间。
• 3 - 类似于 2，但还确保 binlog 文件在因超过 binlog_max_log_size 而关闭之前同步。

默认模式为 2，即每次事务后写入数据，并每秒启动同步，平衡速度和安全性。

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

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

集群 binlog 默认在任何集群操作中启用，但可以通过设置环境变量关闭：

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

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