SYS.DOCS // DOCS

MySQL

Edka runs MySQL in your Kubernetes cluster using the MOCO operator. Open Clusters → Databases to create and manage an installation. Its workspace includes Overview, Insights, Users & DB, Backups, Logs, and Settings.

Create an installation

Open Databases, start a new database, and select MySQL.
On General, enter a name, select the version, choose 1, 3, or 5 instances, and set the storage size and class.
Review Resources and Placement for compute sizing and node-pool selection.
On Users, configure the application database, user, and additional managed users and databases.
Use Access to configure credentials, external access, and TLS. Leave external access off for applications that connect from inside the cluster.
Use Backup to select saved object storage and a schedule, then submit.

The catalog includes 8.4.8.1 (the default image), 8.4.3, and 8.0.40. The fourth component in 8.4.8.1 identifies the MOCO image build; the MySQL server version is 8.4.8.

Edka installs MOCO and cert-manager as dependencies. Private MetalLB exposure requires cluster private networking. Install the Tailscale add-on before selecting tailnet exposure in the form.

The display name and Kubernetes runtime name are separate. Use the endpoints shown on Overview, rather than deriving a hostname from the display name.

Resources, placement, and storage

New installations request 250m CPU and 512 MiB memory per instance. These are starting values; size them for your workload. CPU and memory limits are optional. Older installations without explicit resource settings retain their existing defaults when you save unrelated changes.

Select a node pool on Placement and choose whether to tolerate its taints. On Resources, Prefer separate nodes allows replicas to share a node when necessary. Require separate nodes keeps replicas on different nodes and leaves pods pending if there are too few eligible nodes. Each instance has its own data volume; three instances with 10 GiB each require 30 GiB of data storage.

You can increase storage from Settings, but cannot shrink it or change its storage class in place. Expansion requires a storage class that allows volume expansion. Edka waits for the requested capacity and filesystem resize to complete before reporting the update ready.

Users and configuration

The Users section of Settings manages the bootstrap application user, additional users, databases, and database grants. Use Users & DB to inspect managed objects. Existing users created outside Edka require explicit adoption before Edka manages them. Removing a database from management offers retain or drop behavior; dropping it deletes its data.

Passwords are stored in Kubernetes Secrets. Use application credentials for application connections. Access also supports custom operator admin and writable passwords and subsequent rotation. The operator admin password has a 32-byte UTF-8 limit because it is also used for replication.

On Configuration, set maximum connections, maximum packet size, the InnoDB buffer pool, idle connection timeout, and slow-query logging and its threshold. Empty optional values use operator defaults. These controls validate supported parameters; the form does not accept an arbitrary MySQL configuration file.

Connections and TLS

Use Overview for connection details and Access for these exposure options:

Method	Reachability
In-cluster only	Applications inside the Kubernetes cluster.
Public LoadBalancer	An external endpoint for MySQL clients.
Private MetalLB	An IP in the cluster’s private network, reached through private routing.
Tailscale	An endpoint on your tailnet.

Changing the exposure method replaces the external endpoint. Update clients to use the endpoint shown after reconciliation.

Public exposure requires managed TLS and provisioned application users with TLS required. TLS is optional for internal and private access. Download the CA certificate from the connection details and use the supplied certificate-verifying client settings. If clients use a custom DNS hostname, include it in the TLS server name setting and point its DNS record at the endpoint.

Require TLS for provisioned users applies to Edka-managed application users. It does not enable a server-wide TLS requirement for MOCO’s internal accounts or for unrelated accounts you create directly in SQL.

Scheduled and manual backups

First create an Object Storage integration using Amazon S3 or S3-Compatible. The bucket must be reachable from your cluster, with credentials that can list, upload, read, and delete backup objects. Google Cloud Storage and Azure Blob Storage integrations are not MySQL backup targets.

Open Settings → Backup and turn on Scheduled backups.
Select Backup storage.
Set Interval (hours) from 1 to 168; the default is 24.
Set Retention (days) from 1 to 365; the default is 7.
Review Workspace (Gi), the temporary volume for dumps and binary logs. It defaults to twice the data volume size.
Save, then use Backups to inspect completed snapshots and failures.

The schedule runs on the hour in UTC inside your cluster. Scheduled backups can continue while Edka is unreachable; the catalog synchronizes when connectivity returns. Backup now takes an additional backup to the configured destination.

Backups contain full snapshots and binary-log archives. Expired completed backups are removed according to retention, while active restores protect their source archives. Deleting an installation preserves its backup catalog and archives for recovery, subject to retention. Keep the storage integration and bucket available.

Recovery window

Binary logs are archived during backup runs, not continuously. Recovery between snapshots becomes available only after a successful run has archived the required logs. Backups shows the latest confirmed recovery time; a configured schedule alone does not guarantee that every recent transaction is recoverable.

Choose a whole-second UTC time within the selected snapshot’s confirmed archive interval and strictly before its end. To recover at the next snapshot, select that snapshot instead.

Restore to a new installation

On Backups, select Restore beside a completed snapshot.
Enter the New installation name.
Choose Restore this snapshot, or Restore to an archived time when a confirmed interval is available. For the latter, enter Recovery time (UTC).
Select a destination Storage class and a Storage size (Gi) at least as large as the source volume.
Select Restore and follow the new installation’s provisioning progress.

Restore uses the backup’s exact MySQL version and creates a separate installation. The source is unchanged. The restored installation gets new credentials and starts with cluster-local access and scheduled backups disabled. Configure access and backups after recovery, and update applications to use the new connection details.

To recover a deleted source, start a new MySQL database, open Backup, and use Restore an existing backup. Organization administrators can also select backups from other clusters in the same organization. The destination must be able to reach the storage target and provision the selected storage class.

Maintenance and upgrades

Open Settings → General for Switch primary and Rolling restart. Save or discard configuration edits first. Maintenance requires a healthy runtime with all instances synchronized. Switching primary requires at least three instances and moves the primary role to a synchronized replica.

A single-instance restart interrupts connections. Clients should reconnect and handle interrupted connections during maintenance even with replicas; existing connections are not transferred to another server.

To upgrade, select a supported newer version and acknowledge that exact change. Apply the version upgrade separately from configuration or credential changes. Downgrades are rejected. Take and verify a backup before upgrading; recovery to an older version uses a compatible backup in a new installation.

Troubleshooting

Pending pods: check Overview for scheduling and volume diagnostics. Required replica spreading needs enough eligible nodes; backup jobs also need capacity for their temporary workspace.
Backup failures after credential rotation: correct the Object Storage integration, then save the database settings to apply the credentials in-cluster.
Requested recovery time unavailable: use a completed snapshot or a time inside its confirmed archive interval. Missing backup objects must be restored in storage before Edka can use them.
Failed restore: inspect the lifecycle message and restore-job logs, correct the cause, and start a new restore from the completed snapshot. Edka does not automatically rerun a failed native restore after you change credentials.
MOCO rejects a name longer than 40 characters: older creates could generate an invalid runtime name. Once your Edka backend includes the naming fix, delete and recreate that rejected installation. Retrying preserves its invalid name.