solrCloud..

最新推荐文章于 2024-09-25 13:18:48 发布

键盘上的孤舞者

最新推荐文章于 2024-09-25 13:18:48 发布

阅读量695

点赞数

分类专栏： solr 文章标签： solr

本文链接：https://blog.csdn.net/king_sky_wjb/article/details/25797653

版权

solr 专栏收录该内容

14 篇文章 0 订阅

订阅专栏

#SolrCloud#
##Getting Started with SolrCloud##

###Two-Shard Cluster with Replicas###
为了提供高可用，你可以创建副本，or copies of each shard that run in parallel with the main core for that shard。这个架构包括原始的分片，被称为leaders，他们的副本，包括同样的数据但是让这个leader处理所有的管理任务比如保证数据到任何他们应该到的地方。这样，如果一个分片的拷贝挂掉，数据仍然可用并且集群能够继续行使职责。

开始：创建两个最新的example目录的拷贝：

```

cd $SOLR_HOME

cp -r example/ node3/
cp -r example/ node4/

```

和我们上一节中创建的两个分片一样，你可以将这两个目录命名为任何你想的名字。

如果你还没有运行上一节中创建的两个实例，去运行它。在这里，只是简单的添加实例的问题，开始运行node3：

```
cd node3
java -Djetty.port=8900 -DzkHost=localhost:9983 -jar start.jar

```

注意。这里的参数和刚开始启动的第二个节点完全一样。你只是仅仅把一个新的实例指向了最初的ZooKeeper。但是如果你看SolrCloud admin 页面，你将会看到它不是以第三个分片被添加，而是作为第一个的副本。

这是因为集群已经知道只有两个分片并且他们已经被指定。所以新的节点被作为副本添加，相似的，当你添加第四个实例，他被作为第二个分片的副本添加。

如果你添加额外的实例，及全将会已这种方式继续循环，作为必要的副本添加。Replicas are attached to leaders in the order in which they are started, unless they are assigned to a specific shard with an additional parameter of shardId (as a system property, as in -DshardId=1, the value of which is the ID number of the shard the new node should be attached to). Upon restarts, the node will still be attached to the same leader even if the shardId is not defined again (it will always be attached to that machine).

所以现在我们在那里？你现在已经有四个服务器处理你的数据。如果你发送数据到副本，像这样：

```
curl http://localhost:7500/solr/update?commit=true -H "Content-Type: text/xml" -d "@money.xml"
<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader"><int name="status">0</int><int name="QTime">2146</int></lst>
</response>

```
事件的过程时这样的：

1. 副本（在这里在服务器的7500端口）得到请求
2. 副本把请求转到他的leader（这里时服务器的7574）
3. leader处理请求，并且保证所以他的副本处理也这样请求

这种方式下，到任意运行的实例的请求都是可用的，你可以发送以下请求验证：

http://localhost:8983/solr/collection1/select?q=*:*
http://localhost:7574/solr/collection1/select?q=*:*
http://localhost:8900/solr/collection1/select?q=*:*
http://localhost:7500/solr/collection1/select?q=*:*

但是这个时怎样帮助实现高可用的呢？简单的说，一个集群必须至少有一个运行的服务器为每一个分片来保证它行驶职责。要做这个，关闭7574端口的服务器，检查其他服务器。

http://localhost:8983/solr/collection1/select?q=*:*
http://localhost:8900/solr/collection1/select?q=*:*
http://localhost:7500/solr/collection1/select?q=*:*

你应该可以继续看到全部的数据集合，甚至其中的一个服务器消失了。实际上，你可以关闭多个服务器，只要每一个分片至少有一个实例运行，集群将会继续运行。如果leader宕机-就象在这个例子中-一个新的leader将从剩下的副本中被“选举”（selected）。

现在当我们谈到服务器宕机，在这个例子中，一个特别的服务器保持运行是非常重要的，这个就是运行在端口8983上的服务器。因为正是这个实例运行着ZooKeeper.If that goes down, the cluster can continue to function under some circumstances, but it won't be able to adapt to any servers that come up or go down.

这种单点谷中很明显时不能接受的。幸运的，有一个解决方案：multiple ZooKeeper。