ProxySQL中mysql_group_replication_hostgroups表数据丢失问题分析

问题现象

在使用ProxySQL管理MySQL Group Replication集群时，用户发现配置在mysql_group_replication_hostgroups表中的数据会在ProxySQL服务重启后丢失。具体表现为：

1. 用户通过Admin接口成功添加了Group Replication主机组配置
2. 执行了LOAD和SAVE命令将配置持久化
3. 重启ProxySQL服务后，配置消失

根本原因分析

经过深入排查，发现问题根源在于ProxySQL服务启动时使用了--initial参数。这个参数会导致ProxySQL在每次启动时：

1. 重命名现有的数据库文件(proxysql.db)
2. 创建一个全新的空数据库
3. 仅从配置文件(proxysql.cnf)加载初始配置

这种行为设计初衷是为了防止配置损坏时能够快速恢复，但副作用是会丢失所有通过Admin接口动态添加并保存的配置。

解决方案

要解决这个问题，需要确保ProxySQL服务启动时不带--initial参数。具体操作步骤：

1. 检查systemd服务文件(通常位于/lib/systemd/system/proxysql.service)
2. 确认ExecStart行是否包含--initial参数或引用了可能包含该参数的变量(如$PROXYSQL_OPTS)
3. 移除相关参数或变量引用，确保启动命令简化为：

   ExecStart=/usr/bin/proxysql --idle-threads -c /etc/proxysql.cnf
   

配置持久化最佳实践

为了确保ProxySQL配置能够正确持久化，建议遵循以下工作流程：

1. 通过Admin接口(6032端口)进行所有动态配置变更
2. 每次变更后执行：

   LOAD ... TO RUNTIME;  # 使配置立即生效
   SAVE ... TO DISK;     # 将配置持久化到磁盘
   

3. 避免直接修改配置文件(proxysql.cnf)，除非是初始部署时的基本参数
4. 定期备份datadir目录下的proxysql.db文件

技术原理深入

ProxySQL的配置管理系统采用三层结构：

1. 内存层(RUNTIME)：即时生效的配置
2. 配置层(disk)：通过SAVE命令保存的配置
3. 初始配置层(initial)：来自配置文件的配置

--initial参数会绕过配置层，直接从初始配置层加载，这是导致数据丢失的根本原因。理解这一机制对于正确管理ProxySQL配置至关重要。

总结

ProxySQL作为高性能MySQL中间件，其配置管理系统设计精巧但需要正确使用。对于Group Replication等高级功能的配置，务必确保服务启动时不使用--initial参数，并通过标准的LOAD/SAVE流程管理配置变更。这样才能保证配置的持久性和服务的高可用性。