计算机系统不可避免地会发生内部故障、系统故障、硬件故障等问题,这些问题会造成数据库中的事务非正常停止,或部分数据丢失,因此数据库管理系统必须具有把数据库从错误状态恢复到某一已知的正确状态(亦称为一致状态或完整状态)的功能,这就是数据库的备份与恢复。
KingbaseES 提供的备份恢复方式可以分为两种:一种是基于日志的物理备份恢复,另一种基于SQL语句的逻辑备份还原。物理备份恢复和逻辑备份还原都是各自采用了不同的技术手段来达到保护数据的目的。基于日志的物理备份恢复和基于SQL语句的逻辑备份还原各有特点,适用于不同的场合,没有直接的好坏之分。
目录
物理备份恢复指的是通过备份集和归档日志将数据库转化为一致状态的过程,操作数据库的存储,如数据文件、日志文件等。 KingbaseES 通过备份磁盘中数据目录下的物理文件(数据文件、控制文件和日志文件),依靠还原数据文件和日志恢复技术来保护数据。目前只支持全系统备份,不支持单个数据库备份。
备份时,需要执行SQL查询,归档日志,拷贝文件,因此影响备份速度的因素较多;恢复时,需要拷贝文件,启动数据库后PITR需要归档日志重做到目标点,因此影响恢复速度的因素也较多。具体请查看下表:
影响因素 | 影响类型 | 影响分析 | 建议方案 |
---|---|---|---|
硬盘读写速率 | 备份、还原 | 备份或还原都需要拷贝文件、读取文件,硬盘速率可能会成为备份还原速度的瓶颈。 | 1. 使用高速度的硬盘或存储设备; 2. 在硬盘利用率较低时执行备份还原。 |
网络速率 | 备份、还原 | 备份集可能存储在另一台设备上,备份或还原时受限于网络速率。 | 1. 升级网络,比如千兆变万兆或者链路聚合; 2. 在网络空闲时执行备份恢复。 |
数据库业务繁忙程度 | 备份 | 备份时需要执行 SQL,数据库业务繁忙时响应时间会增加;备份时会等待归档当前WAL文件成功,若业务繁忙积攒了很多WAL,归档进程也会阻塞备份。 | 在数据库业务相对空闲时执行备份,参考用户使用手册设置 |
CPU、内存 | 备份、还原 | 备份还原依赖硬件资源,若硬件资源竞争激烈,必定会降低备份还原速度。 | 在硬件资源相对空闲时执行备份或还原。 |
对于事务内部故障和系统故障,数据库将使用日志文件自动恢复,不需要人工进行干预。但对于硬件故障、操作人员的失误以及恶意破坏事件,数据库无法进行自动恢复。因此,数据库管理员定期备份数据就很必要,当故障发生时,可以使用备份数据来恢复数据库。
数据库恢复到过去时间点时,会导致类似科幻小说里的时间旅行和平行宇宙的复杂情况,因而需要标识这些“平行宇宙”。每当数据库恢复完成时,都会创建一个新的时间线(类似于因时间旅行而产生的新的平行宇宙)来标识在该恢复后产生的WAL日志,为了区分因数据库恢复造成的不同时间段的WAL日志而产生的时间记录称为时间线(TimeLine),WAL日志文件名 000000010000000000000001 中前八位 00000001 表示的便是数据库的时间线。
数据库初始化后,默认时间线是1,随着数据库系统的运行,新时间线会在以下两种情况下产生:
PITR恢复后执行了promote操作( select sys_wal_replay_resume()
)
备节点升为主节点
每次创建一个新的时间线,KingbaseES 都会创建一个“时间线历史”文件,文件名后缀为 .history ,它里面的内容是由原时间线history文件的内容再追加一条当前时间线切换记录。假设数据库恢复启动后,切换到新的时间线ID为4,那么文件名就是 00000004.history ,该文件记录了当前时间线是在什么时间从哪个时间线由于什么原因分出来的,该文件可能含有多行记录,比如:
$ cat 00000004.history 1 0/140000C8 no recovery target specified 2 0/19000060 no recovery target specified 3 0/1F000090 no recovery target specified |
下图是时间线切换的示例,数据库正常运行在时间线1上,做过基础的备份,并且WAL日志归档完整,周五时发现关键数据丢失,经排查是 周四13:00时 误操作导致的, 周四12:00时 到 周四13:00时 期间无数据写入,因此将数据库恢复至 周四12:00时 的状态,恢复后确认数据符合预期,从此数据库运行在 时间线2 上。
可使用SQL查询 select timeline_id from pg_control_checkpoint();
或者 sys_controldata 命令查询数据库系统当前时间线,可参见如下截图:
备份集的时间线信息可以通过 sys_rman info 命令查询(标黄的八个数字代表了时间线),参见下图:
事务ID简称XID(transaction ID),是用于标识事务的唯一ID,在事务开启时分配,是代表事务的顺序编号,在 KingbaseES 内部都是单调递增,不会重复的。KingbaseES支持恢复到某个指定的事务ID,常用于精准恢复。
例如,以下的场景可应用XID恢复:
参考本文 复现和定位问题步骤 中查找 XID 的方法,使用《KingbaseES服务器应用参考手册》中的 sys_waldump 查询 WAL 段文件中的 XID并恢复。
可在SQL中调用 txid_current() 获取当前事务的XID,用于后续恢复
当遇到下述表格内的故障时,通过物理备份恢复就可以解决问题。
故障类别 | 举例说明 |
---|---|
硬件故障 | 硬盘坏道导致表文件读取失败 |
数据库系统故障 | 突然断电导致的缓 存(OS或硬盘)中的数据没有真正写入到持久化存储内 |
物理内存芯片损坏,加载到数据库缓存中 的数据异常,该数据刷回存储介质时写入了错误的数据 | |
数据库内核某项功能出现严重BUG, 导致数据库core掉,无法再次拉起数据库服务 | |
操作系统故障 | 操作系统突然死掉,导致正在运行的 数据库服务没有及时将缓存中的脏数据写到存储介质中 |
误操作或恶意操作 | 恶意程序或病毒感染了操作 系统,数据库关键表文件被加密,数据库服务异常报错 |
删除表数据时忘记添加限定条件,导致表被清空 | |
物理文件删除或 损坏,比如数据库data目录被删除,或某个文件被删除 | |
出于报复等原因恶意删库 |