tomcat上部署的solr的移植以及数据的备份与恢复

背景：移植系统，需要将原来服务器上的solr移植到新系统，考虑的可能受版本问题的影响，所以没有单独安装环境，直接复制了原来服务器的solr-home和tomcat（含有solr）到新服务器。最普遍的遇到的问题：直接复制的文件缺少执行权限，注意检查所有的可执行文件与脚本，chmod 777 *。其次，一些服务需要单独启动，配合日志来检查是否启动成功。

1.solr的移植与启动

tomcat的启动与发布

由于solr通过tomcat发布，故一些配置修改后，可能需要重启tomcat。
注意tomcat的关闭和开启，可能存在失败的问题，可以通过进程来检查。

(base) [mca@server14 bin]$ pwd
/home/mca/software/oodt/tomcat/bin
(base) [mca@server14 bin]$ ./shutdown.sh 				#关闭tomcat
Using CATALINA_BASE:   /home/mca/software/oodt/tomcat
Using CATALINA_HOME:   /home/mca/software/oodt/tomcat
Using CATALINA_TMPDIR: /home/mca/software/oodt/tomcat/temp
Using JRE_HOME:       /usr/local/java/jdk1.8/jre
(base) [mca@server14 bin]$ ps -ef|grep java				#有时tomcat关闭不成功（后面还显示一长串，即关闭不成功）
mca       70801      1  0 11:49 pts/0    00:00:10 /usr/local/java/jdk1.8/jre/bin/java -Djava.ext.dirs=/home/mca/software/oodt/filemgr/lib -Djava.util.logging.config.file=/home/mca/software/oodt/filemgr/etc/logging.properties -Dorg.apache.oodt.cas.filemgr.properties=/home/mca/software/oodt/filemgr/etc/filemgr.properties -Djava.io.tmpdir=/home/mca/software/oodt/temp org.apache.oodt.cas.filemgr.system.XmlRpcFileManager --portNum 9000
mca       83827  27650  0 15:34 pts/2    00:00:00 grep --color=auto java
(base) [mca@server14 bin]$ kill -9 70801				#直接根据进程号kill掉这个进程
(base) [mca@server14 bin]$ ps -ef|grep java				#关闭成功后没有tomcat的相关信息
mca       83847  27650  0 15:35 pts/2    00:00:00 grep --color=auto java
(base) [mca@server14 bin]$ ./startup.sh					#重新启动tomcat 
Using CATALINA_BASE:   /home/mca/software/oodt/tomcat
Using CATALINA_HOME:   /home/mca/software/oodt/tomcat
Using CATALINA_TMPDIR: /home/mca/software/oodt/tomcat/temp
Using JRE_HOME:       /usr/local/java/jdk1.8/jre

solr的启动

直接迁移原始的index数据到solr-home/collection1/data下会出现solr启动不成功的问题

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HIMilaH0-1629465688223)(C:\Users\anonymous\AppData\Roaming\Typora\typora-user-images\image-20210820161735680.png)]

通过删除data下的所有数据（由solr直接新建）可以解决该问题，solr可以正常启动，但是也代表原始数据不能迁移过来。

​ 直接备份还原，备份backup命令有效，还原命令无效。

​ 直接将data数据（含有index、tlog）全部拷贝过去，solr直接运行不起来，出现如上的错误。

后来经过多次尝试（关闭tomcat；只拷贝index【通过备份命令备份的snapshot】过去，全部赋予了执行权限chmod；再次重启tomcat）—最终使用原来的index数据solr可以正常启动！！----（至今仍然不能确定问题在哪里，怀疑可能是与一些缓存数据有关）

2.solr数据的删除

#solr删除数据---可以指定根据关键字和正则匹配来删除数据
curl http://localhost:8080/solr/update --data-binary "<delete><query>CAS.ProductName:LC08*.jpg</query></delete>" -H 'Content-type:text/xml; charset=utf-8'

#必须执行了提交命令才能删除成功
curl http://localhost:8080/solr/update --data-binary "<commit/>" -H 'Content-type:text/xml; charset=utf-8'

3.solr数据的备份与还原

参考 Solr如何制作和还原备份_w3cschool

#以下均可以去掉curl，直接在浏览器执行
1.触发备份的命令
curl http://localhost:8080/solr/collection1/replication?command=backup

#备份的数据存储在/home/mca/software/oodt/solr-home/collection1/data/   以snapshot.name的命名
备份请求还可以采用以下附加参数：

location——
建备份的路径。如果路径不是绝对的，则备份路径将与Solr的实例目录相关。|name |The snapshot将在名为snapshot.<name>的目录中创建。如果没有指定名称，则目录名称将具有以下格式：snapshot.<yyyyMMddHHmmssSSS>。
numberToKeep——
要保留的备份数量。如果maxNumberOfBackups已在solrconfig.xml中的复制处理程序指定，则始终使用maxNumberOfBackups并尝试使用numberToKeep将导致错误。另外，如果指定了备份名称，则不会考虑此参数。有关maxNumberOfBackups的详细信息，请参阅配置ReplicationHandler一节。
repository——
用于备份的存储库的名称。如果没有指定仓库，那么本地文件系统仓库将被自动使用。
commitName——
使用CREATESNAPSHOT命令拍摄快照时使用的提交的名称。



2.查看备份状态的命令
curl http://localhost:8080/solr/collection1/replication?command=details



3.还原备份的数据
curl http://localhost:8080/solr/collection1/replication?command=restore&name=snapshot.20210820144948621

这会将指定的索引快照还原到当前的核心。还原完成后，搜索将开始反映快照数据。
该restore请求可以采取这些附加参数：

location——
备份快照文件的位置。如果未指定，它将在Solr的数据目录中查找备份。

name——
要还原的备份索引快照的名称。如果没有提供该名称，则snapshot.<timestamp>在位置目录中查找带有格式的备份。它在这种情况下选择最新的时间戳备份。

repository——
用于备份的存储库的名称。如果没有指定仓库，那么本地文件系统仓库将被自动使用。

该restore命令是一个异步调用。一旦恢复完成，反映的数据将是还原的备份索引。
在一个时间点上只能对一个核心进行一次restore调用。当正在进行的还原操作正在发生时，随后的还原调用将引发异常。



4.查看还原数据的状态
curl http://localhost:8080/solr/collection1/replication?command=restorestatus

注意：实际使用时还原命令restore好像无效

最终解决办法：删除solr-home，复制原来项目的solr-home，data不复制；最终只把备份的snapshot数据新建一个index引入。（见1.solr的启动）