持续关注突发，数据库运维应该关注哪些潜在风险？

导语 |  数据库技术的发展变化是怎样的？数据库运维优化和设计要从哪些方面入手？如何实现业务自助和业务的高可用？本文是dbaplus社群联合发起人，竞技世界资深DBA 杨建荣老师在「云加社区沙龙online」的分享整理，带给从事DBA领域的同学们一些职业成长方面的思路拓展。

点击视频，查看完整直播回放

引言

正式分享之前，先对最近热门的删库事件做一点反思。作为DBA应如何加强预防，改进措施防止再出现类似事件呢？我认为主要从三点出发：一是流程规范，二是技术支撑，三是安全制度。

之所以没有把技术支撑放在第一点，是因为对于现在暴露出来的许多问题，更多是在流程和规范方面设计不合理，在完善整个流程和规范的基础上，再做技术的补充。

从技术层面来说，一定要完善备份恢复体系。在现今的技术支撑方面存在一个短板，我们更多是在恢复单个环境，对于整个业务集群的恢复方面做得比较薄弱。

最后一定要完善安全制度，安全问题在工作中地位变得越来越重要。

一、技术变化

对于数据库运维开发和管理相关的工作可以浓缩为四点：

第一是技术的变化。

第二是优化和设计。

第三保证业务高可用，我们需要提高系统整体的高可用，和业务结合起来做到真正的业务高可用。

最后是业务自助，尤其在疫情大背景下显得更加重要，很多事情其实不需要太多的沟通环节，如果能够做到自助化服务，整体工作的衔接会比较流畅。

以我入行时经历过的一个难忘的坑说起。

同事很久交给我一套MySQL环境，我看到的是主从的环境，有一天收到一条报警，是从库服务器文件系统问题。我又仔细看了一下发现这个从库竟然没有开binlog，所以这是一个假的从库，但是这个业务是关键业务，摆明是一个坑。

要修复这个问题，就需要重启从库的服务，需要重新搭建slave节点。本来以为重启一个binlog没有什么大问题，但是发现数据库停不掉，或者起不来，起来有一些业务反馈连不上数据库，还有一些反馈的操作日志显示数据连接有异常，逐个做排查，发现这些问题都超出我们计划之外，可谓是一波三折。

所以很多看起来很简单，没有技术含量的事情，在实际工作中，会碰到很多比较具体的问题。我们在实际的工作应用中碎片化，琐碎化的事务会比较多，重复性也会比较多。

从技术的变化来说，我最早是做Oracle，逐步切换到MySQL和运维开发方向。经常听到很多人评判一个数据库哪一个好，哪一个不好，哪个大框架下更吃香。从我经历了Oracle到MySQL过程，感受到的是技术在逐渐返璞归真。

DBMS榜单是显示整个数据库的排行榜，可以看出Oracle、MySQL关系型数据库排名稳定靠前，在这个过程中，一些NoSQL发展也很不错。

我们以MySQL为例，大概十几年前，从原来的Sun公司分离，之后到Oracle公司，MySQL有一个逐渐分裂的过程。

下图列出了一些MySQL的组件服务，十多年之后，可以看到一些从属引擎已经被替代了，有一些被放弃了，而一些像innoDB引擎在Oracle官方支持下不断加强。

所以技术是在不断迭代，不断的演进过程中，而归真的部分是你会发现原来在互联网如火如荼的MySQL，在走入8.0版本之后很多功能都开始和Oracle的设计有相似之处，所以风水也是轮流转，很多问题不是单纯的技术问题。

二、优化和设计

关于对数据库的优化，主要体现在优化思维的转变。

早些年会大量对SQL进行分析优化，因为原来的业务场景比较复杂，导致很多的SQL写得比较长，有时能达到几百行，整个逻辑关系比较复杂，需要优化。

但是在现在互联网场景下面，这样的场景开始减少。原先的优化思维是要做得更多，但现在更多要求做得更少，直至达到至简设计的要求。

举一个例子，我们之前有个业务是做商业数据库迁移到MySQL，原先它的QPS是50万，我们把服务的负载进行分布式改造，改完了以后QPS变成了2万。从50万到2万，它的性能反而更容易扩展、更稳定。

我们原先是希望支撑更多的QPS，但是发现通过这样一个逻辑改造，做得更少的情况下，能够更好地满足原来场景，这就是在优化思维层面上比较大的转变之一。

现在复杂的SQL变得越来越少了，为了保证技术和业务的兼容性，很多业务的调用都在尽可能做到至简。

设计更多也需要从系统层面考虑，大家经常会关注千万级大表的优化方式？其实对于千万级大表的优化，可以拆成三个部分对待：

• 数量级：千万级

• 对象：数据表

• 目标：优化