This topic provides some architectural information about VMware Tanzu™ SQL with MySQL for Kubernetes.
VMware Tanzu™ SQL with MySQL for Kubernetes Architecture
This section illustrates the two topologies of MySQL instances:
- Single-node instances
- High-availablity (HA) instances
Architecture of a Single-Node MySQL Instance
The diagram below shows the architecture of a single-node MySQL instance:
In a single-node MySQL instance, the app or client makes a request to the MySQL service. The service communicates with the single database Pod, named mysql-0. The database Pod stores data in a persistent volume claim (PVC).
Architecture of an HA MySQL Instance
High availability offers automatic failover, ensuring that app requests operate continuously and without extended downtime.
VMware Tanzu™ SQL with MySQL for Kubernetes uses InnoDB Cluster to provide a highly-available MySQL instance on Kubernetes. For information about InnoDB Cluster features, see the MySQL documentation.
InnoDB Cluster uses Group Replication and other MySQL technologies. For information about Group Replication, see the MySQL documentation.
The diagram below shows the architecture of an HA MySQL instance:
In a high-availability (HA) MySQL instance, the topology consists of five Pods:
- One primary MySQL database Pod
- Two secondary MySQL database failover Pods
- Two proxy Pods
The primary database is a read-write database. All external connections, such as from apps, are directed by the proxy to the primary read-write database. The two secondary databases are read-only and are updated as replicas of the primary.
Group Replication ensures that data is synchronously replicated from the primary to the secondary database Pods. If the primary Pod becomes unresponsive, app requests are redirected to a secondary Pod, which gets promoted to primary. All app requests continue to that promoted primary, and a new secondary MySQL Pod is created to replace the failed Pod.
If a proxy Pod fails, Kubernetes directs traffic to the remaining proxy Pod while re-creating the failed Pod in the background.
Controllers and Custom Resource Definitions (CRDs)
VMware Tanzu™ SQL with MySQL for Kubernetes provides extensions to the Kubernetes API through custom resources. The product provides five separate custom resources:
- MySQL: A managed MySQL instance
- MySQLBackupLocation: Defines an S3 storage bucket for backups
- MySQLBackup: Requests for a backup
- MySQLBackupSchedule: Defines a backup schedule
- MySQLRestore: Requests a data restore
MySQL
Applying this resource causes the Kubernetes Operator to create a StatefulSet with a single Pod and three containers. One container runs the MySQL database software, one runs the components to support backups, and the third runs the mysqld_exporter (for monitoring). The MySQL Pod mounts a persistent volume claim (PVC) which holds the MySQL data.
When a MySQL instance is created, the MySQL Operator automatically creates a Kubernetes service with a service type of ClusterIP which routes connections to the MySQL Pod.
---
apiVersion: with.sql.tanzu.vmware.com/v1
kind: MySQL
metadata:
name: mysql-sample
spec:
resources:
mysql:
requests:
memory: 1Gi
storageSize: 1Gi
imagePullSecretName: tanzu-mysql-image-registry
After applying this resource, the Operator creates the low-level Kubernetes resources to run this MySQL instance.
You can see the status of the instance by running:
kubectl get mysqls.with.sql.tanzu.vmware.com
Initially, this instance is in a pending state:
kubectl get mysqls.with.sql.tanzu.vmware.com
NAME READY STATUS VERSION AGE
mysql-sample true Pending 1.1.0 2s
Later, the instance transitions to a running state:
kubectl get mysqls.with.sql.tanzu.vmware.com
NAME READY STATUS AGE
mysql-sample true Running 27s
MySQLBackupLocation
This resource describes metadata and credentials for storing backups in an S3-compatible object store.
MySQLBackup resources reference this backup location to know where to save backup artifacts. The Operator creates or maintains a MySQLBackup resource for every artifact found in the backup location. Consequently, creating a MySQLBackupLocation that contains existing artifacts generates new, corresponding MySQLBackup resources.
---
apiVersion: v1
kind: Secret
metadata:
name: backuplocation-sample-creds
stringData:
# S3 Credentials
accessKeyId: "my-s3-access-key-id"
secretAccessKey: "my-s3-secret-access-key"
---
apiVersion: with.sql.tanzu.vmware.com/v1
kind: MySQLBackupLocation
metadata:
name: backuplocation-sample
spec:
storage:
# For S3 or Minio:
s3:
bucket: "s3bucket"
bucketPath: "optional/prefix/for/backup/objects/"
region: "us-east-1"
endpoint: "" # optional, default to AWS
forcePathStyle: false
secret:
name: backuplocation-sample-creds
Credentials for S3 are stored in a Kubernetes secret with the keys accessKeyId, secretAccessKey. MySQLBackupLocation resources do not currently have any associated status, but you can list them using kubectl. For example:
kubectl get mysqlbackuplocations.with.sql.tanzu.vmware.com
NAME AGE
backuplocation-sample 2m38s
MySQLBackup
This resource triggers the instance to run the Percona XtraBackup utility and upload a backup artifact to the blobstore. Blobstore artifacts are represented as MySQLBackup resources for subsequent restore. The resource requests for a backup to be taken as soon as possible. For a resource that requests a scheduled backup, see MySQLBackupSchedule below. For example:
---
apiVersion: with.sql.tanzu.vmware.com/v1
kind: MySQLBackup
metadata:
name: backup-sample
spec:
location:
name: backuplocation-sample
instance:
name: mysql-sample
You can see the status of the backup using kubectl. For example:
kubectl get mysqlbackups.with.sql.tanzu.vmware.com
NAME STATUS SOURCE INSTANCE TIME STARTED TIME COMPLETED
backup-sample Succeeded mysql-sample 2020-12-07T15:52:12Z 2020-12-07T15:52:16Z
MySQLBackupSchedule
This resource defines a schedule to automatically create MySQLBackup resources. For example:
---
apiVersion: with.sql.tanzu.vmware.com/v1
kind: MySQLBackupSchedule
metadata:
name: mysqlbackupschedule-sample
spec:
backupTemplate:
spec:
location:
name: backuplocation-sample
instance:
name: mysql-sample
schedule: "@daily"
MySQLBackupSchedule resources do not currently have any associated status, but you can list them using kubectl. For example:
kubectl get mysqlbackupschedules.with.sql.tanzu.vmware.com
NAME AGE
mysqlbackupschedule-sample 8s
MySQLRestore
This resource instructs the Operator to create a new PVC and a new MySQL instance from an existing MySQLBackup resource. The backup artifact for the MySQLBackup resource is loaded into the new PVC before the MySQL database is started. For example:
---
apiVersion: with.sql.tanzu.vmware.com/v1
kind: MySQLRestore
metadata:
name: restore-sample
spec:
backup:
name: backup-sample
instanceTemplate:
metadata:
name: mysql-sample
spec:
storageSize: 1Gi
imagePullSecretName: tanzu-mysql-image-registry
You can see the status of the restore using kubectl. For example:
kubectl get mysqlrestores.with.sql.tanzu.vmware.com
NAME STATUS SOURCE BACKUP TARGET INSTANCE TIME STARTED TIME COMPLETED
restore-sample Running backup-sample mysql-sample 2020-12-07T15:56:26Z
The restore retrieves and unpacks the backup artifact and creates the MySQL instance. The restore time is proportional to the size of the backup artifact. For example:
kubectl get mysqlrestores.with.sql.tanzu.vmware.com
NAME STATUS SOURCE BACKUP TARGET INSTANCE TIME STARTED TIME COMPLETED
restore-sample Succeeded backup-sample mysql-sample 2020-12-07T15:56:26Z 2020-12-07T15:56:41Z
At the end of the restore process, you have a MySQL instance with the READY state true and with STATUS running. For example:
kubectl get mysqls.with.sql.tanzu.vmware.com
NAME READY STATUS AGE
mysql-sample true Running 30s
