1、Elasticsearch 保证高可用性的方法
Elasticsearch 包括但不限于以下三种方括但不限于以下三种:
方式一:副本分片。主分片失效后,副本分片会被提升为主分片。
方法二:跨集群复制主从同步。CCR,指索引数据从一个 Elasticsearch 将集群复制到另一个 Elasticsearch 集群。主集群索引数据的任何修改都将直接从索引集群复制同步。
方法3:快照。快照在给定的时间点按下集群或索引的暂停键,并在当时拍摄有的照片。这样,当集群或索引出现故障时,可以根据以前的快照快速恢复。
2、Elasticsearch 7.6 以前版本的备份方法和存在的问题
关于如何创建和恢复快照,请参考本文:干货 | Elasitcsearch7.X集群/索引备份和恢复实战。
问题来了?7.6 之前版本的快照是手动创建和控制的。不支持:定期快照,定期删除历史快照。
在实际业务中,如何定期创建快照,长期删除历史快照?
关于快照的定时管理功能在 Elasticsearch 7.6
版本已经实现。
在什么帮助下?快照生命周期管理 (SLM) !
管理快照生命周期 (SLM) 定期备份集群是最简单的方法。SLM 该策略将根据预设计划自动拍摄快照。该策略还可以根据用户定制的保留规则(retention)删除快照。
3、Elasticsearch 管理快照生命周期(SLM)实现
以下实战演示为基础 Elasticsearch 8.1.3
版本没有权限,只保留了最核心的步骤。
步骤1:配置快照存储路径和注册快照存储
在 elasticsearch 添加以下配置:
path.repo:["/www/elasticsearch_0801/backup_0801"]
在设置存储路径的同时,注册快照存储库。
PUT_snapshot/mytx_backup { "type":"fs", "settings":{ "location":"/www/elasticsearch_0801/backup_0801" } }
步骤2:配置定时快照任务
这部分属于新版本的特点,我们逐一解释。
PUT_slm/policy/test-snapshots { "schedule":"00/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 } }
"schedule": "0 0/15 * * * ?"
含义:定期任务相似 linux 下面的 crontab 命令。
直接看下图:
分别对应:秒、分钟、小时、天、月、周、[年(可选)]。
"0 0/15 * * * ?"中:0/15 代表每15分钟创建一张快照。
15分钟是最小的时间间隔,不能再小了,再小会报错如下:
{ "error":{ "root_cause":[ { "type":"illegal_argument_exception", "reason":"invalidschedule[00/1***?]:schedulewouldbetoofrequent,executingmorethanevery[15m]" } ], "type":"illegal_argument_exception", "reason":"invalidschedule[00/1***?]:schedulewouldbetoofrequent,executingmorethanevery[15m]" }, "status":400 }
也可以从磁盘的角度考虑,周期时间越多,备份次数越多,重复备份数据越多,磁盘就无法携带。
星期部分的?问号是指当我们不关心星期几时,我们可以使用?问号代表。
"name": "<test-snap-{now/d}>"
含义:快照的名字。
"repository": "mytx_backup"
含义:快照存储库的第一步。
"config": { "indices": "*","include_global_state": true},
如果设置为含义true(默认为true),创建的快照包括集群状态和 feature 状态。
啥是 featru 特征状态?
GET _features
返回数据如下:
"retention": { "expire_after": "30d", "min_count": 5, "max_count": 50}
含义:配置可选的保留规则。如上的配置将快照保留 30 天,保留至少保留 5 个且最多不超过 50 个快照。
步骤3:执行步骤2创建的 policy
POST _slm/policy/test-snapshots/_execute
返回结果如下:
{
"snapshot_name" : "test-snap-2022.05.04-2vsflay-syotenwvgbh0kw"
}
执行完毕后,每15分钟会创建一个快照。最终在设定的快照存储路径下的结果为:
扩展:retention 快照的保留规则有定时执行或者手动立即执行两种方式。
retention 定时执行:
PUT _cluster/settings
{
"persistent" : {
"slm.retention_schedule" : "0 30 1 * * ?"
}
}
retention 立即执行:
POST _slm/_execute_retention
4、恢复快照
4.1 步骤1:查看特定快照存储库下的所有快照
GET _snapshot/mytx_backup/*?verbose=false
返回结果如下:
想恢复哪一个?需要通过如上命令行或通过 kibana 可视化界面操作选择。
4.2 恢复快照
选择要恢复的快照后,执行恢复即可。
注意:原恢复索引若存在是不可以的,需要提前删除后再恢复。
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
}
5、Elasticsearch 快照生命周期管理(SLM)常见命令
5.1 监视任何当前正在运行的快照
GET _snapshot/mytx_backup/_current
5.2 返回任何当前正在运行的快照的每个细节
GET _snapshot/_status
5.3 查看全量 SLM policy 执行的历史
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 倍分钟数。
5.4 查看特定 SLM policy 执行的历史
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
}
}
}
last_success 代表上一次执行成功快照的名称;。
start_time 快照执行时间:2022-05-05 14:29:59。
next_execution_millis 下一次快照执行时间:2022-05-05 14:45:00。
snapshots_taken - snapshots_deleted 之差和retention 里规定的 50 个是基本一致的。
5.5 删除快照
DELETE _snapshot/mytx_backup/test-snap-2022.05.05-uhbwjyj8qwwhdxqvcgejbq
执行成功,会返回:
{
"acknowledged" : true
}
6、kibana 图形化界面操作快照生命周期SLM
有图有真相,不必过多解释!
7、小结
快照生命周期管理SLM 会让我们立即想到之前讲过的一个概念:索引生命周期管理 ILM。
ILM:解决的是基于冷热集群架构的时序索引的生、老、病、死全生命周期的管理。
SLM:解决的是快照的定时备份、定时清理功能。相较于之前的手动执行方式,自动执行的好处就是:全自动化,无需人工干预,能极大的提高开发和运维人员工作效率。
你的业务环境有没有使用快照?有没有使用快照生命周期管理 SLM 功能呢?欢迎留言交流......
参考
https://www.elastic.co/guide/en/elasticsearch/reference/current/api-conventions.html#api-cron-expressions
https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshots-take-snapshot.html#create-snapshot-considerations
https://jasmedia.medium.com/elasticsearch-backups-lifecycle-management-with-slm-8268366553a8
推荐
1、重磅 | 死磕 Elasticsearch 方法论认知清单(2021年国庆更新版)
2、如何从0到1打磨一门 Elasticsearch 线上直播课?(口碑不错)
3、如何系统的学习 Elasticsearch ?
4、干货 | Elasitcsearch7.X集群/索引备份与恢复实战
5、干货 | Elasticsearch 可搜索快照深入详解
6、干货 | Elasticsearch 索引生命周期管理 ILM 实战指南
更短时间更快习得更多干货!
和全球 1600+ Elastic 爱好者一起精进!
比同事抢先一步学习进阶干货!