This post is part of our ongoing series on running MariaDB on Kubernetes. We’ve published a number of articles about running MariaDB on Kubernetes for specific platforms and for specific use cases. If you are looking for a specific Kubernetes platform, check out these related articles.
Running HA MariaDB on Amazon Elastic Container Service for Kubernetes (EKS)
Running HA MariaDB on Azure Kubernetes Service (AKS)
Running HA MariaDB on Red Hat OpenShift
Running HA MariaDB with Rancher Kubernetes Engine (RKE)
And now, onto the post…
Google Kubernetes Engine (GKE) is a managed, production-ready environment for deploying containerized applications in Google Cloud Platform. Launched in 2015, GKE is one of the first hosted container platforms which is built on the learnings from Google’s experience of running services like Gmail and YouTube in containers for over 12 years. GKE allows customers to quickly get up and running with Kubernetes by completely eliminating the need to install, manage, and operate Kubernetes clusters.
Portworx is a cloud native storage and data management platform to run persistent workloads deployed on a variety of orchestration engines including Kubernetes. With Portworx, customers can manage the database of their choice on any infrastructure using any container scheduler. It provides a single data management layer for all stateful services, no matter where they run.
This tutorial is a walk-through of the steps involved in deploying and managing a highly available MariaDB database on GKE.
In summary, to run HA MariaDB on Google Cloud Platform you need to:
- Launch a GKE cluster
- Install cloud native storage solution like Portworx as a DaemonSet on GKE
- Create storage class defining your storage requirements like replication factor, snapshot policy, and performance profile
- Deploy MariaDB using Kubernetes
- Test failover by killing or cordoning node in your cluster
How to launch a GKE cluster
When launching a GKE cluster to run Portworx, you need to ensure that the cluster is based on Ubuntu. Due to certain restrictions with GKE clusters based on Container-Optimized OS (COS), Portworx requires Ubuntu as the base image for the GKE Nodes.
The following command configures a 3-node GKE Cluster in zone ap-south-1-a. You can modify the parameters accordingly.
$ gcloud container --project "janakiramm-sandbox" clusters create "gke-px-demo" \ --zone "asia-south1-a" \ --username "admin" \ --cluster-version "1.12.8-gke.10" \ --machine-type "n1-standard-4" \ --image-type "UBUNTU" \ --disk-type "pd-ssd" \ --disk-size "50" \ --scopes "https://www.googleapis.com/auth/compute","https://www.googleapis.com/auth/devstorage.read_only","https://www.googleapis.com/auth/logging.write","https://www.googleapis.com/auth/monitoring","https://www.googleapis.com/auth/servicecontrol","https://www.googleapis.com/auth/service.management.readonly","https://www.googleapis.com/auth/trace.append" \ --num-nodes "3" \ --enable-cloud-logging \ --enable-cloud-monitoring \ --network "default" \ --addons HorizontalPodAutoscaling,HttpLoadBalancing,KubernetesDashboard
Once the cluster is ready, configure kubectl CLI with the following command:
$ gcloud container clusters get-credentials gke-px-demo --zone asia-south1-a
Portworx requires a ClusterRoleBinding for your user. Without this configuration, the command fails with an error clusterroles.rbac.authorization.k8s.io "portworx-pvc-controller-role" is forbidden.
Let’s create a ClusterRoleBinding with the following command:
$ kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole cluster-admin \ --user $(gcloud config get-value account)
You should now have a three node Kubernetes cluster deployed on Google Cloud Platform.
$ kubectl get nodes NAME STATUS ROLES AGE VERSION gke-gke-px-demo-default-pool-d1400de5-7kpf Ready 3d v1.12.8-gke.10 gke-gke-px-demo-default-pool-d1400de5-q277 Ready 3d v1.12.8-gke.10 gke-gke-px-demo-default-pool-d1400de5-zsjh Ready 3d v1.12.8-gke.10
Installing Portworx in GKE
Installing Portworx on Google Kubernetes Engine is not very different from installing it on a Kubernetes cluster setup through Kops. Portworx GKE documentation has the steps involved in running the Portworx cluster in a Kubernetes environment deployed in GCP.
Portworx cluster needs to be up and running on GKE before proceeding to the next step. The kube-system namespace should have the Portoworx pods in the Running state.
NAME READY STATUS RESTARTS AGE portworx-j2z5x 1/1 Running 1 3d portworx-jpvth 1/1 Running 1 3d portworx-rx4sp 1/1 Running 1 3d
Creating a Kubernetes storage class for MariaDB
Once the GKE cluster is up and running, and Portworx is installed and configured, we will deploy a highly available MariaDB database.
Through Kubernetes storage class objects, an admin can define different classes of Portworx volumes that are offered in a cluster. These classes will be used during the dynamic provisioning of volumes. The Storage Class defines the replication factor, I/O profile (e.g., for a database or a CMS), and priority (e.g., SSD or HDD). These parameters impact the availability and throughput of workloads and can be specified for each volume. This is important because a production database will have different requirements than a development Jenkins cluster.
In this example, the storage class that we deploy has a replication factor of 3 with I/O profile set to “db,” and priority set to “high.” This means that the storage will be optimized for low latency database workloads like MariaDB and automatically placed on the highest performance storage available in the cluster. Notice that we also mention the filesystem, xfs in the storage class.
$ cat > px-mariadb-sc.yaml << EOF
kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
name: px-ha-sc
provisioner: kubernetes.io/portworx-volume
parameters:
repl: "3"
EOF
$ kubectl create -f px-mariadb-sc.yaml storageclass.storage.k8s.io "px-ha-sc" created $ kubectl get sc NAME PROVISIONER AGE px-ha-sc kubernetes.io/portworx-volume 10s stork-snapshot-sc stork-snapshot 3d
Creating a MariaDB PVC on Kubernetes
We can now create a Persistent Volume Claim (PVC) based on the Storage Class. Thanks to dynamic provisioning, the claims will be created without explicitly provisioning Persistent Volume (PV).
$ cat > px-mariadb-pvc.yaml << EOF
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: px-mariadb-pvc
annotations:
volume.beta.kubernetes.io/storage-class: px-ha-sc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
EOF
$ kubectl create -f px-mariadb-pvc.yaml
persistentvolumeclaim "px-mariadb-pvc" created
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
px-mariadb-pvc Bound pvc-75f89b88-a6e9-11e9-a1d6-42010aa00171 1Gi RWO px-ha-sc 29s
Deploying MariaDB on GKE
Finally, let’s create a MariaDB instance as a Kubernetes deployment object. For simplicity’s sake, we will just be deploying a single MariaDB pod. Because Portworx provides synchronous replication for High Availability, a single MariaDB instance might be the best deployment option for your MariaDB database. Portworx can also provide backing volumes for multi-node MariaDB cluster. The choice is yours.
$ cat > px-mariadb-app.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: mariadb
spec:
selector:
matchLabels:
app: mariadb
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
type: RollingUpdate
replicas: 1
template:
metadata:
labels:
app: mariadb
spec:
schedulerName: stork
containers:
- name: mariadb
image: mariadb:latest
imagePullPolicy: "Always"
env:
- name: MYSQL_ROOT_PASSWORD
value: password
ports:
- containerPort: 3306
volumeMounts:
- mountPath: /var/lib/mysql
name: mariadb-data
volumes:
- name: mariadb-data
persistentVolumeClaim:
claimName: px-mariadb-pvc
EOF
$ kubectl create -f px-mariadb-app.yaml deployment.extensions "mariadb" created
The MariaDB deployment defined above is explicitly associated with the PVC, px-mariadb-pvc created in the previous step.
This deployment creates a single pod running MariaDB backed by Portworx.
$ kubectl get pods NAME READY STATUS RESTARTS AGE mariadb-9cc8c996c-797vb 1/1 Running 0 8s
We can inspect the Portworx volume by accessing the pxctl tool running with the MariaDB pod.
$ VOL=`kubectl get pvc | grep px-mariadb-pvc | awk '{print $3}'`
$ PX_POD=$(kubectl get pods -l name=portworx -n kube-system -o jsonpath='{.items[0].metadata.name}')
$ kubectl exec -it $PX_POD -n kube-system -- /opt/pwx/bin/pxctl volume inspect ${VOL}
Volume : 1141079924925920044
Name : pvc-75f89b88-a6e9-11e9-a1d6-42010aa00171
Size : 1.0 GiB
Format : ext4
HA : 3
IO Priority : LOW
Creation time : Jul 15 10:15:35 UTC 2019
Shared : no
Status : up
State : Attached: aaf8ea50-a4bb-425f-a887-bb8cae097f97 (10.160.0.41)
Device Path : /dev/pxd/pxd1141079924925920044
Labels : namespace=default,pvc=px-mariadb-pvc
Reads : 234
Reads MS : 216
Bytes Read : 5754880
Writes : 4212
Writes MS : 42612
Bytes Written : 67330048
IOs in progress : 1
Bytes used : 20 MiB
Replica sets on nodes:
Set 0
Node : 10.160.0.40 (Pool 0)
Node : 10.160.0.39 (Pool 0)
Node : 10.160.0.41 (Pool 0)
Replication Status : Up
Volume consumers :
- Name : mariadb-9cc8c996c-797vb (efc72f8c-a6e9-11e9-a1d6-42010aa00171) (Pod)
Namespace : default
Running on : gke-gke-px-demo-default-pool-d1400de5-7kpf
Controlled by : mariadb-9cc8c996c (ReplicaSet)
The output from the above command confirms the creation of volumes that are backing MariaDB database instance.
Failing over MariaDB pod on Kubernetes
Populating sample data
Let’s populate the database with some sample data.
We will first find the pod that’s running MariaDB to access the shell.
$ POD=`kubectl get pods -l app=mariadb | grep Running | grep 1/1 | awk '{print $1}'`
$ kubectl exec -it $POD -- mysql -uroot -ppassword
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 11
Server version: 10.4.6-MariaDB-1:10.4.6+maria~bionic mariadb.org binary distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>
Now that we are inside the shell, we can populate create a sample database and table.
MariaDB> CREATE DATABASE `classicmodels`;
MariaDB> USE `classicmodels`;
MariaDB> CREATE TABLE `offices` (
`officeCode` varchar(10) NOT NULL,
`city` varchar(50) NOT NULL,
`phone` varchar(50) NOT NULL,
`addressLine1` varchar(50) NOT NULL,
`addressLine2` varchar(50) DEFAULT NULL,
`state` varchar(50) DEFAULT NULL,
`country` varchar(50) NOT NULL,
`postalCode` varchar(15) NOT NULL,
`territory` varchar(10) NOT NULL,
PRIMARY KEY (`officeCode`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Query OK, 0 rows affected (0.227 sec)
MariaDB> insert into `offices`(`officeCode`,`city`,`phone`,`addressLine1`,`addressLine2`,`state`,`country`,`postalCode`,`territory`) values
('1','San Francisco','+1 650 219 4782','100 Market Street','Suite 300','CA','USA','94080','NA'),
('2','Boston','+1 215 837 0825','1550 Court Place','Suite 102','MA','USA','02107','NA'),
('3','NYC','+1 212 555 3000','523 East 53rd Street','apt. 5A','NY','USA','10022','NA'),
('4','Paris','+33 14 723 4404','43 Rue Jouffroy D\'abbans',NULL,NULL,'France','75017','EMEA'),
('5','Tokyo','+81 33 224 5000','4-1 Kioicho',NULL,'Chiyoda-Ku','Japan','102-8578','Japan'),
('6','Sydney','+61 2 9264 2451','5-11 Wentworth Avenue','Floor #2',NULL,'Australia','NSW 2010','APAC'),
('7','London','+44 20 7877 2041','25 Old Broad Street','Level 7',NULL,'UK','EC2N 1HN','EMEA');
Query OK, 7 rows affected (0.039 sec)
Records: 7 Duplicates: 0 Warnings: 0
Let’s run a few queries on the table.
MariaDB> select `officeCode`,`city`,`phone`,`addressLine1`,`city` from `offices`; +------------+---------------+------------------+--------------------------+---------------+ | officeCode | city | phone | addressLine1 | city | +------------+---------------+------------------+--------------------------+---------------+ | 1 | San Francisco | +1 650 219 4782 | 100 Market Street | San Francisco | | 2 | Boston | +1 215 837 0825 | 1550 Court Place | Boston | | 3 | NYC | +1 212 555 3000 | 523 East 53rd Street | NYC | | 4 | Paris | +33 14 723 4404 | 43 Rue Jouffroy D'abbans | Paris | | 5 | Tokyo | +81 33 224 5000 | 4-1 Kioicho | Tokyo | | 6 | Sydney | +61 2 9264 2451 | 5-11 Wentworth Avenue | Sydney | | 7 | London | +44 20 7877 2041 | 25 Old Broad Street | London | +------------+---------------+------------------+--------------------------+---------------+ 7 rows in set (0.01 sec)
Find all the offices in the USA.
MariaDB [classicmodels]> select `officeCode`, `city`, `phone` from `offices` where `country` = "USA"; +------------+---------------+-----------------+ | officeCode | city | phone | +------------+---------------+-----------------+ | 1 | San Francisco | +1 650 219 4782 | | 2 | Boston | +1 215 837 0825 | | 3 | NYC | +1 212 555 3000 | +------------+---------------+-----------------+ 3 rows in set (0.00 sec)
Exit from the MariaDB shell to return to the host.
Simulating node failure
Now, let’s simulate the node failure by cordoning off the node on which MariaDB is running.
$ NODE=`kubectl get pods -l app=mariadb -o wide | grep -v NAME | awk '{print $7}'`
$ kubectl cordon ${NODE}
node "gke-gke-px-demo-default-pool-d1400de5-7kpf" cordoned
The above command disabled scheduling on one of the nodes.
$ kubectl get nodes NAME STATUS ROLES AGE VERSION NAME STATUS ROLES AGE VERSION gke-gke-px-demo-default-pool-d1400de5-7kpf Ready,SchedulingDisabled 3d v1.12.8-gke.10 gke-gke-px-demo-default-pool-d1400de5-q277 Ready 3d v1.12.8-gke.10 gke-gke-px-demo-default-pool-d1400de5-zsjh Ready 3d v1.12.8-gke.10
Now, let’s go ahead and delete the MariaDB pod.
$ POD=`kubectl get pods -l app=mariadb -o wide | grep -v NAME | awk '{print $1}'`
$ kubectl delete pod ${POD}
pod "mariadb-9cc8c996c-797vb" deleted
As soon as the pod is deleted, it is relocated to the node with the replicated data. STorage ORchestrator for Kubernetes (STORK), Portworx’s custom storage scheduler allows co-locating the pod on the exact node where the data is stored. It ensures that an appropriate node is selected for scheduling the pod.
Let’s verify this by running the below command. We will notice that a new pod has been created and scheduled in a different node.
$ kubectl get pods -l app=mariadb -o wide NAME READY STATUS RESTARTS AGE IP NODE mariadb-9cc8c996c-kklzp 1/1 Running 0 15s 10.36.0.50 gke-gke-px-demo-default-pool-d1400de5-q277
$ kubectl uncordon ${NODE}
node "gke-gke-px-demo-default-pool-d1400de5-7kpf" uncordoned
Finally, let’s verify that the data is still available.
Verifying that the data is intact
Let’s find the pod name and run the ‘exec’ command, and then access the MariaDB shell.
kubectl exec -it $POD -- mysql -uroot -ppassword Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 8 Server version: 10.4.6-MariaDB-1:10.4.6+maria~bionic mariadb.org binary distribution Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]>
We will query the database to verify that the data is intact.
MariaDB [none]> USE `classicmodels`; MariaDB [classicmodels]> select `officeCode`, `city`, `phone` from `offices` where `country` = "USA"; +------------+---------------+-----------------+ | officeCode | city | phone | +------------+---------------+-----------------+ | 1 | San Francisco | +1 650 219 4782 | | 2 | Boston | +1 215 837 0825 | | 3 | NYC | +1 212 555 3000 | +------------+---------------+-----------------+ 3 rows in set (0.00 sec)
Observe that the database table is still there and all the content is intact! Exit from the client shell to return to the host.
Performing Storage Operations on MariaDB
After testing end-to-end failover of the database, let’s perform StorageOps on our GKE cluster.
Expanding the Kubernetes Volume with no downtime
Currently, the Portworx volume that we created at the beginning is of 1Gib size. We will now expand it to double the storage capacity.
First, let’s get the volume name and inspect it through the pxctl tool.
If you have access, SSH into one of the nodes and run the following command.
$ POD=`kubectl get pvc | grep px-mariadb-pvc | awk '{print $3}'`
$ kubectl exec -it $PX_POD -n kube-system -- /opt/pwx/bin/pxctl volume inspect $POD
Volume : 1141079924925920044
Name : pvc-75f89b88-a6e9-11e9-a1d6-42010aa00171
Size : 1.0 GiB
Format : ext4
HA : 3
IO Priority : LOW
Creation time : Jul 15 10:15:35 UTC 2019
Shared : no
Status : up
State : Attached: 35d822fa-e05a-432a-8ae4-547bd72a0f19 (10.160.0.40)
Device Path : /dev/pxd/pxd1141079924925920044
Labels : pvc=px-mariadb-pvc,namespace=default
Reads : 291
Reads MS : 124
Bytes Read : 6074368
Writes : 165
Writes MS : 1488
Bytes Written : 2306048
IOs in progress : 0
Bytes used : 64 MiB
Replica sets on nodes:
Set 0
Node : 10.160.0.40 (Pool 0)
Node : 10.160.0.39 (Pool 0)
Node : 10.160.0.41 (Pool 0)
Replication Status : Up
Volume consumers :
- Name : mariadb-9cc8c996c-kklzp (189f5190-a6eb-11e9-a1d6-42010aa00171) (Pod)
Namespace : default
Running on : gke-gke-px-demo-default-pool-d1400de5-q277
Controlled by : mariadb-9cc8c996c (ReplicaSet)
Notice the current Portworx volume. It is 1GiB. Let’s expand it to 2GiB.
$ kubectl exec -it $PX_POD -n kube-system -- /opt/pwx/bin/pxctl v update $POD --size=2 Update Volume: Volume update successful for volume pvc-75f89b88-a6e9-11e9-a1d6-42010aa00171
Check the new volume size.
$ kubectl exec -it $PX_POD -n kube-system -- /opt/pwx/bin/pxctl v i $POD Volume : 1141079924925920044 Name : pvc-75f89b88-a6e9-11e9-a1d6-42010aa00171 Size : 2.0 GiB Format : ext4 HA : 3 IO Priority : LOW Creation time : Jul 15 10:15:35 UTC 2019 Shared : no Status : up State : Attached: 35d822fa-e05a-432a-8ae4-547bd72a0f19 (10.160.0.40) Device Path : /dev/pxd/pxd1141079924925920044 Labels : namespace=default,pvc=px-mariadb-pvc Reads : 363 Reads MS : 176 Bytes Read : 6369280 Writes : 185 Writes MS : 1684 Bytes Written : 3223552 IOs in progress : 0 Bytes used : 65 MiB Replica sets on nodes: Set 0 Node : 10.160.0.40 (Pool 0) Node : 10.160.0.39 (Pool 0) Node : 10.160.0.41 (Pool 0) Replication Status : Up Volume consumers : - Name : mariadb-9cc8c996c-kklzp (189f5190-a6eb-11e9-a1d6-42010aa00171) (Pod) Namespace : default Running on : gke-gke-px-demo-default-pool-d1400de5-q277 Controlled by : mariadb-9cc8c996c (ReplicaSet)
Taking Snapshots of a Kubernetes volume and restoring the database
Portworx supports creating snapshots for Kubernetes PVCs.
Let’s create a snapshot for the Kubernetes PVC we created for MariaDB.
cat > px-mariadb-snap.yaml << EOF apiVersion: volumesnapshot.external-storage.k8s.io/v1 kind: VolumeSnapshot metadata: name: px-mariadb-snapshot namespace: default spec: persistentVolumeClaimName: px-mariadb-pvc EOF
$ kubectl create -f px-mariadb-snap.yaml volumesnapshot.volumesnapshot.external-storage.k8s.io "px-mariadb-snapshot" created
Verify the creation of volume snapshot.
$ kubectl get volumesnapshot NAME AGE px-mariadb-snapshot 13s
$ kubectl get volumesnapshotdatas NAME AGE k8s-volume-snapshot-504e9e5f-a6ec-11e9-ab32-7a5327be2608 19s
With the snapshot in place, let’s go ahead and delete the database.
$ POD=`kubectl get pods -l app=mariadb | grep Running | grep 1/1 | awk '{print $1}'`
$ kubectl exec -it $POD -- mysql -uroot -ppassword
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 9
Server version: 10.4.6-MariaDB-1:10.4.6+maria~bionic mariadb.org binary distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>
drop database classicmodels;
Since snapshots are just like volumes, we can use it to start a new instance of MariaDB. Let’s create a new instance of MariaDB by restoring the snapshot data.
$ cat > px-mariadb-snap-pvc << EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: px-mariadb-snap-clone
annotations:
snapshot.alpha.kubernetes.io/snapshot: px-mariadb-snapshot
spec:
accessModes:
- ReadWriteOnce
storageClassName: stork-snapshot-sc
resources:
requests:
storage: 2Gi
EOF
$ kubectl create -f px-mariadb-snap-pvc.yaml
persistentvolumeclaim "px-mariadb-snap-clone" created
From the new PVC, we will create a MariaDB pod.
$ cat < px-mariadb-snap-restore.yaml >> EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: mariadb-snap
spec:
selector:
matchLabels:
app: mariadb-snap
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
type: RollingUpdate
replicas: 1
template:
metadata:
labels:
app: mariadb-snap
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: px/running
operator: NotIn
values:
- "false"
- key: px/enabled
operator: NotIn
values:
- "false"
spec:
containers:
- name: mariadb
image: mariadb:latest
imagePullPolicy: "Always"
env:
- name: MYSQL_ROOT_PASSWORD
value: password
ports:
- containerPort: 3306
volumeMounts:
- mountPath: /var/lib/mysql
name: mariadb-data
volumes:
- name: mariadb-data
persistentVolumeClaim:
claimName: px-mariadb-snap-clone
EOF
$ kubectl create -f px-mariadb-snap-restore.yaml deployment.extensions "mariadb-snap" created
Verify that the new pod is in the Running state.
$ kubectl get pods -l app=mariadb-snap NAME READY STATUS RESTARTS AGE mariadb-snap-655ffd9d67-ff288 1/1 Running 0 15s
Finally, let’s access the sample data created earlier in the walkthrough.
$ POD=`kubectl get pods -l app=mariadb-snap | grep Running | grep 1/1 | awk '{print $1}'`
$ kubectl exec -it $POD -- mysql -uroot -ppassword
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 8
Server version: 10.4.6-MariaDB-1:10.4.6+maria~bionic mariadb.org binary distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>
MariaDB [(none)]> USE `classicmodels`;
MariaDB [classicmodels]> select `officeCode`, `city`, `phone` from `offices` where `country` = "USA";
+------------+---------------+-----------------+
| officeCode | city | phone |
+------------+---------------+-----------------+
| 1 | San Francisco | +1 650 219 4782 |
| 2 | Boston | +1 215 837 0825 |
| 3 | NYC | +1 212 555 3000 |
+------------+---------------+-----------------+
3 rows in set (0.00 sec)
Notice that the collection is still there with the data intact. We can also push the snapshot to Amazon S3 if we want to create a Disaster Recovery backup in another region. Portworx snapshots also work with any S3 compatible object storage, so the backup can go to a different cloud or even an on-premises data center. , Alternatively, we can stretch a single Portworx cluster across two independent Kubernetes clusters for Zero RPO DR for Kubernetes.
Summary
Portworx can easily be deployed on Google Kubernetes Engine to run stateful workloads in production. Through the integration of STORK, DevOps and StorageOps teams can seamlessly run highly-available database clusters in GKE. They can perform traditional operations such as volume expansion, snapshots, backup and recovery for the cloud-native applications.
Share
Subscribe for Updates
About Us
Portworx is the leader in cloud native storage for containers.
Thanks for subscribing!
Janakiram MSV
Contributor | Certified Kubernetes Administrator (CKA) and Developer (CKAD)Explore Related Content:
- gke
- kubernetes
- mariadb
