Cloud SQL：连接、权限与恢复

验证：未记录

适用版本: 未记录
验证范围: 尚未登记验证记录。

PostgreSQL 操作速查；Console：SQL → 实例 → Connections / Backups。

常用操作#

替换为实际资源；本段不依赖 lab.env。

PROJECT_ID='REPLACE_PROJECT_ID'
INSTANCE='REPLACE_INSTANCE'

gcloud sql instances describe "$INSTANCE" --project="$PROJECT_ID"
gcloud sql backups list --instance="$INSTANCE" --project="$PROJECT_ID"
# 本机已有 ADC 与 Cloud SQL Client；在此终端保持 Proxy 运行。
CONNECTION_NAME=$(gcloud sql instances describe "$INSTANCE" \
  --project="$PROJECT_ID" --format='value(connectionName)')
cloud-sql-proxy "$CONNECTION_NAME" --address=127.0.0.1 --port=5433

容易踩的坑#

Auth Proxy 不会为本机建立到 Private IP 的网络路径，也不授予数据库表权限。 私网连接仍需 VPN 等路径或可达 VPC 的管理机；Proxy 使用 --private-ip，数据库另查用户与 SQL GRANT。

Proxy 超时查出站 443/3307；数据库直连查 5432、来源授权和 TLS。
HA 不防误删；恢复会改变数据状态，先在独立实例验证。

连接方式 · 错误定位 · 私网 · 官方建议

配置说明与完整示例（按需展开）

前置：环境篇，本机 psql、Cloud SQL Auth Proxy v2。这是持续计费实验，做完及时删除。

Cloud SQL 适合什么，连接方式如何选#

Cloud SQL 托管 MySQL、PostgreSQL、SQL Server，本篇使用 PostgreSQL。需要关系模型、SQL 和事务时从这里开始；文档模型看 Firestore，分析查询看 BigQuery，缓存看 Memorystore。Aurora 不能与一个 GCP 产品直接画等号：PostgreSQL 场景还可评估 AlloyDB，分布式关系数据库需求可评估 Spanner，均需检查兼容性和负载。数据库产品

Public / Private IP 决定网络路径；直连 / Auth Proxy 决定连接方式；数据库用户决定能执行什么 SQL。 这是三个独立选择。

本地连接方式	必须具备的条件	适合本篇的选择
Public IP + Auth Proxy	实例 Public IP、有效 Google credentials、Cloud SQL Client、数据库用户	本篇默认；无须把本机公网 IP 加入 Authorized networks
Public IP 直连	Authorized networks 放行实际出口 IP；配置符合实例要求的 TLS 与数据库认证	客户端直连实例地址的 5432；换网/VPN 后核对出口 IP
Private IP 直连或 Proxy	本机已有 VPN 等私网路径，或在可达 VPC 的管理 VM 执行	仅安装 Proxy 不会获得私网连接；Proxy 选用 `--private-ip`

直连的 Authorized networks 在 Cloud SQL → 实例 → Connections → Networking 配置，个人出口通常用 /32；同时按实例 CA mode / SSL mode 配置证书。Private IP 的 non-RFC 1918 来源也有授权要求。连接选型、Authorized networks

使用 Proxy 时，DBeaver / pgAdmin / psql 都连接本机 127.0.0.1:5433，不是实例 IP。下方 application-default login 提供 Proxy 的 ADC；普通 gcloud auth login 与它分开，见 CLI 与 ADC。

创建与连接#

source lab.env
gcloud services enable sqladmin.googleapis.com
gcloud sql instances create lab-pg \
  --database-version=POSTGRES_16 \
  --edition=ENTERPRISE \
  --tier=db-f1-micro \
  --region="$REGION" \
  --storage-size=10GB \
  --availability-type=zonal \
  --backup-start-time=20:00
gcloud sql databases create app --instance=lab-pg
# Bash 中隐藏输入；仅使用此次实验的新密码
read -rs -p 'Lab database password: ' DB_PASSWORD; echo
gcloud sql users create appuser --instance=lab-pg --password="$DB_PASSWORD"
unset DB_PASSWORD
export CONNECTION_NAME=$(gcloud sql instances describe lab-pg --format='value(connectionName)')
gcloud auth application-default login
cloud-sql-proxy "$CONNECTION_NAME" --address=127.0.0.1 --port=5433

最后一条在终端 A 保持运行。终端 B：

psql -h 127.0.0.1 -p 5433 -U appuser -d app -W

CREATE TABLE lab_items (id bigint PRIMARY KEY, name text NOT NULL);
INSERT INTO lab_items VALUES (1, 'before-backup');
SELECT * FROM lab_items;

实验使用实例公共 IP + Auth Proxy，不添加 0.0.0.0/0 authorized network。代理需要 Cloud SQL Client，数据库仍需用户认证。代理提供认证加密，不会凭空创建到私有 IP 的网络路径。连接原理

密码通过 CLI 参数提交时可能短暂出现在本机进程参数中；只用于本地合成实验，生产采用受控创建流程或 IAM 数据库认证。

在 psql 中输入 \q 返回 shell，再执行下面的 gcloud 命令；恢复验收时重新连接 psql。不要在 psql 提示符下粘贴 Bash 命令。

本地连接失败时先定位哪一层#

现象	检查
本机 5433 connection refused	Proxy 是否仍运行、监听端口是否正确或被占用；先看 Proxy 日志
Proxy 的 Google API / IAM 错误	ADC 实际身份、Cloud SQL Admin API、Cloud SQL Client、instance connection name
Proxy 连接超时	到 Google API 的出站 TCP 443、到实例的 TCP 3307；Private IP 还查私网路径
Public IP 直连超时	实例是否有 Public IP、实际公网出口是否在 Authorized networks、出站 5432
SSL / certificate 错误	实例 CA/SSL mode 与客户端验证配置；不要用关闭验证代替修复
password authentication failed / permission denied for table	分别查数据库用户密码、SQL GRANT；添加 Cloud SQL Client 不会授予表权限

本篇使用 built-in 数据库用户；IAM database authentication 是另一种需显式配置的认证方式。Proxy 不提供连接池，应用扩容时仍需控制数据库总连接数。Proxy 原理与端口

备份恢复#

gcloud sql backups create --instance=lab-pg
gcloud sql backups list --instance=lab-pg

等备份 SUCCESS 后，用 psql 执行 DELETE FROM lab_items;。复制刚创建的 backup ID：

export BACKUP_ID='替换为备份ID'
# 会覆盖实例数据，仅在本实验实例操作
gcloud sql backups restore "$BACKUP_ID" --backup-instance=lab-pg --restore-instance=lab-pg

重新连接，SELECT * FROM lab_items; 应恢复第一行。记录耗时，理解实际 RTO。备份恢复与 PITR 不同；PITR 需要预先满足日志保留等配置。备份

生产检查与清理#

通过 Cloud SQL 创建且未指定数据库角色的内置用户默认具有较高的 cloudsqlsuperuser 权限；本篇仅用于建表实验。生产用独立迁移账号，并在 PostgreSQL 内为应用授予限定表的 DML 权限。数据库角色

实验的共享核、单区与建表账号不代表生产配置。生产考虑区域 HA、PITR、私网、连接池、迁移身份与业务身份分离。HA 解决部分故障切换，不能替代误删恢复。

停止代理（Ctrl-C），随后：

gcloud sql instances delete lab-pg

检查备份页面的保留/最终备份及其费用。不要复用综合项目实例来做覆盖恢复实验。

生产权限收敛实验#

前置：已完成订单项目且 public.orders 表存在。本段操作订单数据库，独立于前面的 lab-pg 恢复实验。

用表所有者 orders 登录 orders-pg 的 orders 数据库；它还需 CREATEROLE。使用 SQL 创建权限有限的新用户，避免通过 Cloud SQL 默认创建流程附带高权限角色：

CREATE ROLE orders_runtime LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT;
\password orders_runtime
GRANT SELECT, INSERT ON TABLE public.orders TO orders_runtime;
SELECT has_schema_privilege('orders_runtime', 'public', 'USAGE') AS can_use,
       has_schema_privilege('orders_runtime', 'public', 'CREATE') AS can_create;

\password 是 psql 命令，交互设置新实验密码。预期 can_use=true、can_create=false；若 schema 曾自定义授权，由 schema 所有者补 USAGE 并撤销不必要的 CREATE（含 PUBLIC 继承来源），再继续。

在 psql 输入 \q 回到 Bash，将同一新密码写入专用 Secret，再切换 Worker：

read -rs -p 'New runtime database password: ' RUNTIME_DB_PASSWORD; echo
printf '%s' "$RUNTIME_DB_PASSWORD" | gcloud secrets create orders-runtime-password --data-file=- --replication-policy=automatic
unset RUNTIME_DB_PASSWORD
gcloud secrets add-iam-policy-binding orders-runtime-password --member="serviceAccount:orders-worker@$PROJECT_ID.iam.gserviceaccount.com" --role=roles/secretmanager.secretAccessor
gcloud run services update orders-worker --region="$REGION" --update-env-vars=DB_USER=orders_runtime,AUTO_MIGRATE=false --update-secrets=DB_PASSWORD=orders-runtime-password:1

需要项目篇包含 DB_USER、AUTO_MIGRATE 的新版代码；旧镜像先重建。原 orders 账号保留给迁移操作，运行时跳过建表。

验收：新订单仍成功；以 orders_runtime 连接后 SELECT 成功，DELETE FROM public.orders WHERE false; 和 CREATE TABLE public.must_be_denied(id int); 均因权限不足失败。原密码不再注入 Worker；切换确认后撤销 Worker 对旧 Secret 的读取权限，旧 revision 回滚时注意恢复相应配置。

清理：项目结束且 Worker 已删除后，gcloud secrets delete orders-runtime-password；数据库用户随实例删除。生产变更需要迁移、兼容性与回滚设计，不在应用每次请求里建表。