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.
Updated for the Databases workspace: MySQL is now managed under Clusters → Databases. See the MySQL operations guide for current setup and recovery instructions.
Why MOCO
- MOCO orchestrates MySQL 8.4 and 8.0 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
- Create from Clusters → Databases; Edka installs MOCO and cert-manager for you.
- Cluster sizes 1/3/5 with primary and replica endpoints shown in the UI.
- Scheduled and manual backups to saved Amazon S3 or S3-compatible integrations, including MinIO and Hetzner Object Storage. Binary logs are archived during backup runs; recovery is limited to confirmed archive intervals.
- Public LoadBalancer, private MetalLB, or Tailscale access; public exposure requires managed TLS for provisioned application users.
- Restore from a completed snapshot or a confirmed archived time into a new installation.
- Configurable compute and storage, node-pool placement, managed users and grants, runtime insights, and planned maintenance.
Launch a cluster
- In Clusters → Databases, create a MySQL installation.
- Choose a catalog version (default image
8.4.8.1), name it, select 1/3/5 instances, and configure storage and resources. - Configure users and choose in-cluster, public, private MetalLB, or Tailscale access.
- On Backup, select a saved Amazon S3 or S3-compatible integration, an interval from 1 to 168 hours, and retention from 1 to 365 days.
The console shows primary/replica endpoints and connection strings. Secrets live in Kubernetes and can be rotated or replaced later.
Point-in-time recovery
On Backups, select Restore beside a completed snapshot. Choose the snapshot or a whole-second UTC time within its confirmed archive interval. The new installation uses the backup version and new credentials, with external access and scheduled backups off until you configure them.
Binary logs are archived with backups, not continuously. A later successful backup can extend the confirmed recovery window; selecting an arbitrary recent timestamp does not guarantee recovery. See MySQL recovery for the full workflow, including recovery after source deletion.