Warning: file_get_contents(/data/phpspider/zhask/data//catemap/6/apache/8.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181

Warning: file_get_contents(/data/phpspider/zhask/data//catemap/9/solr/3.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
主从设置中的Apache Solr故障切换支持_Apache_Solr_Backup_Replication_Failover - Fatal编程技术网

主从设置中的Apache Solr故障切换支持

主从设置中的Apache Solr故障切换支持,apache,solr,backup,replication,failover,Apache,Solr,Backup,Replication,Failover,我们的开发团队目前正在考虑将我们的搜索系统迁移到ApacheSolr,我们非常感谢您提供一些关于安装的建议。我们正在索引大约2亿个数据库行。我们每天增加大约十万行。这些新数据库行必须在收到后两分钟内可搜索 我们不希望索引使搜索者陷入困境,因此我们的想法是在复制设置中让两台Solr服务器在不同的机器上运行。第一个Solr实例将是索引器。它将使用DataImportHandler对增量进行索引,并启用自动提交功能以防止提交率过高。索引优化将在预定期间进行。第二个Solr实例(从机)将是主搜索程序,其

我们的开发团队目前正在考虑将我们的搜索系统迁移到ApacheSolr,我们非常感谢您提供一些关于安装的建议。我们正在索引大约2亿个数据库行。我们每天增加大约十万行。这些新数据库行必须在收到后两分钟内可搜索

我们不希望索引使搜索者陷入困境,因此我们的想法是在复制设置中让两台Solr服务器在不同的机器上运行。第一个Solr实例将是索引器。它将使用DataImportHandler对增量进行索引,并启用自动提交功能以防止提交率过高。索引优化将在预定期间进行。第二个Solr实例(从机)将是主搜索程序,其索引将存储在被突袭的固态驱动器上


我们关心的是故障切换。我们的搜索任务至关重要。如果主搜索器由于任何原因停止,我们的搜索服务将自动将查询转移到索引器节点。不过,索引也同样重要。如果索引器死了,我们需要有一个热的故障转移备用。是否有一种推荐的方法可以在Solr复制中自动执行主节点故障切换?我已经开始研究ZooKeeper,但我不确定这是否是最好的方法。

正如您所确定的,可以使用复制来处理搜索故障转移

主故障切换有点棘手。一个想法类似于下面的逻辑设置

+--------+       +--------+
|  Slave |  ...  |  Slave |
+--------+       +--------+
     |               |
     v (replicate)   v
+---------------------------+
|     Load balancer         |
+---------------------------+
         /         \
        v           v
+--------+       +--------+
| Master | --->  | Master |
+--------+       +--------+
  • 为了使主索引保持最新,可以使用热备份主索引可以从主索引复制的模式
  • 或者
    • 使用主主机上的
      Ping
      处理程序作为保持活动状态通知。如果无法访问,请编写一个小的编程组件,该组件将触发辅助主机的数据导入处理程序来接管
    • 在所有主服务器上保持数据导入处理程序处于活动状态,允许它们中的任何一个在无需额外配置的情况下接管操作
请注意,您可能需要配置负载平衡器,以便从机在任何时间点只能从一个主机进行复制


顺便说一句,听听你的一些经验对如此庞大的数据集进行索引是很有趣的

谢谢你的反馈,约翰。Solr邮件列表上的人推荐了类似的设置。索引如此大量的行确实带来了一些独特的挑战。一个完整的索引至少需要八个小时,因此任何模式更改都非常耗时。尽管索引大小不同,但单个查询的性能出人意料地好,只有少数例外。模糊搜索有时需要几秒钟才能完成,我们最初在日期范围查询方面遇到了问题。通过1)将索引字段的粒度降低到日级别,以及2)将日期字段的类型TrieDate切换为非常低的precisionstep值,我们成功地减少了日期范围查询的查询时间。看到Solr以这种方式推送真的很有趣。内存消耗曾经是您的问题吗?在索引期间内存消耗非常低,但在索引优化期间,当磁盘缓存快速填充时,内存消耗会急剧增加。这只是我们希望索引远离搜索者实例的原因之一。我还不能为搜索者提供更多关于内存使用的细节,但是大量的缓存会很快消耗大量的内存。一旦我们有了额外的硬件,我们就会知道更多。我计划设置一个主节点和一个搜索器,然后从我们旧的搜索系统的活动日志中重放一天的搜索。这似乎是一个合理的策略。您可能知道,缓存可以进行广泛的调优。一个好主意是完全关闭主服务器上的缓存,甚至节省地将其分配给搜索者。我曾尝试将repeater用作备份主服务器,但当主服务器关闭时,repeater无法复制到从属服务器,有人能帮我吗?我的帖子在这里()