Warning

This page was translated from the original Japanese version by PLaMo Translate. The Japanese version is authoritative; the English translation may contain inaccuracies.

Running Relational Databases

PFCP provides MOCO to simplify the deployment and management of MySQL workloads.

Note

Workloads like MySQL created by MOCO are deployed on Compute Nodes alongside other organizational workloads.

Available MOCO Resources

PFCP supports the following two MOCO resources:

MySQLCluster is a resource for defining MySQL cluster configurations. Creating this resource deploys a MySQL cluster managed by MOCO. For detailed information, please refer to the official MOCO documentation: Creating clusters.

BackupPolicy

BackupPolicy is a resource for managing MySQL backups. Creating this resource enables configuration of regular backups for MySQL clusters. MOCO specifies backup destinations using bucketConfig. For backendType, you can specify s3, gcs, or azure. For PFCP deployments, you must first prepare object storage accessible by the cluster along with authentication settings for accessing that object storage. For detailed information, please refer to the official MOCO documentation: Backup and Restore.

Deploying a MySQL Instance

Below is an example MySQLCluster resource for deploying a MySQL instance. Be sure to specify the StorageClass name for storageClassName as standard-rwo-<organization-name>. Since MySQL’s data directory is written from a single Pod, we recommend using block storage with ReadWriteOncePod instead of RWX file storage.

apiVersion: moco.cybozu.com/v1beta2
kind: MySQLCluster
metadata:
  name: moco-test-instance
spec:
  replicas: 1  # Change replicas to configure replication
  podTemplate:
    spec:
      containers:
      - name: mysqld
        image: ghcr.io/cybozu-go/moco/mysql:8.4.8
        resources:
          limits:
            cpu: "2"
            memory: "8Gi"
  volumeClaimTemplates:
  - metadata:
      name: mysql-data
    spec:
      accessModes:
      - ReadWriteOncePod
      storageClassName: standard-rwo-<組織名>
      resources:
        requests:
          storage: 4Gi

Configuring Backups

A MySQLCluster referencing a BackupPolicy will automatically create a CronJob moco-backup-<MySQLCluster-name> for backups.

The backup job will run under the ServiceAccount specified by spec.jobConfig.serviceAccountName. Authentication credentials for accessing object storage should be provided either through the ServiceAccount or via env/envFrom. If you’re using identity federation with public clouds with PFCP, please also refer to Configuring Identity Federation with Public Clouds.

workVolume serves as a temporary workspace for storing dump files and compressed data. It is not intended for storing actual backups. Using Pod local storage options like emptyDir or ephemeral may not provide sufficient temporary space for backup operations. For larger backup targets, we recommend configuring a separate work volume PVC distinct from the MySQL data PVC and referencing it via workVolume.

Below is an example BackupPolicy configuration that stores daily backups in Google Cloud Storage.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: moco-backup-work
spec:
  accessModes:
  - ReadWriteOncePod
  storageClassName: standard-rwo-<組織名>
  resources:
    requests:
      storage: 20Gi
---
apiVersion: moco.cybozu.com/v1beta2
kind: BackupPolicy
metadata:
  name: daily-backup
spec:
  schedule: "@daily"
  jobConfig:
    serviceAccountName: db-backup-sa
    bucketConfig:
      bucketName: example-moco-backup
      endpointURL: https://storage.googleapis.com
      backendType: gcs
    workVolume:
      persistentVolumeClaim:
        claimName: moco-backup-work

moco-backup-work is a PVC for temporary workspace used by the backup Job. Ensure this is configured separately from the MySQL data storage area. On the MySQLCluster side, specify the BackupPolicy name in spec.backupPolicyName. Since MOCO does not automatically delete old backups, you should also configure lifecycle settings for the backup destination bucket as needed.

Connecting to the MySQL Instance

MOCO creates two Services for each MySQLCluster: a write-access moco-<MySQLCluster-name>-primary Service and a read-only moco-<MySQLCluster-name>-replica Service. For example, if you create a moco-test-instance in the org-<organization-name> Namespace, you can use moco-moco-test-instance-primary.org-<organization-name>.svc and moco-moco-test-instance-replica.org-<organization-name>.svc.

Additionally, MOCO provides standard MySQL users: moco-readonly, moco-writable, and moco-admin. For obtaining credentials or interactive connections, the kubectl-moco kubectl plugin is particularly useful.

$ kubectl moco -n org-<組織名> credential -u moco-admin moco-test-instance --format mycnf
$ kubectl moco -n org-<組織名> mysql -it moco-test-instance
$ kubectl moco -n org-<組織名> mysql -u moco-writable moco-test-instance -- -e "CREATE DATABASE app"

When connecting from application Pods, use moco-<MySQLCluster-name>-primary for write operations and moco-<MySQLCluster-name>-replica for read operations. For detailed instructions, please refer to the official MOCO documentation: Using the Cluster.

Note

Best practices for operating MySQL

Always use MySQL versions supported by MOCO. You can perform MySQL upgrades using the MOCO upgrade features.

For enhanced availability, configure replicas to 2 or higher to enable replication.

For persistent storage requirements, use the BackupPolicy to create backups.

Keyboard shortcuts