解读

这道题考察的是“混合云+多云”场景下的双向数据同步能力，而不仅仅是把 AlloyDB Omni 当成一个本地 PostgreSQL。面试官想确认你能否在合规、低延迟、可回切三大国内硬性要求下，把 Google 的托管服务（Cloud SQL）与本地部署的 AlloyDB Omni 打通，并保证双向复制不冲突、不断链、可监控。因此，回答必须围绕Google 官方 replication 机制、PostgreSQL 逻辑复制槽、冲突检测与解决、网络合规四条主线展开，缺一不可。

知识点

1. AlloyDB Omni 内核：与 Cloud SQL for PostgreSQL 同为 14/15 内核，默认已开启 logical decoding = 'pgoutput'，具备 pglogical 插件，支持 发布-订阅模型。
2. Cloud SQL 逻辑复制：2023Q4 起中国站（vpc-sc 上海/北京地域）已开放 cloudsql.logical_decoding = on 与 cloudsql.enable_pglogical，可创建 PUBLICATION/SUBSCRIPTION，但仅支持出站（read replica）或单向逻辑复制，双向需手工冲突裁决。
3. 双向复制冲突类型：主键冲突、唯一索引冲突、序列跳号、批量更新顺序错位；国内金融、运营商场景下必须给出可审计的冲突策略（last-write-wins 或 site-specific 分区键）。
4. 网络合规：国内机房到 Google 中国站必须走合规跨境专线（含 SR-TE 路由备案），Private Service Connect + Cloud VPN 或 Cloud Interconnect 合作伙伴线路；IP 规划需提前在工信部备案，否则双向复制会被运营商 QoS 丢包。
5. 高可用回切：需借助 pg_rewind + 外部 LSN 记录表实现分钟级回切；回切脚本必须集成 Cloud SQL Admin API 与 AlloyDB Omni 容器编排（systemd 或 K8s CRD），保证角色切换后原主库只读。

答案

整体分五步落地，全部脚本可用 Terraform + Ansible 固化到 GitLab CI，满足国内审计要求。

1. 前置条件校验
   a. 在 Cloud SQL 中国站实例创建时显式打开 cloudsql.logical_decoding = on 与 cloudsql.enable_pglogical，并重启生效（约 30 s 闪断，需放在业务低峰）。
   b. 本地 AlloyDB Omni 用 RPM 包或 OCI 镜像安装后，执行 ALTER SYSTEM SET pglogical.conflict_resolution = 'last_update_wins'; 并reload，确保冲突策略一致。

2. 网络打通
   a. 本地机房边界路由器与 Google 中国站建立 Cloud VPN 高可用隧道（HA VPN），IKEv2 + AES-256-GCM-16 + PFS Group 20，MTU 1460 避免分片。
   b. 在 Cloud SQL 实例上开启 Private IP，并分配已备案的 RFC1918 地址段（如 10.88.0.0/24），通过 VPC 对等与本地 SR-MPLS 专线互通，双向 RTT 控制在 25 ms 以内方可满足 OLTP 同步。

3. 创建双向发布订阅
   ① 以 site A（本地 AlloyDB Omni）→ site B（Cloud SQL） 为例：

   -- AlloyDB Omni 端
   SELECT pglogical.create_node(node_name := 'site_a', dsn := 'host=10.88.0.11 port=5432 dbname=prod user=repl password=***');
   SELECT pglogical.create_replication_set('rs_two_way', replicate_insert := true, replicate_update := true, replicate_delete := true);
   SELECT pglogical.replication_set_add_all_tables('rs_two_way', schemas := ARRAY['public']);
   
   -- Cloud SQL 端
   SELECT pglogical.create_node(node_name := 'site_b', dsn := 'host=10.88.0.22 port=5432 dbname=prod user=repl password=***');
   SELECT pglogical.create_subscription(subscription_name := 'sub_from_site_a', provider_dsn := 'host=10.88.0.11 port=5432 dbname=prod user=repl password=***', replication_sets := ARRAY['rs_two_way'], synchronize_structure := false, synchronize_data := false);
   

   ② 反向链路同理，但表级同步顺序必须先关外键，再开外键，避免 FK 级联死锁。

4. 冲突检测与监控
   a. 在两张库均建 conflict_log 表（含 node_id、table_name、lsn、old_tuple、new_tuple、resolve_ts），通过 pglogical.conflict_handler 钩子写入，TTL 7 天后自动分区归档。
   b. 使用 Cloud Monitoring 自定义指标 custom/ alloydb_logical_lag_seconds 与 custom/cloudsql_logical_lag_seconds，阈值 5 s 告警；同时把 pg_stat_replication.replay_lag 通过 Ops Agent 打到 阿里云 SLS 或腾讯 CLS，满足国内等保日志留存 180 天要求。

5. 回切与演练
   a. 计划内切换：
   ① 在应用层禁写（SET default_transaction_read_only = on;），等待 pg_stat_replication.replay_lag = 0。
   ② 调用 Cloud SQL Admin API 将 Cloud SQL 实例 promote 为可写；同时把 AlloyDB Omni 设为 pglogical.drop_node() 并只读。
   b. 计划外回切：
   ① 使用 pg_rewind --target-timeline=latest --source-server 把落后节点拉回，跳过冲突 LSN。
   ② 通过 Ansible playbook 自动修改 VIP 指向，并短信通知值班（集成腾讯云短信或阿里云短信）。

至此，双向复制在合规网络与冲突裁决机制下即可稳定运行，RPO < 30 s、RTO < 5 min，满足国内政企、券商核心交易场景。

拓展思考

1. 如果业务表使用 自定义序列（bigserial），双向写会导致序列跳号或主键冲突，可改用 雪花算法 UUID 或 PostgreSQL 16 的 GLOBAL 序列；但国内部分 ORM（如 MyBatis-Plus）对 UUID 主键索引碎片化敏感，需评估 BRIN → BTree 回退代价。
2. 当数据需要出境到 Google 国际站（如新加坡）时，中国《数据出境安全评估办法》要求 100 万人以上个人信息或 10 万人以上敏感个人信息必须做省级网信办评估；此时只能把 Cloud SQL 实例留在中国站，再通过 BigQuery Omni 做跨境分析，避免整库复制出境。
3. 未来 Google 官方若推出 AlloyDB Omni ↔ Cloud SQL 托管式双向复制（类似 Oracle GoldenGate），冲突解决策略可能下沉到 Google Cloud 控制面，届时本地只需暴露一个 PSC endpoint，VPN 隧道与 IAM 权限由 Google 托管，运维成本再降 50%；作为架构师应提前在 Terraform 模块化里预留 PSC attachment 插槽，实现一键升级。