dbbot 是什么，能给 MySQL DBA 带来什么

dbbot 是面向 MySQL 生态的开源 Ansible Playbook 仓库，把部署、复制、备份、恢复、监控接入沉淀成稳定、可重复、可审计的执行能力。本文从一个 MySQL DBA 的视角，讲清楚 dbbot 是什么、解决什么痛、怎么开始用。

打开公司的运维群，几乎隔几天就能看到这样的对话：

“MySQL 8.4 部署一下，三台。” “好的，密码、目录、参数发我下。” “和上次那套保持一致就行。”

听着挺顺，真到动手那一刻就开始蛋疼。上次那套是哪一套？变量是写在某台跳板机的 ~/scripts/install_mysql.sh 里？还是上一位同事提交的工单附件里那份 PDF？OS 是 CentOS 7 还是 Rocky 9？binlog 目录、relaylog 目录、备份目录是不是又得重新捋一遍？

你以为是部署，其实是考古。

我做 MySQL DBA 这些年，见过太多团队卡在同一个地方：装一套实例不难，难的是每次都装得一模一样。脚本是有的，文档是有的，知识库也是有的，但它们活在不同人的脑子里、不同电脑的桌面、不同年代的工单里。结果就是每个项目交付都像新做一遍 —— 同样的坑，再踩一次。

dbbot 的出发点很简单：我想要一套自己用着放心、别人也能跟着用、出了问题能复盘的 MySQL 自动化交付工具。不是写给 PPT 看的，是写给真正要在生产上稳稳交付的我自己看的。

这是 dbbot 博客的真正第一篇。先把"它是什么、解决什么、怎么开始"说清楚。

一、dbbot 究竟是什么

去掉一切包装，dbbot 就一句话：面向 MySQL 生态的开源 Ansible Playbook 仓库。

  • GitHub： https://github.com/fanderchan/dbbot
  • 核心覆盖：MySQL / Percona / GreatSQL，外加 ClickHouse 下游和 Prometheus 监控
  • 当前主要支持版本：MySQL 5.7 / 8.0 / 8.4 / 9.7、GreatSQL 8.0
  • 运行时：自带绿色版 portable-ansible 2.10.17，不挑控制机环境

它不是服务端，不是控制台，也不是 SaaS —— 而是 DBA / 运维同学已经熟悉的、基于 Ansible 的中控机工具，几乎没有额外学习成本。下载下来就是一个 tar 包：

curl -fL -O https://github.com/fanderchan/dbbot/releases/download/v0.14.0/dbbot-v0.14.0.tar.gz
tar -zxvf dbbot-v0.14.0.tar.gz -C /usr/local/

解压完里面就是几个 Playbook 子项目：

mysql_ansible/                  # MySQL / Percona / GreatSQL 部署、备份、恢复
clickhouse_ansible/             # ClickHouse 下游分析
monitoring_prometheus_ansible/  # Prometheus / Grafana / Alertmanager
portable-ansible/               # 内置绿色版 Ansible 运行时
bin/dbbotctl                    # 控制节点本地生命周期 CLI

剧本口味也很朴素，single_node.yml、master_slave.yml、mha_go.yml、mgr.yml、innodb_cluster.yml、backup_script_8.4.yml、restore_pitr_8.4.yml —— 文件名怎么写，剧本就干什么。

💡 冷知识： dbbot 的内置运行时来自另一个我维护的子项目 make_ansible_portable。为什么非要做绿色版？两个原因绕不开：(1) 一套工具要同时支持十几个操作系统的安装部署 —— RHEL 7/8/9、Kylin V10、openEuler 20/22/24、Anolis 8、BigCloud 等等 —— 每个 OS 上 Python 版本、pip 镜像、依赖矩阵都不一样，传统 pip install ansible 必然踩坑，更要命的是会污染甚至破坏线上业务正在用的 Python 环境，谁都不想为了装个运维工具把生产 Python 搞坏。(2) 绿色版自带依赖、整包体积更小、适合离线分发，控制机一拉就能跑。dbbot 把这个运行时直接打进发行包，国产化、内网、堡垒机环境也能直接落地。

二、它到底解决了 DBA 的什么痛

我把这几年遇到的 MySQL 运维"啰嗦事"列一下，就能看出 dbbot 想干掉的是什么：

1. 装一次叫一次魂的环境差异。 同样一份脚本，CentOS 7 能跑，Kylin V10 直接挂；好不容易适配了 Kylin，一上 openEuler 又翻车。dbbot 把 OS 适配收进 role 里，统一支持矩阵里查得到 —— RHEL 7/8/9、openEuler 20/22/24、Kylin V10、Anolis 8、BigCloud，谁能装、装哪个版本、能不能上 MGR / InnoDB Cluster，一张表说清楚。

2. “差不多就行"的目录布局。 这次 datadir 在 /data/mysql，下次在 /database/mysql/3306/data，再下次被同事手贱软链了一份到 /var/lib/mysql。dbbot 默认布局是 /database/mysql/<port>/{data,binlog,relaylog,redolog,tmp}，多实例天然按端口隔离，basedir 和 datadir 绑定，不会再有"这台 3307 数据放哪了"的考古活动。

3. 主从、MHA、MGR 自己拼。 主从拉一遍十几条命令，MHA 还要 ssh 互信、VIP、manager 进程；写错一行 CHANGE MASTER TO 半夜就得起来。dbbot 把这些都做成一行命令的剧本：

ansible-playbook master_slave.yml      # 一主多从
ansible-playbook mha_go.yml            # 用 Go 版 MHA 做高可用
ansible-playbook mgr.yml               # MGR 单主
ansible-playbook innodb_cluster.yml    # InnoDB Cluster + Router

4. “部署完了"和"部署成功"不是一回事。 Ansible 跑完没报红，不代表复制起来了、binlog 开了、参数对得上。dbbot 在每个剧本的 post_tasks 里默认跑一轮 post-deploy 检查：服务状态、端口、SQL 登录、binlog 状态、复制线程、复制源地址、复制延迟，一项不过整盘失败。

⚠️ 这一点我想专门强调： 结果可验证，是自动化的下限。一个自动化工具如果只能告诉你"任务跑完了”，却不能告诉你"结果对了”，那它跟 SecureCRT 的批量执行没什么本质区别。

5. 备份做得满意，但恢复没人敢演练。 国内多数团队都这样：备份脚本一年改一次，但谁都不敢动恢复演练。dbbot 把 MySQL 8.4 的 clone 备份和 PITR 恢复做成对称的一对剧本 (backup_script_8.4.yml / restore_pitr_8.4.yml)，把「能恢复」和「能备份」摆在同一个位置。

6. EA、内部包、定制包没法走自动化。 厂商先放出 EA 包，公司内部又会重命名、重打包、加校验，自动化矩阵里的"标准包名"压根追不上节奏。过去这种场景只能临时改 playbook，或者手工分发二进制 —— 自动化做了一半，反而留下一堆"这台机器到底用了哪个包"的考古遗产。这一块 dbbot 也已经有受控的解法，下一篇专门讲。

🔥 一个真实例子： 我们这边一台跳板机用 dbbot 同时管着 5.7、8.0、8.4 三个版本的多实例，端口从 3306 一直排到 3315。每个端口的 basedir、datadir、binlog、配置文件都按变量布在固定路径下。哪天要新加一个 3316，改个端口号、跑一次 single_node.yml，三分钟出实例。环境一致性是靠剧本守住的，不是靠脑子。

三、dbbotctl 不是 wrapper，是真生命周期

很多 Ansible 项目都喜欢配个 shell wrapper 假装自己有 CLI —— cd 进目录、设几个环境变量，仅此而已。dbbot 的 dbbotctl 不是这种东西，它管的是控制节点自己的生命周期：

dbbotctl doctor              # 体检：state 目录、依赖命令、sshpass、portable Ansible、exporter
dbbotctl env setup           # 初始化绿色版 Ansible 运行时
dbbotctl exporter register   # 把 node / mysqld / mysqlrouter exporter 注册到 Prometheus file_sd
dbbotctl release upgrade     # 从 GitHub release 或本地包升级 dbbot 自己，升级前留快照
dbbotctl release rollback    # 升级翻车了从快照回滚

dbbotctl 解决的是另一个老问题：dbbot 自己也要演进，演进过程也要可回滚。我宁愿先把工具自己的升级回滚做利索了，再去谈帮你升级 MySQL。

四、不是孤狼，是配套生态

dbbot 不是孤立项目，它和我维护的另几个开源工具是同节奏演进的，可以单独用，也可以跟 dbbot 一起用：

  • mha_go：用 Go 重写的 MHA manager，单个静态二进制 + 一份 YAML 就能跑。dbbot 的 mha_go.yml 直接编排它。传统 Perl 版 MHA 那种依赖一堆 CPAN 模块、装个 manager 节点要折腾半天的体验，下一代不应该再延续。
  • make_ansible_portable：dbbot 内置 portable-ansible 的构建链。离线、受限、被审计的网络环境最爱用这个。
  • mysqlrouter_exporter：专门采 MySQL Router 指标的 exporter，配合 InnoDB Cluster 用，配置和服务方式跟 dbbot 现有 exporter 体系兼容。
  • make_win_mysql_portable：Windows 本地 MySQL 绿色版，给那些不想装 Docker、不想搞 WSL 的本机开发用。

这些项目共同拼出来的东西，叫"一个 DBA 自己用顺手的工具链"。

五、一条主线：从 Playbook 到 Skills，再到 Agent

最近 AI agent 满天飞，每个 DBA 工具都说自己是"AI 驱动"。我对这类宣传有点警惕 —— 底层动作本身不稳定，自然语言只会把问题藏得更深。

dbbot 的 roadmap 是一条相对保守的路线：

  1. 当前阶段 (dbbot for MySQL)：把单机、主从、MHA-Go、MGR、InnoDB Cluster、备份、恢复、监控接入做成稳定、可重复的剧本。这是地基，是这个工具今天的全部对外承诺。
  2. 下一阶段 (Skills)：把高频运维动作沉淀成更小的 skills —— 明确输入、明确输出、明确前置校验、明确失败处理。让同一个动作可以被文档、CLI、Web、Agent 共用。
  3. 未来阶段 (Agent)：自然语言生成执行计划，由 agent 调度 skills 去触发底层 Playbook。高风险变更必须保留人工确认和审计。

先做稳剧本，再做 skills，最后才是 agent —— 这个顺序我不会调换。详细见 Roadmap。

那么你要从哪里开始？

如果你今天才认识 dbbot，建议按这个顺序入门：

  1. 先看简介 和 支持矩阵，确认你的 OS 和 MySQL 版本在覆盖范围里。
  2. 在测试环境跑一遍 单机部署演示，先把 dbbot 装起来，跑通一台 3306。
  3. 跟一遍 MySQL 主从部署快速开始，体验一次"一行命令一主两从"。
  4. 再把监控接入、备份、恢复挨个走一遍，建立起完整的运维闭环。

后面博客会一个个把真实环境里跑过的事写出来：单机和多实例怎么落、主从和高可用怎么拉、备份恢复怎么演练、监控怎么接入 —— 不是 PPT，是真机器上跑出来的过程和数据。

下一篇先讲一个最新版本 v0.14.0 引入的新能力。dbbot 默认只走官方正式包 —— 这是出于稳定性考虑的刻意克制；而 v0.14.0 在这条边界上留了一个受控的口子，让我们也能把还没进矩阵的版本拉进自动化部署，比如 MySQL 9.7 EA。下一篇就用这个能力，把 9.7 EA 单机并发部署到三台机器上。这三台环境之后会一直留着，后面的文章会拿它们挨个探索 9.7 里那些已经发布、乃至还没正式发布的新特性。