运维开发网

InfluxDB备份策略总结

运维开发网 https://www.qedev.com 2021-01-12 12:13 出处:51CTO 作者:chellman
InfluxDB提供了四种备份策略,基于总结对比,选择出适合于特定场景的备份策略。

备份概述

设备数据采集的时序数据使用InfluxDB进行存储,InfluxDB提供了两大类备份策略来保障数据安全:

1, 数据库实时主备

数据库主备是指通过内置的subscription机制,将主库收到的请求通过go-routine的方式到从库进行重放来实现数据的主备存储。这种方式可以认为是热备。

2, 数据定期备份

数据备份是指通过客户端工具提供的backup命令将数据备份到其他地方进行保存,需要恢复的时候通过restore命令加载数据备份。这种方式根据数据备份的频率存在丢失数据的风险。 

备份策略

数据库主备

通过subscription的方式实现主备的架构如下图:

InfluxDB备份策略总结

首先在InfluxDB的主服务器上通过命令建立订阅,包含如下信息:

1, 订阅名称”mysub”

2, 订阅的数据库和保留策略 ”mydb”.”autogen”

3, 数据目的策略,可选ALL(全部发送)和ANY(Round Robin发送任一)

4, 数据目的地,以逗号分隔的目标主机信息

创建完成后在主服务器上会生成一个类似路由表的数据结构,数采客户端发送数据(1)到主服务器后,主服务器根据路由策略生成一个或者多个writer(2)将数据同步发送到备库。

全量备份

全量备份通过influxd命令行工具,主要语法如下:

InfluxDB备份策略总结

基于全量备份的备份恢复策略可以用如下的流程图来表示:

InfluxDB备份策略总结

每天通过系统定时任务的方式触发bk_influx.sh的shell脚本进行数据备份,备份完成后传输到归档位置,可以是挂载的usb设备也可以是用户定义的网络位置。最后备份进行滚动替换,删除过期的备份数据。当数据库损坏或者需要搭建影子环境的时候只需要直接使用restore命令进行恢复即可。

增量备份

增量备份的是在上述全量备份的时候通过指定start和end进行区间过滤,但是start和end的实现上存在缺陷使得我们即使进行了过滤,一样会占用很多的系统资源进行大量的无用数据文件读操作。恢复的时候需要额外写工具进行数据导入。备份恢复的流程如下:

 

InfluxDB备份策略总结

从流程图上看增量备份的备份过程和全量备份基本一致,主要差异有:

1, bk_influx.sh的逻辑差异,备份时需要指定开始结束时间

2, 由于是增量备份,每一个备份都是相对独立的不需要备份替换过程

3, 数据恢复过程需要一个临时库存储增量数据,然后使用工具通过java 客户端从临时库读取数据并写入到主库。

离线备份

离线备份是InfluxDB早期版本提供的功能,准确的说应该是在线备份离线恢复,对应于MySQL的物理备份。

在InfluxDB的数据目录结构可以看出数据是分成meta、data和wal三个维度存储的。Meta存储的是元数据例如数据库结构,用户信息等;data目录中以tsm的文件格式存储时序数据;wal目录存储的是预写入日志。离线备份模式下会获取meta和data目录下对应的文件,wal目录下的文件因为没有同步到数据文件不做处理。

离线备份的语法如下,

InfluxDB备份策略总结

此外可选的参数有:

-retention 指定保留策略

-shard 指定需要备份的shard Id

-since 指定开始备份的时间RFC格式

离线备份恢复流程如下:

InfluxDB备份策略总结

1, 定时任务运行增量备份,备份当前时间对应的shard ID

2, 传输备份数据到指定位置,usb或者网络位置

3, 进行备份恢复之前需要关闭目标服务

4, 运行客户端命令进行离线恢复

5, 启动目标服务检查数据正确性 

从以上流程可以看出主要的难点有两点

1, 如何确定备份的频率

我们通过show retention policies可以确定shard定义的范围,如下图所示的定义一个shard包含了一周数据:

InfluxDB备份策略总结

基于此我们可以定义备份的频率为一周,当然小于一周也是可以的,只不过操作的是同一个数据文件在备份的时候进行滚动替换。

2, 如何确定最新的shard ID

通过show shards命令可以确定shard的分布:

InfluxDB备份策略总结

然后进入到data 目录下找到当前retention policy目录下最大的shard目录即为最新的shard ID。如图备份的最大shard Id为4185。

InfluxDB备份策略总结

出于完备性考虑,如果某一次备份没有进行则需要从最近一次备份的shard Id进行,所以可以新建文件来保存最近备份的shard ID,这样下次备份只需要找到大于最近备份的shard的所有shard进行备份即可。

获取shard Id的逻辑如下:

1, 获取最近一次备份的shard ID,如无则返回0

2, 遍历data目录,获取大于shard ID的所有文件夹名称

3, 循环进行增量备份

4, 备份完成后更新最近的shard ID

总结

InfluxDB提供了四种备份策略,对比如下表: 

备份策略

优点

缺点

适用场景

数据库主备

实时备份,数据安全性较高

架构复杂,系统资源消耗大

需要实现时序数据库高可用的情况

全量备份

兼容性好,恢复操作简单

海量数据的场景备份恢复占用大量的系统资源,影响实时业务

数据量不多(<10G)或者硬件性能较好的情况

增量备份

备份窗口时间缩短

恢复过程需要引入其他客户端工具(官方提供select into的迁移方式,数据量大的情况下也不现实),提供的start和end参数存在bug

已有InfluxDB迁移工具的情况

离线备份

物理备份速度快,资源占用少

备份的时候需要管理Shard ID,只能离线恢复并重启服务

数据恢复主要应用于离线分析和影子环境的场景

 从上表可以看出数据库主备的方式架构复杂而且系统资源消耗极大,一般情况下直接忽略。

在项目初期数据量较小的时候可以选择全量备份,减少操作的复杂度。随着数据量的逐渐增加,可以选择增量备份或者离线备份。如果选择增量备份需要自己准备InfluxDB迁移工具用于从临时库到主库的数据迁移,而选择离线备份则需要在备份脚本中增加shard ID的管理,当然因此换来的备份资源大幅缩减还是能值回票价的。

扫码领视频副本.gif

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号