New to KubeDB? Please start here.
MySQL StorageClass Migration
This guide will show you how to use KubeDB Ops Manager to migrate StorageClass of MySQL database.
Before You Begin
At first, you need to have a Kubernetes cluster, and the
kubectlcommand-line tool must be configured to communicate with your cluster.You must have at least two
StorageClassresources in order to perform a migration.Install
KubeDBoperator in your cluster following the steps here.You should be familiar with the following
KubeDBconcepts:
To keep everything isolated, we are going to use a separate namespace called demo throughout this tutorial.
$ kubectl create ns demo
namespace/demo created
Prepare MySQL Database
At first verify that your cluster has at least two StorageClass. Let’s check,
➤ kubectl get storageclass
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 12d
longhorn driver.longhorn.io Delete Immediate true 12d
longhorn-custom driver.longhorn.io Delete WaitForFirstConsumer true 2d20h
longhorn-static driver.longhorn.io Delete Immediate true 12d
From the above output we can see that we have more than two StorageClass resources. We will now deploy a MySQL database using local-path StorageClass and insert some data into it.
After that, we will apply MySQLOpsRequest to migrate StorageClass from local-path to longhorn-custom.
Both the old and new PVCs should be on the same node. Therefore, the new StorageClass
VOLUMEBINDINGMODEshould beWaitForFirstConsumerif the old one usesWaitForFirstConsumer. If the old one usesImmediateany mode is allowed.
KubeDB implements a MySQL CRD to define the specification of a MySQL database. Below is the MySQL object created in this tutorial.
apiVersion: kubedb.com/v1
kind: MySQL
metadata:
name: sample-mysql
namespace: demo
spec:
version: "9.1.0"
replicas: 3
topology:
mode: GroupReplication
group:
mode: Single-Primary
storageType: Durable
storage:
storageClassName: local-path
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
deletionPolicy: WipeOut
$ kubectl create -f https://github.com/kubedb/docs/raw/v2025.8.31/docs/examples/mysql/migration/sample-mysql.yaml
mysql.kubedb.com/sample-mysql created
Now, wait until sample-mysql has status Ready and check the StorageClass,
$ kubectl get mysql,pvc -n demo
NAME VERSION STATUS AGE
mysql.kubedb.com/sample-mysql 9.1.0 Ready 101s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
persistentvolumeclaim/data-sample-mysql-0 Bound pvc-64cca3c6-85aa-426f-abc3-b300ecfe365a 1Gi RWO local-path <unset> 96s
persistentvolumeclaim/data-sample-mysql-1 Bound pvc-1de36b06-8e32-4e9a-a01b-3b6d7c618688 1Gi RWO local-path <unset> 90s
persistentvolumeclaim/data-sample-mysql-2 Bound pvc-a75bd538-8a71-4f62-8d38-3f4e42ffb225 1Gi RWO local-path <unset> 85s
The database is Ready and all the PersistentVolumeClaim uses local-path StorageClass, Let’s create a table in the primary.
# find the primary pod
kubectl get pods -n demo --show-labels | grep primary | awk '{ print $1 }'
sample-mysql-0
# exec into the primary pod
$ kubectl exec -it -n demo sample-mysql-0 -- bash
Defaulted container "mysql" out of: mysql, mysql-coordinator, mysql-init (init)
bash-5.1$ mysql -uroot -p$MYSQL_ROOT_PASSWORD
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1780
Server version: 9.1.0 MySQL Community Server - GPL
Copyright (c) 2000, 2024, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> create database hello;
Query OK, 1 row affected (0.02 sec)
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| hello |
| information_schema |
| kubedb_system |
| mysql |
| performance_schema |
| sys |
+--------------------+
6 rows in set (0.00 sec)
mysql> use hello;
Database changed
# Create a table
mysql> CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(50),
email VARCHAR(100)
);
Query OK, 0 rows affected (0.03 sec)
# Insert some data into the table
mysql> INSERT INTO users (name, email) VALUES
('David', '[email protected]'),
('Eva', '[email protected]'),
('Frank', '[email protected]'),
('Grace', '[email protected]'),
('Hannah', '[email protected]'),
('Ian', '[email protected]'),
('Jack', '[email protected]'),
('Karen', '[email protected]'),
('Liam', '[email protected]'),
('Mona', '[email protected]'),
('Nathan', '[email protected]'),
('Olivia', '[email protected]'),
('Paul', '[email protected]'),
('Quincy', '[email protected]'),
('Rachel', '[email protected]'),
('Steve', '[email protected]'),
('Tina', '[email protected]'),
('Uma', '[email protected]'),
('Victor', '[email protected]'),
('Wendy', '[email protected]');
Query OK, 20 rows affected (0.02 sec)
Records: 20 Duplicates: 0 Warnings: 0
Apply StorageMigration Ops-Request
To migrate StorageClass we have to create a MySQLOpsRequest CR with our desired StorageClass. Below is the YAML of the MySQLOpsRequest CR that we are going to create,
apiVersion: ops.kubedb.com/v1alpha1
kind: MySQLOpsRequest
metadata:
name: storage-migration
namespace: demo
spec:
type: StorageMigration
databaseRef:
name: sample-mysql
migration:
storageClassName: longhorn-custom
oldPVReclaimPolicy: Delete
Here,
spec.typespecifies that we are performingStorageMigrationoperation.spec.databaseRef.namespecifies that we are performing StorageMigration operation onsample-mysqldatabase.spec.migration.storageClassNamespecifies our desired StorageClassspec.migration.oldPVReclaimPolicyspecifies the reclaim policy of previous persistent volume.
Note: To retain the old PersistentVolume, set
spec.migration.oldPVReclaimPolicytoRetain.
Let’s create the MySQLOpsRequest CR we have shown above,
$ kubectl create -f https://github.com/kubedb/docs/raw/v2025.8.31/docs/examples/mysql/migration/storage-migration.yaml
mysqlopsrequest.ops.kubedb.com/storage-migration created
Verify the StorageClass Migrated Successfully
If everything goes well, KubeDB operator will migrate the StorageClass along with the data.
Let’s wait for MySQLOpsRequest to be Successful. Run the following command to watch MySQLOpsRequest CR,
$ watch kubectl get mysqlopsrequest -n demo
Every 2.0s: kubectl get mysqlopsrequest -n demo
NAME TYPE STATUS AGE
storage-migration StorageMigration Successful 12m
We can see from the above output that the MySQLOpsRequest has succeeded. Let’s verify the StorageClass.
$ kubectl get pvc -n demo
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
data-sample-mysql-0 Bound pvc-64cca3c6-85aa-426f-abc3-b300ecfe365a 1Gi RWO longhorn-custom <unset> 21m
data-sample-mysql-1 Bound pvc-1de36b06-8e32-4e9a-a01b-3b6d7c618688 1Gi RWO longhorn-custom <unset> 21m
data-sample-mysql-2 Bound pvc-a75bd538-8a71-4f62-8d38-3f4e42ffb225 1Gi RWO longhorn-custom <unset> 21m
The PersistentVolumeClaim StorageClass has changed to longhorn-custom. Now, we will verify that the data remains intact after the StorageMigration operation. Let’s exec into one of the MySQL pod and perform read query.
$ kubectl exec -it -n demo sample-mysql-0 -- bash
Defaulted container "mysql" out of: mysql, mysql-coordinator, mysql-init (init)
bash-5.1$ mysql -uroot -p$MYSQL_ROOT_PASSWORD
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 225
Server version: 9.1.0 MySQL Community Server - GPL
Copyright (c) 2000, 2024, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> select * from hello.users;
+----+--------+--------------------+
| id | name | email |
+----+--------+--------------------+
| 1 | David | [email protected] |
| 2 | Eva | [email protected] |
| 3 | Frank | [email protected] |
| 4 | Grace | [email protected] |
| 5 | Hannah | [email protected] |
| 6 | Ian | [email protected] |
| 7 | Jack | [email protected] |
| 8 | Karen | [email protected] |
| 9 | Liam | [email protected] |
| 10 | Mona | [email protected] |
| 11 | Nathan | [email protected] |
| 12 | Olivia | [email protected] |
| 13 | Paul | [email protected] |
| 14 | Quincy | [email protected] |
| 15 | Rachel | [email protected] |
| 16 | Steve | [email protected] |
| 17 | Tina | [email protected] |
| 18 | Uma | [email protected] |
| 19 | Victor | [email protected] |
| 20 | Wendy | [email protected] |
+----+--------+--------------------+
20 rows in set (0.00 sec)
From the above output we can verify that data remains intact after the StorageMigration operation.
CleanUp
To clean up the Kubernetes resources created by this tutorial, run:
$ kubectl delete mysqlopsrequest -n demo storage-migration
$ kubectl delete mysql -n demo sample-mysql
$ kubectl delete ns demo