Playbook
mysql.yml deploys and adjusts clusters to declared state. Separate mysql-rm.yml retires members or clusters with safeguards. Before every removal, recheck the target, backups, and exact confirmation value.
mysql.yml
Selected clusters follow check → install → bootstrap → access → provision → backup → monitor:
Usage rules:
- Complete HA clusters: Partial
-lselection fails preflight to prevent topology divergence. Multiple complete clusters or no-lare permitted. - Idempotent: Converged clusters return
changed=0within seconds. After AdminAPI rejoin/clone, one expectedchangedcan restore declared replication seeds. - Check mode: Fresh nodes preview through package installation only; later stages need installed components. Deployed clusters support full previews.
- Initial three-node deployment takes approximately two minutes: certificates, configuration/init, AdminAPI creation, two clones, Router bootstrap, business objects, backup, and monitoring.
Stages and Tags
Common tag-scoped runs:
Run the full playbook for parameter and configuration changes. They require the rolling-restart workflow below.
Config Changes and Rolling Restarts
mysql_launch orchestrates restarts after configuration, certificate, or Systemd unit changes:
- Health: All three HA members must be
ONLINE. Degraded clusters reject restarts; repair first. - Secondaries: Use live roles, not
mysql_seq. Restart one secondary at a time and wait forONLINE. - Primary: Restart last. One automatic failover pauses writes for a few seconds.
Standalone restarts in place. Render-time mysqld --validate-config rejects invalid options before service changes.
Guardrails
mysql.yml rejects these conditions and reports the cause and next steps:
| Refused scenario | Rationale |
|---|---|
| Partial member selection | HA operations must cover the whole cluster |
| Invalid topology | Member count must be 1 or 3, with consecutive mysql_seq |
| Unsupported platform | Arch/OS outside the support matrix (e.g. Ubuntu ARM64) |
| Placeholder passwords | CHANGE_ME credentials left in place |
| Foreign datadir | Datadir lacks the Pigsty marker, or the marker names another cluster/instance/topology |
| Retirement marker present | Instance was retired by mysql-rm.yml; resurrection must be explicit |
| Implicit password changes | mysql_cluster_password or live root password differs from the declaration |
| Illegal parameter overrides | Reserved keys, malformed names, or multi-line values in mysql_parameters |
| Degraded-cluster restart | Config-driven restarts require all members ONLINE |
| Non-fresh clone target | Replacement members must be brand-new machines with empty datadirs |
| Complete outage | Quorum is never rebuilt automatically; the error prints the manual recovery steps |
These checks reduce risk but cannot guarantee against data loss. Before bypassing checks, verify backups and exact scope. Marker deletion and datadir erasure must be deliberate decisions.
mysql-rm.yml
Retirement accepts three scopes. Each requires mysql_safeguard=false and mysql_rm_confirm exactly matching its target:
Retirement behavior:
- Single-member retirement uses AdminAPI
force: falsefor anONLINE SECONDARY, or verifies an already detached member, then stops local services. The script runs on the target, which must be reachable. For dead hardware, use manual force removal. Primary retirement is rejected; first switch withsetPrimaryInstance. Removing two of three members together is also rejected. - Full-cluster retirement stops Router and backup timers, then secondaries before the primary. It deregisters exporters and monitoring targets.
- Each datadir receives
.pigsty-mysql-retired, blocking ordinarymysql.ymlreruns. - All data remains: datadirs, backups, configuration, certificates, packages, metadata, and Router identities. Destruction requires a separate manual decision after backup verification.
--check previews the full plan without changes.
Playbook Boundaries
These operations remain outside playbook scope. Follow manual Administration procedures:
- Planned switchover (
setPrimaryInstance); - Force removal of dead, unreachable members (
removeInstancewithforce: true); - Quorum rebuild after a complete outage (
rebootClusterFromCompleteOutage); - Physical restore (XtraBackup copy-back runbook);
- Destruction: removing datadirs, backups, or retirement markers;
- Topology changes (1→3, 3→5) and member re-addressing.
Was this page helpful?
Thanks—your feedback helps us improve this page.
What got in the way? (optional)