☰

备份 Elasticsearch 中的旧索引

tag-icon • tag-icon elasticsearch
备份 Elasticsearch 中的旧索引

我们有一个 ELK (ElasticSearch-Logstash-Kibana) 部署，我们通过 logstash 将日志发送到 Elasticsearch 集群。每天创建索引。我们关闭超过 3 天的索引，并对超过 7 天的索引进行快照，并通过策展人将其推送到 Amazon S3。

我们每天有大约 10 个不同的索引，每个索引的平均大小约为 1GB。复制因子为 1。每个索引有 2 个分片。Logstash 以每秒 2000 个 log_events 的速率将数据推送到 ES 集群

我们的拓扑

  • 3 专用主服务器 + 数据服务器
  • 1 个专用客户端节点 + Kibana

硬件配置

  • 12 核心
  • 64 GB 内存
  • 2 TB 旋转磁盘
  • Debian 7
  • ElasticSearch 版本 - 1.7.1
  • Logstash——1.5.3

所有标准配置都已遵循，例如发现中的单播模式，并分配了 30 GB RAM。

目前，快照作业通过客户端计算机上的策展人运行，请求本地发送到客户端计算机上运行的 ES 实例。Logstash 直接将日志发送到客户端节点

正在使用的 curator 命令：-

curator --timeout 21600 --host es-client --port 9200  snapshot --name $snapshot_name_$project-$date --repository walle_elk_archive indices --older-than 3 --time-unit days --timestring %Y-%m-%d --prefix $prefix

有人可以在以下方面帮助我吗：-

  1. 像我们所做的那样，在客户端机器上运行策展人工作可以吗？
  2. 从一台机器上获取所有索引的快照可以吗？
  3. 由于日志被不断推送，在创建快照并推送到 Amazon S3 时是否会导致集群不稳定？
  4. 人们通常遵循哪些最佳做法来备份 Elasticsearch 的旧索引？

答案1

像我们所做的那样，在客户端机器上运行策展人工作可以吗？

是的，因为“客户端”机器除了向您的 ES 集群发送 REST 请求并等待响应之外没有执行任何操作。

从一台机器上获取所有索引的快照可以吗？

再次，是的。原因与第一个问题相同。

由于日志被不断推送，在创建快照并推送到 Amazon S3 时是否会导致集群不稳定？

根据 ES 文档快照和还原

Snapshotting process is executed in non-blocking fashion. All indexing and searching 
operation can continue to be executed against the index that is being snapshotted.

索引速度可能会略有减慢，但根据您的机器规格，我认为它可能会没问题，但除非您尝试，否则真的没有办法知道。快照速度的限制因素可能是共享文件系统存储库的磁盘，以及 S3 存储库的 Internet 连接速度。

关于使用 S3 存储库以及这会如何影响流程，文档关于 S3 存储库插件的实际工作原理，我怀疑每个持有主分片的数据节点都会将其分片推送到存储库（S3 或其他）。这意味着在对 S3 存储库执行快照时，ES 集群上的负载可能不会比对共享文件系统存储库的负载更大。
再次，测试因为每个环境都是独一无二的，对一个人有用的方法不一定对另一个人有用。

人们通常遵循哪些最佳做法来备份 Elasticsearch 的旧索引？

我发现 ES 有相当好的文档，其中有一节关于快照和还原。实际上，那里面并没有太多关于“最佳”实践的内容，所以除非你在网上遇到其他资源，否则我会说你最好的选择是开始尝试，看看什么对你有用。

相关内容