リレーショナルデータベースを実行する

PFCP では、 MySQL を簡単にデプロイして利用できるようにするための MOCO を提供しています。

Note

MOCO が作成する MySQL などのワークロードは、組織の他のワークロードと同様に計算ノード上にデプロイされます。

利用可能な MOCO リソース

PFCP で利用できる MOCO リソースは以下の 2 つです。

MySQLCluster

MySQLCluster は、 MySQL クラスタを定義するリソースです。このリソースを作成することで、 MOCO により管理された MySQL クラスタがデプロイされます。詳細については、MOCO の公式ドキュメント Creating clustersを参照してください。

BackupPolicy は、 MySQL のバックアップを管理するリソースです。このリソースを作成することで、 MySQL クラスタの定期的なバックアップを構成できます。 MOCO では bucketConfig によってバックアップ先を指定します。 backendType には s3 、 gcs 、 azure を指定できます。 PFCP で利用する場合は、クラスタからアクセスできるオブジェクトストレージと、そのオブジェクトストレージにアクセスするための認証設定をあらかじめ用意してください。詳細については、MOCO の公式ドキュメント Backup and restoreを参照してください。

MySQL インスタンスの起動

以下に、 MySQL インスタンスをデプロイするための MySQLCluster リソースの例を示します。 storageClassName には、ブロックストレージの StorageClass 名 standard-rwo-<組織名> を指定してください。 MySQL のデータディレクトリは単一の Pod から書き込むため、通常は RWX のファイルストレージではなく ReadWriteOncePod を利用できるブロックストレージを利用します。

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

バックアップを構成する

BackupPolicy を参照する MySQLCluster には、バックアップ用の CronJob moco-backup-<MySQLCluster 名> が作成されます。

バックアップジョブは spec.jobConfig.serviceAccountName で指定した ServiceAccount として実行されます。オブジェクトストレージへアクセスするための認証情報は、 ServiceAccount または env / envFrom で渡します。 PFCP でパブリッククラウドとの ID 連携を利用する場合は、パブリッククラウドと ID 連携を構成するも参照してください。

workVolume は、ダンプファイルや圧縮済みデータを一時的に配置するための作業領域です。バックアップ本体の保存先ではありません。 emptyDir や ephemeral のように Pod local storage を使う構成では、バックアップ時に必要な一時領域を十分に確保できないことがあります。そのため、バックアップ対象が大きい場合は、 MySQL データ用の PVC とは別に作業用の PVC を用意して workVolume から参照する構成を推奨します。

以下に、 Google Cloud Storage に日次バックアップを保存する BackupPolicy の例を示します。

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 はバックアップ Job の一時作業領域用 PVC です。 MySQL のデータ領域とは分けて用意します。 MySQLCluster 側では spec.backupPolicyName に BackupPolicy 名を指定します。 MOCO は古いバックアップを自動削除しないため、バックアップ先のバケットでは必要に応じてライフサイクル設定も構成してください。

MySQL インスタンスに接続する

MOCO は各 MySQLCluster に対して、書き込み用の moco-<MySQLCluster 名>-primary Service と読み取り用の moco-<MySQLCluster 名>-replica Service を作成します。たとえば Namespace org-<組織名> に moco-test-instance を作成した場合を考えます。この場合は moco-moco-test-instance-primary.org-<組織名>.svc と moco-moco-test-instance-replica.org-<組織名>.svc が利用できます。

また、 MOCO は moco-readonly 、 moco-writable 、 moco-admin という代表的な MySQL ユーザを用意します。認証情報の取得や対話的な接続には、 kubectl-moco kubectl plugin が便利です。

$ 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"

アプリケーション Pod から接続する場合は、書き込み用途では moco-<MySQLCluster 名>-primary を、読み取り用途では moco-<MySQLCluster 名>-replica を接続先として利用してください。詳しくは、 MOCO の公式ドキュメント Using the Cluster を参照してください。

Note

MySQL を運用する際のプラクティス

MySQL は MOCO がサポートするバージョンを利用してください。 MOCO の機能を利用して MySQL のアップグレードを行うことができます。

可用性を高めたい場合は replicas を2以上にしてレプリケーションを行ってください。

永続性が必要な場合は BackupPolicy を利用してバックアップを作成してください。

Keyboard shortcuts