AWS上的三个节点ElasticSearch群集。 Bigdesk和Head都展示了一个健康的群集。所有三个节点都运行ES 1.3,以及最新的Amazon Linux更新。当我火了像快照请求:Elasticsearch快照因存储库异常而失败
http://localhost:9200/_snapshot/taxanalyst/201409031540-snapshot?wait_for_completion=true
服务器搅动走几分钟与响应之前如下:
{
"snapshot": {
"snapshot": "201409031521-snapshot",
"indices": [
"docs",
"pdflog"
],
"state": "PARTIAL",
"start_time": "2014-09-03T19:21:36.034Z",
"start_time_in_millis": 1409772096034,
"end_time": "2014-09-03T19:28:48.685Z",
"end_time_in_millis": 1409772528685,
"duration_in_millis": 432651,
"failures": [
{
"node_id": "ikauhFYEQ02Mca8fd1E4jA",
"index": "pdflog",
"reason": "RepositoryMissingException[[faxmanalips] missing]",
"shard_id": 0,
"status": "INTERNAL_SERVER_ERROR"
}
],
"shards": {
"total": 10,
"failed": 1,
"successful": 9
}
}
}
这些是在三个不同的虚拟EC2机三个节点,但他们能够通过9300/9200进行通信而没有任何问题。索引和搜索按预期工作。弹性搜索日志文件中似乎没有任何与服务器错误有关的内容。
有没有人知道这里发生了什么,或者至少在哪里开始的好地方呢?
UPDATE:发现集群中的每个节点都需要具有与使用elasticsearch集群注册快照时指定的目录匹配的快照目录。
我想下一个问题是:当你想要快照目录,以便存档或设置备份群集时,只需在主节点上设置快照目录就足够了?或者你必须以某种方式合并所有节点的快照目录。 (这不可能是正确的,可以吗?)
我也看过这个,但是在互联网上的喋喋不休,表明S3快照是,如果不被弃用,然后气馁。 (http://bit.ly/1wEHhuL)当被问及使用什么时,我听到的答案是“使用EBS”。所以我想这给我们留下了n个节点,其中n个连接的EBS设备持有集群中每个节点状态的n个快照。我猜想当集群停止运转时,你需要启动n个新节点,并将匹配的EBS附加到每个节点上。听起来很有趣的维护练习。话虽如此,我仍在使用S3快照。 :) – IanC 2014-11-08 17:00:46
@IanC我认为你在将旧的elasticsearch S3“网关”与ES 1.2中删除的“快照”混淆起来。支持从S3备份和恢复您的elasticsearch数据。 https://groups.google.com/forum/#!msg/elasticsearch/aNUw4nFT6JE/JKDkffZT60sJ – jamshid 2015-04-23 18:12:34