mysql跟solr集成删除的数据怎么同步不了

mysql跟solr集成删除的数据怎么同步不了,第1张

1、创建core或collection,有两种方式创建

第一种是使用命令行,查看README.txt所知道的

bin/solr create -c collection

第二种使用访问链接创建

localhost:8983/solr/admin/cores?action=CREATE&name=collection&instanceDir=collection

默认创建的目录在solr-5.2.1/server/solr下

2、修改solr-5.2.1/server/solr/collection/conf/managed-schema文件为schema.xml

前面进入conf文件夹一看,傻了,居然没有4.6.1里面的schema.xml文件,这怎么设置?后来看到别人的一个文件说可以设置,难道我去4.6.1复制一个过来,再仔细一看有个managed-schema文件,于是试着打开一看,看到了下面的内容:

This is the Solr schema file. This file should be named “schema.xml” and should be in the conf directory under the solr home(i.e. ./solr/conf/schema.xml by default)

3、在schema.xml添加filed,因为我的mysql数据库当中只有id和name两个字段,而name这个filed在schema.xml已经存在,我只需要添加id就行了,如下:

<fields>

<field name="id" type="int" indexed="true" stored="true" required="true" />

</fields>

<uniqueKey>id</uniqueKey>

<defaultSearchField>name</defaultSearchField>

4、修改solr-5.2.1/server/solr/collection/conf/下的solrconfig.xml的配置文件,配置一下添加数据库数据的xml,如下:

<requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler">

<lst name="defaults">

<str name="config">data-config.xm

网上的解释真的不能看,全是错的,因为生产中遇到的一次问题对该原理研究了3天,查看了大量书籍,官方文档终于有了较为深刻的认识

Solr的提交方式只有两种,标准提交(硬提交,hard commit)和软提交(soft commit),说三种的错误

1.默认的提交即硬提交,commit之后会立刻将文档同步到硬盘,在开启新搜索器之前会阻塞,直到同步完成

2.默认情况下commit后会开启一个新搜索器(newSearcher),然后进行预热,预热完成后顶替旧搜索器,使旧缓存失效,但是开启新searcher及预热的过程(IO消耗)耗费资源过大,且可能被阻塞,所以应尽量避免在高峰期开启newsearcher,搜索器同一时间只能有一个处于active状态

3.为了避免频繁commit,solr提供了autocommit功能,可以设置每隔多久提交一次,或者待提交文档量达到阀值提交一次,并且可定义是否在提交后开启新的搜索器,若不开启,则缓存不能够被刷新,新更新文档不能够被实时读取到

1.软提交是将文档提交到内存,并不实时写入硬盘,减少了耗时的I/O *** 作

2.为了保证实时搜索,solr在软提交基础上引入了近实时搜索(NRT),NRT并不会被文档更新所阻塞,也不会等待文档合并完成再打开一个搜索器(以下摘自官方文档)

3.在lucene4.x 之前,solr采用NRTManager实现NRT,之后使用ControlledRealTimeReopenThread实现,它通过IndexWriter对象来监控内存中的文档变化,从而得到最新的文档信息,该过程既不需要高耗时的I/O *** 作,也不需要刷新搜索器,所以非常之快,耗费资源很少

4.所以 近实时搜索(NRT)是软提交的一个特性

5.同样的软提交也支持自动提交的方式,配置如下

5.这 两种提交方式并不冲突 ,试想我们程序使用了软提交,但何时可以把数据真正同步到磁盘呢?这时候就可以两者结合达到目的

我们设置每隔5000ms进行一次软提交,文档存入了内存,也可以实时搜索,然后每隔300000ms又会进行进行一次硬提交,同步到磁盘,无需刷新Searcher,如此两者兼顾

6.在配置文件中配置后,在客户端就不需要维护提交方式和提交时间了

1.很多人说由于软提交不及时写入硬盘,所以在jvm崩溃时会丢失部分数据,但其实不会,因为软提交和硬提交在commit时都会记录下 *** 作log,若发生崩溃,会在重启时会从log恢复,这点很像mysql的事务日志 *** 作

2.若maxDocs和maxTime都配置了,则那个条件先到就按那个执行,官方建议使用maxTime,因为solr文档较多,通常更新量也大,使用maxTime可能更能减少提交的频次,但在此建议根据实际情况来决定

3.commit *** 作后,可执行optimize *** 作,该 *** 作会合并索引碎片,合并后索引性能会有所提升,但该 *** 作消耗较大,每晚定时 *** 作一次即可

solr数据导入,经过这几天的查资料,我觉得solr数据导入可以有三种方式:

1、编写数据xml文件,通过post.jar导入;

2、通过DIH导入;

3、利用solrj导入数据;

现针对第三种方式进行研究,在第一步中写了一段小的测试代码,可以参考:http://wiki.apache.org/solr/Solrj#Streaming_documents_for_an_update

具体的代码解释如下:

String url = "http://localhost:8080/solr"

HttpSolrServer server = new HttpSolrServer(url)

//If you wish to delete all the data from the index, do this

//server.deleteByQuery( "*:*" )

//Construct a document

SolrInputDocument doc1 = new SolrInputDocument()

doc1.addField( "id", "id1_solrj" )

doc1.addField( "type", "doc1_solrj" )

doc1.addField( "name", "name1_solrj" )

//Construct another document

SolrInputDocument doc2 = new SolrInputDocument()

doc2.addField( "id", "id2" )

doc2.addField( "type", "doc2_solrj" )

doc2.addField( "name", "name2_solrj" )

//Create a collection of documents

Collection<SolrInputDocument>docs = new ArrayList<SolrInputDocument>()

docs.add(doc1)

docs.add(doc2)

//Do a commit

try {

server.add(docs)

server.commit()

} catch (SolrServerException e) {

System.out.println("server commit error, error code:")

e.printStackTrace()

} catch (IOException e) {

System.out.println("server commit error, error code:")

e.printStackTrace()

}

}

该端代码执行后报异常:expect mime type application/octet-stream but got text/html

没找到这个的解决办法,根据提示好像是说期望的类型和服务器反馈的类型不匹配

最后的解决办法是这样的:

之前在配置solr服务器的时候将solr解压路径\solr-4.8.1\example\solr下的solr.xml用\solr-4.8.1\example\multicore下的solr.xml文件进行了替换,目的是为了引入core0和core1,现在需要将这个动作进行回滚,并且修改collection1下的conf下的schema.xml文件,修改为对应的需要的列定义。然后执行以上的代码就不会产生问题。

原因我也不太明白,感觉应该是collection1的配置和core1、core0、乃至之前文章提到过的solrtest的配置应该不太一样。原因待查。不过现在已经可以通过客户端的方式将数据导入solr服务器,并在前端可以查询到相应的数据。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/9409750.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-28
下一篇 2023-04-28

发表评论

登录后才能评论

评论列表(0条)

保存