Elasticsearch热备份策略

Question

如果有人可以为ElasticSearch分享他最好的“热备份”策略，那将会很有趣。

此外，随意共享与此问题相关的工具和库，可以提供帮助。

更新 感谢@javanna的回复，它非常完整，为进一步的行动提供了良好的指导。

我还进行了一项小型研究，发现一些文章/讨论可以帮助，如果有人有兴趣的话。

• Elasticsearch backup strategies
• Backup/restore Elasticsearch index和related snippet on github:gist
• Elastic Search Backup and Recovery讨论（查看Paul Smith的评论，他也分享了他tool for verifying indexes的有用链接）

更新： Elasticsearch 1.0有一个“官方”备份解决方案 - Snapshot/Restore API，这是现在唯一正确的方法。 ElasticSearch将识别主分片并注意一致性。备份将以递增方式完成，因此您可以根据需要非常快速地完成备份。

Answer 1

副本是一种备份，而弹性搜索永远不会在原始主分片所在的同一节点上分配一个副本。但是，根据您的群集中有多少分片，副本和节点，仍然存在丢失数据的风险。

我会查看Gateway模块，通过它您可以保存索引和群集元数据。有不同类型的网关。我会查看Shared FS，例如，它允许您将索引和元数据复制到所有节点之间共享的文件系统。您还可以通过Gateway Snapshot API手动启动快照。

此外，一旦您通过index.translog.disable_flush index setting禁用了刷新，您就可以复制数据目录（在每个节点上）。这样你就可以确保在复制时不会发出lucene提交。完成复制后，您需要再次启用刷新。

<强>更新

除了本地网关类型之外的所有网关类型都已弃用，将在以后的版本中删除。 Elasticsearch 1.0将通过更好的备份解决方案发布。

Answer 2

所以这违背了ElasticSearch的工作方式，但我考虑使用两个不相互识别的独立ElasticSearch实例。在您的应用程序代码中，每个命令都会发送到两个实例。如果1个实例的命令失败，请在1分钟后重试该命令，并继续重试。现在，您可以将其中一个实例保留为热备份，或者甚至可以通过在两个实例之间对查询进行负载平衡来使用它来提高性能。

我不喜欢在ElasticSearch中设置副本的原因是配置哪个节点获取哪个副本很痛苦，如果你想在将来重新安排组织，你基本上要经历大量的箍。 ElasticSearch在幕后进行了大量的重新平衡，并试图为您做一切。这可能是好的..如果你有强大的服务器而不关心什么是什么......但是否则会很痛苦。