GCP MIG部署ProxySQL对接CloudSQL主从的副本发现方案咨询

适配GCP MIG + ProxySQL + CloudSQL 动态扩容的最优方案 #

该方案已经在大量高流量GCP业务场景落地，完全匹配你的需求：

1. 健康CloudSQL只读副本发现 #

不需要手动维护副本列表，直接通过GCP原生接口拉取实时可用实例：

• 调用Cloud SQL Admin API的instances.list接口，过滤出实例角色为只读副本、运行状态为RUNNABLE的实例，同时可自定义补充复制延迟检测（执行SHOW SLAVE STATUS校验延迟低于阈值），过滤掉异常实例。
• 也可给所有只读副本绑定统一标签如biz=xxx,role=read-replica，通过GCP资源管理器API按标签批量筛选，维护更灵活。

2. ProxySQL配置自动更新逻辑 #

你提到的VM定时轮询拉取配置的方案完全可行，落地成本极低，是当前最常用的实现方式：

• 在每个MIG实例上打包一个轻量的后台定时脚本（轮询间隔可根据业务需要设为5s~30s），执行以下逻辑：
  1. 拉取最新的健康只读副本地址列表
  2. 对比当前ProxySQL运行时mysql_servers表中的读组节点列表
  3. 存在变更时依次执行ProxySQL管理命令：
     • 新增/删除mysql_servers表中对应节点记录
     • 执行LOAD MYSQL SERVERS TO RUNTIME让配置实时生效到内存
     • 执行SAVE MYSQL SERVERS TO DISK持久化配置到磁盘，避免实例重启丢失
• 新扩容的MIG实例启动时，启动脚本优先执行一次上述拉取配置逻辑，完成ProxySQL初始化后再对外提供服务，无需等待所有SQL副本启动，每次拉取都能拿到当前时刻最新的可用节点列表，不存在启动依赖问题。

3. 无状态MIG适配优化 #

• 将ProxySQL安装包、固定配置（权限、路由规则等）、定时更新脚本都打包进MIG自定义镜像，扩容实例无需额外人工配置。
• ProxySQL的固定配置不要存本地，统一存储在GCP Secret Manager中，实例启动时统一拉取，避免配置不一致问题。

无脚本替代方案 #

如果不想自行维护定时脚本，可通过事件驱动方式实现更新：

• 配置Cloud Audit Log触发器，当监听到CloudSQL副本创建、删除事件时，触发Cloud Function生成最新的副本配置推送到Cloud Storage存储桶，MIG实例监听存储桶配置变更自动更新ProxySQL即可。

落地注意事项 #

• ProxySQL自带后端节点健康检测能力，即使拉取的列表中包含异常节点，ProxySQL也会自动标记下线停止转发流量，所以轮询间隔无需设置过短，降低API调用成本。
• Cloud SQL Admin API配额充足，每秒数次的调用不会触发限流，无需额外申请配额。
• 业务高峰扩容时建议优先扩容CloudSQL只读副本，待副本状态正常、复制稳定后再扩容MIG的ProxySQL实例，避免新实例无足够后端承接流量。

内容的提问来源于stack exchange，提问作者jacorl