Solr之配置文件Solrconfig.xml和solr.xml

2022-06-15  本文已影响0人  上善若泪

1 Solrconfig.xml

在Solr中solrconfig.xml文件是影响Solr本身参数最多的配置文件。
在solrconfig.xml中，需要配置下述的一些重要的功能，如：

1.1 DataDir和DirectoryFactory

1.1.1 使用dataDir参数指定索引数据的位置

默认情况下，Solr将其索引数据存储在一个名为/data的目录下中，该目录位于核心的实例目录下（instanceDir）。如果想要指定不同的目录来存储索引数据，则可以在core.properties文件中为核心配置dataDir，或使用solrconfig.xml文件中的<dataDir>参数。可以使用绝对路径或相对于SolrCore的instanceDir的路径名指定另一个目录。例如：

<dataDir>/solr/data/${solr.core.name}</dataDir>

所述${solr.core.name}取代将导致当前核心的名称被取代，这导致每个核心的数据被保持在一个单独的子目录中。

如果使用复制来复制Solr索引（如传统扩展和分发中所述），那么该<dataDir>目录应该对应于复制配置中使用的索引目录。

如果定义了环境变量 SOLR_DATA_HOME，或者为DirectoryFactory配置了solr.data.home，或者solr.xml包含一个<solrDataHome>元素，则数据目录的位置将是<SOLR_DATA_HOME>/<instance_name>/data

1.1.2 为索引指定DirectoryFactory

默认solr.StandardDirectoryFactory是基于文件系统的，并且试图为当前的JVM和平台选择最好的实现。可以通过指定solr.MMapDirectoryFactory、solr.NIOFSDirectoryFactory或solr.SimpleFSDirectoryFactory来强制执行特定的实现或配置选项。

<directoryFactory name="DirectoryFactory"
                  class="solr.MMapDirectoryFactory">
  <bool name="preload">true</bool>
</directoryFactory>

这solr.RAMDirectoryFactory是基于内存的，不是持久性的，并且不适用于复制。使用此DirectoryFactory将你的索引存储在RAM中。

<directoryFactory class="org.apache.solr.core.RAMDirectoryFactory"/>

如果正在使用Hadoop并希望将索引存储在HDFS中，那么应该使用solr.HdfsDirectoryFactory，而不是上述任何一种实现

1.2 SolrConfig中的Lib指令

Solr允许通过在solrconfig.xml中定义<lib/>指令来加载插件。

插件是按照它们在solrconfig.xml出现的顺序加载的。如果存在依赖关系，请首先列出最低级别的依赖关系jar。

可以使用正则表达式来提供对同一目录中其他jar的依赖关系的控制加载jar。所有目录都解析为相对于Solr instanceDir

<lib dir="../../../contrib/extraction/lib" regex=".*\.jar" />
<lib dir="../../../dist/" regex="solr-cell-\d.*\.jar" />

<lib dir="../../../contrib/clustering/lib/" regex=".*\.jar" />
<lib dir="../../../dist/" regex="solr-clustering-\d.*\.jar" />

<lib dir="../../../contrib/langid/lib/" regex=".*\.jar" />
<lib dir="../../../dist/" regex="solr-langid-\d.*\.jar" />

<lib dir="../../../contrib/velocity/lib" regex=".*\.jar" />
<lib dir="../../../dist/" regex="solr-velocity-\d.*\.jar" />

1.3 SolrConfig中的架构工厂定义（Schema Factory Definition）

Solr的架构API使远程客户端可以通过REST接口访问架构信息并进行架构修改。
其他特性，如Solr的Schemaless Mode，也可以在运行时通过编程方式进行架构修改。

使用托管架构需要能够使用架构API来修改您的架构。然而，使用托管架构本身并不意味着您也在无架构模式(或“架构猜测”模式)中使用Solr

无架构模式需要启用托管架构（如果尚未建立模式），但是完全模式猜测需要额外配置，如“无模式模式”部分中所述。

尽管架构API的“读取”特性对于所有架构类型都是支持的，但是支持以编程方式进行架构修改依赖于正在使用的<schemaFactory/>

1.3.1 Solr默认使用托管架构

当<schemaFactory/>没有在solrconfig.xml文件中显式声明时，Solr隐式地使用ManagedIndexSchemaFactory，它是默认的mutable并将模式信息保存在一个managed-schema文件中。

 <!-- An example of Solr's implicit default behavior if no
      no schemaFactory is explicitly defined.
 -->
  <schemaFactory class="ManagedIndexSchemaFactory">
    <bool name="mutable">true</bool>
    <str name="managedSchemaResourceName">managed-schema</str>
  </schemaFactory>

如果你想明确配置 ManagedIndexSchemaFactory，下列选项可用：

使用上面所示的默认配置，可以使用Schema API根据需要尽可能多地修改架构，如果希望将架构“锁定”到位并防止将来发生更改，则稍后将mutable值更改为false。

1.3.2 经典schema.xml

使用托管架构的替代方法是显式配置一个ClassicIndexSchemaFactory。ClassicIndexSchemaFactory 需要使用schema.xml配置文件，并且不允许在运行时对架构进行任何编程式更改。该schema.xml文件必须手动编辑，仅在加载集合时才加载。

<schemaFactory class="ClassicIndexSchemaFactory"/>

1.3.3 从schema.xml切换到托管架构

如果你有一个现有的Solr集合使用了ClassicIndexSchemaFactory，并且你希望转换为使用托管模式，则可以简单地修改solrconfig.xml以指定使用ManagedIndexSchemaFactory

一旦Solr重新启动，它检测到schema.xml文件存在，但managedSchemaResourceName文件（即：managed-schema）不存在，现有的schema.xml文件将被重命名为schema.xml.bak，内容被重新写入托管的架构文件。如果你查看生成的文件，你会在页面顶部看到这个：

<!-- Solr managed schema - automatically generated - DO NOT EDIT -->

你现在可以随意使用Schema API，只需要进行更改，然后删除schema.xml.bak

1.3.4 从托管架构切换到手动编辑的schema.xml

如果你启动了Solr并启用了托管架构，并且想要切换到手动编辑schema.xml文件，则应执行以下步骤：

  1. 重命名managed-schema文件为：schema.xml。
  2. 修改solrconfig.xml以替换schemaFactory类。删除任何ManagedIndexSchemaFactory定义，如果存在。添加一个ClassicIndexSchemaFactory，如上所示的定义。
  3. 重新加载核心。

如果你正在使用SolrCloud，则可能需要通过ZooKeeper修改文件。该bin/solr脚本提供了一种简单的方法来从ZooKeeper下载文件并在编辑之后将其上传

要完全控制schema.xml文件，你可能还需要禁用架构猜测，这可以在编制索引期间将未知字段添加到架构中

1.4 SolrConfig中的IndexConfig

solrconfig.xml的<indexConfig>部分定义了Lucene索引编写器的低级行为。
默认情况下，这些设置在Solr包含的示例solrconfig.xml中注释掉，这意味着使用默认值。在大多数情况下，默认值是好的。

<indexConfig>
  ...
</indexConfig>

1.4.1 编写新的段

1.4.2 合并索引段

<mergePolicyFactory class="org.apache.solr.index.TieredMergePolicyFactory">
  <int name="maxMergeAtOnce">10</int>
  <int name="segmentsPerTier">10</int>
</mergePolicyFactory>

1.4.3 控制段大小：合并因素

用户对配置TieredMergePolicy（或LogByteSizeMergePolicy）所做的最常见的调整是“合并因素”，以一次更改应合并的段数。

对于TieredMergePolicy，这是通过设置<int name="maxMergeAtOnce">和<int name="segmentsPerTier">选项来控制的，而LogByteSizeMergePolicy只有一个<int name="mergeFactor">选项（全部默认值为10）

如果创建新的段会导致最低层段的数量超过mergeFactor值，那么所有这些段被合并在一起形成一个大的段。因此，如果合并因子为10，则每次合并都会创建一个单独的段，该段大约是其十个成分中的每一个的十倍。当有10个这些较大的段时，他们又被合并成一个更大的单个段。这个过程可以无限期地继续下去。

当使用TieredMergePolicy时，过程是相同的，但不是一个单一的mergeFactor值，该segmentsPerTier设置被用作阈值来决定是否应该发生合并，并且该maxMergeAtOnce设置确定合并中应该包括多少段。

选择最佳的合并因素通常是索引速度与搜索速度的权衡。在索引中有更少的段通常会加速搜索，因为查找的位置更少。它也可以导致磁盘上的物理文件更少。但是为了保持低段的数量，合并会更频繁地发生，这会给系统增加负载并且减慢对索引的更新。

相反，保留更多的段可以加快索引，因为合并发生的次数少，使得更新不太可能触发合并。但是搜索的计算成本更高，并且可能会变慢，因为搜索条件必须在更多的索引段中查找。更快的索引更新也意味着更短的提交周转时间，这意味着更及时的搜索结果。

1.4.4 定制合并策略

如果内置合并策略的配置选项不完全适合你的用例，则可以对它们进行自定义：通过创建您在配置中指定的自定义合并策略工厂，或者配置使用wrapped.prefix配置选项用于控制将如何配置其包装的工厂：

<mergePolicyFactory class="org.apache.solr.index.SortingMergePolicyFactory">
  <str name="sort">timestamp desc</str>
  <str name="wrapped.prefix">inner</str>
  <str name="inner.class">org.apache.solr.index.TieredMergePolicyFactory</str>
  <int name="inner.maxMergeAtOnce">10</int>
  <int name="inner.segmentsPerTier">10</int>
</mergePolicyFactory>

上面的例子显示了 Solr 的 SortingMergePolicyFactory 被配置为通过 timestamp desc对合并段中的文档进行排序，并将 TieredMergePolicyFactory 配置为使用 maxMergeAtOnce=10 和 segmentsPerTier=10 的值，通过SortingMergePolicyFactory的wrapped.prefix选项定义的inner前缀

1.4.5 复合文件段

每个Lucene段通常由十几个文件组成。可以将Lucene配置为将一个段的所有文件打包成单个复合文件，其文件扩展名为.cfs；它是复合文件段的缩写。
由于各种原因，CFS 段可能会受到轻微的性能影响，具体取决于运行时环境。例如，文件系统缓冲区通常与打开的文件描述符关联，这可能会限制每个索引可用的总缓存空间。

在每个进程允许的打开文件数量有限的系统上，CFS可能会避免达到该限制。打开的文件限制也可以通过Linux / Unix ulimit命令对您的操作系统进行调整，或者其他操作系统的类似操作。

注意：CFS: 新段与合并段：要配置新写入的段是否应使用 CFS

许多合并策略实现都支持 noCFSRatio 和 maxCFSSegmentSizeMB 设置, 并使用默认值防止复合文件被用于大段, 但对于小段, 也要用复合文件。

1.4.6 索引锁

LockFactory选项指定要使用的锁定实现。
这组有效的锁定类型选项取决于你配置的DirectoryFactory。以下列出的值受StandardDirectoryFactory（默认）支持：

writeLockTimeout
在IndexWriter上等待写入锁定的最长时间。缺省值是1000，以毫秒表示。
<writeLockTimeout>1000</writeLockTimeout>

1.4.7 其他索引设置

还有一些其他参数可能对您的实现配置很重要。这些设置会影响对索引进行更新的方式或时间。

<reopenReaders>true</reopenReaders>
<deletionPolicy class="solr.SolrDeletionPolicy">
  <str name="maxCommitsToKeep">1</str>
  <str name="maxOptimizedCommitsToKeep">0</str>
  <str name="maxCommitAge">1DAY</str>
</deletionPolicy>
<infoStream>false</infoStream>

1.5 SolrConfig中的InitParams

solrconfig的<initParams> 部分允许你定义处理程序配置之外的请求处理程序参数。
有几个用例可能是需要的：

例如，如果你希望多个搜索处理程序返回相同的字段列表，则可以创建一个<initParams>部分，而无需在每个请求处理程序定义中定义相同的一组参数。如果你有一个单一的请求处理程序，该处理程序应该返回不同的字段，那么可以像往常一样在个别<requestHandler>部分定义重写参数。
一个<initParams>部分的属性和配置镜像了请求处理程序的属性和配置。它可以包含用于默认、附加和不变的部分，与任何请求处理程序相同。

例如，这里是在_default示例中默认定义的<initParams>部分：

<initParams path="/update/**,/query,/select,/tvrh,/elevate,/spell,/browse">
  <lst name="defaults">
    <str name="df">_text_</str>
  </lst>
</initParams>

这会将默认搜索字段（df）设置为路径部分中指定的所有请求处理程序的“文本”。如果我们稍后想要更改/query请求处理程序以在默认情况下搜索不同的字段，则可以通过定义/query中的<requestHandler>部分的参数来重写 <initParams>

1.6 UpdateHandlers

在solrconfig.xml中的<updateHandler>元素中进行配置，可能会影响索引更新的性能。这些设置影响在内部进行更新的方式。<updateHandler>配置不会影响处理客户端更新请求的RequestHandler的更高级配置。

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

1.6.1 提交（Commits）

发送到 Solr 的数据在被提交到索引之前是不可搜索的。这样做的原因是，在某些情况下，提交可能会很慢，并且应该与其他可能的提交请求隔离进行，以避免覆盖数据。所以，最好提供数据提交时的控制权。有几个选项可用来控制提交的时间。

<autoCommit>
  <maxDocs>10000</maxDocs>
  <maxTime>30000</maxTime>
  <openSearcher>false</openSearcher>
</autoCommit>

也可以像指定soft提交一样指定'soft'自动提交，不同之处在于，不应将 autoSoftCommit 标记设置为 "自动提交"。

<autoSoftCommit>
  <maxTime>60000</maxTime>
</autoSoftCommit>

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

有了这个配置，当您将commitWithin作为更新消息的一部分进行调用时，每次都会自动执行一个硬性提交。

1.6.2 事件监听器

UpdateHandler部分也是可以配置与更新相关的事件侦听器的地方。这些可以在任何commit（event="postCommit"）之后触发，或者仅在优化命令（event="postOptimize"）之后触发。
用户可以编写自定义更新事件监听器类，但常见的用例是通过RunExecutableListener运行外部可执行文件：

1.6.3 事务日志

如RealTime Get部分所述，该功能需要事务日志。它在 solrconfig. xml 的 updateHandler 部分中进行了配置。
实时获取当前依赖于默认情况下启用的更新日志功能。它依赖于在 solrconfig. xml 中配置的更新日志，其内容如下：

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

三个额外的专家级配置设置会影响索引性能，以及复制副本在必须进入完全恢复之前可能落后于更新的程度

一个例子，要被包括在solrconfig.xml的<config><updateHandler>下，将使用上述高级设置：

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

1.7 查询SolrConfig中的设置

这些设置都是在solrconfig. xml中的 <query> 元素的子元素中配置的。

<query>
  ...
</query>

1.7.1 高速缓存

Solr缓存与索引搜索器的特定实例关联，索引的特定视图在该搜索器的生命周期内不发生变化。只要索引搜索器正在被使用，其缓存中的任何项目都将是有效的并可供重用。Solr中的缓存与许多其他应用程序中的缓存不同，因为缓存的Solr对象在一段时间间隔后不会过期；相反，它们在索引检索器的整个生命周期内仍然有效。

当新的搜索器被打开时，当前的搜索器将继续服务请求，而新的搜索者则 auto-warms 其缓存。新的搜索器使用当前搜索的缓存预先填充自己的缓存。当新的搜索器准备好时，它被注册为当前的搜索器，并开始处理所有新的搜索请求。一旦完成了所有的请求，旧的搜索器将被关闭。

在Solr中，有三个缓存实现：solr.search.LRUCache，solr.search.FastLRUCache和solr.search.LFUCache

缩写词LRU代表最近最少使用。当LRU缓存填满时，具有最早的最后访问时间戳的条目被驱逐，以为新条目腾出空间。最终的结果是被频繁访问的条目倾向于停留在缓存中，而那些不经常访问的条目倾向于退出，并且如果需要的话将会从索引中重新获取。

Solr 1.4中引入的这个FastLRUCache函数被设计成无锁的，所以它非常适合于在请求中多次触发的缓存。

LRUCache和FastLRUCache都使用 auto-warm 计数来支持整数和百分比，当 warm 发生时，它会相对于缓存的当前大小进行评估。

该LFUCache指最不常用的缓存。这与LRU缓存的工作方式类似，不同之处在于当缓存填满时，已经被使用的条目被删除。

Solr Admin UI中的Statistics页面将显示有关所有活动缓存的性能的信息。这些信息可以帮助您针对特定应用程序适当调整各种缓存的大小。当搜索器终止时，其缓存使用情况的摘要也被写入日志。

每个缓存都有设置来定义它的初始大小（initialSize），最大大小（size）和项目的数量，以用于warm（autowarmCount）。LRU和FastLRU缓存实现可以采取一个百分比，而不是autowarmCount的绝对值。

FastLRUCache和LFUCache支持showItems属性。这是要在缓存的统计信息页面中显示的缓存项目的数量。这是为了调试。

<filterCache class="solr.LRUCache"
             size="512"
             initialSize="512"
             autowarmCount="128"/>

<queryResultCache class="solr.LRUCache"
                  size="512"
                  initialSize="512"
                  autowarmCount="128"
                  maxRamMB="1000"/>

<documentCache class="solr.LRUCache"
               size="512"
               initialSize="512"
               autowarmCount="0"/>

<cache name="myUserCache" class="solr.LRUCache"
                          size="4096"
                          initialSize="1024"
                          autowarmCount="1024"
                          regenerator="org.mycompany.mypackage.MyRegenerator" />

如果要auto-warming缓存，请包含一个regenerator属性的具有实现solr.search.CacheRegenerator类的完全限定名称。你也可以使用NoOpRegenerator，它只是简单地重新填充旧项目的缓存。使用regenerator参数来定义它，比如：regenerator =“solr.NoOpRegenerator”

1.7.2 查询大小和Warm

1.7.3 与查询相关的监听器

如缓存部分所述，新索引搜索器被缓存。可以使用监听器的触发器执行与查询有关的任务。最常见的用途是定义查询，以便在索引搜索器启动时进一步“warm”索引搜索器。这种方法的一个好处是，可以预先填充字段缓存以进行更快的排序。

良好的查询选择对于这种类型的监听器是关键的。最好选择最常见或最重的查询，不仅包括使用的关键字，还包括任何其他参数，如排序或过滤请求。

有两种类型的事件可以触发监听器。正在准备一个新的搜索时，会发生firstSearcher事件，但没有当前注册搜索来处理请求或获得从auto-warming的数据（例如，Solr上的启动）。每当有新的搜索器准备好时，就会触发一个newSearcher事件，并有一个当前的搜索器处理请求。

下面的（注释掉的）例子可以在Solr sample_techproducts_configs 配置集的solrconfig.xml的文件中找到，并且演示如何使用这个solr.QuerySenderListener类来warm一组显式查询：

<listener event="newSearcher" class="solr.QuerySenderListener">
  <arr name="queries">
  <!--
    <lst><str name="q">solr</str><str name="sort">price asc</str></lst>
    <lst><str name="q">rocks</str><str name="sort">weight asc</str></lst>
   -->
  </arr>
</listener>

<listener event="firstSearcher" class="solr.QuerySenderListener">
  <arr name="queries">
    <lst><str name="q">static firstSearcher warming in solrconfig.xml</str></lst>
  </arr>
</listener>

1.8 RequestDispatcher

solrconfig.xml的requestDispatcher元素，控制了Solr HTTP RequestDispatcher实现对请求的响应方式。

1.8.1 handleSelect元素

注意：handleSelect 是为了传统的后向兼容性；那些新来的Solr不需要改变默认配置的方式

第一个可配置项是<requestDispatcher>元素本身的handleSelect当选属性。该属性可以设置为“true”或“false”两个值之一。它管理Solr如何响应请求，如：/select?qt=XXX。如果requestHandler没有显式注册/select名称，默认值“false”将忽略请求/select。值“true”将查询请求路由到定义为qt值的解析器。
在Solr的最新版本中，/selectrequestHandler是默认定义的，因此值“false”将正常工作

<requestDispatcher handleSelect="true" >
  ...
</requestDispatcher>

1.8.2 requestParsers元素

该<requestParsers>子元素控制与解析请求的相关值。这是一个空的XML元素，没有任何内容，只有属性。
属性enableRemoteStreaming控制是否允许远程传输内容。如果省略或设置为false（默认），则不允许流式传输。将其设置为true允许你指定要使用stream.file和stream.url参数进行流式传输的内容或位置。
如果启用远程流式传输，请确保你已启用身份验证。否则，有人可能通过访问任意的URL访问您的内容。将Solr放置在防火墙后面以防止从不可信的客户端访问Solr也是一个好主意。

属性multipartUploadLimitInKB以可以在多部分HTTP POST请求中提交的文档的大小为单位设置以千字节为单位的上限。指定的值乘以1024来确定以字节为单位的大小。-1意味着MAX_INT 的值，如果省略，它也是系统默认值。

属性formdataUploadLimitInKB在HTTP POST请求中提交的表单数据（application / x-www-form-urlencoded）的大小上设置了一个限制（千字节），可用于传递不适合URL的请求参数。-1意味着MAX_INT 的值，如果省略，也是系统默认值。

属性addHttpRequestToContext可以用来指示原始HttpServletRequest对象应该包含在SolrQueryRequest使用httpRequest键的上下文映射。HttpServletRequest不是任何Solr组件所使用的，但在开发自定义插件时可能会有用。

<requestParsers enableRemoteStreaming="false"
                multipartUploadLimitInKB="2048"
                formdataUploadLimitInKB="2048"
                addHttpRequestToContext="false" />

1.8.3 httpCaching元素

该<httpCaching>元素控制HTTP缓存控制标头。不要将这些设置与Solr的内部缓存配置混淆。该元素控制由W3C HTTP规范定义的HTTP响应的缓存。
这个元素允许三个属性和一个子元素。<httpCaching>元素的属性控制是否允许对GET请求的304响应，如果是，则应该是什么类型的响应。当一个HTTP客户端应用程序发出一个GET时，它可以选择性地指定一个304响应是可接受的，如果该资源从上次被提取以来没有被修改过。

<httpCaching never304="false"
             lastModFrom="openTime"
             etagSeed="Solr">
  <cacheControl>max-age=30, public</cacheControl>
</httpCaching>

1.8.4 cacheControl元素

除了这些属性之外，<httpCaching>接受一个子元素：<cacheControl>。这个元素的内容将作为HTTP响应的Cache-Control头的值发送。此标头用于修改请求客户端的默认缓存行为。
设置max-age字段控制客户端在从服务器再次请求之前可以重新使用缓存响应的时间。此时间间隔应根据你更新索引的频率以及你的应用程序是否可接受使用已过时的内容来设置。
设置must-revalidate将告诉客户端在服务器上重新使用之前确认其缓存副本仍然正常。这将确保使用最及时的结果，同时避免在不需要的情况下再次获取内容，则请求服务器进行检查。

1.9 编解码器：Codec Factory

可以在solrconfig.xml中指定一个codecFactory来确定将索引写入磁盘时使用哪个Lucene Codec

如果未指定，则Lucene的默认编解码器将被隐式使用。

Lucene的默认编解码器有两种选择，如下所述：

<codecFactory class="solr.SchemaCodecFactory">
  <str name="compressionMode">BEST_COMPRESSION</str>
</codecFactory>

转载于:https://www.w3cschool.cn/solr_doc/solr_doc-orsk2hja.html

2 Solr核心和solr.xml

在Solr中，术语core用于指单个索引和关联的事务日志和配置文件（包括solrconfig.xml和Schema文件等）。如果需要，你的Solr安装可以具有多个核心，这使你可以在同一台服务器中为不同结构的数据建立索引，并且更好地控制数据如何呈现给不同的受众。在 SolrCloud模式中，将更熟悉术语“collection”。在幕后，一个集合由一个或多个核心组成。

在独立模式下，solr.xml必须驻留在solr_home。在SolrCloud模式下，将从ZooKeeper加载solr.xml（如果它存在），回退到solr_home。

注意：在较旧版本的Solr中，核心必须在solr.xml中预定义为<core>标签。为了让Solr了解它们。现在，Solr支持自动发现核心，它们不再需要显式定义。推荐的方法是使用api动态创建内核/集合。

2.1 solr.xml的格式

2.1.1 定义solr.xml

可以在$SOLR_HOME目录（通常是：server/solr）中以独立模式，或者在使用SolrCloud时在ZooKeeper中找到solr.xml。默认solr.xml文件如下所示：

<solr>
  <solrcloud>
    <str name="host">${host:}</str>
    <int name="hostPort">${jetty.port:8983}</int>
    <str name="hostContext">${hostContext:solr}</str>
    <int name="zkClientTimeout">${zkClientTimeout:15000}</int>
    <bool name="genericCoreNodeNames">${genericCoreNodeNames:true}</bool>
  </solrcloud>

  <shardHandlerFactory name="shardHandlerFactory"
    class="HttpShardHandlerFactory">
    <int name="socketTimeout">${socketTimeout:0}</int>
    <int name="connTimeout">${connTimeout:0}</int>
  </shardHandlerFactory>

</solr>

发现 Solr 配置是SolrCloud 友好的。但是，<solrcloud>元素的存在并不意味着Solr实例在SolrCloud模式下运行。除非在启动时指定了-DzkHost或-DzkRun

2.1.2 Solr.xml参数

2.1.3 替换solr.xml中的JVM系统属性

Solr支持在solr.xml的JVM系统属性值的变量替换，它允许运行时指定各种配置选项。语法是：${propertyname[:option default value]}。这允许定义Solr启动时可以覆盖的默认值。如果未指定默认值，则必须在运行时指定该属性，否则该solr.xml文件将在分析时生成错误。
在启动JVM时通常使用-D标志指定的任何JVM系统属性都可以用作solr.xml文件中的变量。

例如，在下面显示的solr.xml文件中，socketTimeout和connTimeout值都被设置为“0”。但是，如果你使用bin/solr -DsocketTimeout=1000开启Solr，则HttpShardHandlerFactory的socketTimeout的选项要使用1000毫秒的值覆盖，而重写的connTimeout选项将继续使用默认属性值“0”。

<solr>
  <shardHandlerFactory name="shardHandlerFactory"
                       class="HttpShardHandlerFactory">
    <int name="socketTimeout">${socketTimeout:0}</int>
    <int name="connTimeout">${connTimeout:0}</int>
  </shardHandlerFactory>
</solr>

2.2 core.properties

核心发现意味着创建核心就像core.properties在磁盘上的文件一样简单。
该core.properties文件是一个简单的Java属性文件，其中每行只是一个key=value对，例如：name=core1。请注意，不需要使用引号。
最小的core.properties文件看起来像下面的例子。但是，它也可以是空的
name=my_core_name

2.2.1 安置core.properties

Solr核心是通过在solr.home子目录下放置一个名为core.properties的文件来配置的。对树的深度没有先验限制，对于可以定义的内核数量也没有限制。核心可能在树中的任何地方，但核心可能不在现有核心下定义

可以将Solr分割成多个核心，每个核心都有自己的配置和索引。核心可以专用于单个应用程序或非常不同的应用程序，但所有内容都通过一个通用的管理界面进行管理。您可以即时创建新的Solr核心，关闭核心，甚至可以将一个正在运行的核心替换为另一个核心，而不用停止或重新启动Solr。
如有必要，你的core.properties文件可以是空的。假设core.properties位于./cores/core1（相对于solr_home），但是是空的。在这种情况下，核心名称被假定为“core1”。instanceDir将是包含core.properties（即，./cores/core1）的文件夹。dataDir将会是../cores/core1/data，等等。

2.2.2 定义core.properties文件

最小的core.properties文件是一个空文件，在这种情况下，所有的属性默认是适当的。

Java属性文件允许hash（#）或bang（!）字符指定注释到行尾（comment-to-end-of-line）。
以下属性可用：

转载于:https://www.w3cschool.cn/solr_doc/solr_doc-uo952hrm.html

上一篇 下一篇

猜你喜欢

热点阅读