1. 部署
通过网上博客的比较,内置zk的方式比较简单,这里暂时使用这种方式。本文部分图片整理自互联网,如有侵权请联系删除。
规划
参数 值 解释 shards 3 每个collection分为3块 replicationFactor 2 冗余备份一次 总块数 6 - 假设我打算使用3台服务器部署solrcloud,因此有3个节点,每个节点相当于一台服务器,这里我只创建了一个collection,分为3个shard,每个shard备份一次,总共3*2个部分;node1保存2个,node2 保存2个,node3保存2个shard。
借用网上一个图:
将solr/server/solr 目录下的zoo.cfg和solr.xml 复制到每一个node的solr_home下
按照自己的需求配置和修改solrconfig.xml 和schema.xml,比如自定义filed。
采用 2.1 或者 2.2 的过程启动solrcloud
选择配置的类型,basic_configs data_driven_schema_configs sample_techporducts_configs 然后根据选择的类型复制 solr/server/solr/configsets 里边的示例配置文件到自定义的solr_home;
创建collection
1
bin/solr create -c collection1 -d solr_home/conf/collection1/ -shards 3 -replicationFactor 2 -p 8983
这里-d之后指定配置文件的路径,配置文件会被上传到zookeeper。
向任意一个节点插入数据,solrcloud会自动分配到不同的shard。
2. solrcloud启动过程
2.1 内置zk
- 自行启动第一个节点 这里的8983是设置example时的第一个节点的端口号,请保持一致。这里没有指定zk的端口号,默认时solr端口号+1000,这里是9983.
1
./bin/solr -c -p 8983 -s solr_home/node1
- 自行启动其余节点 我这里是在同一台机器上测试,因此都使用不同的端口。
1
2./bin/solr -c -p 7001 -s solr_home/node2 -z 127.0.0.1:9983
./bin/solr -c -p 7002 -s solr_home/node3 -z 127.0.0.1:99832.2 外置zk
- 配置一个zk
1
2
3
4
5
6
7
8
9
10
11
12# 下载二进制
mkdir zk_cluster
wget https://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/stable/apache-zookeeper-3.5.6-bin.tar.gz
tar -zxvf apache-zookeeper-3.5.6-bin.tar.gz -C zk_cluster
cd zk_cluster
mv apache-zookeeper-3.5.6-bin/ zk1
# 设置id
mkdir zk1/data
echo 1>> zk1/data/myid
# 修改配置文件
cp zk1/conf/zoo_sample.cfg zk1/conf/zoo.cfg
vim zk1/conf/zoo.cfg1
2
3
4
5
6dataDir=/home/wbq813/zk_cluster/zk1/data
# the port at which the clients will connect
clientPort=2181
server.1=*.*.*.*:2881:3881
server.2=*.*.*.*:2882:3882
server.3=*.*.*.*:2883:3883 - 配置另外两个zk
1
2
3
4
5
6
7
8
9# 复制两份
cp -r zk1/ zk2
cp -r zk1/ zk3
# 修改id为2和3
vim zk2/data/myid
vim zk3/data/myid
# 修改配置文件的port为2282和2283
vim zk2/conf/zoo.cfg
vim zk3/conf/zoo.cfg - 启动zk
1
2
3
4# 启动
./zk1/bin/zkServer.sh start
./zk2/bin/zkServer.sh start
./zk3/bin/zkServer.sh start - 启动solr
1
2
3
4
5
6SOLR_BASE=../solr
SOLR_BIN=$SOLR_BASE/bin
ZK_HOST=localhost:2181,localhost:2182,localhost:2183
$SOLR_BIN/solr start -c -p 8983 -s ./node1 -z $ZK_HOST
$SOLR_BIN/solr start -c -p 7001 -s ./node2 -z $ZK_HOST
$SOLR_BIN/solr start -c -p 7002 -s ./node3 -z $ZK_HOST
3. 修改Filed
- 修改filed
- 更新zk中的配置文件
1
2
3COLLECTION=search_music
ZK_HOST=localhost:2181,localhost:2182,localhost:2183
$SOLR_BASE/server/scripts/cloud-scripts/zkcli.sh -zkhost $ZK_HOST -cmd upconfig -confdir ./conf/$COLLECTION -confname $COLLECTION
- 更新zk中的配置文件
- 连接检查
1
2
3# 连接检查
./zk_cluster/zk1/bin/zkCli.sh
ls /configs/search_music - 重启所有节点或者重新加载:http://110.64.66.208:8983/solr/admin/collections?action=RELOAD&name=search_music
4. 原理
- 创建索引
以solrj构建索引为例:
当SolrJ发送update请求给CloudSolrServer ,CloudSolrServer会连接至Zookeeper获取当前SolrCloud的集群状态,并会在/clusterstate.json 和/live_nodes 注册watcher,便于监视Zookeeper和SolrCloud,这样做的好处有以下几点:
- CloudSolrServer获取到SolrCloud的状态后,它能跟直接将document发往SolrCloud的leader,降低网络转发消耗。
- 注册watcher有利于建索引时候的负载均衡,比如如果有个节点leader下线了,那么CloudSolrServer会立马得知,那它就会停止往下线leader发送document。
路由document至正确的shard。CloudSolrServer 在发送document时候需要知道发往哪个shard,但是这里需要注意,单个document的路由非常简单,但是SolrCloud支持批量add,也就是说正常情况下N个document同时进行路由。这个时候SolrCloud就会根据document路由的去向分开存放document即进行分类(这里应该是有聚类,官方文档的说法见前面说的),然后进行并发发送至相应的shard,这就需要较高的并发能力。
Leader接受到update请求后,先将update信息存放到本地的update log,同时Leader还会给documrnt分配新的version,对于已存在的document,Leader就会验证分配的新version与已有的version,如果新的版本高就会抛弃旧版本,最后发送至replica。
当只有一个Replica的时候,replica会进入recoveing状态并持续一段时间等待leader重新上线,如果在这段时间内,leader没有上线,replica会转成leader并有一些文档损失。(我的理解:如果leader挂了,请求还会发送成功???? )
最后的步骤就是commit了,commit有两种,一种是softcommit,即在内存中生成segment,document是可见的(可查询到)但是没有写入磁盘,断电后数据丢失。另一种是hardcommit,直接将数据写入磁盘且数据可见。前一种消耗较少,后一种消耗较大。
每commit一次,就会重新生成一个ulog更新日志,当服务器挂掉,内存数据丢失,就可以从ulog中恢复
- Shard分裂
![20151217015557737.png](https://img.hacpai.com/file
若你觉得我的文章对你有帮助,欢迎点击上方按钮对我打赏
扫描二维码,分享此文章