What dbbot is, and what it gives MySQL DBAs

Open a company operations chat and you will often see this kind of conversation:

“Deploy MySQL 8.4 on three hosts.” “OK. Send me the passwords, directories, and parameters.” “Just keep it the same as last time.”

It sounds simple until the moment you actually start. Which “last time” are we talking about? Are the variables in ~/scripts/install_mysql.sh on some bastion host? Are they in a PDF attached to an old ticket by a former teammate? Was the OS CentOS 7 or Rocky 9? Do the binlog, relay log, and backup directories need to be sorted out again?

You thought this was deployment. In practice, it becomes archaeology.

After years of MySQL DBA work, I have seen too many teams get stuck in the same place: installing one instance is not hard. Installing it exactly the same way every time is hard. There are scripts, documents, and knowledge bases, but they live in different people’s heads, on different desktops, and in tickets from different years. Every delivery ends up feeling like a new one-off job, with the same holes stepped into again.

The starting point for dbbot is simple: I wanted a MySQL automation delivery tool that I can trust for my own work, that other people can follow, and that leaves enough evidence for review when something goes wrong. It is not written for slides. It is written for the person who has to deliver production systems steadily.

This is the real first article of the dbbot blog. Let’s make clear what it is, what it solves, and where to start.

1. What exactly is dbbot?

Without packaging it up, dbbot is this: an open-source Ansible Playbook repository for the MySQL ecosystem.

• GitHub: https://github.com/fanderchan/dbbot
• Core scope: MySQL / Percona / GreatSQL, plus ClickHouse downstream analytics and Prometheus monitoring
• Main supported versions today: MySQL 5.7 / 8.0 / 8.4 / 9.7, GreatSQL 8.0
• Runtime: bundled portable portable-ansible 2.10.17, so the control host environment matters much less

It is not a server, not a console, and not a SaaS product. It is a control-host tool based on Ansible, which DBAs and operations engineers already know. The learning curve is intentionally small. Download it and you get a tarball:

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/

After extraction, the package contains several playbook projects:

mysql_ansible/                  # MySQL / Percona / GreatSQL deployment, backup, recovery
clickhouse_ansible/             # ClickHouse downstream analytics
monitoring_prometheus_ansible/  # Prometheus / Grafana / Alertmanager
portable-ansible/               # Bundled portable Ansible runtime
bin/dbbotctl                    # Local lifecycle CLI for the control node

The playbook naming is deliberately plain: single_node.yml, master_slave.yml, mha_go.yml, mgr.yml, innodb_cluster.yml, backup_script_8.4.yml, restore_pitr_8.4.yml. The filename says what the playbook does.

Note: dbbot’s bundled runtime comes from another project I maintain, make_ansible_portable. Why build a portable runtime at all? Two reasons are hard to avoid. First, one tool has to support deployments across more than a dozen operating systems, including RHEL 7/8/9, Kylin V10, openEuler 20/22/24, Anolis 8, BigCloud, and others. Python versions, pip mirrors, and dependency matrices differ across those systems. A traditional pip install ansible path is guaranteed to hit problems, and worse, it can pollute or break the Python environment that production workloads already rely on. Second, a portable runtime carries its dependencies, keeps the release package smaller, and works well for offline distribution. The control host can pull it and run it directly. dbbot ships this runtime inside the release package so it can land cleanly in domestic, intranet, and bastion-host environments.

2. What DBA pain does it solve?

List the repetitive MySQL operations work from the past few years and you can see what dbbot tries to remove.

1. Environment differences that turn every install into guesswork. The same script works on CentOS 7 and fails on Kylin V10. After adapting it for Kylin, openEuler breaks again. dbbot moves OS adaptation into roles, and the unified support matrix makes the boundary visible. RHEL 7/8/9, openEuler 20/22/24, Kylin V10, Anolis 8, BigCloud: which OS can install which version, and whether it can run MGR or InnoDB Cluster, is shown in one table.

2. Directory layouts that are “close enough”. This time the datadir is /data/mysql; next time it is /database/mysql/3306/data; another time someone adds a symlink back to /var/lib/mysql. dbbot’s default layout is /database/mysql/<port>/{data,binlog,relaylog,redolog,tmp}. Multi-instance deployments are naturally separated by port, and basedir and datadir are bound clearly. You no longer need to rediscover where the 3307 data lives.

3. Building replication, MHA, and MGR by hand. Creating replication means running a dozen commands. MHA also needs SSH trust, a VIP, and a manager process. One wrong CHANGE MASTER TO line can wake you up at night. dbbot turns these into one-command playbooks:

ansible-playbook master_slave.yml      # One primary, multiple replicas
ansible-playbook mha_go.yml            # High availability with the Go version of MHA
ansible-playbook mgr.yml               # MGR single-primary mode
ansible-playbook innodb_cluster.yml    # InnoDB Cluster + Router

4. “Deployment finished” is not the same as “deployment succeeded”. An Ansible run with no red output does not prove replication is running, binlog is enabled, or the parameters match expectation. dbbot runs post-deploy checks by default in each playbook’s post_tasks: service state, port, SQL login, binlog status, replication threads, replication source address, and replication lag. If any item fails, the whole run fails.

This point matters: verifiable results are the baseline for automation. If an automation tool can only tell you “the tasks ran” but cannot tell you “the result is correct”, it is not fundamentally different from batch execution in a terminal client.

5. Teams like their backup scripts, but nobody wants to rehearse restore. Many teams are like this: backup scripts are adjusted once a year, but restore drills are avoided. dbbot puts MySQL 8.4 clone backup and PITR restore into a matching pair of playbooks (backup_script_8.4.yml / restore_pitr_8.4.yml) so “can restore” sits at the same level as “can back up”.

6. EA packages, internal packages, and customized packages do not fit normal automation. Vendors release EA packages first. Companies may rename, repackage, or add checks around them. The standard package names in an automation matrix cannot keep up. In the past, this usually meant temporarily editing a playbook or manually distributing binaries. Automation was only half done, and later you still had to ask: which package did this host actually use? dbbot now has a controlled answer for this scenario. The next article focuses on it.

A real example: one bastion host on my side manages multi-instance deployments of MySQL 5.7, 8.0, and 8.4 through dbbot, with ports from 3306 through 3315. Each port’s basedir, datadir, binlog directory, and config file are laid out by variables in fixed paths. When I need a new 3316 instance, I change the port and run single_node.yml. The instance is ready in about three minutes. Environment consistency is protected by the playbook, not by memory.

3. dbbotctl is not a wrapper. It is real lifecycle management

Many Ansible projects add a shell wrapper and call it a CLI. It changes into a directory, sets a few environment variables, and stops there. dbbot’s dbbotctl is not that. It manages the control node’s own lifecycle:

dbbotctl doctor              # Health check: state dir, required commands, sshpass, portable Ansible, exporters
dbbotctl env setup           # Initialize the portable Ansible runtime
dbbotctl exporter register   # Register node / mysqld / mysqlrouter exporters into Prometheus file_sd
dbbotctl release upgrade     # Upgrade dbbot from GitHub releases or a local package, with snapshots first
dbbotctl release rollback    # Roll back from snapshots if an upgrade fails

dbbotctl solves another old problem: dbbot itself evolves, and that evolution also needs rollback. I would rather make the tool’s own upgrade and rollback solid before talking about helping you upgrade MySQL.

4. Not a lone project, but an ecosystem

dbbot is not isolated. It evolves together with several other open-source tools I maintain. They can be used independently or together with dbbot:

• mha_go: a Go rewrite of the MHA manager. One static binary plus one YAML file is enough to run it, and dbbot’s mha_go.yml playbook orchestrates it directly. The old Perl MHA experience of installing a pile of CPAN modules just to prepare a manager node should not define the next generation.
• make_ansible_portable: the build chain for dbbot’s bundled portable-ansible. It is especially useful for offline, restricted, and audited network environments.
• mysqlrouter_exporter: an exporter dedicated to MySQL Router metrics, designed for InnoDB Cluster and compatible with dbbot’s existing exporter configuration and service model.
• make_win_mysql_portable: a portable local MySQL workflow for Windows, useful when you do not want Docker or WSL for local development.

Together, these projects form a toolchain that a DBA can actually use comfortably.

5. One direction: from Playbooks to Skills, then to Agents

AI agents are everywhere now, and every DBA tool wants to say it is “AI-driven”. I am cautious about that marketing. If the underlying actions are unstable, natural language only hides the problem deeper.

dbbot’s roadmap is intentionally conservative:

1. Current stage (dbbot for MySQL): make standalone, replication, MHA-Go, MGR, InnoDB Cluster, backup, recovery, and monitoring workflows stable and repeatable as playbooks. This is the foundation, and it is the full public promise of the tool today.
2. Next stage (Skills): extract frequent operations into smaller skills with explicit inputs, outputs, prechecks, and failure handling. The same action should be callable from docs, CLI, Web, or an Agent.
3. Future stage (Agent): generate an execution plan from natural language, then let an agent schedule skills to invoke the underlying playbooks. High-risk changes must still keep human confirmation and audit trails.

Stable playbooks first, skills second, agents last. I will not change that order. See the Roadmap for details.

Where should you start?

If you are meeting dbbot for the first time, start in this order:

1. Read the Introduction and Support Matrix to confirm that your OS and MySQL version are covered.
2. Run the single-node deployment demo in a test environment. Install dbbot first, then bring up one 3306 instance.
3. Follow the MySQL replication quick start to experience “one command, one primary, two replicas”.
4. Then walk through monitoring, backup, and recovery to build a complete operations loop.

Future blog posts will go through real runs one by one: standalone and multi-instance deployment, replication and high availability, backup and restore drills, and monitoring onboarding. No slideware, just processes and data produced on real machines.

The next article covers a new capability introduced in v0.14.0. dbbot defaults to official GA packages only. That restraint is intentional for stability. But v0.14.0 adds a controlled opening at that boundary, so versions outside the matrix can also enter automated deployment, such as MySQL 9.7 EA. In the next article, we will use that capability to deploy MySQL 9.7 EA standalone instances concurrently on three machines. Those three environments will stay around for later articles, where we will explore the new features in 9.7, including those already published and the ones not yet formally released.

• ←Previous
• Next→