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
1 2 3 4 5 6 7 8 9 10 | # 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
1 2 3 4 5 6 | # 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:
1 2 3 4 5 6 | # 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.
1 2 3 4 5 6 | # 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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | # 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" } |
However, the DB has taken configurations from secrets
1 2 3 4 | 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 🙂
