zl程序教程

您现在的位置是:首页 >  数据库

当前栏目

Elasticsearch 之 慘痛部署(分片移位)

elasticsearch部署 分片 移位
2023-09-11 14:14:42 时间

部署说明

硬件

server两台:
机器A:64G内存
机器B:32G内存

分片

共12个节点
2个查询节点。10个存储节点
8个主分片
1个复制分片(每一个分片都有一个副本分布在不同的节点上面)
每台机器都挂了6个机械盘每一个盘都是不同的分区。

部署环境用docker weave 来做 elasticsearch cluster
能够參考我的另外一篇博文:
http://blog.csdn.net/mrsunnycream/article/details/50921012

就这样环境默默的部署着。一切都非常顺利。


部署完毕后開始导入数据,导入一部分数据后(因为数据量比較大),就关机下班了。

大约有几十G左右。

第二点上班后要继续导入数据。开机,启动weave,启动Es 集群,
然后查看集群状态:red. 我想了下主分片不可用?不可能啊,是不是有的节点没有增加集群呢,然后查看weave 状态。两台机器都互相Ping一下 weave 转发的路由,一切都是通的,过了一会还是red,不淡定了,查看集群节点数量12个。对啊没错啊,怎么回事呢?然后又去看日志,没有报什么错误。如今真的開始不淡定了。


然后就用 _cat/shards,来查看究竟是哪个分片出问题了。

结果看到7号分片没有挂载到集群里面


出现这个问题感觉非常诡异啊,即使主分片找不到,副本也能顶上去啊。

这个问题发现越来越大了。我勒个乖乖。

每一个节点的数据都是挂载到不痛的机械盘上的也就是不同的分区上面的。

然后就一个一个分区的挨着找,然后查看分区数量也没错。进去分区中看看昨天传送数据的时候七号分片在那个盘上面。当找到第三个分区的时候发现 明明是两个节点的数据挂在这个分区上面怎么这个分区上面有五个节点的数据。哎開始头晕啊。没办法继续找原因吧,可是发现这个分区的两个节点中有七号分片,可是一点数据都没有,又看看其他的几个数据文件夹是正常的,然后紧跟着查看其他分区的情况发现第四个分区也是这种情况,感觉跟发生了灵异事件差点儿相同,命名配置的节点数据都在指定的分区上面(就是Docker挂在不通的文件夹以下),假设把第三个分区和第四分区的文件夹调换一下就应该是正确了。

可是也不能手动的移动文件夹吧,还得找问题出在什么地方吧。

我用了以下的办法
在每一个分区上面建立一个文件,文件名称字就和分区编号一样。紧接着我关机,再次又一次启动机器发现有的文件名称称和自己所在的分区编号不一致(当然经过多次关机和开机測试的)。

我勒个乖乖啊,如今大家可能想到问题的根源了啊。

原来是挂盘出现的问题,最后把原来的盘符名称改成UUID后问题就攻克了。
打开 /etc/fstab这个文件。把上面的/dev 开头的换成以下UUID开头的即可了

先在机器上面运行sudo blkid命令
然后依照相应关系进行替换,例如以下所看到的

stat and raid
/dev/sdb1 /opt/lucy1 ext4 defaults 0 0
/dev/sdc1 /opt/lucy2 ext4 defaults 0 0
/dev/sdd1 /opt/lucy3 ext4 defaults 0 0
/dev/sde1 /opt/lucy4 ext4 defaults 0 0
/dev/sdf1 /opt/raid ext4 defaults 0 0

UUID=aaaaa-aaa-aaaa-aaa-aaaa /opt/lucy1 ext4 defaults 0 0
UUID=bbbbb-bbb-bbbb-bbb-bbbb /opt/lucy2 ext4 defaults 0 0
UUID=ccccc-ccc-cccc-ccc-cccc /opt/lucy3 ext4 defaults 0 0
UUID=ddddd-ddd-dddd-ddd-dddd /opt/lucy4 ext4 defaults 0 0
/dev/sdf1 /opt/raid ext4 defaults 0 0
真是一个悲伤的故事!

。!