elasticsearch集群数据迁移之乾坤大挪移——snapshot

        对于使用elasticsearch的用户而言有个事情不可避免,也比较棘手,那就是索引库的迁移,包括它的数据、mapping等等信息,最近公司正好遇到了这个问题,需要对集群数据进行迁移,在网上查了很多资料,自己又通过自己的实际情况做了一次数据迁移工作,折腾了几天终于尘埃落定了,为此就在这里总结一下迁移的过程。

一、问题背景

       因为原来的服务器集群容量比较少,应用型的服务器容量也就是30G左右,对于大几千万的数据肯定是吃不了的,导致后续数据存储不了了,可能有人会说增加节点不就行了,是呀,我也想这么干呀,无奈的是对于公司 而言得考虑成本,一台服务器成本十几万,预估了下全部数据弄完大概需要8台,几百万就没了,因此在本地搭了三台服务器,每台容量500G。集群搭好后就开始进行数据迁移了。

二、迁移方式

       对于数据的迁移网上也有很多方式,本文用的是snapshot快照的方式,这种方式速度快,并且很适用于大数据量的迁移。

三、遇到的问题

      (1)对于源集群的快照生成,容量不够问题,迁移的原因就是容量不够,快照怎么生成呢?解决办法是挂载到一台新的服务器进行快照的生成

      (2)拷贝快照也是问题,对于内网服务器而言,外网不方便拷贝。解决办法通过运维同事挂载到一台FTP服务器,最后通过局域网进行续点下载

      (3)对于目标集群快照恢复总是报错:{"error":{"root_cause":[{"type":"repository_missing_exception","reason":"[my_backup。。。。。

      我只能说遇到问题不要慌,首先要分析问题,不要盲目的baidu,结果一推无效信息。字面上就是仓库缺失问题,my_backup这个玩意不存在,重新建立就ok了,原来恢复的时候要在目标集群中建立一个和源集群一模一样的快照仓库,最终问题得到恢复。

    (4)在快照恢复的过程中,出现如下:

elasticsearch集群数据迁移之乾坤大挪移——snapshot_第1张图片

不要慌,这也是正常的,正在恢复中,不要心急,恢复也需要时间,大家可以通过命令进行监控:

curl -XGET http://172.28.xx.xx:9200/_recovery


 会详细展示每个节点的恢复进度,监控结果如下:

elasticsearch集群数据迁移之乾坤大挪移——snapshot_第2张图片

四、迁移过程之快照备份

(1)源集群节点进行目录挂载

使用sshfs进行挂载:
 
// 在每台机器上安装sshfs
yum install fuse-sshfs
【千万注意】安装命令前,必须先安装EPEL源,否则会一直提示命令不存在:
yum install epel-release.noarch
// 每台机器上创建Mount共享目录
mkdir /home/bbk/data/backup_es
//在每一台节点上执行挂载远程机子的命令
sshfs [email protected]:/home/bbk/data/backup_es /home/bbk/data/backup_es -o allow_other
//最后可以卸载挂载点
fusermount -u /home/bbk/data/backup_es
//如果上述执行提示:device is busy,则执行下面
umount -fl /home/bbk/data/backup_es

(2)在源集群建立ES仓库

curl -XPUT http://192.168.xx.xx:9200/_snapshot/my_backup -H  'Content-Type: application/json' -d '{
     "type": "fs",
     "settings": {
         "location": "/data/backup_es", 
         "compress": true
     }
}'
//查看仓库状态
curl http://192.168.xx.xx:9200/_snapshot
{
    "my_backup": {
        "settings": {
            "compress": "true",
            "location": "/data/backup_es"
        },
        "type": "fs"
    }
}

(3)设置elastic集群中的配置文件elasticsearch.yml,并重启集群:

path.repo: ["/data/backup_es"]

(4)在源集群创建快照备份

// 针对具体的index创建快照备份(可以指定1个快照1个索引,或1个快照多个索引)
// 后面会依据快照的名称来进行恢复
curl -XPUT http://192.168.xx.xx:9200/_snapshot/my_backup/snapshot_name_youdao -H  'Content-Type: application/json' -d '{
    "indices": "index_question_youdao"
}'

//查看快照状态
curl -XGET http://192.168.11.78:9200/_snapshot/my_backup?pretty

{
  "my_backup" : {
    "type" : "fs",
    "settings" : {
      "compress" : "true",
      "location" : "/data/backup_es"
    }
  }
}

注意】快照名称必须是小写

成功之后,备份已经异步开始了。可以查看备份状态:

curl http://192.168.11.78:9200/_snapshot/my_backup/snapshot_name_youdao/_status

elasticsearch集群数据迁移之乾坤大挪移——snapshot_第3张图片

五、迁移过程之快照恢复

(1)在新(目标)集群创建挂载点

   具体同上,这里可以把挂载的目标设置为某台节点下面快照恢复的目录

(2)创建同源集群一样的ES仓库

curl -XPUT http://172.28.yy.yy:9200/_snapshot/my_backup -H  'Content-Type: application/json' -d '{
     "type": "fs",
     "settings": {
         "location": "/data/backup_es", 
         "compress": true
     }
}'

(3)设置elastic集群中的配置文件elasticsearch.yml,并重启集群:

path.repo: ["/data/backup_es"]

(4)进行恢复命令

curl -XPOST http://172.28.162.113:9200/_snapshot/my_backup/snapshot_name_youdao/_restore?wait_for_completion=true

wait_for_completion=true表示,直到备份完成进行结果返回

(5)可以监控恢复状态

如果想监控恢复的进度,您可以使用 recovery API用来展示集群中移动着的分片状态:
curl -XGET http://172.28.162.113:9200/_recovery

最后好了后就看到了迁移成功的集群:

elasticsearch集群数据迁移之乾坤大挪移——snapshot_第4张图片

以上就是一次ES集群迁移的过程,网上得到终觉浅,觉知此事要躬行呀。

喜欢的可以点个赞哦。

 

你可能感兴趣的:(大数据)