Architecture

This topic provides some architectural information about VMware SQL with MySQL for Kubernetes.

VMware 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. A single node is a box that contains three other boxes: a mysql service box, (that accepts the client requests), a mysql database box, and a persistent volume claim box. All boxes are connected sequentially with bi-directional arrows.

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 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 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-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.3.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 or Azure Blob Storage.

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

  # Azure Credentials
  # accountName: my-storage-account
  # accountKey: my-storage-access-key
  # sasToken: my-container-sas-token # provide either accountKey or sasToken
---
apiVersion: with.sql.tanzu.vmware.com/v1
kind: MySQLBackupLocation
metadata:
  name: backuplocation-sample
spec:
  storage:
    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
    # azure:
    #  container: my-container
    #  repoPath: optional/prefix/for/backup/objects/
    #  domain: "" # optional, defaults to public Azure cloud
    #  secret:
    #    name: backuplocation-sample-creds

Credentials for S3 are stored in a Kubernetes secret with the keys accessKeyId, secretAccessKey.

Credentials for Azure are stored in a Kubernetes secret with the keys. accountName is required. To authorize access to the bucket, supply either a shared access key with accountKey or a shared access signature with sasToken.

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-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