掘金 后端 ( ) • 2024-04-26 14:37
基于elasticsearch的快照机制实现集群的数据迁移
elasticsearch 集群 快照 数据

一、背景

因为各种原因，我需要将环境A的ip分别为172.17.3.132，172.17.3.133，172.17.3.134组成的es集群的所有数据迁移至环境B的ip分别为172.16.129.184，172.16.129.185，172.16.129.186的es集群中，以下是我基于elasticsearch的快照机制完成数据迁移的整个过程。希望可以给有相同业务场景的朋友以参考。

二、源服务器（环境A）集群数据导出

1、创建快照存储库

（1）、集群中的每台es服务器修改elasticsearch.yml配置：

这行配置主要是指定es存储库可以创建的路径，当然你需要提前创建好对应的文件目录， 下面是我的配置：

path.repo: ["/data/to/kibana/snapshot"]

然后重启每台es服务器

（2）、创建es的存储库

这边的方式有多种: 如果你有kibana的控制台：

image.png

输入存储库名字，按图操作

image.png

image.png

你也在开发工具中可以通过指令创建：

image.png

PUT /_snapshot/kibana_backup
{
  "type": "fs",
  "settings": {
    "location": "/data/to/kibana/snapshot"
  }
}

如果你只有linux的界面： 可以在其中一台es服务器上curl创建; 可以参考一下指令，当然你需要自己替换ip和端口

curl -X PUT "http://<elasticsearch_host>:<port>/_snapshot/kibana_backup" -H 'Content-Type: application/json' -d' { "type": "fs", "settings": { "location": "/data/to/kibana/snapshot" } }'

2、生成索引快照

（主要以kibana控制台操作为主） 生成所有索引的快照指令：

POST /_snapshot/kibana_backup/snapshot_1

如果你只需要生成指定索引快照指令： 例如：索引名为（blockhead）

PUT /_snapshot/kibana_backup/snapshot_1
{ "indices": "blockhead" }1.2.3.4.

然后等待快照生成（应该是异步生成的，需要等待），当然可以在kibana中看快照是否完成

image.png

3、迁移数据至目标服务器集群（环境B）

生成的快照会放在三台服务器的/data/to/kibana/snapshot下生成文件，如图

image.png

这里的snapshot2是我的第二个存储库，可以忽略不看

我这边是将源服务器（环境A）的三台的/data/to/kibana/snapshot打包再分别拷贝到目标服务器（环境B）的三台服务上的。 为了方便我这边建议快照也解压放在目标服务器（环境B）的/data/to/kibana/snapshot路径下

三、目标服务器集群（环境B）从快照中恢复数据

1、创建快照存储库

（1）、目标服务器（环境B）集群中的每台es服务器修改elasticsearch.yml配置：

这行配置主要是指定es存储库可以创建的路径，当然你需要提前创建好对应的文件目录， 下面是我的配置：

path.repo: ["/data/to/kibana/snapshot"]

然后重启每台es服务器

（2）、搭建目标服务器（环境B）的NFS文件共享机制

具体的搭建方式和步骤我这边就不描述了（因为我自己尝试搭建，然后失败了。不得不找了个专业的运维同事来帮忙搭建了--我其实是个开发），最终需要确保：环境B的/data/to/kibana/snapshot目录为 172.16.129.184，172.16.129.185，172.16.129.186这三台服务器的共享目录，并且三台服务器的es用户对这个目录拥有读写的权限。

（3）、解压源服务器（环境A）的快照

（已经做了，可以忽略此步骤） 解压至目标服务器（环境B）的/data/to/kibana/snapshot路径下

（4）、生成目标服务器（环境B）存储库

此步骤需要在完成上述步骤后执行，不然此存储库可能没法识别到快照文件

image.png

PUT /_snapshot/kibana_backup
{
  "type": "fs",
  "settings": {
    "location": "/data/to/kibana/snapshot"
  }
}

虽然我这边在检验存储库的时候，还是有权限的报错，但是我这边好像实际没有什么影响，可以忽略。不过你得确保目标服务器（环境B）的NFS文件共享机制没有问题，并且都赋予了对应的权限

image.png

image.png

2、从快照中恢复数据

如果一切正常，你的存储应该就能识别到有一个快照文件

image.png

（1）、删除目标服务器（环境B）中的索引

因为我接受环境A的所有数据，所以在还原前得把服务器（环境B）中的索引全部删除掉，当然你也可以使用快照把B的数据提前备份，但是建议不要放在一个存储库里，以免数据错乱了

（2）、指令恢复

然后你就可以通过指令来恢复数据：

恢复所有索引：

POST /_snapshot/kibana_backup/snapshot_1/_restore

恢复指定索引： 以索引blockhead为例： 当然你也需提前删除掉目标服务器（环境B）的blockhead索引

POST /_snapshot/kibana_backup/snapshot_1/_restore
{   
  "indices": "blockhead",  
  "rename_pattern": "index_(.+)",   
  "rename_replacement": "blockhead_$1"}1.2.3.4.5.6.
}

然后就是等待数据慢慢生成，因为是异步线程恢复的，需要等待

正在恢复的索引状态应该是yellow,恢复好的应该是green

image.png