当前位置:   article > 正文

Elasticsearch数据迁移

Elasticsearch数据迁移

前言

近期在搞ES集群的迁移,以及日常ES运维中也涉及到同集群内索引的重命名、迁移等实际场景。就考虑把实际场景模拟一下,侧重不同集群间的数据迁移,对比观察一下目前主流的数据迁移方式的优点和缺点。为之后真实迁移场景提供参考。

这次对比测试了4种方式:

  • 原生的reindex
  • 使用快照
  • 第三方:elsaticdump
  • 第三方:logstash

先上结果吧!

验证环境信息:

源es: http://192.168.1.10:9200

目标ES: http://192.168.1.20:9200

用户名密码均为: test/Aa123456

索引:my-test-index-01

ES配置: 2C8G200GB * 3

ES版本: 6.8

测试索引数据大小: 221MB

注:鉴于内部特殊环境,源集群及目标集群位于同一个网内,同一个k8s集群上。

验证结果

方式时间复杂度其他限制条件
Reindex55秒3步reindex前需要先建索引,受限于源和目标集群的带宽情况,需要重启目标集群
Snapshot&restore30秒4步需要一个源和目标集群都可用的共享存储
Elasticdump2-3分钟3步需要一台到源和目标集群网络都通的机器,受两方网络带宽影响。
Logstash1分20S2步需要一台到源和目标集群网络都通的机器、本次测试logstash版本与es要保持一致。同时jdk版本也需要支持对应的版本

结论

reindex适用普通场景,速度快。但不适用于源、目标集群网络不通的情况下。

快照恢复速度最快,但严重依赖于共享存储,且操作步骤较多,速度快慢只受集群性能和共享存储性能影响。

logstash操作步骤最少,但受限于中间机器到源、目标集群的网络限制。

elasticsdump速度最慢,适用于索引数据量小,又不方便直接操作双方集群的情况下。

验证过程

1. reindex

跨集群迁移索引数据:

远程reindex实质上等于再源集群执行有过滤条件或者无条件的_scroll查询加速写入目标集群,并且需要在目标集群配置中增加远程集群节点的白名单reindex.remote.whitelist,适用于数据量较小的场景,比如几十万数据

reindex.remote.whitelist

在目标集群控制台高级配置中,修改reindex.remote.whitelist的值为源集群的地址,格式为host:port,不需要加协议schema. 修改配置后重启es集群。

新集群创建索引

在执行reindex前需要在新集群中优先创建出来要迁移的索引; 否则dest索引不存在的话,在reindex的时候虽然系统会自动创建索引,但会引起一些错误,已发现有字段类型改变。

PUT my-test-index-01
{
 "settings": {
  "index": {
   "search": {
    "slowlog": {
     "threshold": {
      "fetch": {
       "warn": "4s",
       "trace": "500ms",
       "debug": "1s",
       "info": "2s"
      },
      "query": {
       "warn": "4s",
       "trace": "500ms",
       "debug": "1s",
       "info": "2s"
      }
     }
    }
   },
   "refresh_interval": "10s",
   "indexing": {
    "slowlog": {
     "threshold": {
      "index": {
       "warn": "4s",
       "trace": "500ms",
       "debug": "1s",
       "info": "2s"
      }
     }
    }
   },
   "number_of_shards": "3",
   "number_of_replicas": "1"
  }
 },
 "mappings": {
  "data": {
   "_field_names": {
    "enabled": false
   },
   "dynamic": "false",
   "properties": {
    "hostName": {
     "type": "keyword"
    },
    "user_pin": {
     "type": "keyword"
    },
    "restart": {
     "type": "keyword"
    },
    "ipAddress": {
     "type": "keyword"
    },
    "ts": {
     "format": "epoch_millis",
     "type": "date"
    }
   }
  }
 },
 "aliases": {}
}

  • 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
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
reindex迁移数据
POST _reindex?timeout=30m
{
  "source": {
    "remote": {
      "host": "http://192.168.1.10:9200",
      "username": "test",
      "password": "Aa123456"
    },
    "index": "my-test-index-01"
  },
  "dest": {
    "index":  "my-test-index-01"
  }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

命令返回结果:

耗时: 55S

2. 快照迁移

es数据快照迁移适用以下场景:

  • 大量数据需要迁移,如几十GB到几百TB ,版本兼容情况可查看官方文档[1]
  • 对迁移速度要求较高的场景,且用户接受短暂停写(在我们的实践中10tb的数据,用户只需要停写10分钟)
  • 要求迁移数据比较快:快照走的是物理文件复制,所以速度上限基本是带宽的限制。

快照迁移适合数据量大,索引数量多的迁移场景;要求源集群和目的集群有共同的快照库。

这里为了测试,临时搭建了一个minio的存储。

MINIO_ROOT_USER=myadmin
MINIO_ROOT_PASSWORD=myadmin
./minio server /export/test/data  --console-address ":9001"
  • 1
  • 2
  • 3

默认密码是minioadmin/minioadmin

注册仓库

仓库为共享文件系统或s3等存储;可以在多个集群上注册。

查看当前集群的快照库列表

GET _cat/repositories?v
  • 1

注册s3类型快照库

使用上面搭建的minio作为临时对象存储

 curl -XPUT  -H 'Content-Type: application/json'  'http://test:Aa123456@192.168.1.10:9200/_snapshot/source_snapshots?timeout=60s' -d '
 {
 "type": "s3",
 "settings": {
  "bucket": "test",
  "base_path": "",
  "endpoint": "192.168.1.30:9001",
  "protocol": "http",
  "compress": "true",
  "access_key": "minioadmin",
  "secret_key": "minioadmin",
  "max_restore_bytes_per_sec": "200mb",
  "max_snapshot_bytes_per_sec": "100mb"
 }
}'
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15

创建快照

指定要快照的索引,支持多个索引逗号分隔;通配符。

PUT /_snapshot/source_snapshots/mytestindex01
{
"indices": "my-test-index-01",  
"ignore_unavailable": true,  
"include_global_state": false  
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

查看创建中的快照

GET _snapshot/source_snapshots/_current
  • 1

查看系统中的快照

GET _snapshot/source_snapshots/
  • 1

在目标集群注册库

在源集群创建完快照后,在目标集群创建同样的快照库。快照库配置信息与源集群一致。

PUT _snapshot/source_snapshots
 {
 "type": "s3",
 "settings": {
  "bucket": "test",
  "base_path": "",
  "endpoint": "192.168.1.30:9000",
  "protocol": "http",
  "compress": "true",
  "access_key": "minioadmin",
  "secret_key": "minioadmin",
  "max_restore_bytes_per_sec": "200mb",
  "max_snapshot_bytes_per_sec": "100mb"
 }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15

从快照恢复索引数据

查看目标集群中的快照

GET _cat/snapshots/source_snapshots
  • 1

恢复前确保要恢复的索引在当前集群内不存在,否则会报错。

POST _snapshot/source_snapshots/mytestindex01/_restore
{
  "indices": "my-test-index-01",
  "ignore_unavailable": true,
  "include_global_state": false, 
  "include_aliases": false
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

结果:

命令为异步提交,查看restore task的执行时间,因数据量小,执行时间比较短,只能估算在30s之内,没有更准确的统计方式。 但对于大规模索引的迁移,快照的方式是效率比较高的。

3.elasticdump

elasticsearch-dump可以对索引的mapping、别名和索引模版等进行迁移,它的适用场景所如:

  • 数据量较小的场景
  • 离线迁移场景

从原ES使用elsticdump将索引迁移到目标ES集群中:

这一步保证了源索引和目标索引分片数、副本数等一些非默认配置的一致性。

  elasticdump \
  --input=http://test:Aa123456@192.168.1.10:9200/my-test-index-01\
  --output=http://test:Aa123456@192.168.1.20:9200/my-test-index-01\
  --type=settings
  • 1
  • 2
  • 3
  • 4

先同步索引结构

  elasticdump \
  --input=http://test:Aa123456@192.168.1.10:9200/my-test-index-01\
  --output=http://test:Aa123456@192.168.1.20:9200/my-test-index-01\
  --type=mapping
  • 1
  • 2
  • 3
  • 4

成功后再同步索引内数据

前面两步执行时间很短,在实际迁移中可以忽略。

  elasticdump \
  --input=http://test:Aa123456@192.168.1.10:9200/my-test-index-01\
  --output=http://test:Aa123456@192.168.1.20:9200/my-test-index-01\
  --type=data --noRefresh --limit=10000
  • 1
  • 2
  • 3
  • 4

在实际迁移操作时默认参数下,迁移速度非常慢。在调整limit的值后,发现对迁移速度影响比较大,重复测试了不同limit值下的迁移速度。

迁移所需时间:

并发数数据大小开始时间结束时间耗时
100221MB17:12:0817:00:001小时48分钟
5000221MB11:34:1811:38:202分02秒
10000221MB11:23:3211:26:353分钟

验证结果:

–limit 并发数量严重影响数据迁移速度.。 并发100时,221MB数据大约需要1小时48左右才能完成迁移 。 在当前集群配置下,10000并发为上限。受index.max_result_window值限制。且最佳并发数实际依赖于集群写入性能。

附:

elasticdump本次用到参数介绍

  • –input #源集群连接地址
  • –outout #目标连接地址
  • –noRefresh #导入过程中禁用refresh,提高数据写入速度
  • –type #迁移的类型
  • –limit #每次执行操作多少条数据

4.logstash

  • 迁移全量或增量数据(前提条件需要唯一排序的字段,对于有删除操作是无法同步到目标集群),且对实时性要求不高的场景
  • 需要对迁移的数据通过 es query 进行简单的过滤的场景.
  • 需要对迁移的数据进行复杂的过滤或处理的场景.
  • 版本跨度较大的数据迁移场景,如 5.x 版本迁移到 6.x 版本或 7.x 版本.

下载安装logstash

最开始使用8.14版本的logstash迁移6.8版本的ES集群,执行过程报错退出。为避免其他干扰重新下载6.8版本的logstash进行测试。logstash适配jdk8或jdk11。

编辑配置文件

源es: http://192.168.1.10:9200

目标ES: http://192.168.1.20:9200

用户名密码均为: test/Aa123456

索引:my-test-index-01

input {        
    elasticsearch {            
        hosts => ["http://192.168.1.10:9200"]            
        user => "test"            
        password => "Aa123456"            
        index => "my-test-index-01"            
        docinfo => true            
        size => 5000        
    }}
    
    filter {        
        mutate {            
            remove_field => ["@timestamp", "@version"]        #去掉logstash添加的字段
             }
             }
             
             
    output {       
         elasticsearch {            
            hosts => ["http://192.168.1.20:9200"]            
            user => "test"            
            password => "Aa123456"            
            index => "my-test-index-01"                 
            document_type => "%{[@metadata][_type]}"            
            document_id => "%{[@metadata][_id]}"        
}
  • 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

开始时间

2024-07-03T11:25:13

结束时间:

2024-07-03T11:26:34

耗时: 1分20S

结论: 也需要提前创建索引,否则会导致原索引自定义配置部分丢失。索引大小从221增加到了259; 文档数没有变。

实际迁移时,需要提前在目标集群创建好要迁移的索引。

PUT my-test-index-01
{
 "settings": {
  "index": {
   "search": {
    "slowlog": {
     "threshold": {
      "fetch": {
       "warn": "4s",
       "trace": "500ms",
       "debug": "1s",
       "info": "2s"
      },
   "refresh_interval": "10s",
   "number_of_shards": "3",
   "number_of_replicas": "1"
  }
 },
 "mappings": {
  "data": {
   "_field_names": {
    "enabled": false
   },
   "dynamic": "false",
   "properties": {
    "hostName": {
     "type": "keyword"
    },
    "user_pin": {
     "type": "keyword"
    },
    .....
    "ts": {
     "format": "epoch_millis",
     "type": "date"
    }
   }
  }
 },
 "aliases": {}
}


  • 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
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
声明:本文内容由网友自发贡献,转载请注明出处:【wpsshop】
推荐阅读
相关标签
  

闽ICP备14008679号