Elasticsearch热备份策略

Question

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

同样，可以自由地分享与这个问题相关的工具和库，并且可以提供帮助。

更新：谢谢您的响应，它非常完整，为进一步的操作提供了很好的指导。

我也做了一个小的研究，并发现一些文章/讨论，可以帮助，如果有人有兴趣。

• Elasticsearch backup strategies
• Backup/restore Elasticsearch index和related snippet on github:gist
• Elastic Search Backup and Recovery讨论(查看Paul的评论，他还分享了一个有用的链接到他的tool for verifying indexes )

更新：ElasticSearch1.0有一个“官方”备份解决方案-- Snapshot/Restore API，这是现在唯一正确的方法。ElasticSearch将识别主碎片并注意一致性。备份将以增量的方式完成，因此您将能够以您想要的速度和频率执行它。

Answer 1

副本是一种备份，elasticsearch从不在原始主碎片所在的同一节点上分配副本。但是，根据集群中的碎片、副本和节点数量，仍然存在丢失数据的风险。

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

此外，一旦禁用了通过flush index setting的刷新，您也可以复制数据目录(在每个节点上)。这样，您将确保在复制时不会发出lucene提交。复制完成后，您需要再次启用刷新。

更新

除本地网关类型外，所有网关类型都已被取消，并将在以后的版本中删除。ElasticSearch1.0将发布一个更好的备份解决方案。

Answer 2

因此，这与ElasticSearch的工作方式背道而驰，但我会考虑有两个互不知情的ElasticSearch实例。在应用程序代码中，每个命令都被发送到两个实例。如果一个命令在一个实例中失败，请在1分钟后重试该命令，然后继续重试。现在，您可以将其中一个实例保留为热备份，甚至可以通过负载平衡两个实例之间的查询来提高性能。

我不喜欢在ElasticSearch中设置副本的原因是，要配置哪个节点获得哪个副本是很痛苦的，而且如果您想在未来重新安排组织，您基本上必须经历大量的循环。ElasticSearch在幕后做了大量的再平衡工作，并试图为您做任何事情。这可能是好事..。如果你有强大的服务器，而不管什么得到什么。但如果不是这样的话就会很痛苦。