Architecture

Page last updated:

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:

A diagram showing the architecture of a single-node instance, described below

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:

HA MySQL cluster: A diagram showing the high-availability architecture.
This diagram is described in the text below.

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

Applying this resource causes the Kubernetes Operator to create a StatefulSet with a single Pod with two containers. One container runs the MySQL database software, and the other runs components to support backups.

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
    imagePullSecret: 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    AGE
mysql-sample           Pending   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
      imagePullSecret: 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