江苏龙网

  1. 主页 > 生活百科 > >

DBA致命的低级工作？超大型系统数据库版本质量控制

DBA

宇文湛泉，现任金融行业核心业务系统DBA，主要涉及Oracle、DB2、Cassandra、MySQL、GoldenDB、TiDB等数据库开发工作 。
这似乎是DBA工作中最为无聊、繁琐以及最没有技术含量的事情 。这也许是DBA工作中，最可能一击致命、产生巨大损失的工作内容 。这部分内容虽然LOW，但是对于DBA工作来说，却是基石般的存在 。
从最朴素的角度上看，投产上线的数据库版本只有两部分，一部分是DDL文件，另一部分是在OS上运行生效DDL文件的脚本 。当一个系统里的数据库表并不多的时候，数据库版本可以作为应用程序版本的一部分 。数据库建表、变更，由开发者或者运维者执行生效到生产环境即可 。往往有经验的开发者或者架构师，可以凭借丰富的经验，一眼看出版本生效是否存在风险并给出回避方案 。
当系统越做越大，变得复杂起来，数据库表变得种类繁多，开发者的人数也越来越多 。通常会有出现两种选择 。一种是，谁的表谁管，即每次投产的数据库变更归对应的开发者，依然视为应用程序版本的一部分 。另一种是，整个系统的所有数据库变更，由某一个DBA来统一实施 。
前一种方式，往往会产生各式各样，五花八门的实施方案 。因为每个程序员都有自己的开发习惯和喜欢用的脚本 。如果这个系统，不仅复杂，而且还很重要 。那么这个系统的架构师就不得不花加倍的时间，来复核这些五花八门的方案的正确性和风险程度，以确保投产上线的万无一失 。
这时候，另一种模式会有个显著的好处，因为它有一个统一的实施工艺，这对于系统架构师或许会非常的重要 。因为无论这个系统里面有多少数据库表，架构师只需要审核有限种类的实施方法就行了 。毕竟只有一个实施的DBA，怎么着也不可能做出太多的实施方案 。不过显而易见，这种模式对这个实施的DBA可不是什么友好的事情 。我们来想象一下，若是一个DBA做一个超大规模的数据库版本，可能会遇到什么？
一、版本准备阶段
版本准备阶段，这指的是上线范围确认之后，到上线投产之前，做准备的阶段 。
【DBA致命的低级工作？超大型系统数据库版本质量控制】1、手滑风险
如果一次投产，仅仅是新建一张表或者加一个索引 。选择手搓一个SQL语句并拍到环境里的情况，并不罕见 。甚至不能说这有什么非常不合理 。但是手写数据库DDL和生效脚本绝对是充满了风险和不确定性的一件事情 。也许在测试环境或者专门的版本验证环境运行一次版本，能有效的挡住一些错误，但是绝对不会是万无一失的 。
举个例子：比如说数据库表的最后一个RANGE的范围（000-999）手滑写成了（000-998），凑巧测试环境，并没有这条边界数据，那么这个问题就极有可能在生产报错时能才能发现 。一旦一次变更的内容足够多，那手工版本不出错的可能性非常的低 。想象一下，你面对100个手写DDL文件时，你从第1个检查开始检查，在看第100个文件的时候，你是否还保持着你可靠的专注力，以确保你不会犯低级错误 。
2、版本范围准确性
当你面对很多的开发人员，在某一次版本，一次性变更100张甚至更多数据库表时，你做完数据库版本，难免会产生一种自我怀疑，“我有没有可能漏了一个索引？”更要命的是，尽管这100个表当初都是你亲自做的数据库设计，评审的SQL语句 。但是经过测试过程中，解决问题、调整方案 。这时候其中的某一张表，到底有几个索引，到底是什么使用场景，你可能都记不清楚了 。这时候如何对整个版本的正确性有把握呢？
3、版本内容准确性
当上线前，你打开上百个DDL文件，任何一张表都可能就有几十个字段加若干索引 。假设你是一个记忆力不错的DBA，你几乎记住了每一张表的各种使用形态，清楚它的分区等存储设计，了解哪些SQL使用哪个索引，甚至于你记得针对业务场景设计了一些特别参数，这些已经相当不易 。
如果说开发的程序员，在测试过程中，调整了某一两个字段的属性 。这时候还要让一个超大系统的DBA，把这个细粒度级别的内容，都记得清清楚楚，是非常困难的 。所以，超大型的数据库版本，必然会需要核准机制来确认你上线的DDL是完全没有问题的 。最简单的方式可能是，DBA需要确认投产使用的DDL于开发环境和各种功能、非功能测试环境的DDL一致 。或者DBA根本就是用同一个DDL文件来实施所有的环境的 。
4、警示机制
对于特别重要的数据库表，或者影响面特别重要的交易，在投产准备的过程中，应该要有足够的警示和应急预案 。比如说在线DDL有可能导致线上交易卡顿 。当版本中某一个数据库表涉及到类似监管机构考核响应时长的交易时，在版本实施之前，DBA应该提前给出相关的警示 。


推荐阅读


上一篇：Kafka到底会不会丢数据？

下一篇：Springboot2 什么才是真正的架构设计?