A production installation would use a Statefulset to deploy a MySQL, you can see an example https://github.com/storageos/use-cases/tree/master/mysql. For demonstration purposes, we are using a PVC and a Pod.

1. Create PersistentVolumeClaim

   kubectl create -f storageos-pvc.yaml

   Note the PVC definition has the label storageos.com/replicas: 1 enforcing one synchronous replica of the volume in addition to the Primary

2. Create Pod

   kubectl create -f mysql-pod1.yaml

3. Check the PVC, PV and StorageOS Volume

   storageos get volume

   kubectl get pvc,pv

   StorageOS dynamically provisions the PV when the PVC is created

4. Check the Pod status

   kubectl get pods -w

   The above command watches the pod created in the default namespace. Press Ctrl+C to continue once the pods are up.

Connect to MySQL and create a test database (your prompt will change):

kubectl exec -it mysql -- mysql

CREATE DATABASE shop;

Now connect to the database and insert some sample data:

USE shop;

CREATE TABLE FRUIT( ID INT PRIMARY KEY NOT NULL, INVENTORY VARCHAR(25) NOT NULL, QUANTITY INT NOT NULL );

INSERT INTO FRUIT (ID,INVENTORY,QUANTITY) VALUES (1, 'Bananas', 132), (2, 'Apples', 165), (3, 'Oranges', 219);

Check your commands succeeded:

SELECT * FROM FRUIT;

Quit the MySQL container:

\q

StorageOS handles the IO of the Volume and manges all network traffic when the Pod and its data, the Volume primary location, are in separate nodes.

Lets see how the MySQL Pod can start in any node and access its data.

1. Find the node holding the Volume Primary data

   node1=$(storageos get volume | grep pvc- | awk '{ print $5 }')

2. Find the node where mysql is running

   node2=$(kubectl get pod mysql -ocustom-columns=_:.spec.nodeName --no-headers)

3. Cordon nodes

   echo $node1 $node2

   kubectl cordon $node1 $node2

4. Delete MySQL Pod

   kubectl delete pod mysql

   Wait until the Pod is deleted

5. Recreate the Pod

   kubectl create -f mysql-pod1.yaml

   Because we cordoned the node where MySQL was running, the Pod is forced to start in a different one.

6. Check the new Pod location

   kubectl get pod mysql -owide -w

7. Check MySQL's data

   kubectl exec mysql -- /bin/sh -c "mysql -e \"select * from shop.FRUIT\""

Congratulations, you have moved the application while its data remains accessible!

StorageOS implements synchronous replication and automatic failover.

Lets cause node downtime and see how StorageOS heals the Volume automatically.

1. The node $node1 holds the primary location

   echo $node1

2. Check where the StorageOS replica is located

   storageos get volume -oyaml

   Note the section replicas.nodeName

3. Remove the node to be stopped from the StorageOS CLI endpoint

   ip=$(kubectl get node -owide | grep $node1 | awk '{print $6}')
   
   export $(echo STORAGEOS_ENDPOINTS="http://[[HOST2_IP]]:5705,http://[[HOST3_IP]]:5705,http://[[HOST4_IP]]:5705" | sed "s#http://$ip:5705,##g")
   

4. SSH into the node

   ssh -o StrictHostKeyChecking=no $node1

5. Reboot the node

   reboot

   The promt goes back to the master shell cli

1. Check that StorageOS sees the node as "Offline"

   storageos get node

   As soon as the Node is shutdown, StorageOS detects the node failure

2. Check the location of the StorageOS Volume Primary and Replica

   storageos get volumes -oyaml

   A previous replica has been promoted to master and keeps serving the data.

3. Check the MySQL Pod and its data

   kubectl get pod

   kubectl exec mysql -- /bin/sh -c "mysql -e \"select * from shop.FRUIT\""

Congratulations you have failedover a Volume without downtime!