Kubernetes Custom Resource for MySQL.
Build Status Coverage Status Go Report Card GoDoc
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.
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
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/configRun code directly (ex. after making changes)
git clone https://github.com/grtl/mysql-operator && cd $_ go run -kubeconfig ~/.kube/config
Download MySQL Operator image from DockerHub to easily deploy it in your Kubernetes cluster.
docker pull grtl/mysql-operator
Or build it yourself
GOOS=linux GOARCH=amd64 go build -o mysql-operator && docker build .
Make sure the operator is up and running before creating any custom resources. All resources may be created with standard Kubernetes yaml files.
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
apiVersion: cr.mysqloperator.grtl.github.com/v1 kind: MySQLCluster metadata: name: "my-cluster" spec: secret: "my-secret"
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
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
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"
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"
Simply delete the cluster custom resource
kubectl delete mc "my-cluster"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
Simply delete the backup schedule custom resource
kubectl delete mbs "my-backup"A backup schedule will create backup instances according to the schedule.
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月27日T14:42:33Z
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.