Running MySQL / Percona Server in Kubernetes with a Custom Config

PREVIOUS POST
NEXT POST

modify MySQL config in KubernetesAs we continue the development of our Percona Operators to simplify database deployment in Kubernetes (Percona Server for MongoDB Operator 0.3.0 and Percona XtraDB Cluster Operator 0.3.0), one very popular question I get is: how does deployment in Kubernetes affect MySQL performance? Is there a big performance penalty? So I plan to look at how to measure and compare the performance of Kubernetes deployments to bare metal deployments. Kubernetes manages a lot of infrastructure resources like network, storage, cpu, and memory, so we need to look individually at different components.

To begin: I plan to run a single MySQL (Percona Server) instances in a Kubernetes deployment, and use local storage (fast NMVe device). I also want to customize my MySQL configuration, as the one that is supplied in public images are pretty much all set to defaults.

Let’s take a look at how we can customize it.

  1. We are going to use a public Percona Server docker image “percona:ps-8.0.15-5”, it will deploy the latest version (at the time of writing) Percona Server for MySQL 8.0.15
  2. We will deploy this on a specific node and will assign specific local storage to use for MySQL data
  3. We’ll set up a custom configuration for MySQL.

Setting up Kubernetes

Here’s an example yaml file:

There is a lot of typical Kubernetes boilerplate to create a deployment, but the most important parts to note:

  • We choose the node where to deploy with nodeSelector (lines 28–29).
  • We allocate the local storage for MySQL volume with hostPath (lines 31–34).

After deploying this, we make sure the Pod is running

Set up MySQL to access fast storage and modify the default config for performance

Now as we are running MySQL on a dedicated node with fast storage, we want to customize the MySQL configuration to allocate a big buffer pool and adjust its IO settings.

As I said, a downloaded image will most likely run with default settings and there is no straightforward way to pass our custom my.cnf to deployment. I’ll show you how to resolve this now.

The default my.cnf contains the directive !includedir /etc/my.cnf.d

So the solution for the custom my.cnf is as follows:

  • Create a Kubernetes configmap from our custom my.cnf. Here’s how to achieve that:

  • Define yaml to load the configmap into the volume that mapped to /etc/my.cnf.d (nb lines 23–26 and 40-41).

And here’s our example my.cnf:

When we deploy this yaml, we will have a MySQL instance running on a dedicated box with fast local storage, big log files, and 100GB allocated for its InnoDB buffer pool.

Now we’re set to proceed to our performance measurements. Stay tuned!


Photo by Joseph Barrientos on Unsplash

PREVIOUS POST
NEXT POST

Share this post

Leave a Reply