SolrCloud，感谢ZooKeeper集成，为managing和reloading核心/集合配置提供了一些很好的实用工具。
但是，这仅仅完全涵盖了琐碎更新的情况 - 但也有非平凡的更新。在这种情况下， Nontrivial 意味着导致一些更改，使更新的节点和/或其核心与以前的某些状态不兼容。
特别是，我想到了这些子句：
我的问题是：如何使用SolrCloud和相关的Zookeeper服务来使这些更新更容易，更可靠和/或确保更高的可用性？
注意：我希望有一些“理解”此类更新的API /功能。到目前为止，我发现的最值得注意的事情是CoreAdmin中的集合别名，这将允许“旧”和“新”版本之间更平滑的过渡 - 考虑到上述希望，这有点令人失望。
答案 0 :(得分：-1)
我不确定你的意思
A code update necessitating a restart of an underlying Solr instance.你的意思是Solr代码改变了吗？ （例如，在较新的版本中）或访问Solr实例的应用程序是否已更改？ （例如你的代码库）
在第一个场景中，只需启动一个新实例，并将其添加到ZooKeeper，即使版本不同，也应该是它的结尾。
在第二种情况下，访问数据的应用程序发生了什么并不重要，对吗？
然后你提到我认为最“常见”的情景
需要完全重建核心的架构更改。
如果要更改架构，这意味着您要更改某些索引，字段和/或元数据，那么您不能指望Solr不知道此更改并继续运行并返回结果，因为他们的哈希不再对应于相同的结构。
我认为这里最好的方法是尝试确定更改的深度，然后将更新的结构重新加载到新索引中，然后对应用程序执行所需的代码更改，以便查询这些新结构，或者如果允许停机时间窗口，只需删除并重建整个事物（这种攻击你的“确保更高的可用性”要求虽然）
我认为它与SQL中的DB表的热更新相同，并且使用两个版本的应用程序，旧的和新的结构，它可以通过极其谨慎的方式完成，并且您将成为如果可以的话，最好将它们分开......
不确定这是否有帮助，欢呼，
麦克