设计基线 v2 · MIT · 不实现

津梁 JinLiang：一期三种组合，覆盖 13 个版本

MySQL 5.7 / 8.0 / 8.4 / 9.x × PostgreSQL 10–18 · 同构含跨版本割接 · 169 条链路推演

定下来的事

许可证 MIT；一期只做 MySQL + PostgreSQL，含同构；同表双向与 UI 二期。
三种组合：MySQL→MySQL、PG→PG、MySQL↔PG（两个方向算一种异构）。
版本：**PG 10 起的每个大版本都要覆盖**；MySQL 5.7 / 8.0 / 8.4 / 9.x 四个家族。

9PG 大版本（10–18）

4MySQL 家族

169链路（全笛卡尔）

1352测试单元（×8 场景）

PostgreSQL 10–18：差异比想象中大

每一项差异都会改变同步的实现路径，不能靠"应该差不多"糊过去。

版本	EOL	对同步有实质影响的差异
10	2022-11	逻辑复制首发（pgoutput）；无 TRUNCATE 复制、无 slot 磁盘阀、无 slot advance
11	2023-11	+ TRUNCATE 复制，+ slot advance
12	2024-11	仍无 slot 磁盘阀
13	2025-11	+ max_slot_wal_keep_size（磁盘阀，弃槽才不至于写满盘）、+ 分区根表发布
14	2026-11	+ 流式大事务（protocol v2）、+ 二进制初始拷贝
15	2027-11	+ 行过滤 / 列清单、+ 两阶段提交解码
16	2028-11	+ 订阅端并行 apply、+ pg_stat_io
17	2029-11	+ slot 随主备切换存活、+ pg_createsubscriber
18	2030-11	+ 冲突检测视图、+ idle_replication_slot_timeout；宣称含 DDL 复制（需实测确认）

MySQL 4 个家族：语法和认证都会咬人

版本	状态	坑
5.7	EOL 2023-10	无 `LOCK INSTANCE FOR BACKUP`、无原子 DDL、无 `binlog_expire_logs_seconds`、默认 native 认证
8.0	EOL 2026-04	caching_sha2 默认；`binlog_transaction_compression`（8.0.20+）解析必须解压
8.4 LTS	2032 前	native 认证默认关闭；`SHOW MASTER STATUS` 已移除 → 必须用 `SHOW BINARY LOG STATUS`
9.x 创新版	滚动	native 认证插件彻底移除；`default_authentication_plugin` 变量删除

一个具体例子：拿 8.0 时代写死的 SHOW MASTER STATUS 去连 8.4，直接语法报错。所以连接器不能按版本号分支，只能运行时探测。

169 条链路怎么跑得起：四层矩阵

层	内容	链路	何时跑
T1 自洽	每版本 → 同版本（PG 10→10 … 18→18；MySQL 5.7→5.7 … 9.x→9.x）	13	每 PR（改动连接器的子集）× 3 场景
T2 相邻升级	n → n+1（10→11 … 17→18；5.7→8.0→8.4→9.x）	11	每日 nightly
T3 极端跨度	最老 ↔ 最新；降级只验「明确拒绝 + 给人话原因」	4	nightly
T4 异构轮转	MySQL 4 × PG 9 × 2 方向 = 72，每周轮转抽样	72（每周 12）	nightly 抽样 / release 全量

≤15 分钟PR 门禁（T1 子集 × 3 场景）

30–50 分钟nightly（≈40 链路 × 8 场景）

2–3 小时release 全量 169 链路

每周一遍全版本全覆盖

为什么不全量每 PR 跑：1352 个单元跑不起也不必要。但一个版本都不许漏——漏的那条往往就是用户的生产版本。分层让 PR 不堵、每周仍全量扫一遍。

能力探测表（不写版本号分支）

能力	探测方式	缺失时降级
快照导出	slot 创建是否接受 `EXPORT_SNAPSHOT`	短锁取位点，并标注那一瞬
slot 磁盘阀	`pg_settings` 是否有 `max_slot_wal_keep_size`	只能告警不能自动失效，界面明说「你的版本没有磁盘保护阀」
流式大事务	pgoutput 协议版本协商	全量缓冲 + 上限 512 MB，超限拒绝并给建议
行过滤 / 列清单	`pg_publication_rel.prattrs/prqual`	全表传输 + 客户端过滤（标出带宽代价）
TRUNCATE 复制	pgoutput 消息支持	目标端定期校验 + 告警「源端 TRUNCATE 不同步」
binlog 状态语句	`SHOW BINARY LOG STATUS` 是否可用	回退 `SHOW MASTER STATUS`
备份锁	`LOCK INSTANCE FOR BACKUP`	回退 FTWRL；云上被禁 → 快照后取位点 + 重叠去重
认证插件	`mysql.user.plugin` 分布	native / caching_sha2 三态适配

产品表现：预检写「你的 PG 12 没有磁盘保护阀，我们用告警代替自动失效」，而不是抛 max_slot_wal_keep_size is not a valid parameter。

支持档：EOL 的也测，但不假装它是主力

全支持PG 14–18、MySQL 8.0 / 8.4 / 9.x — 缺陷必修，CI 全场景

尽力支持PG 10–13、MySQL 5.7 — 仍进矩阵仍跑 nightly，但上游已不再出补丁，预检里明示「建议升级」

不支持PG ≤ 9.6（无原生 pgoutput）、MySQL ≤ 5.6、MariaDB（本期）

降级方向PG 18→17 这类只验「明确拒绝 + 人话原因」，不承诺支持

测试形态（不变的骨架）

五层单元 / 连接器契约 / 端到端 / 故障注入（kill -9、slot 被删、schema 漂移）/ 性能基线（退化 >15% 红）

影子模型对拍内存影子库 vs 目标库逐行比；schema fuzz × 操作序列 fuzz；断言最终一致 / 重放幂等 / 位点不倒退 / 不串位；失败最小化成 seed

准入制度每个连接器带 testmatrix.yaml（镜像/版本/启动参数/能力位），没有清单 PR 直接红

覆盖度报表进 READMEpostgres 10→10 … 18→18 = 9/9 ✔，空格子一眼可见，不许吹「生产级」

语料 TPC-H / northwind / sakila / 各版本官方 regression DDL —— 零本地依赖，不拿任何客户库做基准。

降级：先补偿，后拒绝

每个能力缺口按三步走：① 自动补偿（用户无感）→ ② 有代价的替代（如实标注、可开关）→ ③ 才拒绝 + 解释 + 替代路径。降级不能降正确性——补偿会让结果不一致时，宁可不做。

缺口	① 自动补偿	② 有代价替代
PG 10–12 无 slot 磁盘阀	监控落后量，超 5 GB 暂停并告警；主动推进位点	定期全量校验 + 重建
PG 10 无 `slot_advance()`	临时解码连接消费到位点后丢弃（需显式确认）	只告警
PG 10 无 TRUNCATE 复制	定时校验 + 自动订正；或源端触发器写入 `_ds_event`	只告警
PG ≤13 无流式大事务	大事务 spill 到磁盘，不占内存	上限调到可用内存内
PG ≤14 无行过滤/列清单	快照只 SELECT 需要的列；增量客户端侧过滤	建议用视图当源
PG ≤14 无两阶段解码	侦测 prepared xact 后暂停告警	建议 `max_prepared_transactions=0`
目标版本更低（18→17）	逐特性落地：虚拟生成列→普通列、`uuidv7()`→客户端生成、新类型→TEXT/JSONB、行过滤→客户端、DDL 复制→我们自己做	目标端加影子列 / 落地 JSON
MySQL 5.7 无备份锁	毫秒级 FTWRL 取位点	快照后取位点 + 5 分钟重叠去重（标注极小重复可能）
MySQL 8.4/9.x native 被禁/移除	自动建独立 caching_sha2 账号（不动用户原账号）	建议升级客户端驱动
MySQL 8.4+ 无 `SHOW MASTER STATUS`	双语法探测；后备读 `performance_schema.log_status`	—
binlog 事务压缩	实现 zstd 解压（源端开了也必须能读）	建议源端关闭
MySQL 5.7 无原子 DDL	白名单只允许可安全重放；DDL 期间短暂暂停该表	轮询 information_schema 感知

落在实现上是「一张表驱动」：探测能力 → 查补偿表 → 有 ① 就用 ① 并在预检记「已补偿」→ 否则问用户是否接受 ② 的代价 → 都不行才拒绝。
跨版本降级只拒绝那一张表，不拒绝整个任务。

性能指标与开销：都要能算出来

≥20k 行/s单核快照（200 B 窄行）

p99 <100 ms端到端（同机房，batch 1 ms）

<80 MB / <256 MB空转 / 增量常驻内存

<200 ms冷启动；二进制 <25 MB

怎么测：TPC-H lineitem 三档（1M / 10M / 100M 行）+ sysbench 写入压测驱动增量；延迟用「源端写 clock_timestamp() → 目标端可见时间」打点；每次 release 存基线 JSON，任一指标退化 >15% 就红。

对谁	开销项	控制手段
源库	1 个复制连接 + 快照期 ≤4 只读连接	`--snapshot-conns`
	快照读压力	每连接 QPS 上限 200；按 PK 分块，块间可 sleep
	WAL / binlog 保留	slot 落后阈值 5 GB / 30 min；binlog 保留需覆盖最长断连（预检提示）
目标库	写放大	批量 500 行/事务；建议同步完再建二级索引
目标库	状态 / 死信表	每任务 <10 MB；死信表上限 + 轮转

测试自身的开销	估算	墙钟
PR	3 链路 × 3 场景 × 90 s + 单元 30 s	12–15 min（并行 6）
nightly	40 链路 × 9 min ≈ 6 机器小时	20–30 min（并行 20）
release	169 链路 × 9 min ≈ 25 机器小时	1.5–2.5 h（并行 20）

磁盘约束 runner 只有 14 GB → matrix 让每个 job 只拉自己那个镜像，不要把 9 个 PG + 4 个 MySQL（约 6 GB）全缓存。

其余设计（v1 继承）

预检三级 + 定制教程；可逆准备全部前置，最后只剩「重启一次数据库」
垃圾清理：孤儿四条判定、默认 dry-run、租约防双跑、位点与数据同事务（幂等）
Catalog：行数/主键/「有无稳定主键」硬提示/类型映射预览/单表覆盖；目标同名表默认报错
频次五档：一次性 / 初始化+实时 / 实时仅增量 / 定时增量（只要 SELECT）/ 定时全量（>500 万行拒绝）
内容：列/行/结构可选；DDL 只跟随四类，其余拦截暂停
转换：单位/时区/编码/枚举/脱敏/计算列；不做聚合、join、脚本；失败进死信表

名字候选（六个，slug 在 spencerswagger 名下均未被占用）

名字	slug	出处 / 含义	气质
津梁	JinLiang	渡口与桥（"津，水渡也"）	桥接异构两端；最接近兰台、灵枢的文气
飞挽	FeiWan	「飞刍挽粟」——古代高速转运军粮	最贴"低延迟 + 高吞吐 + 持续运输"
漕运	CaoYun	古代大规模水路转运	强调吞吐与持续，略"重"
通渠	TongQu	打通水道、引流	直白好记；但易与 Alibaba Canal 的"渠"联想
驿传	YiChuan	驿站接力传递	与"雁书"语义偏近，容易撞
转输	ZhuanShu	《史记》"转输"= 转运输送	稳、朴实，但记忆点弱

已定：津梁（JinLiang） —— 渡口与桥，异构两端之间那一段水路。仓库 spencerswagger/JinLiang、二进制 jinliang（短写 jl）。