高可用性的碎片/副本设置

Question

我们在具有14个节点的集群中嵌入Elasticsearch的Java应用程序。所有数据都驻留在一个中央数据库中，并且它们在elasticsearch中进行索引以进行查询。完全重新索引可以随时完成。

系统查询量很大，写入量很小。文件数量不会高于300.000。 每个文档的大小差别很大，从几个标识符到从多个页面的单词文档中提取的文本差异很大。

我想确保在发生全面故障的情况下，一个或两个节点可用于系统正常工作。

写入一致性不应该是一个问题，因为数据的主要副本在数据库中，而且似乎ES能够通过使用最新版本解决冲突的数据（在我们的情况下，这应该是正确的）

我的第一个虽然是使用1个碎片和13个副本。这自然会确保所有节点都可以访问所有数据。这也可以通过具有2个碎片/ 13个副本来实现，所以为了确保所有数据可用，副本的数量应该是节点的数量 - 1，而不取决于碎片的数量（这可以是任何）。

如果节点数量的要求减少到“2个节点应该随时启动”，那么“x /节点数量-2”的分片/副本分布应该足够了。

所以，对于这样的问题：

断言上面的设置，我的想法是正确的，将与1分片建立/ 13副本意义或会有任何通过增加更多的碎片，以获得和运行如4个分片/ 13个副本设置？

Answer 1

经过一段时间的研究并与ES-gurus交谈之后;

只要分片大小足够小，设置此集群的最有效方式的确只有1个分片，有13个副本。我一直无法精确定位碎片的阈值大小，从而使这个开始变得更糟。

Answer 2

如果索引很大...您将需要多个碎片（如果您想要性能）。你真的需要13副本吗？当你只放2个副本时，ES管理它以保持它的方式，如果主节点失败，ES将创建一个新的答复。也许你会需要一个平衡器节点。