This topic provides some architectural information about VMware Tanzu™ SQL with MySQL for Kubernetes.
This section illustrates the two topologies of MySQL instances:
- Single-node instances
- High-availablity (HA) instances
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).
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.
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
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
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
MySQLBackupLocation resources do not currently have any associated status,
but you can list them using kubectl.
$ kubectl get mysqlbackuplocations.with.sql.tanzu.vmware.com NAME AGE backuplocation-sample 2m38s
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
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
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
$ kubectl get mysqls.with.sql.tanzu.vmware.com NAME READY STATUS AGE mysql-sample true Running 30s