Setup and Deploy Vitess on Kubernetes (Minikube) for MySQL – Part III of III

vitess kubernetes mysql pt3In this blog post, we will continue to explore Vitess and test an example database provided in its repository. This is Part III of the previously discussed installation of Vitess on minikube environment, so please make sure to follow those steps to bring the cluster up to the following level.  

Copy local files to percona-client pod after running the following:

Creating a Keyspace

The sample helm chart provides single unsharded keyspace with a single shard named 0:

The sample schema is simple enough to have only fields required to demonstrate sharding scheme. 

At this point, Vitess is a single keyspace and VSchema is required to describe keyspaces. 

Vertical Split

We will start loading some sample data to our keyspace. But before that, we need the sample SQL script. 

On another shell on a host machine (laptop);

Creating Customer Tablets

This part is to create vttablet instances (as seen above diagram) back to the new keyspace. Later, we’ll move the necessary tables. 

We have now two schemas even though customer vschema has tables, as the physical tables are still in commerce.

We have six running vttablet pods ($kubectl get pods,jobs).

Creating VerticalSplitClone

The following step is to run a vertical split which will start the migration of commerce data to customer

The following tasks have been performed. 

  • Dirty copy data from commerce’s customer and corder tables to customer’s tables.
  • Stop replication on commerce’s rdonly tablet and perform final sync.
  • Start a filtered replication process from commerce->customer that keeps the customer’s tables in sync with those in commerce

Final Cut Over

Once we’ve verified the customer and corder tables are being updated continuously from commerce we can cut over by the order of rdonly, replica and master. 

After running the above commands, commerce data will not be available. 


In this blog, we’ve gone over preplanned examples by Vitess as you should be able to mimic your use case using a similar methodology. We had to go outside of the conventional Kubernetes setup using Minikube. While this has caused us to apply some workarounds, it’s clear to see how to scale with Vitess and its possibilities. 


Please read part I of this series: Introduction to Vitess on Kubernetes for MySQL – Part I

Please read part II of this series: Setup and Deploy Vitess on Kubernetes (Minikube) for MySQL – Part II




Share this post

Comment (1)

  • Neo Reply

    Great blog!

    January 16, 2020 at 12:25 am

Leave a Reply