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集群上。

验证结果

结论

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值下的迁移速度。

迁移所需时间:

验证结果:

–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