解读

国内云面试里，这道题常被用来区分“只搭过主从”与“真正调优过读写分离”的候选人。
面试官真正想听的是：

1. 你知道 VACUUM 清理死元组 与 备库快照冲突 的本质；
2. 你能把参数作用范围、生效方式、Cloud SQL 托管限制讲清楚；
3. 你清楚打开该参数后带来的 复制延迟、主库膨胀、GC 压力 副作用，并给出权衡方案。
   答不到副作用，基本会被追问“那主库磁盘打满怎么办？”

知识点

• hot_standby_feedback 逻辑：备库把 oldest active xmin 回传给主库，使主库延迟清理仍被备库可见的旧元组，从而避免 “canceling statement due to conflict with recovery” 错误。
• 生效位置：只在备库配置，主库读该参数无意义；Cloud SQL 只读副本（Read Replica）本质是托管备库，因此要在 副本实例级 设置。
• 修改路径：Cloud SQL 不提供直接改 postgresql.conf 的权限，需通过 Google Cloud Console → 实例 → 参数 → 添加 hot_standby_feedback = on 或使用 gcloud sql instances patch REPLICA_NAME --database-flags hot_standby_feedback=on。
• 与 max_standby_streaming_delay 区别：后者是“允许等多久”，前者是“告诉主库别删”，两者可配合使用，但 不能 100% 解决冲突，只能降低概率。
• 国内合规注意：若数据库部署在 华北-北京、华东-上海 等地域，变更参数同样走 Cloud SQL 统一管控面，无需额外 ICP 备案，但需评估参数变更窗口对业务的影响。

答案

1. 确认实例角色：仅对 Cloud SQL 只读副本 设置，主库无需改动。
2. 选择变更方式：
   • 控制台：进入副本实例 → 数据库参数 → 新增 hot_standby_feedback = on → 保存 → 等待滚动重启（秒级闪断）。
   • CLI：
     gcloud sql instances patch <副本实例ID> --database-flags hot_standby_feedback=on --project=<项目ID>
3. 验证：
   • 在副本执行 SHOW hot_standby_feedback; 应返回 on；
   • 主库 pg_stat_replication 中 backend_xmin 列被持续填充，即反馈生效。
4. 副作用治理：
   • 监控主库 pg_stat_database.deadlocks 与 pg_stat_user_tables.n_dead_tup 暴涨；
   • 结合 max_standby_streaming_delay = 30s 与 vacuum_defer_cleanup_age = 0 做权衡；
   • 若主库磁盘因此膨胀，可临时关闭参数，或把长查询拆短、加索引降低扫描范围。
5. 回滚：同样命令置 off，Cloud SQL 自动重启副本，无需停机。

拓展思考

• 如果业务侧出现 “长事务 + 批量更新” 场景，仅靠 hot_standby_feedback 仍可能把主库撑爆，此时可引入 Cloud SQL 的并行副本：让报表走 BigQuery 联邦查询，或把大查询路由到 Cloud SQL 高可用实例的只读节点（需开启 查询洞察 做自动分流）。
• 国内金融云客户常要求 两地三中心，在 上海主 + 深圳备 的跨区域复制中，hot_standby_feedback 打开后网络 RTT 高，反馈包延迟会导致主库 autovacuum worker 积压；解决方式是 调大 autovacuum_work_mem 并 按表级设置 vacuum_cost_limit，而非盲目关参数。
• 面试加分项：主动提到 Cloud SQL Auth Proxy 的自动 IAM 鉴权 与 Private Service Connect 可在只读副本上启用，既保证安全，又避免长查询被公网抖动放大冲突，体现你对 Google Cloud 整体数据面的深度理解。