Background

Migration

先说结论,最终是没有实现 zero downtime。参考了几个不停机迁移方案以及现有的业务模型和数据规模,感觉过程实现成本和风险远远大于短暂的停机,所以选择了在凌晨重启服务加入了两个新的节点构成集群并在 data nodes 之间同步数据,修改配置和加入集群期间服务不可用大概一分钟多,新的 data node 同步百G级数据完成大概用了4个小时。这一分钟左右没有出现更新操作(凌晨原因),新增操作在后续通过脚本做了补充。

关于不停机迁移的方法也看了几个现成的方法诸如

https://blog.engineering.ticketbis.com/elasticsearch-cluster-migration-without-downtime/
https://thoughts.t37.net/migrating-a-130tb-cluster-from-elasticsearch-2-to-5-in-20-hours-with-0-downtime-and-a-rollback-39b4b4f29119

多半离不开版本号和更新时间这两个字段,迁移过程区分迁移前的数据和迁移过程中新增的数据,在迁移完毕时把新数据再同步一次,这就要求数据只有 create 没有 update 操作在迁移过程中发生,感觉不太适合除了自增类型的例如日志以外的其他业务逻辑。

关于集群,需要至少3个 master eligible node 以防止脑裂,并把其中两个设置为 data node 承载数据,在磁盘的扩充过程中给每个节点挂载数据盘,方便日后扩容。

以其中一个节点为例,几个比较重要的配置是

discovery.zen.ping.unicast.hosts: ["10.66.90.77:9300", "10.66.91.150:9300", "10.30.55.37:9300"]
network.host: ["10.30.55.37", _local_]

作为有限且小规模的集群,为 discovery module 指定广播发现节点的私有地址列表,同时允许各个节点在本机的访问调试.

Summary

总之如果不是追求绝对的不停机,并且不愿意增加额外的字段或改变自己的逻辑,es提供的加入集群方式来做迁移数据在我看来是相当简便又稳定的一种方式。

后续应该会在众多开源产品中选择一种 monitor 让集群和服务的状态更透明、报警和响应更及时。