当前位置:   article > 正文

【云上ELK系列】Logstash迁移Elasticsearch数据方法解读

logstash迁移elasticseach数据

摘要: 用Logstash实现Elasticsearch集群快速迁移,解读Logstash中metadata的功效,避免踩坑

Elasticsearch中数据搬迁是工程师们经常会做的,有时是为了集群迁移、有时是为了数据备份、有时是为了升级等等,迁移的方式也有很多种,比如说通过elasticsearch-dump、通过snapshot、甚至是通过reindex的方式来做。今天为大家介绍另一种方案:用Logstash实现Elasticsearch集群快速迁移

我们希望通过logstash来做数据迁移本身的原理很容易理解,通过logstash从源elasticsearch Cluster读数据,写入到目标elasticsearh
Cluster中,详细操作如下:

在logstash的目录下创建一个logstash的用于数据同步的conf文件

vim ./logstash-5.5.3/es-es.conf
  • 1

配置conf文件,由于我们只需要做index搬迁,所以目标Cluster和源Cluster的index命名相同即可。

input {
    elasticsearch {
        hosts => ["********your host**********"]
        user => "*******"
        password => "*********"
        index => "logstash-2017.11.07"
        size => 1000
        scroll => "1m"
    }
}
# 该部分被注释,表示filter是可选的
filter {
}
output {
    elasticsearch {
        hosts => ["***********your host**************"]
        user => "********"
        password => "**********"
        index => "logstash-2017.11.07"
    }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21

conf文件配置完成后执行logstash

bin/logstash -f es-es.conf
  • 1

执行这句指令时,有时会遇到如下的报错信息

[FATAL][logstash.runner] Logstash could not be started because there is already another instance using the configured data directory.  If you wish to run multiple instances, you must change the "path.data" setting.
  • 1

这是因为当前的logstash版本不支持多个instance共享一个path.data,所以需要在启动时,命令行里增加”–path.data PATH “,为不同实例指定不同的路径

bin/logstash -f es-es.conf --path.data ./logs/
  • 1

如果执行顺利,执行下面这个命令就可以在目标的elasticsearch中看到对应的index

curl -u username:password host:port/_cat/indices
  • 1

以上介绍了如何通过logstash来迁移elasticsearch中指定的index,下面介绍一个实用的场景:

**很多自建了Elasticsearch客户最近都会关注到阿里云Elasticsearch这款产品。想要使用时却遇到了一个如何把自建中的数据迁移到阿里云Elasticsearch的困惑。下面介绍一下如何通过logstash快速的搬迁云上自建的Elasticsearch中的index数据。
**

这个方案的逻辑很简单,拆解开就是配置N个es-to-es的conf文件,但这样做很繁琐。其实logstash提供了批量做这件事情的能力,为此需要提前介绍三个重要概念:

metadata:logstash 1.5版本之后,使用了metadata的概念,来描述一次event,并且允许被用户修改,但是不会写到event的结果中,对event的结果产生影响。除此之外,metadata将作为event的元数据描述信息,可以在input、filter、output三种插件的全执行周期内存活;
参考文档《Make Your Config Cleaner and your Log Processing Faster with Logstash Metadata》

docinfo:elasticsearch input插件中的一个参数,默认是false,官网上描述的原文是“If set, include Elasticsearch document information such as index, type, and the id in the event.”也就意味着设置了这个字段生效,会将index、type、id等信息全部记录到event中去,也就是metadata中去,这也就意味着可以在整个event执行周期内,使用者可以随意的使用index、type、id这些参数了;
elasticsearch input插件中的index参数,支持通配符,可以用“*”这样的模糊匹配通配符来表示所有对象;
由于metadata的特性,我们可以在output中直接“继承”input中的index、type信息,并在目标Cluster中直接创建和源Cluster一摸一样的index和type,甚至是id。

在整个过程中如果希望可以看到metadata信息,并且对其进行类debug的操作,需要在output中添加一个配置:

stdout { codec => rubydebug { metadata => true } }
  • 1

示例配置代码如下:

input {
    elasticsearch {
        hosts => ["yourhost"]
        user => "**********"
        password => "*********"
        index => "*"#该通配符代表需要读取所有index信息
        size => 1000
        scroll => "1m"
        codec => "json"
        docinfo => true
    }
}
# 该部分被注释,表示filter是可选的
filter {
}

output {
    elasticsearch {
        hosts => ["yourhost"]
        user => "********"
        password => "********"
        index => "%{[@metadata][_index]}"

    }
    stdout { codec => rubydebug { metadata => true } }

}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27

执行后,logstash会将源Cluster中所有的index全部copy到目标Cluster中去,并将mapping信息携带过去,随后开始逐步做index内的数据迁移。

建议:正式执行的时候

stdout { codec => rubydebug { metadata => true } }
  • 1

这个配置项建议去掉,否则会被满屏的刷metadata信息。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/盐析白兔/article/detail/492686
推荐阅读
相关标签
  

闽ICP备14008679号