Module: MYSQL
MySQL is a widely used open-source relational database. Pigsty’s MYSQL module installs a fixed native MySQL 8.4 LTS platform on managed nodes. Choose a standalone instance or three-node single-primary InnoDB Cluster with Group Replication. The module manages TLS, backups, monitoring, and lifecycle.
MYSQL is a supplementary pilot module for a simple, low-cost MySQL cluster. Its scope is smaller than PGSQL. Deployment, convergence, HA failover, daily backups, monitoring, and alerts have systematic tests. Destructive complete-outage recovery and physical restore remain manual. Follow the Administration procedures.
Module Capabilities
The MYSQL module currently provides:
- Fixed native MySQL 8.4 LTS server, client, Shell, Router, and matching XtraBackup packages.
- Standalone or three-node single-primary InnoDB Cluster, created and reconciled through MySQL Shell AdminAPI.
- Router on each HA member, with topology-aware read/write
6446and read-only6447endpoints. - TLS with leaf certificates from the shared Pigsty CA. Non-TLS connections are rejected.
- Additive
mysql_databasesandmysql_usersdeclarations that never delete data implicitly. mysql_parametersoverrides, includingmax_connections, with rolling restarts after configuration changes.- Daily full physical XtraBackup backup and prepare, retention, concurrency locks, and atomic completion.
- mysqld_exporter metrics, 68 recording rules, 27 alerts, five Grafana dashboards, and VictoriaLogs error logs.
- Default
sql_require_primary_key, blocking tables without primary keys that would break MGR replication and recovery. - Convergent repair of dropped members and AdminAPI drift by rerunning
mysql.yml. Safeguards restrict destructive paths.
Module Architecture
NODE supplies node management, repositories, and the shared CA. INFRA supplies VictoriaMetrics, VictoriaLogs, Grafana, and Alertmanager. MYSQL depends on both, but not ETCD or PGSQL.
In three-node clusters, mysql_seq=1 coordinates bootstrap only. Runtime PRIMARY is elected. Reruns never force it back to node 1.
Components and Ports
| Component | Purpose | Fixed endpoint |
|---|---|---|
mysqld | Standalone server or MGR member | Classic 3306, X Protocol 33060 |
| Group Replication | Three-member replication and consensus (XCOM) | 33061 |
| MySQL Router | Topology-aware entry point on every HA member | RW 6446, RO 6447 |
| MySQL Shell | AdminAPI cluster lifecycle | Local control plane |
| XtraBackup | Daily full physical backup | Local backup repository |
mysqld_exporter | Server and MGR metrics | 9104 |
The role creates and manages three platform identities:
dbuser_cluster@'%': TLS-only AdminAPI and Router bootstrap identity (created on HA clusters only);dbuser_monitor@'127.0.0.1': least-privilege exporter identity;dbuser_backup@'localhost': local XtraBackup identity.
Supported Platforms
The native-package platform gate admits:
| Arch | Supported systems |
|---|---|
x86_64 | EL 8/9/10, Debian 12/13, Ubuntu 22/24 |
aarch64 | EL 9/10 |
Preflight rejects Debian/Ubuntu ARM64 because Oracle APT has no MySQL 8.4 arm64 packages. On ARM, use EL 9/10, such as Rocky Linux.
Scope and Boundaries
MYSQL provides a fixed platform. Before adoption, accept these scope limits:
- One or three nodes only: No in-place 1→3 or 3→5 expansion and no persistent two-node operation. Use logical migration for capacity changes and same-address replacement for hardware refresh.
- Fixed versions, ports, directories, and charset: No parameters change them. Memory sizing comes from node specifications. Override individual keys through
mysql_parameters. - Daily local full backups: No incremental chains, continuous binlog archives, or PITR. Physical restore is manual; follow the procedure.
- Manual complete-outage recovery: This avoids split-brain from automated guesses. Playbook failures print recovery instructions.
- No VIP, DNS, or HAProxy access layer: Connect through any member’s Router, preferably with a multi-host DSN.
Documentation
| Page | Content |
|---|---|
| Configuration | Topology planning, identity, databases, users, parameter overrides, backup settings |
| Parameters | The 11 public parameters and fixed platform conventions |
| Administration | Status checks, client access, config changes, failure handling, and three recovery runbooks |
| Playbook | mysql.yml and mysql-rm.yml usage, tags, and guardrails |
| Monitoring | Dashboards, recording rules, alert rules, log queries |
| Metrics | Label model and the derived-metric dictionary |
| FAQ | Platform limits, primary-key policy, recovery, troubleshooting |
Quick Start
Declare a cluster in the inventory (full template: conf/demo/mysql.yml):
After NODE provisioning, deploy:
Then open the Grafana MySQL Overview dashboard to inspect the cluster.
Plan MySQL topology and identity; declare databases, users, parameter overrides, and backup policy.
The MYSQL module’s 13 public parameters: 11 deployment parameters, 2 protected-removal parameters, and fixed platform conventions.
Status checks, client access, configuration changes, failure handling, and the three recovery runbooks for MySQL clusters.
Deploy, converge, tune, and retire MySQL clusters with mysql.yml and mysql-rm.yml.
MySQL metric collection, Grafana dashboards, alert rules, and log queries.
Label model, derived-metric dictionary, and raw metric families of the MYSQL module.
Frequently asked questions and troubleshooting for the Pigsty MySQL pilot module.
Was this page helpful?
Thanks—your feedback helps us improve this page.
What got in the way? (optional)