数据库的备份是数据库工作的一个基本项,但实际上能做到毫无挑剔的备份,少之又少, 主要的问题在于备份的频率与性能之间的问题. 这有点类似于 RTO 和 RPO 之间的平衡. 具体怎么设置备份的策略是一个重要的问题.
系统1 800G 数据库整体数据大小,每天服务 8:00 - 18:00, 在晚上12点进行备份,备份时间2小时. 某天数据库10点DOWN机,数据磁盘损毁,通过备份恢复数据库用时3个小时,并且后续软件重新进行匹配和系统调试花费了4小时. 在下午5点的时候,系统整体恢复重新工作.(当然从夜里面12点到上午10点数据当然是丢失了)
嗯, 你的老板没有FIRE你,真是幸运.
我们看看到底我们出了什么问题
1 备份的策略的问题
2 恢复时间太慢的问题
3 没有高可用的问题
4 软件是否有解耦,降低恢复系统的时间的问题
看上图,一个备份恢复可能会把 ,软件部门的, 系统架构部门的, 运维部门的, DBA 部门的,统统抓起来痛打20大板子, 没有一个部门是无辜的.
估计说到这里,有人已经说,你这不胡说八道吗? 和软件部门有什么关系, 和架构部门有什么关系, 要说和运维和DBA 部门有关倒是对的. 那咱们就来分析分析.
一个系统在设计之初,是不是需要考虑未来几年内的数据量,并发量,故障中的恢复的时间,(故障恢复的便捷性), 系统架构层是不是的考虑,架构是不是能进行解耦, 应用系统的冗余,和数据库方面的高可用的冗余, 在什么状态下的 CRASH 能让系统继续工作, 关键点在哪里, DBA 那就毋庸置疑了,板子打的是妥妥的, 备份策略怎么制定的, RTO RPO 到底是怎么衡量的,和业务部门和开发部门怎么商量的, 备份软件怎么选择的, 如果预料到有问题, "为什么不早说 ,为什么不早说". 运维部门也逃脱不了干系,恢复数据库的硬件当初的选型是怎么选的,应该用那种技术来提高恢复的速度.
还是那句话,一个CRASH , 雪崩前的,没有一个雪花是无辜的. 这里跳过得罪人的N多文字. 仅仅从DB 层的备份策略来好好说说备份策略到底怎么做.
已POSTGRESQL 为例, 确认业务的重要程度和数据库丢失对于业务的影响度,告知目前的硬件水平,备份速度,以及对数据库在备份期间影响业务的程度,都需要一一评估并作出最终的结论, 告知 RTO , RPO 的平衡性, 因为在数据库系统中,你在怎么备份,遇到CRASH 的情况,都不能保证能百分之百的恢复数据.
(凡是说我们能百分之百恢复的数据的, 那您是备份软件的销售吧)
RPO Recovery Point Objective RTO Recovery Time Objective
RPO是指应用程序在不对业务造成重大损害的情况下可以停机的时间。一些应用程序可能宕机数日而没有严重后果。一些高优先级的应用程序只能宕机几秒钟，要不......
RTO
恢复时间目标是一个指标，它帮助计算在发生灾难后恢复应用程序(App 数据库)和服务以维持业务连续性所需的速度。
剩下的就是来通过一个业务连续性和数据备份频率之间的平衡了,因为备份必然对数据库的运行有影响,如果经常频繁的备份,那业务被影响,卡单,无响应等等,那备份就没有分辨出来到底他在整个系统运行中的角色.
那么到底备份的意义在哪里, 备份实际的意义,在于
1 降低数据库系统由于软硬件的问题,导致的数据丢失
2 快速通过备份来恢复丢失的部分数据
3 对于某些政策和规则性的满足,例如 银监会对于数据库的保留时间的要求
4 将数据恢复到其他数据库设备,提供其他公用
但备份一定不是一个系统CRASH 后救命的唯一稻草,系统早期的设计当中是不是应该考虑这个问题,我们举一个例子.
关键核心系统的交易,流水,必然不能光是数据库本身的责任,在操作的时候,将操作的信息同时记录到日志中,或者文档型数据库中,是一个方法. 有人可能不同意, 我将记录的信息也记录在业务得数据库里面这样不也是可以的吗,并且还少使用数据库,便于查询和恢复.
哼,
