es实战-数据备份snapshot

灾备相关知识点RPO：最多可能丢失的数据的时长，即我们可以将数据恢复到什么时候，并且越接近现在（崩溃/丢失点）越好。RTO：从灾难发生到整个系统恢复正常所需要的最大时长。好的RPO实现：频繁增量备份好的RTO实现：加快从快照恢复数据速度ES snapshot 注意事项可在kibana的Snapshot and Restore功能模块进行操作不同快照间为增量式快照(节约时间空间)，且删除一个

casterQ

2210人浏览 · 2022-03-01 16:32:58

casterQ · 2022-03-01 16:32:58 发布

灾备相关知识点

RPO： 最多可能丢失的数据的时长，即我们可以将数据恢复到什么时候，并且越接近现在（崩溃/丢失点）越好。
RTO： 从灾难发生到整个系统恢复正常所需要的最大时长。

好的RPO实现： 频繁增量备份
好的RTO实现： 加快从快照恢复数据速度

ES snapshot 注意事项

可在kibana的Snapshot and Restore功能模块进行操作
不同快照间为增量式快照(节约时间空间)，且删除一个快照不会影响其他快照
SLM策略和集群执行保留策略是两个配置
可以手动执行策略测试
可以monitor后台运行的快照任务状态
删除正在制作的快照可以结束制作过程并删除文件
删除正在恢复的索引可以结束restore过程。

查看快照仓库下全部快照信息：

GET /_snapshot/test_backup/_all

查看快照仓库下正在制作快照信息：

GET /_snapshot/test_backup/_current

获取快照运行详细状态信息：

GET /_snapshot/_status
GET /_snapshot/test_backup/_status
GET /_snapshot/test_backup/snapshot_1/_status

查看 SLM 运行状态及计划：

GET /_slm/policy?human

立刻执行一次 SLM 计划：

POST _slm/policy/nightly-snapshots/_execute

使用删除快照 API 删除或取消快照制作：

DELETE /_snapshot/test_backup/my_snapshot

清理仓库删除无用快照文件：

POST /_snapshot/test_backup/_cleanup

SLM 定期清理策略执行时间：每天凌晨5点执行一小时

PUT _cluster/settings
{
    "persistent": {
        "slm.retention_schedule": "0 0 21 * * ?",
        "slm.retention_duration":"1h"
    }
}

跨集群数据迁移只读集群配置:

PUT _snapshot/test_backup
{
    "type": "hdfs",
    "settings": {
        "path": "/user/quantum_social/es-snapshot/mz_bia_social/test_backup",
        "uri": "hdfs://10.11.1.1:8020",
        "readonly":true
    }
}

恢复快照到集群使用自定义索引名：
将 my_snapshot 快照中的 caster 索引恢复为 test_caster 索引

POST /_snapshot/test_backup/my_snapshot/_restore
{
    "indices": "caster",
    "ignore_unavailable": true,
    "include_global_state": false,
    "rename_pattern": "(.+)",
    "rename_replacement": "test_$1",
    "include_aliases": false
}

查看索引的恢复状态

GET /caster/_recovery?human
GET /_cat/shards/caster?v&s=state&h=index,shard,p,state,node,unassigned.reason
GET /_cluster/allocation/explain //查看分片未恢复的原因

快照相关集群设置：

snapshot.max_concurrent_operations
快照创建和删除并发操作数限制

创建仓库时可配置参数：

max_snapshot_bytes_per_sec
节点级别快照制作速率限制，默认40mb。
max_restore_bytes_per_sec
节点级别快照恢复速率限制，默认无限制；同时受indices.recovery.max_bytes_per_sec参数影响，默认40mb，7集群当前配置120mb。
compress
是否压缩元数据，默认为false
readonly
是否设置存储库为只读，默认为false

restore 速度相关配置参数：

es 的 snapshot restore 操作由 snapshot 线程池控制的。这个线程池控制并发snapshot或者restore的线程的数量。一个shard需要绑定一个thread来进行操作。此线程池大小受3个因素影响：

机器可用processor数量，也既cpu核数。这个默认是读取机器配置。但是可以通过参数进行配置。
thread_pool.snapshot.max
thread_pool.snapshot.core: 20
restore 的并发分片数除了受到 snapshot 线程池控制之外，因为restore是与索引recover的机制相同，因此还受节点可并发恢复的主分片数量的限制。
cluster.routing.allocation.node_initial_primaries_recoveries：默认为4，限制了单节点同时recover/restore的主分片数为4。如果需要通过提高并行度从而加快restore过程，可增大此设置。
注：可能存在 restore 并发数不足数据节点数×4的情况，因为分片需要在节点均衡分布，某些节点提前完成，某些节点滞后。

FAQ:

快照制作并发和速率限制？
在运行多个快照制作、量较大时，会发现较多索引分片处于initializing状态；且会按启动顺序阻塞快照制作和删除任务。max_snapshot_bytes_per_sec 参数控制。
多 SLM 策略设置同样 schedule 是否存在问题？
kibana 的 warning，对 ES 影响不大。资料1 资料2
restore中出现部分分片无法恢复的情况
在 restore 过程中，部分分片通过 GET _cat/shardsapi 查看处于UNASSIGNED状态且其他分片均已恢复完成(即非等待恢复中而是不可恢复)
可通过GET /_cluster/allocation/explainapi 查看问题原因，并寻找解决办法，多为分片分配限制配置的问题，例：
索引index.routing.allocation.total_shards_per_node配置导致，每个节点分配分片数量。可在 restore api 中 index_settings 内修改对应参数进行恢复。
首次快照出现部分索引部分分片备份失败情况
由于网络超时，ES索引状态和HDFS状态等原因偶尔会出现部分索引的部分分片备份失败的情况，再次运行快照成功即可，无需纠结细节内容。