Elasticsearch 保证集群高可用的方式包含但不限于如下三种:
关于如何创建快照和恢复快照,可以参考这篇:干货 | Elasitcsearch7.X集群/索引备份与恢复实战。
问题来了?7.6 之前的版本快照都是手动创建、手动控制的。不支持:定时快照、定时删除历史快照等功能。
实际业务中,如何定时创建快照、定时删除时间比较久的历史快照呢?
关于快照的定时管理功能在 Elasticsearch 7.6+
版本已经实现。
借助什么实现的呢?快照生命周期管理 (SLM) !
快照生命周期管理 (SLM) 是定期备份集群的最简单方法。SLM 策略会按照预设计划自动拍摄快照。该策略还可以根据用户自定义的保留规则(retention)删除快照。
如下实战演示是基于 Elasticsearch 8.1.3
版本进行的,没有涉及权限,只保留了最最核心的步骤。
在 elasticsearch 中添加如下配置:
path.repo: ["/www/elasticsearch_0801/backup_0801"]
注册快照存储库,同时设置存储路径。
PUT _snapshot/mytx_backup
{
"type": "fs",
"settings": {
"location": "/www/elasticsearch_0801/backup_0801"
}
}
这部分内容属于新版本才有的特性,我们逐行解释一下。
PUT _slm/policy/test-snapshots
{
"schedule": "0 0/15 * * * ?",
"name": "<test-snap-{now/d}>",
"repository": "mytx_backup",
"config": {
"indices": "*",
"include_global_state": true
},
"retention": {
"expire_after": "30d",
"min_count": 5,
"max_count": 50
}
}
含义:定时任务,类似 linux 下面的 crontab 命令。
直接看下面这张图:
分别对应的是:秒、分钟、小时、天、月、星期、[年(可选)]。
"0 0/15 * * * ?"中:0/15 代表每15分钟创建一次快照。
15分钟是最小的时间间隔,不能再小了,再小会报错如下:
{
"error" : {
"root_cause" : [
{
"type" : "illegal_argument_exception",
"reason" : "invalid schedule [0 0/1 * * * ?]: schedule would be too frequent, executing more than every [15m]"
}
],
"type" : "illegal_argument_exception",
"reason" : "invalid schedule [0 0/1 * * * ?]: schedule would be too frequent, executing more than every [15m]"
},
"status" : 400
}
也可以从磁盘的角度考虑,周期时间越多,备份的次数越多,涉及重复备份数据越多,磁盘会扛不住。
星期部分的“?”问号指代的是——当我们不关心是星期几的时候,都可以使用“?”问号代表。
含义:快照的名称。
含义:第一步创建的快照存储库。
含义如果设置为true(默认为true),则创建的快照包括集群状态以及 feature 状态。
啥是 featrue 特征状态?
GET _features
返回数据如下:
含义:配置可选的保留规则。如上的配置将快照保留 30 天,保留至少保留 5 个且最多不超过 50 个快照。
POST _slm/policy/test-snapshots/_execute
返回结果如下:
{
"snapshot_name" : "test-snap-2022.05.04-2vsflay-syotenwvgbh0kw"
}
执行完毕后,每15分钟会创建一个快照。最终在设定的快照存储路径下的结果为:
扩展:retention 快照的保留规则有定时执行或者手动立即执行两种方式。
PUT _cluster/settings
{
"persistent" : {
"slm.retention_schedule" : "0 30 1 * * ?"
}
}
POST _slm/_execute_retention
GET _snapshot/mytx_backup/*?verbose=false
返回结果如下:
想恢复哪一个?需要通过如上命令行或通过 kibana 可视化界面操作选择。
选择要恢复的快照后,执行恢复即可。
注意:原恢复索引若存在是不可以的,需要提前删除后再恢复。
DELETE .kibana-event-log-8.1.3-000001
POST _snapshot/mytx_backup/test-snap-2022.05.04-13d-_6dore-kc1x0-fdaiq/_restore
{
"indices": ".kibana-event-log-8.1.3-000001"
}
{
"accepted" : true
}
GET _snapshot/mytx_backup/_current
GET _snapshot/_status
GET _slm/stats
召回结果如下:
{
"retention_runs" : 0,
"retention_failed" : 0,
"retention_timed_out" : 0,
"retention_deletion_time" : "0s",
"retention_deletion_time_millis" : 0,
"total_snapshots_taken" : 67,
"total_snapshots_failed" : 0,
"total_snapshots_deleted" : 0,
"total_snapshot_deletion_failures" : 0,
"policy_stats" : [
{
"policy" : "test-snapshots",
"snapshots_taken" : 67,
"snapshots_failed" : 0,
"snapshots_deleted" : 0,
"snapshot_deletion_failures" : 0
}
]
}
其中, "snapshots_taken" : 67 是执行快照的次数。
我是:2022-05-04 14:21执行的快照,现在是:2022-05-05 6:51,时间间隔为正好接近 67 的 15 倍分钟数。
GET _slm/policy/test-snapshots
返回结果:
{
"test-snapshots" : {
"version" : 1,
"modified_date_millis" : 1651645270018,
"policy" : {
"name" : "<test-snap-{now/d}>",
"schedule" : "0 0/15 * * * ?",
"repository" : "mytx_backup",
"config" : {
"indices" : "*",
"include_global_state" : true
},
"retention" : {
"expire_after" : "30d",
"min_count" : 5,
"max_count" : 50
}
},
"last_success" : {
"snapshot_name" : "test-snap-2022.05.05-l4eldgoorfkkik8khlmuiq",
"start_time" : 1651733999879,
"time" : 1651734000637
},
"next_execution_millis" : 1651734900000,
"stats" : {
"policy" : "test-snapshots",
"snapshots_taken" : 100,
"snapshots_failed" : 0,
"snapshots_deleted" : 49,
"snapshot_deletion_failures" : 0
}
}
}
DELETE _snapshot/mytx_backup/test-snap-2022.05.05-uhbwjyj8qwwhdxqvcgejbq
执行成功,会返回:
{
"acknowledged" : true
}
有图有真相,不必过多解释!
快照部分截图
存储库部分截图
policy截图
restore截图
快照生命周期管理SLM 会让我们立即想到之前讲过的一个概念:索引生命周期管理 ILM。
你的业务环境有没有使用快照?有没有使用快照生命周期管理 SLM 功能呢?欢迎留言交流......
本文分享自 铭毅天下Elasticsearch 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!