sql 审核 - 避免离线 sql 导致的 db 集群故障

关键词： sql 审核、sql 审批、sql 检查、sql 检测、sql 执行

离线 sql 可能会导致的问题

首先，什么是离线 sql 呢？就是说手动触发执行的这种 sql；相对的还有在线 sql，位于我们的程序代码中，由程序触发执行的 sql 是在线 sql。举个例子，我们想要建库、建表、改表的时候，通常会编写 sql 语句，选一个合适的时间执行；这就是离线 SQL。当然，操作数据的离线 sql 也是有的，比方说线上程序 bug，我们想要手动修复个别数据，这时候也会提交离线的修改数据的 SQL。

那么，离线的 sql 可能会导致哪些问题呢？这个说起来还挺多的，我们来列举一下。建表或者改表的时候，可能会存在不规范的列，比如我们可能会不希望字段存在空值；可能会不小心使用不同的字符集；可能会不小心创建了重复的索引，给变更数据带来不必要的负担。而操作数据的时候，如果数据量特别大，一个不走索引的查询或者变更语句就可能给 db 带来灾难；或者偶尔由于手速过快，提交了不带条件限制的变更语句；另外，手动操作难免偶尔出错，出错了再去纠正数据也会十分麻烦。

如何避免问题

如何避免这些问题呢？最简单的方式是我们每次执行 sql 都提交给 dba，由 dba 同学手动检查后执行。如果公司规模很小，这样的话还能凑合（如果公司有 dba 同学的话），但人工审核也难免有注意不到的地方；而公司规模比较大的话，就比较费 dba 同学了【手动狗头】。

那我们可以在这个基础上再加一层：由研发 leader 审核完后，再由 dba 同学审核并执行。这样可以减轻 dba 同学的工作量，但是还是没有办法避免人工检查的遗漏。而且也没有办法方便的进行数据备份。

那么有没有更好的方式呢？当然是有的，把检查 sql 的标准梳理清楚形成一条一条的规则，然后固化到程序里，由程序来应用规则完成首轮检查，并在执行的时候，进行数据备份，需要时还可以进行数据回滚。

现成可使用的工具-Owl

Owl 就是这样一个开源工具，它提供 sql 提交流程审批、按规则检测 sql、执行 sql、备份、回滚等功能，可以用以管理起来所有的离线 sql 执行场景。它让我们的 db 数据更规范、db 集群更安全。下图是它的一个流程结构示意图。

首先它提供一个审批流程的地方，研发同学想要对自己访问不到（网络隔离）的线上环境执行 sql 时，可以在 Owl 上提交 sql 执行的请求工单，分别经过规则审核、leader 审核、dba 审核后，由 dba 在 Owl 上直接执行。

规则审批即是通过一些规则限制可执行的 sql。这些规则的实现还是挺有意思的，感兴趣的同学可以去代码中看，文末会有地址。规则举例：1，表必须使用 utf8 字符集；2，列和表都必须要有注释；3，变更数据影响行数不能超过 100；4，变更数据的 sql 必须完全匹配索引。上面这些都是具体的规则，规则可以打开或者关闭，打开状态的规则会拒绝不满足此条规则的 sql。下图是具体支持的部分规则截图，目前已实现 37 条规则。

dba 审核通过后，可以选择定时执行或者马上执行，如果是操作数据的 sql，则执行的时候会进行数据备份。之后，如果有需要可以进行数据回滚，回滚的时候会展示变更了哪些列以及原来的数据内容。下图是回滚时的截图,所修改行的数据会展示为红色。

当然，为了可以使用上述的一些功能还需要一些基础的功能模块，比如用户、管理员管理，集群管理、登陆认证等。由于一些规则需要获取具体的表数据信息来实现验证，所以需要 db 的账号和密码。密码是加密存储在数据库的，必须要有配置文件中的 key 和程序中固定的 key 才能解密，所以安全性是有保障的。

最后还需要说明的是：大批量的数据更新不适合通过 owl 去做，除非我们不需要做数据备份。因为 owl 的数据备份方式是特殊编码后转储到一张 db 表里，数据量过大会给内存带来很大的压力，也不适合放到表里了。

未来规划

首先是分库分表工具（gh-ost）的支持，有的公司使用了分库分表的模式，Owl 如果可以配置化的支持这个工具，用起来会更方便一些。

其次是支持数据查询功能，并使用部分规则加以限制，这是一个很常见的需求，没什么好说的。

另外还想改造一下用户相关的逻辑，让没有使用 ldap 做用户管理的公司也能方便的用起来。让使用更简单是一个长期目标。

以上的规划会在半年内逐步完成。

长远来看还可以加入 redis、es 等其他存储的读写功能，但是这个就比较久远了。

求个 star

最后，求一个 star 呀，每一个 star 都是对开源项目研发者的巨大鼓励！

项目地址：https://github.com/ibanyu/owl