MySQL on Edka now runs on the upstream MOCO operator, so you get Kubernetes native MySQL clustering, automated failover, and managed backups without leaving the Edka console.
Why MOCO
- MOCO orchestrates MySQL 8.4.3 and 8.0.40 with Kubernetes CRDs, replication, health checks, and rolling updates built in.
- Primary/replica roles are monitored and healed automatically; no manual failover.
- Uses the official MOCO MySQL images and tooling, keeping you aligned with the project docs.
What you get in Edka
- One-click install from Apps & Add-ons; Edka installs MOCO and cert-manager for you.
- Cluster sizes 1/3/5 with primary and replica endpoints shown in the UI.
- Backups to S3 or GCS with schedules and binlog retention for point-in-time recovery; S3-compatible endpoints (MinIO, Ceph, Hetzner) work too.
- Optional LoadBalancer for external access; in-cluster services stay available for apps.
- MySQL Restore flow to hydrate a new cluster from the latest backup or a specific timestamp.
- Defaults tuned for Hetzner volumes and reasonable resource requests.
Launch a cluster
- In Apps, add MySQL (Edka ensures MOCO is installed).
- Pick MySQL 8.4.3 or 8.0.40, name it, choose 1/3/5 instances, set storage, and optionally set your own credentials.
- Choose connectivity: in-cluster only or external LoadBalancer.
- Enable backups if needed: pick S3 or GCS, set bucket/endpoint, schedule (e.g.,
@daily), and binlog retention to match your RPO.
The console shows primary/replica endpoints and connection strings. Secrets live in Kubernetes and can be rotated or replaced later.
Point-in-time recovery
Use MySQL Restore to spin up a new cluster from an existing backup. Choose the source, pick latest or a timestamp, and Edka recreates the data with MOCO managed credentials and endpoints. Binlog retention keeps restore points aligned with your recovery window.