前面介绍了 ElasticSearch 基础概念 、技术原理、安装和基础使用、索引管理、 DSL 查询、聚合查询、索引文档与读取文档流程

、集群部署、规划与运维经验总结、集群规划与运维、分片/副本与数据操作流程等相关的知识点。今天我将详细的为大家介绍 ElasticSearch 数据备份和迁移相关知识。

Elasticsearch 默认配置是数据持久化的，就是 ES 会定时地把缓存数据刷新到硬盘，从而达到数据持久化地效果。在生产环境中，ES 的数据持久化是必须的，防止出现断电时数据的丢失。固然，除了数据持久化外，咱们也是得作到数据备份的，防止出现数据损坏时没法恢复数据的状况。

备份方案

离线方案

• Snapshot
• Reindex
• Logstash
• ElasticSearch-dump
• ElasticSearch-Exporter

增量备份方案

• logstash

备份数据

配置文件elasticsearch.yml

在配置文件config/elasticsearch.yml 中添加一行数据，设置ES备份的快照数据存储路径。如果没有此目录则须要自行建立。配置好后，须要重启ES。

path.repo: ["/usr/local/elasticsearch/snapshot"]

建立仓库

其实就是在ES库中建立一个备份存储的目的仓库，这里以仓库名称为 backup 为例，有以下两种方式。

• 在linux服务器上执行如下命令。

curl  -H "Content-Type: application/json" -XPUT -u elastic:xxx http://ES的IP:9200/_snapshot/backup -d '{"type": "fs","settings": {"location": "/usr/local/elasticsearch/snapshot"}}'

• 在kibana的Dev Tools开发工具中调用接口。

PUT _snapshot/backup
{
  "type": "fs",
  "settings": {
    "location": "data_bk",
    "compress": true,
    "max_snapshot_bytes_per_sec" : "50mb",
    "max_restore_bytes_per_sec" : "50mb"
  }
}

调用参数说明：

compress   #是否压缩，默认为是。
max_snapshot_bytes_per_sec   #每一个节点快照速率。默认40mb/s。  
max_restore_bytes_per_sec    #节点恢复速率。默认40mb/s。 

返回结果以下，则说明建立成功。

{
    "acknowledged": true
}

删除备份数据

在备份数据以前，最好是先根据备份数据的名称删除原来已经备份好的数据。相同名称的备份数据是不能重复备份的。

这里以备份数据的名称为 bk_20190926 为例，后面的执行都以此为例，有以下两种方式。

• 在linux服务器上执行如下命令。

curl -XDELETE http://ES的ip:端口/_snapshot/backup/bk_20190926

• 在kibana的Dev Tools开发工具中调用接口。

DELETE _snapshot/backup/bk_20190926

返回结果以下，则说明删除成功。

{
    "acknowledged": true
}

开始备份数据

备份数据一样是与删除数据同样，直接调用ES的接口实现的，有以下两种方式。

• 在linux服务器上执行如下命令。

curl -XPUT http://ES的ip:端口/_snapshot/backup/bk_20190926?wait_for_completion=true

• 在kibana的Dev Tools开发工具中调用接口。

PUT _snapshot/backup/bk_20190926?wait_for_completion=true

返回结果以下，则说明已经备份成功。

{
    "snapshot": {
        "snapshot": "bk_20190926",
        "uuid": "K4fze5eGSvOwot_xWtz0Hw",
        "version_id": 6050399,
        "version": "6.5.3",
        "indices": [
            "first_index"
        ],
        "include_global_state": true,
        "state": "SUCCESS",
        "start_time": "2019-09-27T05:36:39.398Z",
        "start_time_in_millis": 1569562599398,
        "end_time": "2019-09-27T05:36:39.723Z",
        "end_time_in_millis": 1569562599723,
        "duration_in_millis": 325,
        "failures": [],
        "shards": {
            "total": 5,
            "failed": 0,
            "successful": 5
        }
    }
}

同时，能够在ES所在的服务器的目录/usr/local/elasticsearch/snapshot/data_bk下查看到增长了不少文件，这些就是备份数据所需的文件。

查看备份数据

备份完数据后，直接在服务器上能够看到这些备份的文件，可是这些文件并非一眼就能看出你备份了哪些数据的，此时你能够经过调用ES的接口来查看你备份了哪些数据。一样有两种方式调用。

• 在linux服务器上执行如下命令。

curl -XGET http://ES的ip:端口/_snapshot/backup/_all

• 在kibana的Dev Tools开发工具中调用接口。

GET _snapshot/backup/_all

返回结果以下，你备份了多少快照均可以在这里看到，snapshots列表的最后一个元素就是你最近备份的快照。

{
    "snapshots": [
        {
            "snapshot": "bk_20190926",
            "uuid": "K4fze5eGSvOwot_xWtz0Hw",
            "version_id": 6050399,
            "version": "6.5.3",
            "indices": [
                "first_index"
            ],
            "include_global_state": true,
            "state": "SUCCESS",
            "start_time": "2019-09-27T05:36:39.398Z",
            "start_time_in_millis": 1569562599398,
            "end_time": "2019-09-27T05:36:39.723Z",
            "end_time_in_millis": 1569562599723,
            "duration_in_millis": 325,
            "failures": [],
            "shards": {
                "total": 5,
                "failed": 0,
                "successful": 5
            }
        }
    ]
}

恢复数据

数据备份好了，若是真的出现了不可逆的数据损坏状况，此时就能够进行数据恢复了。

备份data文件夹

data文件夹其实就是当前ES的数据存储地，防止恢复数据出现异常，先把ES目录下面的data目录备份一下。

tar -cvf data-20190626.tar.gz data

清空数据

恢复数据以前，先把当前ES的数据清空掉。有以下两种方式。

（1）在linux服务器上执行如下命令。

curl -XDELETE http://ES的ip:端口/_all

（2）在kibana的Dev Tools开发工具中调用接口。

DELETE _all

返回结果以下，则说明清空数据成功。

{
    "acknowledged": true
}

恢复数据

恢复数据一样有以下两种方式操做。

（1）在linux服务器上执行如下命令。

curl -XPOST http://ES的ip:端口/_snapshot/backup/bk_20190926/_restore

（2）在kibana的Dev Tools开发工具中调用接口。

POST _snapshot/backup/bk_20190926/_restore

返回结果以下，则说明恢复数据成功。

{
    "accepted": true
}

至此，ES的数据备份和恢复就介绍完啦！

总结

这里只是讲解了手动的操做ES的数据备份和恢复，在程序里面咱们同样能够经过调用ES的接口来进行数据备份和恢复，例如经过java程序来定时天天进行ES地数据备份，而后删除昨天或前天的备份数据，只保留一份或两份备份数据，以此来节约磁盘空间。

ElasticSearch 数据迁移

ES数据迁移有三种方式

• Rolling upgrades回滚
• snapshot快照
• elasticdump方式
• 

• 迁移需考虑的问题

  • 版本问题，从低版本到高版本数据的迁移
  • 多租户的适配问题
  • 多次或者分批迁移数据
  • 数据在迁移时候富化
  • FieldMapping 和数据信息分离

  Rolling upgrades滚动升级

  方法说明

  该方法更好的使用在跨版本ES集群迁移中，它允许 ES集群一次升级一个节点，因此在升级期间不会中断服务。不支持在升级持续时间之后在同一集群中运行多个版本的 ES，因为无法将分片从升级的节点复制到运行旧版本的节点。所以在升级前需要对当前使用版本进行备份，以便在升级出现异常时进行回滚。

  同时在升级过程中优先选择data节点，在data节点升级完成后，在对集群中master节点进行升级。

  支持滚动升级准则：

  • 同一主要版本的次要版本之间
  • v 从 5.6 到 6.8
  • v 从 6.8 到 7.17.5
  • v 从 7.17.0 到 7.17.5 的任何版本
  • 从 6.7 或更早版本直接升级到 7.17.5 需要 完全重启集群。

  在做滚动升级时需要保证ElasticSearch间的集群节点通讯，所以要保证安全认证同步。

  具体步骤升级前准备

  在开始将集群升级到版本 7.17.5 之前，您应该执行以下操作：

  • 1、检查弃用日志以查看您是否正在使用任何弃用的功能并相应地更新您的代码。
  • 2、查看重大更改并对版本 7.17.5 的代码和配置进行任何必要的更改。
  • 3、如果您使用任何插件，请确保每个插件都有一个与 Elasticsearch 版本 7.17.5 兼容的版本。
  • 4、在升级生产集群之前，在隔离环境中测试升级。
  • 5、通过拍摄快照备份您的数据！（或对当前集群所有节点进行数据和安装包进行全量备份）
  升级集群

  禁用自动分片功能（若在升级过程中不考虑IO性能瓶颈，可以忽略），关闭一个数据节点时，分配过程会等待。

  index.unassigned.node_left.delayed_timeout（默认为一分钟），然后才开始将该节点上的分片复制到集群中的其他节点，这可能涉及大量 I/O。由于节点很快将重新启动，因此此 I/O 是不必要的。您可以通过在关闭数据节点之前禁用副本分配来避免争分夺秒 ：

  PUT _cluster/settings{ “persistent”: { “cluster.routing.allocation.enable”: “primaries” }}
  

  • 停止不必要的索引并执行同步刷新（可选的）

  POST _flush/synced
  

  • 暂停要升级节点与集群间其他节点进行数据通讯，避免有新的数据产生（可选的）

  POST _ml/set_upgrade_mode?enabled=true
  

  关闭当前节点，在当前服务器中升级该节点ElasticSearch版本，其中ElasticSeaarch参考原节点进行配置。

  • 升级ElasticSearch使用插件

  使用elasticsearch-plugin脚本安装每个已安装的 Elasticsearch 插件的升级版本。升级节点时必须升级所有插件。

  
  

  语法：$ES_HOME bin/elasticsearch-plugin install XXXX
  

  • 启动升级的节点

  语法：$ES_HOME bin/nohup ./elasticsearch &
  

  • 重新启用分片分配（若为禁用自动分片功能，无需执行此步骤）

  PUT _cluster/settings{ “persistent”: { “cluster.routing.allocation.enable”: null }}
  

  • 等待节点恢复

  GET _cat/health?v=true
  

  注意

  在滚动升级期间，分配给运行新版本的节点的主分片不能将其副本分配给使用旧版本的节点。新版本可能具有旧版本无法理解的不同数据格式。

  如果无法将副本分片分配给另一个节点（集群中只有一个升级节点），则副本分片保持未分配状态，状态保持不变yellow。

  在这种情况下，一旦没有初始化或重新定位分片，您就可以继续（检查init和relo列）。一但另一个节点升级，就可以分配副本并且状态将更改为green。

  • 重复任务

  当节点恢复并且集群稳定后，对每个需要更新的节点重复这些步骤。

  • 重新启动节点与集群间其他节点进行数据通讯（若已经暂停该功能，若未暂停，忽略此操作）

  POST _ml/set_upgrade_mode?enabled=false
  

  注意

  在滚动升级期间，集群继续正常运行。但是，在升级集群中的所有节点之前，任何新功能都会被禁用或以向后兼容的模式运行。一旦升级完成并且所有节点都在运行新版本，新功能就会开始运行。一但发生这种情况，就无法返回以向后兼容模式运行。运行先前版本的节点将不允许加入完全更新的集群。

  如果升级过程中出现网络故障，将所有剩余的旧节点与集群隔离开来，您必须使旧节点脱机并升级它们以使其能够加入集群。

  如果您在升级过程中同时停止一半或更多符合主节点条件的节点，则集群将不可用，这意味着升级不再是滚动升级。如果发生这种情况，您应该升级并重新启动所有已停止的符合主节点资格的节点，以允许集群再次形成，就像执行全集群重启升级一样。可能还需要升级所有剩余的旧节点，然后它们才能在重新形成后加入集群。

  snapshot快照

  首先创建快照仓库

  注意：对于快照仓库需要每个节点都对其有访问权限，所以在实际使用中需要使用nfs挂载。

  • 使用Psotman方式创建仓库

  Postman:PUT http://192.168.115.130:9200/_snapshot/my_repository{
       “type”: “fs”, 
       “settings”: { 
           “location”: “/home/elastic/my_repo_floder”,
           “compress”: true, 
           “max_restore_bytes_per_sec”: “50mb”, 
           “max_snapshot_bytes_per_sec”: “50mb” 
       }
       }
  

  说明：my_repository为镜像仓库名称，Location 为镜像路径。

  • 使用Curl方式创建仓库

  curl -XPUT ‘http://192.168.115.130:9200/_snapshot/my_repository’ -H ‘content-Type:application/json’ -d ‘{ 
  “type”: “fs”, 
  “settings”: {
      “location”: “/home/elastic/my_repo_floder”, 
      “compress”: ****true****, 
      “max_restore_bytes_per_sec”: “50mb”,
      “max_snapshot_bytes_per_sec”: “50mb” 
      }
  }’
  

  备份索引（全量）
  • 使用Psotman方式备份

  Postman:PUT http://192.168.115.130:9200/_snapshot/my_repository/snapshot_1?wait_for_completion=true
  

  • 使用Curl方式备份

  curl -XPUT ‘http://192.168.115.130:9200/_snapshot/my_repository/snapshot_1?wait_for_completion=true’
  

  日志显示 completed with state SUCCESS

  • 查看备份对应索引信息

  Postman:GET http://192.168.115.130:9200/_snapshot/my_hdfs_repository/snapshot_1#snapshot_1是备份文件名称
  

  elasticdump方式

  Elasticdump工具是依赖于npm进行安装的，离线安装elasticdump步骤如下：

  #第一步下载node安装包
  wget https://nodejs.org/dist/v16.14.0/node-v16.14.0-linux-x64.tar.xz
  
  #第二步 在一台外网服务器安装node
  解压：tar xvf  node-v16.14.0-linux-x64.tar.xz
  建立软链接
  ln -s ~/node-v16.14.0-linux-x64/bin/node /usr/bin/node
  ln -s ~/node-v16.14.0-linux-x64/bin/npm /usr/bin/npm
  确认安装成功
  node -v
  npm -v
  
  #第三步安装npm-pack-all
  npm install -g npm-pack-all
  
  #第四步安装elasticdump
  npm install elasticdump -g
  
  #第五步 打包elasticdump
  进入到elasticdump安装目录 
  cd node-v16.3.0-linux-x64/lib/node_modules/elasticdump/
  执行 npm-pack-all
  当前目录生成 elasticdump-6.82.0.tgz
  
  #第六步 将node安装包和 elasticdump安装报复制到离线安装的服务器
  node-v16.14.0-linux-x64.tar.xz
  elasticdump-6.82.0.tgz
  
  #第七步 按照第二步安装node 和npm
  #第八步 安装elasticdump 
  npm install elasticdump-6.82.0.tgz
  
  #第九步建立软连接
  ls ~/node_modules/elasticdump/bin/elasticdump /usr/bin/elasticdump
  
  #第十步确认安装成功
  elasticdump --help
  

  #导出分词器
  [root@localhost ~]# elasticdump --input=http://ip:9200/my_index --output=http://127.0.0.1:9200/my_index --type=analyzer 
  
  #导出映射mapping
  [root@localhost ~]# elasticdump --input=http://ip:9200/ --output=http://127.0.0.1:9200/ --all=true --type=mapping
  
  #导出全部数据
  [root@localhost ~]# elasticdump --input=http://ip:9200/ --output=http://127.0.0.1:9200/ --all=true --type=data
  
  #如果集群配置了x-pack认证
  [root@localhost ~]# elasticdump --input=http://user:password@ip:9200/ --output=http://user:password@127.0.0.1:9200/ --all=true --type=data
  

  
  

  
  

  迁移注意事项

  ES数据迁移有两种情况

  • 一、ES版本不做变更，只是数据进行迁移；
  • 二、ES版本升级，同时数据迁移至新版本ES中

  上述三种方法均能完成ES的数据迁移，在实际操作时，请根据实际生产环境进行选择，优先选择Rolling upgrades滚动升级，同时需要注意一下几点：

  • ES版本发生变化，需要关注JAVA版本是否要随之变化，ES7版本时开始内嵌JAVA版本为17版本，由原1.8版本升级到17版本，jdk跨度较大，对API的调用挑战性较强。需要经过大量测试，必要时需要对代码进行重构。
  • ES存储数据类型发生变化，ES6版本中为自定义手动创建的，但是在ES7中只有一种数据类型为“doc”;
  • 当迁移数据量较大时，数据迁移花费时间较长，建议在业务平滑起或者晚上进行;
  
  
•