solr 分片与复制

在没有使用solrcloude的时候,可以使用如下的架构图进行分片与复制:

具体可以参考solr的官方指南:Combining Distribution and Replication  章节 。简单来说就是一主两从。从片的同步方式,我觉得应该是通过从主片同步快照的方式,来实现的。

Snapshot :A directory containing hard links to the data files of an index. Snapshots are distributed from the master nodes when the slaves pull them, “smart copying” any segments the slave node does not have in snapshot directory that contains the hard links to the most recent index data files.

在solr cloud里面,这种方式主要是用来进行备份使用。其实我个人觉得这种快照的复制方式应该是用来快速备份的,不应该是用来进行主从分片同步用的,更可能用的是PULL索引文件的形式。

Solr cloud提供了三种分片模式,分别为:

NRT: This is the default. A NRT replica (NRT = NearRealTime) maintains a transaction log and writes new documents to it’s indexes locally. Any replica of this type is eligible to become a leader. Traditionally, this was the only type supported by Solr.

TLOG: This type of replica maintains a transaction log but does not index document changes locally. This type helps speed up indexing since no commits need to occur in the replicas. When this type of replica needs to update its index, it does so by replicating the index from the leader. This type of replica is also eligible to become a shard leader; it would do so by first processing its transaction log. If it does become a leader, it will behave the same as if it was a NRT type of replica.

PULL: This type of replica does not maintain a transaction log nor index document changes locally. It only replicates the index from the shard leader. It is not eligible to become a shard leader and doesn’t participate in shard leader election at all.

这三种模式的主要分别是,NRT可以做主片,可以使用近实时索引(支持SOFT COMMIT),同步索引靠数据转发;TLOG也可以做主片,当为主片是和NRT一致,不能近实时索引,从片需要和主片同步的时候,只是从从片同步索引文件;PULL不能做主片,仅从主片同步索引文件。
创建分片的时候,副本默认使用的NRT模式。

Solr cloud可推荐使用的分片组合方式:

1、全部NRT:适用于小到中级的集群;更新吞吐量不太高的大型集群;

2、全部TLOG:不需要 实时索引;每一个分片的副本数较多;同时需要所有分片都能切换为主片;

3、TLOG+PULL:不需要 实时索引;每一个分片的副本数较多;提高查询能力,能够容忍短时的过期数据。

我们做了个测试:solr7.3,16个物理节点,每个节点3个实例,每个实例20G,需要索引的数据量为一亿,160个spark executors,一主两从(注:我们不需要NRT特性,我们是夜间批量)

1、全部NRT需要20分钟,大概每分钟600-800万。

2、全部TLOG需要10分钟,大概每分钟10000万。

3、TLOG+PULL:未测

PS:solr创建索引,可以先使用solr自带的zk脚本工具中uploadconfig方法上传配置文件,再使用solr的collection api里面的createcollection方法创建。

一份参考资料:

下面参考文章的原文地址:https://berlinbuzzwords.de/sites/berlinbuzzwords.de/files/media/documents/replicatypes-berlinbuzzwords.pdf

其中有启发的一张图:

solr 一主多从模式灌数据总是报错

我们有一张大宽表,大概200个字段,共有20亿左右的数据。在使用spark并行从hive导入Solr的时候,总是会报错,不是 no register leader 就是we are leader这类的错误。

后来搜索后发现这类问题有两类原因:

1、solr 内存过小,导致GC时间过长,从而让zk认为solr已经挂掉了。但是我们给了16G的内存还算不错,同时也检查了solr的gc日志,没有发现有GC时间过长的情况。

2、solr 与Zookeeper的timeout 时间过短。这正是我们的问题所在,我们在安装solr的时候没有指定solr的timeout时间。http://lucene.472066.n3.nabble.com/SOLR-zookeeper-connection-timeout-during-startup-is-hardcoded-to-10000ms-td4403341.html#a4403671

解决方法:

找到/ETC/solr.in.sh,添加配置:

ZK_CLIENT_TIMEOUT=”120000″

同时调整zookeeper的最大会话超时时间为160秒。

solr shard down无法启动

solr 上的一个collection的一个分片处于down的状态,无论如何重启solr都没有任何作用,一直是处于down 的状态。

解决办法:执行splitshard

执行以下链接:

http://serverip:9984/solr/admin/collections?action=SPLITSHARD&shard=shardname&collection=collectionname&wt=xml

刚方法会将原来down的shard,默认分为两个分片即可。

CDH5.13上独立安装Solr7.3.1

CDH5.13默认带的Solr版本号比较低,只有4.10.3。这种低版本无法支持我们的应用需求,所以只能独立安装Solr7.3.1,唯一的缺点就是无法在CDH上面统一管理了。

1、下载Solr的安装包省略,下载后解压Solr安装包。下面的流程默认解压到当前用户根目录,即 ~

2、解压solr7

tar -zxvf solr-7.3.1.tgz

3、创建ZK的solr7 root

cd ~/solr-7.3.1/bin
./solr zk mkroot /solr7 -z 10.127.60.2,10.127.60.3,10.127.60.4:2181
4、查看端口占用情况,避免端口被CDH占用
netstat -nl | grep 9983
或者
sudo netstae -nltp | grep 9983,这样可以拿到正在使用端口的pid
5、执行安装指令。如下指令,在一个物理机上建立两个solr实例。建议将每个实例的数据文件目录放在不同硬盘下。

sudo ./install_solr_service.sh ../../solr-7.3.1.tgz -i /srv/BigData/hadoop/solr1 -d /srv/BigData/hadoop/solr1/solr_data -u solrup -s solr1 -p 9983 -n

sudo ./install_solr_service.sh ../../solr-7.3.1.tgz -i /srv/BigData/hadoop/solr2 -d /srv/BigData/hadoop/solr2/solr_data -u solrup -s solr2 -p 9984 -n

6、修改 /etc/default/solr1.in.sh,改变部分参数。
----HDFS版本
SOLR_JAVA_MEM="-Xms16g -Xmx16g -Dsolr.directoryFactory=HdfsDirectoryFactory -Dsolr.lock.type=hdfs -Dsolr.hdfs.home=hdfs://10.127.60.1:8020/solr7 -XX:MaxDirectMemorySize=20g -Dsolr.autoSoftCommit.maxTime=-1 -Dsolr.autoCommit.maxTime=-1 -XX:+UseLargePages -Dsolr.hdfs.blockcache.slab.count=100"
ZK_HOST="10.127.60.2,10.127.60.3,10.127.60.4/solr7"

---本地
SOLR_JAVA_MEM="-Xms16g -Xmx16g -Dsolr.autoSoftCommit.maxTime=-1 -Dsolr.autoCommit.maxTime=-1 -XX:+UseLargePages"

ZK_HOST="10.127.60.2,10.127.60.3,10.127.60.4/solr7"

SOLR_JAVA_MEM="-Xms32g -Xmx32g -Dsolr.autoSoftCommit.maxTime=-1 -Dsolr.autoCommit.maxTime=-1 -XX:+UseLargePages"

ZK_HOST="10.127.60.2,10.127.60.3,10.127.60.4/solr7"
7、创建collection

---在zookeeper上传配置文件
bin/solr zk upconfig -z 10.127.60.2,10.127.60.3,10.127.60.4:2181 -n mynewconfig -d /path/to/configset

–参考资料:https://lucene.apache.org/solr/guide/7_3/solr-control-script-reference.html#solr-control-script-reference

./solr create -c picc_bigdata -d /zp_test/solor7/conf -n picc_bigdata -s 6

8、如果将数据温江放在HDFS上,solrup用户需要有对应的权限。在HDFS上创建目录 /solr7,同时赋予solrup用户所有权。 hdfs dfs -chown solrup /solr7

Solr索引建立优化

测试环境的硬件情况:四台pc,20颗2核,内存256G,11盘1.4T。带宽为千兆网络,最快传输速度为140MB/S。

测试情况结论:

1、Solr在使用HDFS索引的建立速度远不如本地索引。但是我们在其它公司使用的都是HDFS索引,不至于这么慢。最有可能的情况是网络传输速度不够,因为在其它公司都是使用的双万兆网卡。

2、增加Solr的实例数量,可以增加Solr的分片数量,提高写入速度。

3、每行的数据量越大,也减慢写入速度,毕竟一行的数据字段数越多,一行数据的数据量越大。

4、由于我们只使用批量导入,不是会设计到近实时索引。所以我们禁用了soft commit。而且只在批量导入完成的时候,执行一次hard commit。这样做可以极大的降低solr的压力。因为每一次hard commit或者达到soft commit的阀值的时候,就会触发solr的索引handler更替,以及一系列动作。

禁用软提交的方法:

修改 /etc/default/solr1.in.sh,设置参数-Dsolr.autoSoftCommit.maxTime=-1 -Dsolr.autoCommit.maxTime=-1;

----HDFS版本
SOLR_JAVA_MEM="-Xms16g -Xmx16g -Dsolr.directoryFactory=HdfsDirectoryFactory -Dsolr.lock.type=hdfs -Dsolr.hdfs.home=hdfs://10.127.60.1:8020/solr7 -XX:MaxDirectMemorySize=20g -Dsolr.autoSoftCommit.maxTime=-1 -Dsolr.autoCommit.maxTime=-1 -XX:+UseLargePages -Dsolr.hdfs.blockcache.slab.count=100"

---本地
SOLR_JAVA_MEM="-Xms16g -Xmx16g -Dsolr.autoSoftCommit.maxTime=-1 -Dsolr.autoCommit.maxTime=-1 -XX:+UseLargePages"

SOLR_JAVA_MEM="-Xms32g -Xmx32g -Dsolr.autoSoftCommit.maxTime=-1 -Dsolr.autoCommit.maxTime=-1 -XX:+UseLargePages"