使用 PXC Kubernetes Operator V1.10.0 管理 MySQL 配置第 3 部分：结论

在本系列的第一部分和第二部分中，我们介绍了在使用 Percona XtraDB Cluster (PXC) 对象和 ConfigMap 时管理 MySQL 配置和优先级的不同方法。在这篇文章中，我们将看到在基于 Percona XtraDB Cluster 的 Percona Operator for MySQL中将机密用于 MySQL 配置的优先级。

案例 4：名称为 cluster1-pxc 的密钥和名称为 cluster1-pxc 的 ConfigMap 但在 PXC 对象中没有配置

当 MySQL 配置存在于 ConfigMap 和 secret 但不存在于 PXC 对象中时，以下将是状态

# 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 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>

可以看出，secrets 优先于 ConfigMap

案例5：PXC 对象中存在的配置，ConfigMap cluster1-pxc，secret cluster1-pxc

当前状态：

# 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"
}

让我们尝试使用 secrets cluster1-pxc 并查看效果。

# 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

如下图所示，ConfigMap 和 pxc 对象没有变化。

# 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"
}

但是，数据库已从秘密中获取配置

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

Secret 优先于 pxc 对象和 ConfigMap

结论

1. 通过秘密 cluster1-pxc 的 MySQL 配置优先于 ConfigMap cluster1-pxc 或 pxc 对象
2. 如果秘密 cluster1-pxc 不存在，则与 PXC 对象一起存在的 MySQL 配置优先于 ConfigMap cluster1-pxc。
3. 操作员从 PXC 对象中获取配置，并在协调循环中覆盖 ConfigMap cluster1-pxc 中的配置。
4. 如果配置仅存在于 ConfigMap 或 secret 中，则不会在协调循环中的 PXC 对象中写入相同的配置。

原文标题：Managing MySQL Configurations with the PXC Kubernetes Operator V1.10.0 Part 3: Conclusion
原文作者：Chetan Shivashankar
原文地址：https://www.percona.com/blog/managing-mysql-configurations-with-the-pxc-kubernetes-operator-v1-10-0-part-3-conclusion/