Administration
Declare state in the inventory and apply it with the playbook. Most dropped members or AdminAPI drift recover after ./mysql.yml -l <cluster>. Member replacement, physical restore, and complete-outage recovery require the manual procedures below.
Quick Reference
| Operation | Command |
|---|---|
| Deploy / converge a cluster | ./mysql.yml -l <cluster> |
| Preflight without changes | ./mysql.yml -l <cluster> --check |
| Local root session | mysql --defaults-extra-file=/etc/mysql/pigsty/root.cnf |
| Inspect MGR topology | SELECT MEMBER_HOST,MEMBER_STATE,MEMBER_ROLE FROM performance_schema.replication_group_members; |
| AdminAPI status | dba.getCluster().status() in mysqlsh |
| Trigger a backup | systemctl start mysql-backup (in HA, only the primary runs it) |
| Retire a secondary | ./mysql-rm.yml -l <IP> -e mysql_safeguard=false -e mysql_rm_confirm=<instance> |
| Retire a whole cluster | ./mysql-rm.yml -l <cluster> -e mysql_safeguard=false -e mysql_rm_confirm=<cluster> |
Status Checks
Run these commands as root on a cluster member. Only root can read /etc/mysql/pigsty/ credentials. Examples use EL service names. Debian/Ubuntu uses mysql, not mysqld.
On any member, confirm services and topology:
A healthy three-node cluster has three ONLINE rows and exactly one PRIMARY. For AdminAPI status:
Use MySQL Overview or mysql:cls:health for fleet status: 2 healthy, 1 degraded, 0 critical.
Client Access
HA clients connect through any member’s Router, which follows failovers automatically:
Guidance:
- The server requires TLS and rejects plaintext. Client
PREFERREDnegotiates encryption automatically. Prefer explicitVERIFY_CAwith the Pigsty CA; JDBC usessslMode=VERIFY_CA. - There is no VIP/DNS layer. Use a multi-host DSN, such as
jdbc:mysql://10.10.10.11:6446,10.10.10.12:6446,10.10.10.13:6446/app, to avoid one Router failure point. Alternatively, list all members in the application load balancer. - Standalone instances have no Router. Connect directly to
3306. - A partitioned or quorum-lost member makes its Router reject read/write and read-only connections. This prevents stale Router reads.
Measured write interruptions are approximately 3–4 seconds for graceful primary shutdown and 20 seconds for kill -9 with default eviction. Secondary rolling restarts do not interrupt clients.
Manage Databases and Users
Edit mysql_databases / mysql_users in the inventory, then converge:
In HA, changes run on the current primary and replicate to other members. Declarations are additive. Nothing is dropped or revoked implicitly. Perform removals manually, then update inventory.
Change Cluster Parameters
All tuning goes through mysql_parameters:
Rolling-restart semantics (verified by testing):
- Validate rendered settings with
mysqld --validate-config. Invalid options stop execution without changing the service. - Check health. Fewer than three ONLINE members blocks rolling restarts. Repair before changing configuration.
- Restart secondaries one at a time, waiting for
ONLINEafter each. Restart the primary last. - Primary restart causes one automatic failover and a write pause of a few seconds. Schedule a change window if needed.
Standalone instances restart in place.
Switchover
The module does not orchestrate planned switchovers; use AdminAPI when you need one:
Routers follow the switchover automatically. Rerun ./mysql.yml -l <cluster> to verify convergence. Primary placement is runtime state, so the playbook does not move it back.
Member Failures and Self-Healing
No action is needed for ordinary failover. After a primary crash, MGR elects a replacement in approximately 20 seconds. Routers follow it. Systemd restarts the failed member, which rejoins automatically. Intervene for these cases:
| Symptom | Action |
|---|---|
A member stays OFFLINE (process up, GR stopped) | Rerun ./mysql.yml -l <cluster> — it rejoins the member |
A member repeatedly fails to join, logging peers not configured | Same: the converge pins group_replication_group_seeds back to the declared list |
| A member has not returned after a network partition heals | Wait ~1 minute for auto-rejoin; rerun the playbook if it still has not rejoined |
All members OFFLINE | Complete outage — see Recover from a Complete Outage |
| Hardware is unrecoverable | See Replace a Failed Member |
Matching alerts: MySQLClusterMemberOffline (WARN), MySQLClusterNoPrimary / MySQLClusterQuorumLost (CRIT).
Replace a Failed Member
Replacement hardware must reuse the failed member’s service address. Keep inventory unchanged. For failed my-test-3 (10.10.10.13), use three steps:
Notes:
- Step 1 removes the address from cluster metadata. Only an absent address qualifies for fresh clone. Retirement requires a reachable ONLINE SECONDARY or detached member. For dead hardware, use force removal in 1b.
- Replacement hardware must be fully clean, with an empty datadir and no Router keyring. OS reinstallation guarantees this. Preflight or Router bootstrap rejects partial cleanup.
- Clone copies the full dataset; time depends on size. One primary and one secondary keep the cluster available.
- Address changes during replacement and long-term two-node operation are unsupported.
Retire and Resurrect a Cluster
Retire a whole cluster (stop services, deregister monitoring, keep all data):
Retirement writes /var/lib/mysql/.pigsty-mysql-retired on every member. This blocks ordinary mysql.yml reruns and accidental revival. To restore service deliberately:
Two commands suffice for standalone instances. HA needs another step. Reruns start services, but all three Group Replication members remain OFFLINE. No member self-bootstraps, to prevent split-brain. The playbook reports complete outage. Follow steps 3–4 of complete-outage recovery to restore quorum.
Playbooks never destroy datadirs, backups, or packages. Decide on destruction manually after verifying backups.
Manage Backups
Backup layout, on the current primary’s local disk:
Check backup freshness on all HA members because backups follow the primary:
This version has no backup-freshness metric or backup alerts. Failures appear only in mysql-backup logs.
Query them through VictoriaLogs or the Instance dashboard’s Router / Backup Logs panel. In important environments, add external log checks and regularly rehearse restoration.
Restore from Physical Backup
This procedure restores standalone data to the latest backup. It is destructive: later writes are lost. Check the latest timestamp first. For HA, restore one primary node, then clone it to the other members.
The step-4 marker proves datadir ownership. Missing or mismatched contents cause mysql.yml to reject the restored directory. For HA, use "topology": "innodb_cluster" and the member’s own instance name.
Recover from a Complete Outage
If all three members are OFFLINE, MGR does not rebuild quorum automatically, preventing split-brain. This can follow power loss or cascading failure. mysql.yml stops with instructions. Use this procedure:
Notes:
- Step 3 usually restores all reachable members. Step 4 rejoins remaining members without manual per-node work.
- If only a minority survives, complete reboot to restore writes, then replace failed members.
super_read_onlyprevents writes until step 3 finishes. Members usually allow reads. Previously expelled members can remain inoffline_modeand reject ordinary connections.- Default
sql_require_primary_key=ONprevents tables without primary keys from blocking recovery.
Platform Password Boundaries
Operational boundaries for the three platform passwords (details: Parameters):
mysql_monitor_password: Change inventory and rerun to rotate.mysql_root_password: Implicit resets are rejected. On the primary, manually runALTER USER 'root'@'localhost' IDENTIFIED BY '...';. Then update inventory and rerun to refresh credential files.mysql_cluster_password: HA metadata and Router keyrings bind this password. Ordinary reruns reject rotation, and no automated HA rotation exists. If necessary, rotate manually through AdminAPI, synchronize all member credential files, then update inventory. Standalone instances rotate through inventory and rerun.
Was this page helpful?
Thanks—your feedback helps us improve this page.
What got in the way? (optional)