★ FEATURED ARTICLE 简介《Archery使用手册》是一份面向MySQL数据库管理员、后端开发及运维工程师的中文技术文档系统讲解了SQL审核查询平台Archery的部署、配置与应用。手册围绕SQL审核、SQL优化、实例管理和工具插件四大功能模块展开SQL审核部分介绍了自定义规则、高危语句自动驳回以及钉钉通知SQL优化部分涵盖执行计划查看、优化建议与慢日志统计实例管理部分包含binlog清理、会话终止、事务与锁信息查询、账号管理和参数配置工具插件部分演示了PTArchiver数据归档、Binlog2SQL日志解析与回滚、SchemaSync表结构同步。实践案例则完整演示了开发及测试环境下的SQL提交流程、回滚SQL下载以及常见阻塞问题的排查思路。资源共1个doc文档约1.2MB结构紧凑、便于按需查阅。该手册已有1477人学习浏览适合正在使用或计划引入Archery的团队作为快速上手手册与内部培训资料。1. Archery 是什么SQL 审核平台能把哪些运维事一把抓第一次把 Archery 放到生产环境团队里开发觉得多了一道审批DBA 反而觉得终于有理由拦住那些不带 WHERE 的 UPDATE 了。Archery 是一个 SQL 审核与查询平台核心思路是让所有 SQL 先过规则解析再走人工审批通过后才允许执行并且每一步都留回滚路径。它解决的不是“这条 SQL 能不能跑”而是“跑出问题后还能不能全身而退”。它适合开发团队统一上线入口也适合 DBA 管理测试库、归档库和日常排障。整套功能围绕 SQL 审核、SQL 优化、实例管理、工具插件四块展开真正用起来后会取代不少手写的临时运维脚本。2. SQL 审核流程怎么跑提交、检测、审批、执行与回滚一条线2.1 SQL 检测环节到底检测什么页面上“SQL 检测”按钮是我用得最多的功能。点下去之后Archery 会先做语法解析返回结果分成 error 与 warning 两级。error 直接拦截工单连提交按钮都点不了warning 提示风险但不会拦死留给审批人判断。语法错误只是最浅一层真正让团队反复改的是规范类规则。默认规则里最常见的三条建表必须有主键、表与列必须有注释、高危语句自动驳回。高危语句通常就是不带 WHERE 的 UPDATE/DELETE、DROP、TRUNCATE 这类不可逆操作。我第一次用的时候只点过一次 SQL 检测改完语句后忘了重新检测结果提交的还是旧版本审批通过后执行才发现问题。正确做法是每次改动都重新点一次“SQL 检测”按钮。这个按钮在工单操作栏里检测结果红色为 error、黄色为 warningerror 级别的 SQL 必须改到通过才能提交warning 级别可以把处理意见写在工单说明里让审批人知晓。规则不是写死的。管理员在规则配置页面可以调整严重级别例如把“UPDATE 无 WHERE”从 warning 提升到 error让它在源头就拦下来。生产库和测试库我建议用同一套规则标准否则开发在测试环境习惯了直接提交到生产第一个工单就会被驳回来回沟通成本比想象中高。2.2 开发与测试环境的两条审核链路手册里给了两个典型流程方向非常清楚。开发环境是研发工程师写好 SQL 文件由研发发起审核项目经理审批测试环境是测试同事从 git 取开发提交的 SQL 文件在测试环境发起审核审核通过后自己执行。两条链路的核心差异在审批人与发起人Archery 支持按流程模板配置审批层级单级、多级都可以改。按环境分开配模板别让测试同事去审生产工单也别让项目经理用测试模板走开发流程。环节开发环境测试环境SQL 来源研发工程师编写 SQL 文件测试同事从 git 取研发提交的 SQL 文件发起人研发工程师测试工程师审核人项目经理测试工程师可按流程模板调整执行人项目经理/研发测试工程师回滚能力工单详情页下载回滚 SQL工单详情页下载回滚 SQL实际操作时发起人要先选择目标实例和库名再把 SQL 粘贴进工单。这里最容易出错的就是实例选择。测试库与开发库经常同名比如都是 test选错实例后工单落到错误环境审核人看着一模一样的表名直接点了通过执行完才发现改的是另一个库。我现在提交前会把实例名、库名、环境标签连起来读一遍再点“SQL 检测”。完整操作序列是填工单信息、粘贴 SQL、SQL 检测、按提示修正、再次 SQL 检测、点击 SQL 提交。2.3 审批、执行与回滚工单审批入口在右上角“通知”按钮。项目经理登录后点开会看到待办工单工单详情里有 SQL 全文、检测结果和历史执行记录。审核通过是过了最后一道闸口之后页面出现两个执行选项立即执行和定时执行。立即执行适合测试环境或变更窗口内的低峰时段定时执行会弹出具体时间选择到点后平台把 SQL 提交到目标实例。执行完成后工单详情里会出现“下载回滚 SQL”和“查看回滚 SQL”两个入口。平台根据已执行语句生成反向脚本INSERT 对应 DELETEUPDATE 对应反向 UPDATE。这套能力来自对执行语句的解析记录不是对所有历史数据的通用回溯所以回滚范围严格限定在本工单涉及的表与语句。我的建议是执行通过后马上把回滚 SQL 下载下来按变更单号命名保存。真要到出了事再回工单页面下载现场人手一慌容易点错按钮。这里有个使用惯性的问题有些开发手头有数据库客户端直连权限工单审核完直接在客户端里执行绕过了 Archery 的执行记录后续出了疑似问题既没有回溯依据回滚 SQL 也关联不上。既然上了平台执行就尽量全走平台至少回滚时有据可查。2.4 用 SQL 优化功能给上线前做个体检手册里还单开了一块 SQL 优化功能。选中实例后输入待分析 SQL平台会生成执行计划和优化建议把 SELECT * 改成明确字段列表后分析结果才从 warning 变成 OK慢日志里的样本也会消失。这个功能不只用来调优我一般把它当成上线前体检新工单在执行前先跑一遍优化分析如果报出的问题集中在大表全扫、无索引字段就先别急着提交。慢日志列表同样值得定期看。页面会展示慢 SQL 统计信息哪个实例哪个库哪条语句最频繁上榜按执行次数和耗时排序都看得到。每周固定翻一次慢日志很多潜在问题能在业务方感知到卡顿之前被发现。这块和审核流程串起来正好是闭环优化分析发现慢语句审核流程拦住不规范写法执行后回滚 SQL 兜底。需要注意的是SQL 优化页面的分析是基于当前实例统计信息给出的建议仍然要以真实执行计划为准。看到分析结果 OK 不代表线上一定快表数据量、索引基数和并发都会影响最终表现。合理用法是把优化分析用于拦截明显问题上线后再结合慢日志验证实际效果。3. 实例管理实战清理 binlog、终止会话与锁阻塞定位实例管理默认只有管理员账号有权限。它解决的是上线之外的问题磁盘告警、会话阻塞、事务卡住、权限混乱。下面按我实际排查的顺序拆。3.1 清理 binlog先看备份再看可回滚时间窗口磁盘空间不足时清理 binlog 是最快的释放手段。入口在实例列表里选中目标实例后能看到当前可用的 binlog 文件列表每个文件按序号排列。Archery 的逻辑是选择某个 binlog 文件后该文件及其之前的文件都会一起被删除。清理前要确认这个实例有全量备份否则删掉的 binlog 没法再做基于时间点的恢复。有次同事在磁盘告警时选了当前正在写的 binlog 清理平台直接报错原因是正在使用的 binlog 文件被锁定关不掉。这不是 bug是保护机制。正确做法是选择当前文件之前的一个已经写完的 binlog 作为截止点先确认要保留的回溯窗口有多长。比如 Binlog2SQL 还要靠这些文件生成回滚 SQL回滚需求的时间范围在三天内那 binlog 至少要保留三天以上再清。清理完成后建议顺手刷新实例状态确认磁盘使用率已经降下来而不是等下次告警才回来看。提示binlog 删除是不可逆的清理前先确认全备时间与回滚需求窗口。3.2 会话管理定位阻塞并终止会话排查阻塞问题时会话管理是最先打开的功能。页面上能看到当前正在执行的 SQL顶部有数据库实例和 command 类型筛选默认 Query。如果只想看正在跑的查询保持默认就能过滤掉大量 Sleep 连接要排查长连接占连接数的问题就把所有状态列出来command 类型选 All。筛选栏下面有个“完整 INFO”的勾选务必先勾上再看否则长 SQL 会被截断经常只看到前半段条件根本判断不出是哪个业务。定位到可疑 SQL 后点击“终止会话”按钮即可把它杀掉。这里要理解这个动作的底层行为终止会话不等同于撤销数据库层面会对当前事务做回滚已经提交的语句不会回退。要撤销已提交的改动得靠前面的回滚 SQL而不是在会话管理里点终止。所以会话管理的使用场景是应急止血真正恢复数据走回滚工具链。3.3 事务信息与锁信息把死锁根源找出来事务信息页面能看到当前运行的事务列表核心关联字段是 trx_mysql_thread_id它对应会话管理里的 THREAD ID。排查流程是发现一个延迟很高的查询后在这个页面找是否有对应事务一直处于打开状态如果有未提交的长事务就会堵塞其他会话的更新操作。锁信息页面解决的是真正锁等待。手册给了一个很典型的模拟场景-- 会话 A持有锁 BEGIN; UPDATE test_schema.orders SET status paid WHERE order_id 2; -- 会话 B被阻塞 UPDATE test_schema.orders SET status shipped WHERE order_id 2;会话 B 执行第二条 UPDATE 会被阻塞因为 order_id 2 这一行被会话 A 锁住且事务未提交。锁信息里能看到等待方的事务 SQL也就是被阻塞的语句同时能看到持有锁的线程 id。根据这个 id 回会话管理搜索进程并终止阻塞立刻解除。这一步需要两个页面配合没有事务与锁的对应关系光看会话列表很难判断是谁持锁不放手。我每次遇到“页面转圈、更新超时”类问题都是直接进锁信息查持有线程再杀会话比到处翻监控快很多。3.4 账号管理与参数配置顺手做的事实例管理里的账号管理可以建账号、授权、改密、删除。典型做法是应用账号只给业务需要的增删改查权限表结构变更权限单独走工单授予只读账号只给 SELECT。授权界面是按权限项勾选的建完账号先授权再交付给业务方避免裸账号连上库却什么权限都没有。示例里最常见的授权组合就是增删改查加修改表结构权限建议根据业务实际用途收敛。参数配置页面可以修改实例动态参数并记录修改历史。我一般只动明确影响业务的参数比如连接数、超时时间改完立刻在会话管理页面观察连接是否异常然后记录变更原因方便出问题时回滚参数。每个实例的参数变更历史都会留痕审计时能直接追溯是谁在什么时间改了什么值。4. 工具插件怎么用不翻车PTArchiver、Binlog2SQL、SchemaSync 边界插件是 Archery 把外部工具可视化的模块。这类工具的核心价值不是功能多炫而是把命令行能力包成界面降低误操作率。但前提是你知道每个工具的适用边界否则插件只会让你更快地翻车。4.1 PTArchiver归档不是搬家先想好分批策略PTArchiver 适合把一张大表中的历史数据按条件归档到另一个库表典型应用是流水表只保留最近三个月三个月前的数据移到归档库。Archery 支持直接添加配置和由用户申请归档两种入口添加配置时填源库连接、目标库表、归档条件即可。平台会把 pt-archiver 的核心参数暴露成配置项。我比较关注的参数有两类批大小和提交频率。批大小太小归档慢太大主库压力明显上升。常见做法是监控主从延迟调整初始批次几千行内跑完整表延迟上来就调小。另一个硬性前提是源表必须有主键工具需要按主键逐行或分批处理没有主键的表直接放弃归档改成离线导出的思路。归档完成后到源库和目标库各做一次 count 校验数量不一致就得回查归档条件是否写错。4.2 Binlog2SQL闪回的范围只到 DMLBinlog2SQL 是回滚数据的重要通道。在界面上选择实例和 binlog 文件填起始与结束位置点击“获取 SQL”就能把这一段的日志解析成 SQL。示例里查看某个 binlog 从 857 到 1183 位置之间的语句获取结果后如果需要回滚再点一次 flashback 按钮重新获取平台输出的是反向 SQL用于恢复被修改的数据。要特别强调边界Binlog2SQL 不支持回滚 DDL 操作只能回滚 DML。建表、加字段、删索引这一类变更没有对应的“反向生成”基础想靠这个按钮恢复结构变更是不现实的。DDL 变更的后悔药只能靠变更前全备或结构导出。还有一点binlog 文件一旦被清理这一通道就断掉所以它和实例管理中清理 binlog 的联动要格外留意。前面提到保留窗口至少覆盖常用回溯时间就是怕关键时刻文件已经被清掉。注意Binlog2SQL 只能回滚 DMLDDL 操作没有对应的回滚 SQL。拿到回滚 SQL 后建议先在测试库跑一遍确认影响行数和数据形态符合预期再拿到生产执行。有些人拿到回滚 SQL 直接在生产上执行回滚完发现被反向更新覆盖了其他并发写入这种案例不在少数。4.3 SchemaSync只比对结构不要期待它动数据SchemaSync 用于读取源库和目标库的 schema自动生成同步更新与回滚 SQL方便自动化结构同步。使用前把源库目标库连接填好点击比对后页面会列出差异项包括两边表结构不一致、缺表、缺列等同时生成目标库需要执行的 DDL 和对应的回滚 DDL。这个工具的两条边界要记牢。第一仅比对表结构不比对数据别指望它发现数据差异第二它生成的是建议 DDL执行前要人工过一遍尤其是可能带出 DROP COLUMN 的差异项确认该列确实应该删除再执行。我的习惯是把生成的 DDL 粘贴到工单里再走一遍 SQL 审核流程而不是绕过平台直接跑。三个插件的边界总结成一张表合适插件核心作用硬性边界PTArchiver按条件分批归档清理源表数据表必须有主键需控制批次与频率Binlog2SQL解析 binlog 生成原始/回滚 SQL仅支持 DMLDDL 无法回滚SchemaSync对比两端结构生成同步与回滚 DDL只比对表结构不比对数据5. 高频踩坑与避坑清单审核、执行、binlog 回滚的五个典型问题5.1 工单显示“已执行”业务却说表里根本没有这个字段现象SQL 检测通过、审核通过、执行成功上线后接口立刻报 Unknown column。原因最常见的是发起人把实例选错检测与执行连接的库和业务实际使用的库不是同一个另一种可能是规则检查时没有重新检测SQL 在审批期间被改动过提交版本和执行版本不一致。解决提交前核对实例与库名一致性改动 SQL 后强制重新点一次 SQL 检测执行完成后在工单详情里查看实际执行语句与提交版本是否完全一致。5.2 清理 binlog 后数据无法回溯现象上线第二天想回滚一笔数据Binlog2SQL 页面选不到对应时段的 binlog 文件。原因磁盘告警时把 binlog 当成普通日志顺手清理了被删除的文件已经不在实例上也没有备份可恢复。解决清理前先确认全量备份时间点在实例列表做 binlog 清理时选择保留窗口内的截止点而不是一次全选把“Binlog2SQL 需要文件在”这个约束写进清理检查清单。5.3 定时执行到点没有跑现象工单里选了定时执行审核也通过了时间到了状态还是等待。原因平台调度组件没有正常执行也可能填的是过去时间或执行时目标实例无法连接。解决先看实例连接状态再确认调度进程是否在线紧急变更直接改用“立即执行”手动兜底别等到业务方来催。我发现定时执行比较适合低频窗口夜间自动化变更建议前后段都有人盯着而不是完全无人值守。5.4 回滚 SQL 执行后数据仍然对不上现象按工单下载的回滚 SQL 在生产执行核对发现部分行没有恢复到变更前状态。原因回滚 SQL 基于工单内的语句生成期间如果业务有其他并发写入覆盖了同一条数据回滚就会与新数据冲突另外回滚顺序不按主键顺序批量执行时主键冲突会中断整批。解决执行前在测试库试跑回滚 SQL观察影响行数执行时选择业务低峰暂停相关应用写入回滚完成立刻做 count 与抽样数据校验。5.5 pt-archiver 归档跑到一半把主库拖慢现象归档任务执行中监控发现主库延迟上升应用侧查询开始排队。原因批量大小设置过大提交频率过高源表又比较大归档流量挤占了正常业务。解决把批次调小提交频率调慢错峰运行避开业务高峰执行过程中盯着主从延迟延迟超过阈值先暂停任务。归档不是一次性的“搬家”把它当成一个持续任务来治理。6. 上线后的验证习惯用会话、锁与慢日志复盘一张工单6.1 我每次上线后强制走的四步复核工单执行完只是一个开始真正的验证在后面。我习惯把上线后的检查拆成四步。第一步进实例管理的会话管理页筛选应用账号对应的连接确认没有残留的异常 SQL 再放行第二步打开事务与锁信息看有没有产生新的长事务或锁等待出现就按前面的方法定位并终止第三步等半小时左右看一次 SQL 优化页里的慢日志列表对比上线前后的统计变化第四步把下载好的回滚 SQL 按“变更单号-日期”保存至少保留三天再清理。四步走下来大多数上线问题都能在业务投诉之前被发现。慢日志这个点最容易被人忽略。一次只改了一个 SELECT * 没有改为字段列表当时 SQL 检测显示 warning我没在意执行完第二天慢日志统计里多了一条查询接口平均耗时直接翻倍。完善 SQL 后重新分析语句才恢复 OK。从那以后SQL 检测返回的任何 warning 我都会当成上线前必须处理的问题而不是可选项。工具链里没有“银弹”Archery 能帮我们把审批流程、执行记录、回滚路径和排查能力集中在同一个平台但每一步还是需要人去做判断。建议新团队从 SQL 审核流程开始先把开发到测试的工单闭环跑起来再开实例管理和插件不要第一天把所有功能权限放开。这套手册把流程和案例都收在了一份文档里边看边配按环境逐步放开用两周时间就能把一套可落地的 SQL 运维流程搭起来。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
