Downloads

Blog

Managing MySQL Configurations with the PXC Kubernetes Operator V1.10.0 Part 3: Conclusion

August 3, 2022

Author

Share this Post:

Managing MySQL Configurations Kubernetes In part one and part two of this series, we introduced the different ways to manage MySQL configurations and precedence when using the Percona XtraDB Cluster (PXC) object and ConfigMap. In this post, we will see the precedence when secrets are used for MySQL configurations in Percona Operator for MySQL based on Percona XtraDB Cluster.

CASE-4: Secret with name cluster1-pxc and ConfigMap with name cluster1-pxc but without configuration in PXC object

When the MySQL configuration is present in the ConfigMap and secret but not in the PXC object, the following would be the state

# kubectl get pxc cluster1 -ojson | jq .spec.pxc.configuration
 
# kubectl get secrets cluster1-pxc -ojson | jq -r '.data."secret.cnf"' |base64 -d
[mysqld]
wsrep_debug=CLIENT
wsrep_provider_options="gcache.size=768M; gcache.recover=yes"
# kubectl get cm cluster1-pxc -ojson | jq .data
{
 "init.cnf": "[mysqld]\nwsrep_debug=CLIENT\nwsrep_provider_options=\"gcache.size=64M; gcache.recover=yes\"\n"
}

# kubectl get pxc cluster1 -ojson | jq .spec.pxc.configuration

# kubectl get secrets cluster1-pxc -ojson | jq -r '.data."secret.cnf"' |base64 -d

[mysqld]

wsrep_debug=CLIENT

wsrep_provider_options="gcache.size=768M; gcache.recover=yes"

# kubectl get cm cluster1-pxc -ojson | jq .data

{

"init.cnf": "[mysqld]\nwsrep_debug=CLIENT\nwsrep_provider_options=\"gcache.size=64M; gcache.recover=yes\"\n"

}

Let’s query the DB to see which value has been taken

# kubectl run -i --rm --tty percona-client --image=percona:8.0 --restart=Never -- bash -il
 
mysql> SHOW VARIABLES LIKE 'wsrep_provider_options'\G
*************************** 1. row ***************************
Variable_name: wsrep_provider_options
 </snip>       gcache.size = 768M;  … </snip>

# kubectl run -i --rm --tty percona-client --image=percona:8.0 --restart=Never -- bash -il

mysql> SHOW VARIABLES LIKE 'wsrep_provider_options'\G

*************************** 1. row ***************************

Variable_name: wsrep_provider_options

</snip> gcache.size = 768M; … </snip>

As it can be seen, secrets take precedence over ConfigMap

CASE-5: Configuration present in PXC object, ConfigMap cluster1-pxc, secret cluster1-pxc

Current State:

# kubectl get pxc cluster1 -ojson | jq .spec.pxc.configuration
"[mysqld]\nwsrep_debug=CLIENT\nwsrep_provider_options=\"gcache.size=128M; gcache.recover=yes\"\n"
# kubectl get cm cluster1-pxc -ojson | jq .data
{
 "init.cnf": "[mysqld]\nwsrep_debug=CLIENT\nwsrep_provider_options=\"gcache.size=128M; gcache.recover=yes\"\n"
}

# kubectl get pxc cluster1 -ojson | jq .spec.pxc.configuration

"[mysqld]\nwsrep_debug=CLIENT\nwsrep_provider_options=\"gcache.size=128M; gcache.recover=yes\"\n"

# kubectl get cm cluster1-pxc -ojson | jq .data

{

"init.cnf": "[mysqld]\nwsrep_debug=CLIENT\nwsrep_provider_options=\"gcache.size=128M; gcache.recover=yes\"\n"

}

Let’s try to use secrets cluster1-pxc and see the effects.

# cat secret.cnf
[mysqld]
wsrep_debug=CLIENT
wsrep_provider_options="gcache.size=768M; gcache.recover=yes"
# kubectl create secret generic cluster1-pxc --from-file secret.cnf
secret/cluster1-pxc created

# cat secret.cnf

[mysqld]

wsrep_debug=CLIENT

wsrep_provider_options="gcache.size=768M; gcache.recover=yes"

# kubectl create secret generic cluster1-pxc --from-file secret.cnf

secret/cluster1-pxc created

As it can be seen below, ConfigMap and pxc object had no changes.

# for i in `seq 1 100`; do kubectl get pxc cluster1 -ojson | jq .spec.pxc.configuration ; sleep 2 ; done
"[mysqld]\nwsrep_debug=CLIENT\nwsrep_provider_options=\"gcache.size=128M; gcache.recover=yes\"\n"
"[mysqld]\nwsrep_debug=CLIENT\nwsrep_provider_options=\"gcache.size=128M; gcache.recover=yes\"\n"
 
# for i in `seq 1 100`; do kubectl get cm cluster1-pxc -ojson | jq .data; sleep 2 ;done
{
 "init.cnf": "[mysqld]\nwsrep_debug=CLIENT\nwsrep_provider_options=\"gcache.size=128M; gcache.recover=yes\"\n"
}
{
 "init.cnf": "[mysqld]\nwsrep_debug=CLIENT\nwsrep_provider_options=\"gcache.size=128M; gcache.recover=yes\"\n"
}
{
 "init.cnf": "[mysqld]\nwsrep_debug=CLIENT\nwsrep_provider_options=\"gcache.size=128M; gcache.recover=yes\"\n"
}

# for i in `seq 1 100`; do kubectl get pxc cluster1 -ojson | jq .spec.pxc.configuration ; sleep 2 ; done

"[mysqld]\nwsrep_debug=CLIENT\nwsrep_provider_options=\"gcache.size=128M; gcache.recover=yes\"\n"

# for i in `seq 1 100`; do kubectl get cm cluster1-pxc -ojson | jq .data; sleep 2 ;done

{

"init.cnf": "[mysqld]\nwsrep_debug=CLIENT\nwsrep_provider_options=\"gcache.size=128M; gcache.recover=yes\"\n"

}

{

"init.cnf": "[mysqld]\nwsrep_debug=CLIENT\nwsrep_provider_options=\"gcache.size=128M; gcache.recover=yes\"\n"

}

{

"init.cnf": "[mysqld]\nwsrep_debug=CLIENT\nwsrep_provider_options=\"gcache.size=128M; gcache.recover=yes\"\n"

}

However, the DB has taken configurations from secrets

mysql> SHOW VARIABLES LIKE 'wsrep_provider_options'\G
*************************** 1. row ***************************
Variable_name: wsrep_provider_options
 </snip>   gcache.size = 768M; …  </snip>

mysql> SHOW VARIABLES LIKE 'wsrep_provider_options'\G

*************************** 1. row ***************************

Variable_name: wsrep_provider_options

</snip> gcache.size = 768M; … </snip>

Secrets take precedence over pxc object and ConfigMap

Conclusion

MySQL Configurations via secret cluster1-pxc takes precedence over ConfigMap cluster1-pxc or pxc object
If secret cluster1-pxc is not present, MySQL configurations present with the PXC object take precedence over ConfigMap cluster1-pxc.
The operator takes the configuration from the PXC object and overwrites the configuration in ConfigMap cluster1-pxc in the reconciliation loop.
If the configuration is present in just ConfigMap or secret, the same is not written in the PXC object in the reconciliation loop.

We would love to hear how you are managing MySQL configurations, feel free to comment 🙂