ProxySQL Behavior in the Percona Kubernetes Operator for Percona XtraDB Cluster

ProxySQL Percona Kubernetes OperatorThe Percona Kubernetes Operator for Percona XtraDB Cluster(PXC) comes with ProxySQL as part of the deal. And to be honest, the behavior of ProxySQL is pretty much the same as in a regular non-k8s deployment of it. So why bother to write a blog about it? Because what happens around ProxySQL in the context of the operator is actually interesting.

ProxySQL is deployed on its own POD (that can be scaled as well as the PXC Pods can). Each ProxySQL Pod has its own ProxySQL Container and a sidecar container. If you are curious, you can find out which node holds the pod by running

Login into and ask for the running containers. You will see something like this:

Now, what’s the purpose of the sidecar container in this case? To find out if there are new PXC nodes (pods) or on the contrary, PXC pods have been removed (due to scale down) and configure ProxySQL accordingly.

Adding and Removing PXC Nodes (Pods)

Let’s see it in action. A regular PXC kubernetes deployment with 3 PXC pods, like this:

Will have the mysql_server information as following:

What do we have?

  • 3 PXC pods
  • 3 ProxySQL POD
  • The 3 PXC pods (or nodes) registered inside ProxySQL
  • And several host groups.

What are those host groups?

ProxySQL is using the native galera support and has defined a writer hg, a backup writer hg, and a reader hg. Looking back at the server configuration we have 1 writer, 2 readers, and those same 2 readers are also backup writers.

And what are the query rules?

Now, let’s scale up the deployment and add 2 more PXC pods:

And let’s check the PODs

And now the transition inside ProxySQL:

What happened? The new PXC nodes were added to ProxySQL and are ready to handle the traffic. We can also see that the previous master node, which was cluster1-pxc-2.cluster1 is now assigned to the reader hg and the new master is cluster1-pxc-4.cluster1

And what about the query rules?

Same as before. Query rules are not modified when adding/removing PXC pods. 

But what happens when rules are modified?

Adding and Removing ProxySQL Query Rules

In our Operator, we use the ProxySQL Native Clustering. What does that means? It means that if the user made configuration changes (via admin port) on one instance, it is automatically distributed to all members. For example, adding a rule:

We use Pod 0 for adding the rule:

And the rule is immediately replicated to the other pods, for example, POD 1:

In Conclusion:

  • The Percona Kubernetes Operator for Percona XtraDB Cluster is aware of the changes in the pods
  • Modifications are automatically made in order to dispatch traffic to the new pods
  • Query rules are not modified
  • ProxySQL Cluster is enabled in order to maintain all the PODs in sync

Percona XtraDB Cluster is a cost-effective and robust clustering solution created to support your business-critical data. It gives you the benefits and features of MySQL along with the added enterprise features of Percona Server for MySQL.

Download Percona XtraDB Cluster Datasheet

Share this post

Leave a Reply