Home

Awesome

MySQL Operator

Kubernetes Custom Resource for MySQL.

Build Status Coverage Status Go Report Card GoDoc

Running MySQL Operator

In order for the custom resources to be properly processed and an actual MySQL cluster deployed, a running instance of the MySQL Operator is required inside your Kubernetes infrastructure. The operator listens for changes on MySQLCluster and MySQLBackupSchedule custom resources and creates the appropriate objects.

As a Kubernetes pod

This is the recommended option. MySQL Operator will run as a pod inside your Kubernetes cluster.

kubectl run mysql-operator --image=grtl/mysql-operator:latest

As an out-of-cluster binary

Another option (suitable for development rather than a production-ready solution) is to run the MySQL Operator binary outside of the Kubernetes cluster.

go get -u github.com/grtl/mysql-operator
mysql-operator -kubeconfig ~/.kube/config

Run code directly (ex. after making changes)

git clone https://github.com/grtl/mysql-operator && cd $_
go run -kubeconfig ~/.kube/config

MySQL Operator Docker image

Download from DockerHub

Download MySQL Operator image from DockerHub to easily deploy it in your Kubernetes cluster.

docker pull grtl/mysql-operator

Build yourself

Or build it yourself

GOOS=linux GOARCH=amd64 go build -o mysql-operator && docker build .

Usage

Make sure the operator is up and running before creating any custom resources. All resources may be created with standard Kubernetes yaml files.

Clusters

Creating a cluster

First, a Kubernetes Secret containing the database password needs to be created.

kubectl create secret generic my-secret --from-literal=password="P4sSw0rD"

Then you can create a cluster from a yaml file.

kubectl create -f cluster-config.yaml

Example cluster-config.yaml (minimal)

apiVersion: cr.mysqloperator.grtl.github.com/v1
kind: MySQLCluster
metadata:
  name: "my-cluster"
spec:
  secret: "my-secret"

Example cluster-config.yaml (fully customized)

apiVersion: cr.mysqloperator.grtl.github.com/v1
kind: MySQLCluster
metadata:
  name: "my-cluster"
spec:
  secret: "my-secret"   # Name of the secret containing the password
  port: 3306            # Port on which the service will expose the MySQL
  replicas: 2           # Number of replicas
  storage: "1Gi"        # Persistance Volume Claim size for each replica
  image: "mysql:latest" # MySQL image

Restoring a cluster from the backup

While creating a cluster its data may be restored from an existing backup instance. The only difference between the configuration files for creating a cluster and the one to restore a cluster from backup is an additional field fromBackup field pointing to the backup instance.

kubectl create -f cluster-restore-config.yaml

Example cluster-restore-config.yaml (minimal)

apiVersion: cr.mysqloperator.grtl.github.com/v1
kind: MySQLCluster
metadata:
  name: "my-cluster"
spec:
  secret: "my-secret"
  fromBackup: "my-backup-2017-12-14-01-22"

Example cluster-restore-config.yaml (fully customized)

apiVersion: cr.mysqloperator.grtl.github.com/v1
kind: MySQLCluster
metadata:
  name: "my-cluster"
spec:
  secret: "my-secret"
  fromBackup: "my-backup-2017-12-14-01-22"
  port: 3306
  replicas: 2
  storage: "1Gi"
  image: "mysql:latest"

Deleting a cluster

Simply delete the cluster custom resource

kubectl delete mc "my-cluster"

Backup Schedules

Creating a backup schedule

You can create a backup schedule, which will automatically create backups according to the schedule (cron job style).

kubectl create -f backup-config.yaml

Example backup-config.yaml

apiVersion: cr.mysqlbackup.grtl.github.com/v1
kind: MySQLBackup
metadata:
  name: "my-backup"
spec:
  cluster: "my-cluster"
  time: "*/5 * * * *"    # Create a backup every 5 minutes

Deleting a backup schedule

Simply delete the backup schedule custom resource

kubectl delete mbs "my-backup"

Backup Instances

A backup schedule will create backup instances according to the schedule.

Getting backup instances

Get all backup instances

kubectl get mbi

Get all backup instances created within a given backup schedule

kubectl get mbi -l schedule="my-backup"

Get all backup instances created for a given cluster

kubectl get mbi -l cluster="my-cluster"

Standard kubectl output for backup instances lacks important fields, for a valuable output we recommend using output flag with the following configuration.

kubectl get mbi -o custom-columns="NAME:metadata.name,STATUS:status.phase,\
    SCHEDULE:spec.schedule,CLUSTER:spec.cluster,CREATED:metadata.creationTimestamp"

Example output:

NAME                 STATUS      SCHEDULE       CLUSTER      CREATED
my-backup-instance   Completed   my-backup      my-cluster   2018-04-27T14:42:33Z

Deleting a backup instance

Simply delete the backup instance custom resource

kubectl delete mbi "my-backup-instance"

Be aware that removing a backup instance will delete its contents from the Persistent Volume.