Elasticsearch集群数据迁移

参考

https://www.elastic.co/guide/en/elasticsearch/reference/5.0/modules-snapshots.html
https://www.elastic.co/guide/en/elasticsearch/guide/current/_rolling_restarts.html
https://blog.csdn.net/u014431852/article/details/52905821

环境

阿里云elasticsearch集群5.0版本
微软云elasticsearch集群5.6版本

需求

需要把阿里云elasticsearch集群新老数据迁移到微软云elasticsearch集群

解决

新数据比较好弄数据源输出到新的微软云kafka集群然后微软云logstash消费新数据到新elasticsearch集群即可,关于老数据迁移比较麻烦,但官网也给了成熟的解决方案既是快照备份与还原,下面实施过程既是对实施过程的记录

实施

阿里云elasticsearch集群操作

一,先关闭数据平衡,注意一个一个的来,关一个节点的进程none,all循环一次,否则最后集群切片变动,恢复时间很长

1、修改elasticsearch.yml配置,添加如下
path.repo: /storage/esdata
设置索引备份快照路径
注意所有的master节点与data节点都需要配置

2、关闭自动平衡

curl -XPUT http://10.10.88.86:9200/_cluster/settings -d‘
{
"transient" : {
"cluster.routing.allocation.enable" : "none"
}
}‘
elasticsearch日志
[[email protected] storage]# tail -f es-cluster.log
[2018-05-11T15:24:15,605][INFO ][o.e.c.s.ClusterSettings ] [elk-es01] updating [cluster.routing.allocation.enable] from [ALL] to [none]

3、重启elasticseach

4、启动自动平衡

curl -XPUT http:///10.10.88.86:9200/_cluster/settings -d‘
{
"transient" : {
"cluster.routing.allocation.enable" : "all"
}
}‘

5、重复循环1、2、3、4操作在剩下几个节点,最好通过/_cat/health查看集群恢复100%后操作下一次,如果不关闭allocation重启elasticsearch集群恢复时间很长会从0%开始,关闭后从节点数减一除以总节点数比例开始恢复会块很多

二、设置快照基本配置

curl -XPUT http:///10.10.88.86:9200/_snapshot/client_statistics -d‘
{
"type": "fs",
"settings": {
"location": "/storage/esdata",
"compress": true,
"max_snapshot_bytes_per_sec" : "50mb",
"max_restore_bytes_per_sec" : "50mb"
}
}‘

注意错误
报错没有权限

store location [/storage/esdata] is not accessible on the node [{elk-es04}
{"error":{"root_cause":[{"type":"repository_verification_exception","reason":"[client_statistics] [[TgGhv7V1QGagb_PNDyXM-w, ‘RemoteTransportException[[elk-es04][/10.10.88.89:9300][internal:admin/repository/verify]]; nested: RepositoryVerificationException[[client_statistics] store location [/storage/esdata] is not accessible on the node [{elk-es04}{TgGhv7V1QGagb_PNDyXM-w}{7dxKWcF3QreKMZOKhTFgeg}{/10.10.88.89}{/10.10.88.89:9300}]]; nested: AccessDeniedException[/storage/esdata/tests-_u6h8XrJQ32dYPaC7zFC_w/data-TgGhv7V1QGagb_PNDyXM-w.dat];‘]]"}],"type":"repository_verification_exception","reason":"[client_statistics] [[TgGhv7V1QGagb_PNDyXM-w, ‘RemoteTransportException[[elk-es04][10.51.57.54:9300][internal:admin/repository/verify]]; nested: RepositoryVerificationException[[client_statistics] store location [/storage/esdata] is not accessible on the node [{elk-es04}{TgGhv7V1QGagb_PNDyXM-w}{7dxKWcF3QreKMZOKhTFgeg}{/10.10.88.89}{/10.10.88.89:9300}]]; nested: AccessDeniedException[/storage/esdata/tests-_u6h8XrJQ32dYPaC7zFC_w/data-TgGhv7V1QGagb_PNDyXM-w.dat];‘]]"},"status":500}

解决方法:
发现node1,node2,node3的es权限是500,node4的权限是501,最近比较背,感觉任何一个小问题都会遇到很多意想不到的地方,这不google了下https://discuss.elastic.co/t/why-does-creating-a-repository-fail/22697/16显然是权限问题,nfs这边有些策略,权衡利弊想短时间内解决问题
打算修改node4的es的uid和gid都为500,使其与前三个节点保持一致
https://blog.csdn.net/train006l/article/details/79007483
usermod -u 500 es
groupmod -g 500 es
注意usermod时需要es用户没有进程在活动,就是说elasticsearch进程需要关闭,重复上面的node,all操作,另外如果有其他用户占用了500 id,相应的修改且注意相关进程。
如果不放心也可手动修改,主要是/home/es下的权限及es数据权限
find / -user 501 -exec chown -h es {} \;
find / -group 501 -exec chown -h es {} \;

再次执行就不报错了:
[[email protected] ~]# curl -XPUT http:///10.10.88.86:9200/_snapshot/client_statistics -d‘

{
"type": "fs",
"settings": {
"location": "/storage/esdata",
"compress" : "true",
"max_snapshot_bytes_per_sec" : "50mb",
"max_restore_bytes_per_sec" : "50mb"
}
}‘
{"acknowledged":true}[[email protected] ~]#

查看配置

[[email protected] ~]# curl -XGET http:///10.10.88.86:9200/_snapshot/client_statistics?pretty
{
"client_statistics" : {
"type" : "fs",
"settings" : {
"location" : "/storage/esdata",
"max_restore_bytes_per_sec" : "50mb",
"compress" : "true",
"max_snapshot_bytes_per_sec" : "50mb"
}
}
}

三、给需要迁移的索引做快照

注意索引数量多但是数据量不大时可以统配多一些index,保证每次迁移的数据量不至于太大,比如每次100G以内,防止网络等其他原因导致传输中断等
[[email protected] ~]# curl -XPUT http://10.10.88.86:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2018.05.11 -d‘

{
"indices": "logstash-nginx-accesslog-2018.05.11"
}‘
{"accepted":true}[[email protected] ~]#

2018年5月份只是前10天

curl -XPUT http://10.10.88.86:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2018.05 -d‘
{
"indices": "logstash-nginx-accesslog-2018.05.0"
}‘
curl -XPUT http://10.10.88.86:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2018.04 -d‘
{
"indices": "logstash-nginx-accesslog-2018.04
"
}‘
curl -XPUT http://10.10.88.86:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2018.03 -d‘
{
"indices": "logstash-nginx-accesslog-2018.03"
}‘curl -XPUT http://10.10.88.86:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2018.02 -d‘
{
"indices": "logstash-nginx-accesslog-2018.02
"
}‘
curl -XPUT http://10.10.88.86:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2018.01 -d‘
{
"indices": "logstash-nginx-accesslog-2018.01"
}‘
curl -XPUT http://10.10.88.86:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2017.12 -d‘
{
"indices": "logstash-nginx-accesslog-2017.12
"
}‘
curl -XPUT http://10.10.88.86:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2017.11 -d‘
{
"indices": "logstash-nginx-accesslog-2017.11*"
}‘

例子

[[email protected] ~]# curl -XPUT http://10.10.88.86:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2017.11 -d‘
{
"indices": "logstash-nginx-accesslog-2017.11*"
}‘
{"accepted":true}[[email protected] ~]#
[[email protected] ~]# curl -XGET http://10.10.88.86:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2017.11?pretty
{
"snapshots" : [
{
"snapshot" : "logstash-nginx-accesslog-2017.11",
"uuid" : "PwPlyCbQQliZY3saog45LA",
"version_id" : 5000299,
"version" : "5.0.2",
"indices" : [
"logstash-nginx-accesslog-2017.11.20",
"logstash-nginx-accesslog-2017.11.17",
"logstash-nginx-accesslog-2017.11.24",
"logstash-nginx-accesslog-2017.11.30",
"logstash-nginx-accesslog-2017.11.22",
"logstash-nginx-accesslog-2017.11.18",
"logstash-nginx-accesslog-2017.11.15",
"logstash-nginx-accesslog-2017.11.16",
"logstash-nginx-accesslog-2017.11.27",
"logstash-nginx-accesslog-2017.11.26",
"logstash-nginx-accesslog-2017.11.19",
"logstash-nginx-accesslog-2017.11.21",
"logstash-nginx-accesslog-2017.11.28",
"logstash-nginx-accesslog-2017.11.23",
"logstash-nginx-accesslog-2017.11.25",
"logstash-nginx-accesslog-2017.11.29"
],
"state" : "IN_PROGRESS",
"start_time" : "2018-05-14T02:31:58.900Z",
"start_time_in_millis" : 1526265118900,
"failures" : [ ],
"shards" : {
"total" : 0,
"failed" : 0,
"successful" : 0
}
}
]
}

注意state 在IN_PROGERESS,变成SUCCESS时快照完成,注意SUCCESS时再执行下一次快照,如果index比较少时也可以一次性执行,不分开。

在微软云elasticsearch集群上操作

四、迁移数据到微软云elasticsearch集群

1、挂载nfs服务端

yum -y install nfs-utils
mkdir -p /storage/esdata
mount -t nfs 192.168.88.20:/data/es-data01/backup /storage/esdata/
df -h
所有master节点与node节点都需要挂载nfs
scp阿里云的数据包到微软云nfs服务端,注意需要先tar包,后解压缩,scp前需要open***打通
scp [email protected]:/storage/esdata/es20180514.tar.gz ./
scp [email protected]:/storage/esdata/indices20180514.tar.gz ./

2、修改新集群配置

1)、修改elasticsearch.yml配置,添加如下
path.repo: /storage/esdata
#设置索引备份快照路径
注意所有的master节点与data节点都需要配置
2)、关闭自动平衡操作同上

curl -XPUT http://192.168.88.24:9200/_cluster/settings -d‘
{
"transient" : {
"cluster.routing.allocation.enable" : "none"
}
}‘
sleep 3
/etc/init.d/elasticsearch restart
curl -XPUT http://192.168.88.24:9200/_cluster/settings -d‘
{
"transient" : {
"cluster.routing.allocation.enable" : "all"
}
}‘
curl http://192.168.88.20:9200/_cluster/health?pretty

3、恢复快照

1)、先建数据仓库

curl -XPUT http://192.168.88.20:9200/_snapshot/client_statistics -d‘
{
"type": "fs",
"settings": {
"location": "/storage/esdata",
"compress" : "true",
"max_snapshot_bytes_per_sec" : "50mb",
"max_restore_bytes_per_sec" : "50mb"
}
}‘

2)、再恢复index

[email protected] es]# curl -XPOST http://192.168.88.20:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2018.05/_restore
{"accepted":true}

依次执行:注意只有当前任务执行完了,才能正确执行下一个任务,开始index状态是yellow,等都变成green就正常了

curl -XPOST http://192.168.88.20:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2018.04/_restore
curl -XPOST http://192.168.88.20:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2018.03/_restore
curl -XPOST http://192.168.88.20:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2018.02/_restore
curl -XPOST http://192.168.88.20:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2018.01/_restore
curl -XPOST http://192.168.88.20:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2017.12/_restore
curl -XPOST http://192.168.88.20:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2017.11/_restore

3)、最后检查状态

[[email protected] es]# curl -XGET http://192.168.88.20:9200/_snapshot/client_statistics/logstash-nginx-accesslog-2018.05/_status?pretty
{
"snapshots" : [
{
"snapshot" : "logstash-nginx-accesslog-2018.05",
"repository" : "client_statistics",
"uuid" : "VL9LHHUKTNCHx-xsVJD_eA",
"state" : "SUCCESS",
"shards_stats" : {
"initializing" : 0,
"started" : 0,
"finalizing" : 0,
"done" : 45,
"failed" : 0,
"total" : 45
},
"stats" : {
"number_of_files" : 4278,
"processed_files" : 4278,
"total_size_in_bytes" : 22892376668,
"processed_size_in_bytes" : 22892376668,
"start_time_in_millis" : 1526280514416,
"time_in_millis" : 505655
},
"indices" : {
"logstash-nginx-accesslog-2018.05.08" : {
"shards_stats" : {
"initializing" : 0,
"started" : 0,
"finalizing" : 0,
"done" : 5,
"failed" : 0,
"total" : 5
},
"stats" : {
"number_of_files" : 524,
"processed_files" : 524,
"total_size_in_bytes" : 2617117488,
"processed_size_in_bytes" : 2617117488,
"start_time_in_millis" : 1526280514420,
"time_in_millis" : 260276
},
"shards" : {
"0" : {
"stage" : "DONE",
"stats" : {
"number_of_files" : 67,
"processed_files" : 67,
"total_size_in_bytes" : 569057817,
"processed_size_in_bytes" : 569057817,
"start_time_in_millis" : 1526280514420,
"time_in_millis" : 68086
}
},
"1" : {
"stage" : "DONE",
"stats" : {
"number_of_files" : 124,
"processed_files" : 124,
"total_size_in_bytes" : 499182013,
"processed_size_in_bytes" : 499182013,
"start_time_in_millis" : 1526280514446,
"time_in_millis" : 62925
}
},
"2" : {
"stage" : "DONE",
"stats" : {
"number_of_files" : 109,
"processed_files" : 109,
"total_size_in_bytes" : 478469125,
"processed_size_in_bytes" : 478469125,
"start_time_in_millis" : 1526280698072,
"time_in_millis" : 76624
}
},
"3" : {
"stage" : "DONE",
"stats" : {
"number_of_files" : 124,
"processed_files" : 124,
"total_size_in_bytes" : 546347244,
"processed_size_in_bytes" : 546347244,
"start_time_in_millis" : 1526280653094,
"time_in_millis" : 103590
}
},
"4" : {
"stage" : "DONE",
"stats" : {
"number_of_files" : 100,
"processed_files" : 100,
"total_size_in_bytes" : 524061289,
"processed_size_in_bytes" : 524061289,
"start_time_in_millis" : 1526280514456,
"time_in_millis" : 69113
}
}
}
},
"logstash-nginx-accesslog-2018.05.09" : {
"shards_stats" : {
"initializing" : 0,
"started" : 0,
"finalizing" : 0,
"done" : 5,
"failed" : 0,
"total" : 5
},
"stats" : {
"number_of_files" : 425,
"processed_files" : 425,
"total_size_in_bytes" : 2436583034,
"processed_size_in_bytes" : 2436583034,
"start_time_in_millis" : 1526280514425,
"time_in_millis" : 505646
},
"shards" : {
"0" : {
"stage" : "DONE",
"stats" : {
"number_of_files" : 94,
"processed_files" : 94,
"total_size_in_bytes" : 462380313,
"processed_size_in_bytes" : 462380313,
"start_time_in_millis" : 1526280971948,
"time_in_millis" : 48123
}
},
"1" : {
"stage" : "DONE",
"stats" : {
"number_of_files" : 103,
"processed_files" : 103,
"total_size_in_bytes" : 506505727,
"processed_size_in_bytes" : 506505727,
"start_time_in_millis" : 1526280851761,
"time_in_millis" : 69562
}
},
"2" : {
"stage" : "DONE",
"stats" : {
"number_of_files" : 73,
"processed_files" : 73,
"total_size_in_bytes" : 506830214,
"processed_size_in_bytes" : 506830214,
"start_time_in_millis" : 1526280514425,
"time_in_millis" : 60508
}
},
"3" : {
"stage" : "DONE",
"stats" : {
"number_of_files" : 52,
"processed_files" : 52,
"total_size_in_bytes" : 494390868,
"processed_size_in_bytes" : 494390868,
"start_time_in_millis" : 1526280593311,
"time_in_millis" : 52673
}
},
"4" : {
"stage" : "DONE",
"stats" : {
"number_of_files" : 103,
"processed_files" : 103,
"total_size_in_bytes" : 466475912,
"processed_size_in_bytes" : 466475912,
"start_time_in_millis" : 1526280583835,
"time_in_millis" : 64169
}
}
}
}
}
}
]
}

原文地址:http://blog.51cto.com/jerrymin/2139066

时间: 2024-07-31 19:31:03

Elasticsearch集群数据迁移的相关文章

elasticsearch7.5.0+kibana-7.5.0+cerebro-0.8.5集群生产环境安装配置及通过elasticsearch-migration工具做新老集群数据迁移

一.服务器准备 目前有两台128G内存服务器,故准备每台启动两个es实例,再加一台虚机,共五个节点,保证down一台服务器两个节点数据不受影响. 二.系统初始化 参见我上一篇kafka系统初始化:https://www.cnblogs.com/mkxfs/p/12030331.html 三.安装elasticsearch7.5.0 1.因zookeeper和kafka需要java启动 首先安装jdk1.8环境 yum install java-1.8.0-openjdk-devel.x86_64

【源】从零自学Hadoop(17):Hive数据导入导出,集群数据迁移下

阅读目录 序 将查询的结果写入文件系统 集群数据迁移一 集群数据迁移二 系列索引 本文版权归mephisto和博客园共有,欢迎转载,但须保留此段声明,并给出原文链接,谢谢合作. 文章是哥(mephisto)写的,SourceLink 序 上一篇,我们介绍了Hive的数据多种方式导入,这样我们的Hive就有了数据来源了,但有时候我们可能需要纯粹的导出,或者集群Hive数据的迁移(不同集群,不同版本),我们就可以通过这两章的知识来实现.   下面我们开始介绍hive的数据导出,以及集群Hive数据的

【源】从零自学Hadoop(16):Hive数据导入导出,集群数据迁移上

阅读目录 序 导入文件到Hive 将其他表的查询结果导入表 动态分区插入 将SQL语句的值插入到表中 模拟数据文件下载 系列索引 本文版权归mephisto和博客园共有,欢迎转载,但须保留此段声明,并给出原文链接,谢谢合作. 文章是哥(mephisto)写的,SourceLink 序 上一篇,我们介绍了Hive的表操作做了简单的描述和实践.在实际使用中,可能会存在数据的导入导出,虽然可以使用sqoop等工具进行关系型数据导入导出操作,但有的时候只需要很简便的方式进行导入导出即可   下面我们开始

HBase集群数据迁移方案

一.静态迁移方案 1.在hbase停止的状态下进行数据的迁移. 2.采用Hadoop distcp方式,将以上目录的内容,迁移到另一个集群. 使用add_table.rb进行恢复. 缺点:不太灵活 二.动态迁移方案 -Replication备份方案 -CopyTable方案 -Export and Import方案 1.Replication备份方案 修改hbase-site.xml配置,增加hbase.replication属性, 增加表属性REPLICATION_SCOPE属性. add_p

不停机迁移 elasticsearch 集群

一.背景 ES 集群不停机迁移,迁移过程中不影响业务使用. 所用集群版本为 6.3.0 . 二.方案 1.业务通过域名访问集群: 2.在新的机器搭建集群: 3.对原有集群进行快照,万一数据有丢失可以从快照进行恢复: 4.新旧集群进行合并,并强制使旧集群数据通过数据均衡的方式迁移到新集群: 5.下线原有旧集群. 三.实施 1.在新的机器搭建集群的方法 1)机器准备(root设置):参考官网 vim /etc/security/limits.conf 解除文件与内存限制 * soft memlock

我的ElasticSearch集群部署总结--大数据搜索引擎你不得不知

摘要:世上有三类书籍:1.介绍知识,2.阐述理论,3.工具书:世间也存在两类知识:1.技术,2.思想.以下是我在部署ElasticSearch集群时的经验总结,它们大体属于第一类知识“techknowledge(技术)”.但其中也穿插一些我个人的理解.敬请指正. 关键词:ElasticSearch, 搜索引擎, 集群, 大数据, Solr, 大数据 三类书籍 和 两类知识: 有一些书是对某一新知识领域的介绍,将此知识领域从头到尾.从内而外剖开了分析,吸收这些知识主要在于“记忆”,(也有“领会”)

elasticsearch集群介绍及优化【转】

elasticsearch用于构建高可用和可扩展的系统.扩展的方式可以是购买更好的服务器(纵向扩展)或者购买更多的服务器(横向扩展),Elasticsearch能从更强大的硬件中获得更好的性能,但是纵向扩展也有一定的局限性.真正的扩展应该是横向的,它通过增加节点来传播负载和增加可靠性.对于大多数数据库而言,横向扩展意味着你的程序将做非常大的改动来利用这些新添加的设备.对比来说,Elasticsearch天生是分布式的:它知道如何管理节点来提供高扩展和高可用.这意味着你的程序不需要关心这些.对于大

手把手教你搭建一个Elasticsearch集群

一.为何要搭建 Elasticsearch 集群 凡事都要讲究个为什么.在搭建集群之前,我们首先先问一句,为什么我们需要搭建集群?它有什么优势呢? (1)高可用性 Elasticsearch 作为一个搜索引擎,我们对它的基本要求就是存储海量数据并且可以在非常短的时间内查询到我们想要的信息.所以第一步我们需要保证的就是 Elasticsearch 的高可用性,什么是高可用性呢?它通常是指,通过设计减少系统不能提供服务的时间.假设系统一直能够提供服务,我们说系统的可用性是 100%.如果系统在某个时

手把手教你搭建一个 Elasticsearch 集群

为何要搭建 Elasticsearch 集群 凡事都要讲究个为什么.在搭建集群之前,我们首先先问一句,为什么我们需要搭建集群?它有什么优势呢? 高可用性 Elasticsearch 作为一个搜索引擎,我们对它的基本要求就是存储海量数据并且可以在非常短的时间内查询到我们想要的信息.所以第一步我们需要保证的就是 Elasticsearch 的高可用性,什么是高可用性呢?它通常是指,通过设计减少系统不能提供服务的时间.假设系统一直能够提供服务,我们说系统的可用性是 100%.如果系统在某个时刻宕掉了,