mingbai

关键词: 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

相关文章: