Oracle recently open sourced a Kubernetes operator for MySQL that makes running and managing MySQL on Kubernetes easier.
The MySQL Operator is a Kubernetes controller that can be installed into any existing Kubernetes cluster. Once installed, it will enable users to create and manage production-ready MySQL clusters using a simple declarative configuration format. Common operational tasks such as backing up databases and restoring from an existing backup are made extremely easy. In short, the MySQL Operator abstracts away the hard work of running MySQL inside Kubernetes.
The project started as a way to help internal teams get MySQL running in Kubernetes more easily, but it quickly become clear that many other people might be facing similar issues.
Before we dive into the specifics of how the MySQL Operator works, let’s take a quick look at some of the features it offers:
We have only two options for how a cluster is configured.
- Primary (in this mode the group has a single-primary server that is set to read-write mode. All the other members in the group are set to read-only mode)
- Multi-Primary (In multi-primary mode, there is no notion of a single primary. There is no need to engage an election procedure since there is no server playing any special role.)
- Create and scale MySQL clusters using Innodb and Group Replication on Kubernetes
- When cluster instances die, the MySQL Operator will automatically re-join them into the cluster
- Use Kubernetes Persistent Volume Claims to store data on local disk or network attached storage.
Backup and restore
- Create on-demand backups
- Create backup schedules to automatically backup databases to Object Storage (S3 etc)
- Restore a database from an existing backup
- Run on any Kubernetes cluster (Oracle Cloud Infrastructure, AWS, GCP, Azure)
- Prometheus metrics for alerting and monitoring
- Self healing clusters
The Operator Pattern
A Kubernetes Operator is simply a domain specific controller that can manage, configure and automate the lifecycle of stateful applications. Managing stateful applications, such as databases, caches and monitoring systems running on Kubernetes is notoriously difficult. By leveraging the power of Kubernetes API we can now build self managing, self driving infrastructure by encoding operational knowledge and best practices directly into code. For instance, if a MySQL instance dies, we can use an Operator to react and take the appropriate action to bring the system back online.
How it works
The MySQL Operator makes use of Custom Resource Definitions as a way to extend the Kubernetes API. For instance, we create custom resources for MySQLClusters and MySQLBackups. Users of the MySQL Operator interact via these third party resource objects. When a user creates a backup for example, a new MySQLBackup resource is created inside Kubernetes which contains references and information about that backup.
The MySQL Operator is, at it’s core, a simple Kubernetes controller that watches the API server for Customer Resource Definitions relating to MySQL and acts on them.
HA / Production Ready MySQL Clusters
The MySQL Operator is opinionated about the way in which clusters are configured. We build upon InnoDB cluster (which uses Group Replication) to provide a complete high availability solution for MySQL running on Kubernetes.
The following examples will give you an idea of how the MySQL Operator can be used to manage your MySQL Clusters.
Create a MySQL Cluster
Creating a MySQL cluster using the Operator is easy. We define a simple YAML file and submit this directly to Kubernetes via kubectl. The MySQL operator watches for MySQLCluster resources and will take action by starting up a MySQL cluster.
You should now be able to see your cluster running
There are several other options available when creating a cluster such as specifying a Persistent Volume Claim to define where your data is stored. See the examples directory in the project for more examples.
Create an on-demand backup
We can use the MySQL operator to create an “on-demand” database backup and upload it to object storage.
Create a backup definition and submit it via kubectl.
You can now list or fetch individual backups via kubectl
kubectl get mysqlbackups
Or fetch an individual backup
kubectl get mysqlbackup api-production-snapshot-151220170858 -o yaml
Create a Backup Schedule
Users can attach schedule backup policies to a cluster so that backups get created on a given cron schedule. A user may be create multiple backup schedules attached to a single cluster if required.
This example will create a backup of a cluster test database every hour and upload it to Oracle Cloud Infrastructure Object Storage.
schedule: '30 * * * *'
Some of the features on our roadmap include
- Support for MySQL Enterprise Edition
- Support for MySQL Enterprise Backup
The MySQL Operator showcases the power of Kubernetes as a platform. It makes running MySQL inside Kubernetes easy by abstracting complexity and reducing operational burden. Although it is still in very early development, the MySQL Operator already provides a great deal of useful functionality out of the box.
Visit https://github.com/oracle/mysql-operator to learn more. We welcome contributions, ideas and feedback from the community.
If you want to deploy MySQL inside Kubernetes, we recommend using the MySQL Operator to do the heavy lifting for you.
mysql-operator - Create, operate and scale self-healing MySQL clusters in Kubernetes
MySQL :: MySQL 5.7 Reference Manual :: 20 InnoDB Cluster
MySQL Backup and Recovery MySQL Globalization MySQL Information Schema MySQL Installation Guide MySQL and Linux/Unix…