从系统CRASH 恢复到应用系统的架构设计打板子

数据库的备份是数据库工作的一个基本项,但实际上能做到毫无挑剔的备份,少之又少, 主要的问题在于备份的频率与性能之间的问题. 这有点类似于 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 后救命的唯一稻草,系统早期的设计当中是不是应该考虑这个问题,我们举一个例子.

关键核心系统的交易,流水,必然不能光是数据库本身的责任,在操作的时候,将操作的信息同时记录到日志中,或者文档型数据库中,是一个方法. 有人可能不同意, 我将记录的信息也记录在业务得数据库里面这样不也是可以的吗,并且还少使用数据库,便于查询和恢复.

哼,????, 从几个角度就可以说明上面的想法有问题

1  将操作得流水信息,记录到业务的数据库中,数据库在频繁交易中不光是要应付业务的数据库,同时要应付你的操作流水得数据,  ---- 你考虑到数据库承受的压力与分散压力了吗?  自然是没有

2  任何系统都有可能CRASH在CRASH 的时候,操作的日志记录信息,可能是你能恢复数据的一个救命稻草,但你将他放到业务系统的数据库中, 试问是何道理, 是要一损俱损, 这样的应用一定要进行解耦,----不解耦数据的安全方面方面是一种问题,不知道这样设计的架构师,考虑没有考虑这样的问题.

3  数据的查询和数量之间的关系,自然操作日志的数据,大部分是不规则的,并且量也是比较大的,查询数据的时候却要定位准确,至少基于时间,或者关键字的方式. 所以这样的数据应该和传统数据库存储方式挂钩吗,是应该这样做的吗?

总结,一个系统的CRASH 以及恢复,是可以发现整体系统设计是好是坏的一个试金石, 良好的系统设计,让系统的备份,恢复以及CRASH 后的系统的恢复都变得简单, 反之,那就是一个灾难, 所以系统CRASH 后恢复的快慢,是不是和系统应用架构的设计和底层架构设计有关,答案是 YES.