当 Solr 运行内嵌 zookeeper 服务时,默认使用 solr 端口+1000 作为客户端口,另外,solr 端口+1 作为 zookeeper 服务端口,solr 端口+2 作为主服务选举端口。所以第一个例子中,Solr 运行在 8983端口,内嵌 zookeeper 使用 9983 作为客户端端口,9984 和 9985 作为服务端口。
内嵌启动的SolrCloud的例子点击:http://wiki.apache.org/solr/SolrCloud
1).创建接口(第一种自动分配)
这样会出来一个collection,它有3个shard,每个shard有1个数据节点,1个备份节点,即该collection共有6个core
参数:
name:将被创建的集合的名字
numShards:集合创建时需要创建逻辑碎片的个数
replicationFactor:分片的副本数。replicationFactor(复制因子)为 3 意思是每个逻辑碎片将有 3 份副本。
maxShardsPerNode:默认值为1,每个Solr服务器节点上最大分片数(4.2新增的)
注意三个数值:numShards、replicationFactor、liveSolrNode(当前存活的solr节点),一个正常的solrCloud集群不容许同一个liveSolrNode上部署同一个shard的多个replic,因此当maxShardsPerNode=1时,numShards*replicationFactor>liveSolrNode时,报错。因此正确时因满足以下条件:numShards*replicationFactor<liveSolrNode*maxShardsPerNode
createNodeSet:如果不提供该参数,那么会在所有活跃节点上面创建core,如果提供该参数就会在指定的solr节点上创建core
例如我现在在5台tomcat上面创建3个片,1个副本,不提供该参数结果是这样的
提供该参数例如:createNodeSet=192.168.66.128:8083_solr,192.168.66.128:8081_solr,192.168.66.128:8082_solr
结果是这样的
collection.configName:用于新集合的配置文件的名称。如果不提供该参数将使用集合名称作为配置文件的名称。
创建接口2(手动分配)实例:通过下面多个链接进行创建(3个分片,每个节点上面一个备份)推荐使用,因为这种方式你想创建多少次就多少次
参数含义:
name:新建core的名称
创建的core的命名规则:
coreName_shardName_replicaN
例如:创建pscp的集合,2个分片,每个分片上面有两个备份
则命名如下:
pscp_shard1_replica1
pscp_shard1_replica2
pscp_shard2_replica1
pscp_shard2_replica2
shard:指定一个分配id,这个core将挂在那个分片上(随便写,如果还没有这个id,第一次会帮你创建)
collection.configName:从zookeeper中指定一份配置文件
instanceDir和dataDir:从下图看出他的含义
命名规则:instanceDir与name的名称相同,dataDir:统一建议命名为data
总结一:在一个集群中添加一个副本的两种方式
2).删除接口
参数:
name:将被创建的集合别名的名字
collections:逗号分隔的一个或多个集合别名的列表
3).重新加载接口,这个时候,相应的core会重新加载配置文件
参数:
name:将被重载的集合的名字
4).分割碎片接口
collection:集合的名字
shard:将被分割的碎片 ID
这个命令不能用于使用自定义哈希的集群,因为这样的集群没有一个明确的哈希范围。 它只用于具有plain 或 compositeid 路由的集群。该命令将分割给定的碎片索引对应的那个碎片成两个新碎片。通过将碎片范围划分成两个相等的分区和根据新碎片范围分割出它在父碎片(被分的碎片)中的文档。新碎片将被命名为 appending_0 和_1。例如:shard=shard1 被分割,新的碎片将被命名为 shard1_0 和 shard1_1。一旦新碎片被创建,它们就被激活同时父碎片(被分的碎片)被暂停因此将没有新的请求到父碎片(被分的碎片)。该特征达到了无缝分割和无故障时间的要求。原来的碎片数据不会被删除。使用新 API 命令重载碎片用户自己决定。该特性发布始于 Solr4.3,由于 4.3 发布版本发现了一些 bugs,所以要使用该特性推荐等待 4.3.1
之所以能分布式是因为引入ZooKeeper来统一保存配置文件,故而需要将SolrCloud的配置文件上传到ZooKeeper中,这里演示命令行进行上传
要使用命令行管理管理工具,必须要先有包,这些包就是solr.war里面/WEB-INF/lib下面的所有jar包
第一步:新建文件夹
在可以和Zookeeper集群通讯的任意一台机子上面,新建两个文件夹,例如如下是我的目录
/usr/solrCloud/conf/files /usr/solrCloud/conf/lib
files:用来保存配置文件 lib:用来存放jar包
第二步:上传需要使用的jar和配置文件
上传jar到lib目录,将solr发布包下面的jar(solr-4.8.0\example\solr-webapp\webapp\WEB-INF\lib\ 和 solr-4.8.0\example\lib\ext\ 下面包都要)全部上传到上面的lib目录
将solr的配置文件上传到上面的files目录下面
第三步:将文件上传Zookeeper进行统一管理
-cmd upconfig:上传配置文件
-confdir:配置文件的目录
-confname:指定对应的名称
查看文件是否已经上传到Zookeeper服务器:
第四步:将上传到ZooKeeper中配置文件与collection相关联
-cmd linkconfig:为指定collection"绑定"配置文件
-collection:上面指定的collection的名称
-confname:zookeeper上面的配置文件名称
上面这句代码的意思就是:创建的core(collection1)将使用myconf这个配置文件
例如:执行下面这个请求将创建一个core为collection1,那么他使用的配置文件为zookeeper中的myconf这个配置
话又说回来,如果zookeeper管理的集群上面仅有一份配置,那么创建的core都会用这份默认的配置。如果有多份,如果没有执行第四步,随便创建一个core将抛出异常,构建失败!
例如执行:
将抛出:因为上面有两份配置,但是并没有执行第四步,将配置与即将创建core(name=sdf)关联起来
当然了第四步也可以用下面替换,而且下面这个更灵活,推荐使用(有了这步,第四步完全可以省略)
文档写到这里,下面来看下怎么对上传到zookeeper中的文件进行修改和删除操作:
修改的常用做法就是:重新上传,重新上传会覆盖上面的文件,从而达到修改的目的
删除zookeeper中的文件或者目录的方式如下:
将配置上传到zookeeper,如果要让正在运行的solr同步加载这些文件,只需要需要让solr重新加载一下配置文件,在浏览器中输入
转自: http://eksliang.iteye.com/blog/2124078
写的非常好,收藏