故障自愈是不是应该尽可能让数据库自己来做

实际上我还是倾向于故障自愈主要还是要从应用架构上去做,如果要考虑数据库的故障自愈问题,那么我们就应该选择更适合自己的系统故障自愈场景的数据库系统,充分利用数据库的故障自愈能力来实现系统的故障自愈目标。依靠算法去自动发现数据库内部存在的复杂问题,并且通过自愈手段来修复故障,做起来往往很难落地。

前阵子和一个朋友谈到系统故障自愈的事情,因为朋友的企业属于传统行业企业,IT系统虽然做了大量的微服务化的改造,不过总体来说还是偏传统生产管理类业务。对于他们的一些故障自愈需求,实际上有些问题是系统故障自愈的问题,有些问题通过应用架构方面的优化,都是不难实现的。比较困难的大多数问题依然是数据库的故障自愈。他说他们做了几年数据库的故障自愈,真正做的比较好的也就是存储空间的自动扩容了。以前用Oracle的RAC和RAC ONENODE,通过FAN实现RAC节点故障的客户端无感自动切换做的也还可以,不过现在切换到开源和国产数据库上后,这部分也不太好做了。

故障自愈确实是数据库运维自动化系统中最难做的功能,去年和一个客户交流DBAIOPS的时候,客户问我你们的智能诊断准确率有多高?我说受限于算法和知识图谱目前的规模,我们的DBAIOPS系统的智能诊断的能力目只能能大致指向几个可能的方向,而无法直接定位到根因。他听了以后有点失望,说能不能提高算法的能力,直接定位根因呢?我问他为什么非要直接定位根因,他说他们做了几年数据库故障自愈,但是稍微复杂一些的场景都无法实现,主要是因为根因定位不清,导致自愈采取的措施不当。因此他们一直在努力提高根因定位的能力,想找到好的算法来提高故障自愈的能力。

实际上我觉得他们在做的工作是被互联网公司在这方面的成功给忽悠了,互联网公司是针对自己的业务对系统架构和数据架构都做了十分精细的设计,首先把数据库的功能简化了,大量的功能都已经拆分到应用系统中去了,因此故障自愈完全不是依赖于数据库来做的。数据库的故障自愈只剩下重启、切换、扩容等少量的十分容易实现的场景。

传统企业的应用系统对数据库功能而依赖十分强,数据库高可用、高并发等都是围绕着数据库来做的,因此做故障自愈的时候,往往刚开始做应用系统的时候还比较容易,做到数据库上面,就做不动了。像Oracle这样复杂的大型数据库系统,出现各式各样的故障,不可能重启一下就能解决问题了。

实际上我还是倾向于故障自愈主要还是要从应用架构上去做,如果要考虑数据库的故障自愈问题,那么我们就应该选择更适合自己的系统故障自愈场景的数据库系统,充分利用数据库的故障自愈能力来实现系统的故障自愈目标。依靠算法去自动发现数据库内部存在的复杂问题,并且通过自愈手段来修复故障,做起来往往很难落地。

数据库故障自愈的事情最好还是由数据库产品自身来完成是我一直的观点,因为在大多数情况下,数据库内核应该最先发现数据库自身存在的问题。实际上数据库自身就有很多故障自愈的能力,比如说死锁的自动检测与解决,早期的数据库是没有这个能力的,必须应用自己发现死锁,这个算法很复杂,自从数据库有了死锁自动解锁的能力,应用开发就简单多了。Oracle的TAF、FCF(FAN)等也是故障自愈很好的例子,也都是值得我们数据库厂商去学习的。包括在Oracle 11g之后,对某些HANG场景的自动发现与自动解除能力也越来越强,这些数据库产品上的故障自愈能力,都为我们系统级的故障自愈提供了极好的功能。这些实际上是广大用户除了优化器能力之外,最为关注的数据库功能,值得国产数据库厂商认真研究,这也是自治数据库最关键的能力之一。

要提高数据库的故障自愈能力,0数据丢失备机或者共享存储RAC集群是十分关键的能力。要想实现复杂场景中的故障自愈,重启或者切换依然是应用系统最容易实现的手段。但是在应用系统中切换主数据库并不是一件容易的事情,因为数据丢失可能会导致业务数据的不一致,如果能够做到无论何时都是0数据丢失的,那么应用系统切主数据库就可以变成一个十分常规的操作,完全可以不需要人为干预了。这也是我觉得集中式数据库需要去参考AWS AURORA的最主要原因。日志即数据库的方案不仅仅可以实现近实时复制的备机,通过在主数据库实例与只读备库实例之间实现CACHE FUSION,还可以实现強一致性读。这种架构的最大好处是能实现真正的0数据丢失,这让应用系统的切主数据库操作变得更为顺畅。

国产数据库产品除了提升核心的稳定性,提升CBO优化器的能力之外,实际上还是有很多事情可做的。Oracle因为有独步天下的RAC技术,因此没有在数据库上发展类似AURORA的技术,不过其MAA架构的发展也值得我们的国产数据库厂商参考。当我们还在大力学习MAA的时候,Oracle实际上已经在大力发展GDS计算框架了,我们的厂商完全可以跳过MAA,直接去学习GDS。前几天和一个数据库厂商交流的时候,他们说很快会在自己的数据库中推出类似ORACLE TAF的故障切换功能,我建议他们在发展TAF的时候,同时也应该学习一下FAN/FCF,FCF才能更好的让应用系统做故障切换。

应用系统做故障自愈的时候,我觉得还是尽可能放在应用系统本身,而数据库的故障自愈,还是尽可能交给数据库来做。系统设计者要做的是尽可能简化应用对数据库的使用方式,从而让数据库的故障自愈更简单一些,另外就是根据自己应用的特点,选择一个更适合你的应用故障自愈的数据库产品,这样做故障自愈,可能成功的机会更大一些。

请扫码关注数字化经济观察网
责编:高蝶
参与评论
文明上网,理性发言!请遵守新闻评论服务协议
0/200