摘要

  • Google Cloud 9 月 8 日宣布，Cloud SQL for MySQL 的区域管理 API 端点正式可用；该功能在 5 月已进入预览。
  • 区域入口能缩小部分管理请求的处理边界，但不能代替完整的依赖清单与恢复方案。

企业选云时，往往先问数据库放在哪里。这次 Cloud SQL 的变化提出了另一个问题：管理数据库的请求从哪里进入，发生故障时又依赖谁？这两张地图并不相同。

Google Cloud 的 9 月 8 日发布说明将 Cloud SQL for MySQL 的区域管理 API 端点列为正式可用。它并非首次开放区域入口；MySQL 更新记录已在 5 月 11 日记载预览版。新的商业意义，在于企业可以把这个入口选择纳入日常运维，而不是据此宣称整个服务已脱离全球依赖。

成功返回，也可能只看见一部分

按操作文档，区域端点把请求送往指定区域的前端设施，而非先经过全球负载均衡器。对要求区域匹配的操作，目标资源与端点不在同一区域，请求会收到 4xx 错误。

更容易被忽略的是清单范围。同样调用实例列表，全球端点会列出用户跨区域的实例，区域端点只列出本区域。资产盘点工具收到正常结果，并不意味着已经看全数据库。切换入口后清单变短，也不意味着其余实例已被删除。

这使区域化带来一项组织成本：谁负责把局部视图重新核对成完整资产清单？若各业务团队自行选择入口，中央运维就需要明确清单范围，否则局部正确的数据也可能支持错误的整体判断。这是运营推论，不是已发生的客户事故。

备份和工具并不走同一条路

文档同时保留了重要限制：部分后台 API 依赖和元数据仍可能使用全球组件。因此，前端的区域边界不能直接推导为整个 Cloud SQL 服务完全隔离，也不能自动变成某项法规的合规证明。

恢复路径尤其需要分开看。Google Cloud 为跨区域恢复而将备份资源视作全球资源，并建议备份访问和恢复继续使用全球端点；区域访问不是完全不可用。另一个名为 BackupRuns 的资源则由实例所在区域的端点提供。把两者统称为“备份都已区域化”，会抹掉关键差别。

工具支持也未统一。gcloud 与 Terraform 可以通过手动配置覆盖值使用区域端点；控制台和 Config Connector 暂不支持，Cloud SQL 远程 MCP 服务仍走全球端点。认证方式、请求正文、路径和 API 版本本身不因换入口而改变。

目前区域管理端点只支持公共网络连接，不支持私有网络接入或多区域端点地址。这是管理 API 的接入限制，不是在要求企业把私有数据库改为公开访问。对买方而言，需要核算的是多种操作路径并存的维护工作，而非凭一个新地址推算尚未披露的降本收益。