GaussDB技术解读系列：运维自动驾驶探索

​

随着企业数字化转型进入深水区，数据库系统越来越复杂，运维团队维护的数据库规模越来越大，传统工具化的运维已无法满足当前运维的要求，数据库运维逐渐向智能化发展。

如何更好地感知和预测数据库故障，进而进行智能诊断、自适应恢复，是我们一直探索的内容。接下来本篇将分享GaussDB在运维自动化驾驶上的探索与实践，分别从云数据库运维挑战，GaussDB运维体系架构，以及我们如何进行快速感知和快速诊断4个方向进行分享。

云数据库运维面临哪些挑战？
随着企业将数据库搬迁上云，云上数据库运维面临的挑战更加复杂。数据库可能会部署在裸金属、虚拟机、容器等多样化的基础设施上，不同的基础设施面对的故障场景也随之多样化。

如果我们遇到一个性能抖动的亚健康问题，通常解决思路是从应用数据库、操作系统、计算、存储、网络等方面多层次全面分析，每一层都可能发生故障，不同层次发生故障可能引发相同的亚健康现象。比如说一个慢SQL，可能是磁盘故障导致的，也有可能是网络抖动引起的，但是表现上对于客户来讲都是一个慢SQL。

如果运维能力不足，我们很难在短时间内去定位和解决亚健康问题，因为它在处理过程中一般有三个挑战：

第一，无法准确预测和监控亚健康问题

这里主要涉及到多和少的问题，“少”就是在每一层上缺少对亚健康问题的监控，比如说磁盘故障了，可以很容易感知到；但如果磁盘出现了坏块或者慢盘的情况，我们就没有办法快速监控。“多”体现在我们在每一层都做了监控和告警，但告警之间是没有关联性的，很难从这些告警中识别真正发生问题的点在哪里，所以很难精确发现当前的亚健康问题。

第二，发现亚健康问题之后没有办法进行快速诊断

对于数据库内部发生的问题，往往依赖DBA经验进行诊断和决策，对运维的能力要求比较高，效率也无法保证。

第三，恢复能力不足

我们当前诊断到发生问题的根源之后需要去恢复，但恢复能力不足，比如限流、扛过载的有效能力不足，涉及数据库参数调优、烂SQL优化等需要很深的数据库能力和经验的积累。

GaussDB整体运维架构
GaussDB是如何处理这些问题的？下面我们看一下GaussDB整体运维的架构，

GaussDB统一运维平台主要分为5个部分：

第一部分是实例运维，主要负