Solr配置：提交与事务日志详解

在Solr中，文档在”提交”更新Lucene索引文件之前不可用于搜索。提交策略将决定文档添加、删除或更改何时可用于搜索。事务日志记录自上次”硬”提交点以来收到的文档更新。

solrconfig.xml中的<updateHandler>

此部分中的设置在solrconfig.xml的<updateHandler>元素中配置，可能影响索引更新的性能。这些设置影响内部更新的完成方式。

<updateHandler>元素需要一个class参数，该参数必须是solr.DirectUpdateHandler2。Solr附带的_default配置集已经定义了此部分，但下面讨论的许多参数值可能需要为应用程序自定义。

<config>
  <updateHandler class="solr.DirectUpdateHandler2">
    ...
  </updateHandler>
</config>

注意，<updateHandler>配置不影响处理客户端更新请求的请求处理器的更高级别配置。

提交

发送到Solr的数据在提交到索引之前不可搜索。这是因为在某些情况下提交可能很慢，应该与其他可能的提交请求隔离执行，以避免覆盖数据。

硬提交vs软提交

Solr支持两种类型的提交：硬提交和软提交。

硬提交在索引文件上调用fsync，确保它们已刷新到稳定存储。当前事务日志被关闭并打开一个新的。有关在没有硬提交的情况下如何恢复数据，请参见下面的<<事务日志>>部分。可选地，硬提交也可以使文档对搜索可见，但在某些使用情况下这可能不理想，因为它比软提交更昂贵。默认情况下，提交动作会导致所有Lucene索引文件硬提交到稳定存储（磁盘）。

软提交更快，因为它只使索引更改可见，不执行fsync索引文件、启动新段或启动新事务日志。具有NRT要求的搜索集合需要足够频繁地软提交以满足应用程序的可见性要求。软提交可能比硬提交（openSearcher=true）”成本更低”，但不是免费的。建议在应用程序要求的合理范围内设置此值。

硬提交意味着，如果服务器崩溃，Solr将确切知道数据的存储位置；软提交意味着数据已存储，但位置信息尚未存储。权衡是软提交提供更快的可见性，因为它不等待后台合并完成。

在TLOG/PULL副本设置中，提交配置还影响副本轮询分片领导者的间隔。希望在TLOG/PULL副本中使用不同轮询间隔的用户可以通过指定形式为”hh:mm:ss”的commitPollInterval值来实现。例如，”01:00:00”表示每小时轮询一次，”00:15:00”表示每十五分钟轮询一次。

显式提交

当客户端在更新请求中包含commit=true参数时，这确保受更新上的添加和删除影响的所有索引段在索引更新完成后立即写入磁盘。

如果指定了额外参数softCommit=true，则Solr执行软提交。这是近实时存储的实现，该功能提高了文档可见性，因为您无需等待后台合并和存储（如果使用SolrCloud则到ZooKeeper）完成后才能继续其他操作。

有关在索引期间使用显式提交请求的详细信息，请参见使用更新处理器进行索引部分。

有关近实时操作的更多信息，请参见近实时使用案例。

自动提交

为了避免在索引期间发送显式提交命令并提供对提交发生时间的控制，可以在solrconfig.xml中配置autoCommit参数。

这比从索引客户端发送显式提交更可取，因为它为提交策略提供了更多控制。注意，solrconfig.xml中提供了默认值，但它们很可能未针对您的需求进行调整，如果不有效调整，可能会引入性能问题。

这些设置控制待处理更新自动推送到索引的频率。

maxDocs

• 可选参数，默认值：无
• 自上次提交以来发生的更新数量

maxTime

• 可选参数，默认值：无
• 自最旧未提交更新以来的毫秒数
• 发送大批量文档时，此参数优于maxDocs

maxSize

• 可选参数，默认值：无
• 磁盘上事务日志(tlog)的最大大小，超过此大小将触发硬提交
• 当文档大小未知且意图将事务日志大小限制为合理大小时，这很有用
• 有效值可以是字节（无后缀的默认值）、千字节（使用k后缀定义，如25k）、兆字节（m）或千兆字节（g）

openSearcher

• 可选参数，默认值：true
• 执行提交时是否打开新的搜索器
• 如果为false，提交将刷新最近的索引更改到稳定存储，但不会打开新搜索器使这些更改可见

如果达到任何maxDocs、maxTime或maxSize限制，Solr会自动执行提交操作。第一个达到的阈值将触发提交。

如果solrconfig.xml中缺少autoCommit标签，则只有显式提交才会更新索引。是否使用autoCommit的决定取决于应用程序的需求。

<autoCommit>
  <maxDocs>10000</maxDocs>
  <maxTime>30000</maxTime>
  <maxSize>512m</maxSize>
  <openSearcher>false</openSearcher>
</autoCommit>

您还可以使用autoSoftCommit标签指定’软’自动提交。

<autoSoftCommit>
  <maxTime>5000</maxTime>
</autoSoftCommit>

自动提交最佳实践

确定最佳autoCommit设置是性能和准确性之间的权衡。导致频繁更新的设置将提高搜索的准确性，因为新内容可以更快地搜索，但由于频繁更新，性能可能受到影响。较少频繁的更新可能提高性能，但更新显示在查询中需要更长时间。

这是两种提交方式的NRT配置示例，每60秒硬提交一次，每10秒软提交一次。请注意，这些不是Solr附带示例中的值！

<autoCommit>
  <maxTime>${solr.autoCommit.maxTime:60000}</maxTime>
  <openSearcher>false</openSearcher>
</autoCommit>

<autoSoftCommit>
   <maxTime>${solr.autoSoftCommit.maxTime:10000}</maxTime>
 </autoSoftCommit>

提示： 这些参数可以在运行时通过定义Java”系统变量”来覆盖，例如指定-Dsolr.autoCommit.maxTime=15000会用15秒的值覆盖硬提交间隔。

autoCommit（使用openSearcher=false）和autoSoftCommit的选择有不同后果。在非正常关闭的情况下，Solr可能需要最多在autoCommit中指定的时间来从事务日志重播未提交的文档。

为autoSoftCommit选择的时间确定文档发送到Solr后变为可搜索的最大时间，不影响事务日志。

为此值选择应用程序可以容忍的尽可能长的间隔，通常15-60秒是合理的，或者根据要求更长。在时间设置为非常短间隔（比如1秒）的情况下，考虑禁用缓存（特别是queryResultCache和filterCache），因为它们几乎没有用处。

提示： 对于极高的批量索引，特别是如果没有搜索的初始加载，考虑通过为maxTime参数指定值-1来关闭autoSoftCommit。

在时间段内提交

autoCommit的替代方案是使用commitWithin，它可以在向Solr发出更新请求时（即推送文档时）或在更新请求处理器中定义。

commitWithin设置允许强制文档提交在定义的时间段内发生。这最常与近实时使用案例一起使用，因此默认情况下执行软提交。但是，这不会将新文档复制到用户管理集群中的追随者服务器。如果这是您实现的要求，您可以通过添加参数来强制硬提交，如此例所示：

<commitWithin>
  <softCommit>false</softCommit>
</commitWithin>

使用此配置，当您在更新消息中调用commitWithin时，它每次都会自动执行硬提交。

事务日志

事务日志(tlogs)是自上次硬提交以来更新的”滚动窗口”。每次发生任何形式的硬提交时，当前事务日志都会关闭并打开新的事务日志。软提交对事务日志没有影响。

启用tlogs时，添加到索引的文档在索引调用返回到客户端之前被写入tlog。在非正常关闭（断电、JVM崩溃、kill -9等）的情况下，写入tlog但在Solr停止时尚未通过硬提交提交的任何文档都会在启动时重放。因此数据不会丢失。

当Solr正常关闭时（使用bin/solr stop命令），Solr会关闭tlog文件和索引段，因此启动时不需要重放。

一个令人困惑的点是事务日志包含多少数据。tlog不包含所有文档，只包含自上次硬提交以来的文档。不再需要的较旧事务日志文件会被删除。

警告： 上述隐含的是，如果禁用硬提交，事务日志将无限增长。因此，在索引时启用硬提交很重要。

事务日志配置

所有SolrCloud集群以及实时获取功能都需要事务日志。它在solrconfig.xml的updateHandler部分中配置。

事务日志在solrconfig.xml中配置，在如下部分：

<updateLog>
  <str name="dir">${solr.ulog.dir:}</str>
</updateLog>

唯一必需的参数是：

dir

• 必需参数，默认值：无
• 事务日志的位置
• 在Solr的默认solrconfig.xml文件中，这定义为${solr.ulog.dir:}
• 如默认值所示，事务日志的位置可以在任何地方，只要它在solrconfig.xml中定义并且Solr可读可写

有三个额外的专家级配置设置，它们影响索引性能以及副本在必须进入完全恢复之前在更新上可以落后多远。这些设置主要影响SolrCloud集群配置：

numRecordsToKeep

• 可选参数，默认值：100
• 要在所有事务日志文件中保留的最小更新记录数

maxNumLogsToKeep

• 可选参数，默认值：10
• 要保留的最大事务日志文件数

syncLevel

• 可选参数，默认值：FLUSH
• 事务日志文件的同步级别。可以是NONE、FLUSH或FSYNC，如果未设置任何内容，FLUSH是默认值

这些配置选项的工作方式如下：

• FSYNC：明确刷新Solr内部缓冲区到底层文件系统特定缓冲区，该缓冲区也会刷新到事务日志文件。这是更昂贵的操作，但更安全，因为内容写入事务日志文件。
• FLUSH：我们只明确刷新Solr内部缓冲区到底层文件系统特定缓冲区，但该缓冲区不会明确刷新到事务日志文件。这成本较低但也不太安全，因为如果我们在文件系统特定缓冲区也刷新之前发生崩溃，其数据将丢失。
• NONE：没有明确刷新缓冲区。此配置选项成本最低，但也是最不安全的。

使用上述高级设置的示例，包含在solrconfig.xml的<updateHandler>下：

<updateLog>
  <str name="dir">${solr.ulog.dir:}</str>
  <int name="numRecordsToKeep">500</int>
  <int name="maxNumLogsToKeep">20</int>
  <str name="syncLevel">FSYNC</str>
</updateLog>

事件监听器

UpdateHandler部分也是可以配置更新相关事件监听器的地方。这些可以触发在任何提交后发生（event="postCommit"）或仅在优化命令后发生（event="postOptimize"）。

用户可以在Solr插件中编写自定义更新事件监听器类。从Solr 7.1开始，出于安全原因删除了RunExecutableListener。

总结

合理配置提交策略和事务日志对Solr性能和数据安全至关重要。硬提交保证数据持久性，软提交提供快速可见性，而自动提交策略可以平衡性能和实时性要求。事务日志确保在系统异常时的数据恢复能力。通过理解这些机制并根据具体需求进行优化配置，可以构建既高效又可靠的Solr索引系统。