前文
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查询两个信息来查看原因:文章来源:https://www.toymoban.com/news/detail-554772.html
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,将这三个目录在三个节点合并即可。文章来源地址https://www.toymoban.com/news/detail-554772.html
到了这里,关于elasticsearch 快照丢失部分的恢复 ----- 一种解决方式的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!