背景:我们有一个迁移到Docker的3节点Solr云。但是,对于插入的新数据,它只能通过ID检索。一旦我们尝试使用过滤器,就不会显示。请注意,旧数据仍然可以在没有任何问题的情况下过滤。
数据库是通过类似弹簧靴的应用程序使用的。
更多背景:
该应用程序和SOLR是由另一个人迁移的,我最近继承了代码库,因此我对实现的详细介绍了,并且仍在进行挖掘和调试。节点被按原样迁移(将数据复制到Docker Mount中)。
我到目前为止拥有的内容:
我已经检查了所有SOLR节点的日志,并在调用应用程序时查看以下情况:
过滤:
2019-02-22 14:17:07.525 INFO (qtp15xxxxx-15) [c:content_api s:shard1 r:core_node1 x:content_api_shard1_replica0] o.a.s.c.S.Request
[content_api_shard1_replica0]
webapp=/solr path=/select
params=
{q=*:*&start=0&fq=id-lws-ttf:127103&fq=active-boo-ttf:(true)&fq=(publish-date-tda-ttf:[*+TO+2019-02-22T15:17:07Z]+OR+(*:*+NOT+publish-date-tda-ttf:[*+TO+*]))AND+(expiration-date-tda-ttf:[2019-02-22T15:17:07Z+TO+*]+OR+(*:*+NOT+expiration-date-tda-ttf:[*+TO+*]))&sort=create-date-tda-ttf+desc&rows=10&wt=javabin&version=2}
hits=0 status=0 QTime=37
获得ID:
2019-02-22 14:16:56.441 INFO (qtp15xxxxxx-16) [c:content_api s:shard1 r:core_node1 x:content_api_shard1_replica0] o.a.s.c.S.Request
[content_api_shard1_replica0]
webapp=/solr path=/get params={ids=https://example.com/app/contents/127103/middle-east&wt=javabin&version=2}
status=0 QTime=0
免责声明:
我是与Solr合作的绝对初学者,并且正在通过文档ATM,以便更好地了解螺母和螺栓。
假设和WIP:
迁移它的人告诉我,只有数据被复制而不是配置。我已经获取了旧的配置文件(
/opt/solr/server/solr/configsets/
),并试图与新的配置文件进行比较。但是假设配置是默认的。旧版本是
6.4.2
,而新版本是6.6.5
(不确定这可能是问题)
我们这里有明显的东西吗?超级概念是可以通过ID检索数据的事实,并且可以过滤旧数据
更新:
- 经过一些研究后,我不得不说我排除了配置问题,因为当我从管理UI中检查配置时,我会看到正确的配置。
- 也是,另一个怪异的行为是可以在一段时间后查询数据(例如超过5天)。我可以看到这一点,因为我从UI运行查询并通过下降创建日期订购。从那里,我可以看到我的测试,不只是几天前
相关提交配置部分:
<autoCommit>
<maxTime>${solr.autoCommit.maxTime:15000}</maxTime>
<openSearcher>false</openSearcher>
</autoCommit>
<autoSoftCommit>
<maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime>
</autoSoftCommit>
从管理员端点的更多配置输出:
config:{
znodeVersion:0,
luceneMatchVersion:"org.apache.lucene.util.Version:6.0.1",
updateHandler:{
indexWriter:{
closeWaitsForMerges:true
},
commitWithin:{
softCommit:true
},
autoCommit:{
maxDocs:-1,
maxTime:15000,
openSearcher:false
},
autoSoftCommit:{
maxDocs:-1,
maxTime:-1
}
},
query:{
useFilterForSortedQuery:false,
queryResultWindowSize:20,
queryResultMaxDocsCached:200,
enableLazyFieldLoading:true,
maxBooleanClauses:1024,
filterCache:{
autowarmCount:"0",
size:"512",
initialSize:"512",
class:"solr.FastLRUCache",
name:"filterCache"
},
queryResultCache:{
autowarmCount:"0",
size:"512",
initialSize:"512",
class:"solr.LRUCache",
name:"queryResultCache"
},
documentCache:{
autowarmCount:"0",
size:"512",
initialSize:"512",
class:"solr.LRUCache",
name:"documentCache"
},
:{
size:"10000",
showItems:"-1",
initialSize:"10",
name:"fieldValueCache"
}
},
...
根据您的示例,您只在查询实时端点时才检索文档 - 即/get
。该端点通过ID查询来返回文档,即使该文档尚未将文档定为索引或已打开了新的搜索器。
必须在常规搜索端点可见的任何更改索引之前创建一个新的搜索器,因为旧搜索器仍将使用旧的索引文件进行搜索。如果未创建新的搜索器,那么陈旧的内容仍将返回。这与您看到的行为相匹配,在搜索者由于其他原因被回收(可能是由于重新启动/另一个显式提交/Merges/equintizes/etc。/p>
您的示例配置显示了禁用AutoSoftCommit,而常规自动加入设置为未打开新搜索器(因此,没有显示新的内容)。我通常建议禁用此功能,而要依靠在URL中使用commitWithin
,因为它可以为不同类型的数据提供更大的可配置性,并允许您要求在添加数据后至少在X秒内打开新搜索器。commitwithin的默认行为是在提交事件发生后将打开一个新的搜索器。
听起来您可能已切换到升级时默认的托管模式。在您的上一个安装中查找schema.xml以及先前安装的solrconfig.xml中的部分。有关更多信息,请访问https://lucene.apache.org/solr/guide/6_6/schema-factory-definitory-indinition-in-solrconfig.html#schemafactorydefinitionsolrconlconfig-solrressolrasemandsolrustessschemabydefault