elasticsearch 快照丢失部分的恢复 ----- 一种解决方式

前文

  es提供了数据备份和恢复的方式，可以很方便的供数据备份，同时应用于多套环境，且可以自定义备份目标（比如具体到索引），可以自定义备份策略（比如每天早上定时备份），可以说是非常方便，关于如何备份，网上的文档很多，有机会我也出一篇。另外，关于snap和restore，通过kibana可以非常方便的管理，所以es和kibana还是非常搭配。
  本质上的备份是服务于多节点的es cluster，因为多节点，由于es本身的shards机制，会随机分配在不同的节点；而所谓的备份，则是将这些shards拷贝一份到备份目录，那么此时各个不同的shards要拷贝到同个目录就比较麻烦，所以备份要建立nfs，通过多个节点读取相同的nfs server，将数据都备份在同个目录，于是一切都轻松可解。举例说，假如是3个节点的es集群，此时需要再开发备份节点，将这个备份节点设置为nfs的server，同时将三个节点设置为nfs client，关联上nfs server的目录，实现同目录的关联。
  此次快照丢失的场景是，当我需要恢复数据的时候，发现仅2个primary shards和replica shards可以恢复，而第3个则一直不能恢复（unsigned）；而且有时恢复又变成仅恢复1个primary shard和replica shard，另外2个都恢复不了（unsigned）。所以恢复变得很随机，且不稳定。

分析

  此时要借助工具来排查，首选是 kibana 和 es-head(chrom插件)，根据这两个定位问题。
  首先在es-head上，会显示unsigned的具体是哪些分片，通过点击unsigned分片，显示原因有：

SnapshotMissingException[[backup:xxxx-htswmp2zr9ivjz8tq8uk1q/KaabJorhTfK69IaZ2T3spw] is missing]

  原因很长，这里节选最重要的，说明备份目录里名字是KaabJorhTfK69IaZ2T3spw的备份丢失，导致其无法恢复。于是登上对应的节点，进入备份目录通过find查找，发现目录的确不存在，同时发现nfs连接不上了，导致各个shards的备份存储分散在各个节点服务器上，所以出现了is missing的情况，所以直接定位到是nfs丢失连接导致的。
  如果问题原因有变，需要通过kibana查询两个信息来查看原因：

GET /_cluster/allocation/explain  # 获取集群内分配分片失败的原因，重点查看其中explanation的解释

GET _cat/shards?h=index,shard,prirep,state,unassigned.reason  # 这也是获取分片失败的原因

# 如果是偶发性的失败，或者原因不明的失败，可以尝试重新分配，执行：
POST /_cluster/reroute?retry_failed=true

解决

  识别nfs如何连接不上即能解决，直接mount nfs-server:/backup /backup，报错mount.nfs： no route to host，所以原因是nfs连接被server端拒绝了，直接关闭nfs server的firewalld（systemctl stop firewalld;systemctl disable），然后重新mount即可。
  但是上述是恢复nfs保证备份时数据都在同一个目录下，那已经执行了备份，分散在不同节点的如何处理？ 可以选择一个节点为目标，然后将另外2个节点的该目录都拷贝过来即可。举例说，我们的备份目录一般是存放在 /backup/indices/xxxx，这个xxxx就是es生成的标识md5码，此时每个节点，都有这样的目录，在这个目录下继续分 0/1/2三个目录，标识3个shard，将这三个目录在三个节点合并即可。

这篇好文章是转载于：学新通技术网