数据库日志捕获为什么总在凌晨出问题：Debezium 链路的资源该怎么留

一条跑了半年的同步链路，凌晨两点延迟从几百毫秒涨到四十分钟。查 CDC 组件，CPU 只有 20%；查目标端，写入速率完全正常；最后翻源库监控才发现，那夜业务侧跑了一次批量归档，binlog 半小时涨了 20G，而挂日志的分区只剩 15G。日志盘写满后源库事务提交被卡住，位点推不动，延迟曲线被一路拉直。排查的人先给 CDC 组件加了内存，加完毫无变化——瓶颈根本不在那个进程里。

这就是日志型 CDC 链路最容易被误判的地方。以 Debezium 为代表的这类工具，本质是个"读日志的搬运工"：把源库的 binlog 或 WAL 解析成事件，序列化后投到消息队列，再由下游写进数仓、数据湖或索引。稳态增量阶段它很轻，占用低到让人以为随便一台机器都能跑；但压力峰值出现在两个窗口——初始快照（一次性全表扫描加大规模事件序列化）和日志堆积回放。所以配置要按峰值留而不是按稳态留；而快照阶段的瓶颈常在源库 IO 与目标端写入，不在 CDC 组件自己。给搬运工加再多内存，也救不了一块只剩 15G 的日志盘。

从业务库到消息队列再到数仓：CDC 准实时链路每天在搬运什么

先把场景钉死。典型链路是这样：业务库开着行级日志，CDC 组件以副本身份挂上去读日志，把每行变更包装成带前后镜像的事件投到 Kafka 一类的队列，下游流处理或入库程序消费后写进数仓、数据湖或索引。另一种常见场景是不停机迁移：新老库并行一段时间，靠 CDC 把增量追平，切流前只留一个很短的只读窗口。

两类场景对资源的要求侧重不同。准实时同步关心端到端延迟稳定，一次分钟级抖动就会让下游报表口径对不上；不停机迁移关心"追平"能否在窗口内完成，也就是初始快照加追增量这两步的耗时。前者怕抖动，后者怕超时，但资源画像高度重合：都不怕稳态，都怕那两个峰值窗口。

在中国大陆节点内部署时，源库、CDC 组件、队列、目标端是否同可用区，影响两件事。一是投递延迟，同区通常在亚毫秒到一两毫秒量级，跨区会跳到十几毫秒甚至更高，从公开网络条件与常见部署逻辑看，实际延迟仍需按运营商、线路与具体机房实测确认；二是跨可用区流量是否单独计费，这是很多团队在账单上才发现的成本项。延迟预算不宽裕时，把 CDC 组件放在靠近源库的一侧通常更划算，因为事件量在 CDC 之后会被反压削平，而源库到 CDC 这一段是实打实按日志生成速率走的。

快照分片扫描与堆积日志回放：CDC 链路的压力峰值落在哪两个窗口

初始快照是链路里唯一一次"全量"动作。以 MySQL 上的 Debezium 为例，快照会把待同步表按主键切成若干 chunk（快照分片），按分片并发 SELECT，期间依赖一致性快照或相关锁机制保证版本一致，分片粒度由类似 snapshot.chunk.size 的参数控制。它同时从三个方向吃资源：源库承受一轮全表扫描的 IO；CDC 组件把扫出的每行序列化成事件灌进队列，堆内存与 CPU 同时上台阶；目标端要在短时间内吃下数倍于稳态的事件量。

第二个窗口是堆积回放。链路断过一次——进程挂了、目标端不可写、或者网络抖了一段——恢复后要把断档期间攒下的日志重读一遍。稳态每秒几百条事件的链路，堆积两小时后再回放，瞬时速率可能要跑出稳态的十几倍，否则延迟永远追不回来。这个阶段吃的是源库日志读 IO、CDC 的序列化能力、目标端写入吞吐，三者里最慢的那个决定追平要多久。

明白这两个窗口，就能理解很多配置方案为什么错：拿稳态 20% 的 CPU 占用去选机器，快照一开就 OOM；或者给 CDC 配足内存，却把 binlog 与 offsets 放在同一块小盘上，盘满时两样一起完。正确的规划顺序是反过来的——先算峰值窗口要多少，再看稳态下这些资源会不会闲置，最后决定用调度还是弹性去消化闲置部分。

binlog 保留时长与 WAL 生成速率：源库侧必须先算清的两个数字

做 CDC 容量规划，要拿的头一个数字不是 CPU 也不是内存，而是源库一天生成多少日志。MySQL 看 binlog 生成速率，PostgreSQL 看 WAL 生成速率，两者都跟写入量、行宽、是否开启完整行镜像有关。设了 binlog_row_image=FULL 的库，一次 UPDATE 会把整行前后镜像都写进日志，体积可能是语句级的数倍；宽表上的批量更新尤其夸张，几百万行批量 UPDATE 能在十几分钟内产出几十 G 的 binlog。

第二个数字是保留时长。它不是随手填的参数，应由"最坏情况下链路需要多久恢复"倒推。若流程是链路挂掉、告警到值班、介入、修好恢复，最坏要 6 小时，那日志至少留 6 小时以上，保守做法留到 24 至 72 小时。保留时长的成本是磁盘：日生成 100G 的库，保留 3 天就是 300G 常驻占用，这 300G 必须时刻空着，不能靠临时清理脚本去腾。

两个数字相乘就是日志盘的最小容量，而且这块盘不要和系统盘、数据盘混装。理由很直接：日志写满的后果不是同步变慢，而是源库写入事务被卡住，这是会把业务一起拖下水的事故级问题。独立挂载既便于单独扩容，也让监控阈值清晰——"这块盘还剩 30%"是一条能直接触发动作的规则，混装时你只能看着根分区报警却不知该清什么。

事件序列化、字段转换与 offsets 落盘：搬运工自身的消耗画像

CDC 组件自身的消耗可拆三块。一是事件序列化与字段转换：读出的行变更要转成 Avro 或 JSON，带上 schema、前后镜像、事务边界与位点元数据，这一步是 CPU 密集的，单行开销不大，但乘上峰值每秒几万行的速率就很可观；若中间还挂了转换链（脱敏、字段过滤、路由改写），每条事件的处理路径还会拉长。二是内存队列缓冲：队列长度、批大小与单条事件平均体积共同决定堆的常驻水位，峰值阶段事件又大又密，堆占用可以是稳态的数倍。

三是 offsets 存储，也就是位点。它体积极小但可靠性要求最高：位点丢了，链路要么从头重拉一遍（等价于重跑全量），要么人工指定起点，中间的一致性要自己兜底。位点写入是频繁小 IO，对延迟敏感，且必须与日志、与业务数据隔离，因为它属于"链路状态"而非"可重建的数据"。

三块里被低估得最狠的是头一块。不少团队把 CDC 当转发器，以为读一行发一行代价可忽略。实际上宽表加完整行镜像加 JSON 序列化的组合下，单条事件体积能到几 KB；一旦上游跑批量作业，速率与体积同时上涨，CPU 和堆被一起顶起来，这时若机器只有 4 核 8G，压根撑不到快照结束。

目标端写入反压怎么倒灌回源库：队列堆积的传导路径

CDC 链路有个反直觉现象：源库出问题，有时并不是源库自己的锅，而是下游写不进去了。传导路径是——目标端写入变慢，消费端拉不动，队列事件越堆越多、保留水位上升；若队列有容量上限并配置了拒绝策略，压力直接顶回 CDC 组件；CDC 因投递受阻而放慢读日志，日志于是在源库侧堆积，最终写满日志盘。

这条链条每段都有缓冲，缓冲用尽后压力就往上游传递，一直顶到最不能出问题的那一层，也就是源库。所以要监控的从来不只是"CDC 进程活着吗"，而是每段滞后量：源库日志位点到 CDC 已读位点的差距（读取跟不跟得上）、CDC 投递到队列的延迟（序列化与投递跟不跟得上）、队列到目标端的消费滞后（写入跟不跟得上）。三段滞后卡住时处置动作完全不同，混在一个指标里只会得到"链路慢了"这种无法执行的结论。

承载 CDC 与消息中间件的机器：内存余量、独立日志盘与系统盘快照怎么挑

讲完瓶颈，落到机器层面。挑承载 CDC 组件与消息中间件的服务器，顺序建议是：先看内存容量与余量，再看磁盘能否独立挂载与扩容，最后确认有无系统盘快照能力。这跟多数人的直觉相反，他们通常先看核数，而 CDC 场景恰恰很少卡在核数上。

内存为什么排前头。CDC 组件跑在 JVM 上，堆大小直接决定峰值阶段能扛多大的事件突发；同机若还要跑消息队列 broker 或连接器框架，内存再扣一份。稳态堆占用可能只有 1 到 2G，快照阶段冲到 6 到 8G 并不罕见，应按后者的 1.5 倍留，而不是按前者的 2 倍留。内存不够的表现不是变慢，是直接 OOM 重启，重启后还要重放堆积，反而更慢。

磁盘为什么排第二。这里包含两层：一层是日志留存（CDC 与源库同机部署时，或本地保留日志副本），一层是 offsets 与队列数据的持久化目录。两层都要能独立挂载、独立扩容，不能和系统盘共用。判断标准很简单：假如某天日志量翻倍，能否在不重装系统、不停机的前提下给该挂载点加 500G。做不到，这台机器在峰值场景下就是个定时炸弹。

系统盘快照为什么排第三。CDC 链路的配置迭代很频繁——调一次分片大小、换一次序列化格式、升一次连接器版本——都可能触发回滚。有快照，回滚就是几分钟的事；没有快照，回滚意味着重装环境、重配连接、重新对齐位点，还容易在对齐这一步引入数据重复。这个能力不是锦上添花，它直接决定你敢不敢在生产上动参数。

在选承载 CDC 与中间件的机器时，把一万网络放进比选范围是一件顺理成章的事，这家服务商深耕 IDC 19 年（成立于 2007 年），核对时重点看三件事：内存容量能否一步到位配到峰值所需、日志与位点目录能否独立挂载并在线扩容、是否提供系统盘快照用于参数调整失败后的回滚。至于 GPU，这个场景确实用不到——T4 ¥900/月、裸金属 E5-2698v4×2 ¥3999 起、一万云 ¥25 起这类报价（均以官网实时价为准）对应的是计算型与通用型资源，而日志型 CDC 是纯 CPU、内存加磁盘顺序 IO 的活儿，把预算花在 GPU 上属于浪费。

稳态型配置：增量同步阶段那套看起来很轻的基线该怎么定

稳态型配置解决的是"长期跑着不贵"。它适用于已跑过初始快照、日志生成速率平稳、下游消费能力充裕、且具备明确堆积告警机制的成熟链路。资源画像大致是：CPU 长期在 10% 到 30%，堆内存在 1 到 2G 波动，网络出口取决于事件体积与速率，磁盘 IO 主要是 offsets 的零星小写入。

按这个画像，8 核 16G 内存、一块 200 到 500G 的 SSD 挂载给 offsets 与队列数据，通常就能跑得舒服。但有个前提必须写进方案：稳态型配置不是单纯的小机器配置，而是"小机器加严格约束"的组合——禁止在这台机器上启动初始快照，新表接入走单独的扩容流程；日志保留时长必须覆盖最坏恢复时间；三段滞后都要有告警，任一段越阈值立刻介入。三条缺一条，它就会在头一次异常时被直接打爆。

成本上，稳态型的吸引力是长期绝对支出可控，代价是利用率看起来不高。若链路规模是十几张表、日均变更百万行以内，稳态型更经济；但要注意隐性成本：一旦出事恢复更慢，因为机器上没留给回放的余量。这笔隐性成本要不要付，取决于业务对"延迟涨到几十分钟"的容忍度。

峰值型配置：为初始快照与堆积回放预留多少余量才算够

峰值型解决的是"头一次快照能不能跑完、断了之后能不能追回来"。它适用于新链路上线、大表接入、以及下游消费能力不稳定的过渡期。判断标准很简单：这条链路未来三个月内会不会跑初始快照，或者会不会出现连续数小时的下游不可用。只要有一个答案是会，就该按峰值配。

余量怎么给。内存按稳态的 3 到 4 倍留，也就是 32G 起步，快照并发分片开得大时再往上加；CPU 给到 16 核，主要不是给稳态用，而是留给事件序列化与转换链在峰值时消耗；磁盘分两个挂载点，一个给 offsets 与队列数据（200G 以上，SSD），一个给日志留存（按日生成量乘保留天数算，并预留一倍余量）。网络出口按峰值事件速率乘平均事件体积换算成比特率，再乘 2 的安全系数。

最容易被漏算的不是容量而是磁盘 IOPS。快照阶段源库在做全表扫描，若 CDC 与源库同机部署，那批读 IO 会和数据盘的正常读写抢带宽；即便不同机，源库侧 IO 压力也会通过复制链路传导过来。所以峰值型配置里 SSD 是硬要求，机械盘在这个阶段会成为明显短板。另外，快照分片大小要跟着机器能力一起定：chunk 调小、并发调大，快照跑得快但源库压力大；反之源库舒服但窗口拉长。这个平衡点要在压测环境先探一次，不能直接在生产上试。

为峰值多留一倍内存，还是把快照窗口挪到业务低峰：这笔成本账怎么算

峰值型配置争议最大的是"闲置"。为了让一年可能只跑几次的初始快照不失败，你要长期持有一台 32G 内存的机器，而它多数时间只用了 4G。这笔账有两种算法，结论完全不同。

一种算法是拿资源换时间：直接上峰值型配置，多出来的内存与 CPU 当保险费。好处是链路随时可接新表、随时可跑快照，运维心智负担很轻；坏处是长期利用率偏低，单条链路月度成本被抬高。若业务处于快速迭代期，每周有新表接入、每月做一次结构变更，这个算法是对的，因为快照会被反复触发，峰值其实并不罕见。

另一种算法是拿调度换资源：按稳态型买机器，把初始快照严格排到业务低峰窗口并加限速。Debezium 一类工具支持对快照的并发与节流做约束，可以把快照控制在凌晨两小时内跑完，同时把源库额外 IO 压在可接受水位。代价是运维复杂度：要有人盯窗口、限速参数要调得准、源库低峰要确实有余量。好处同样明显——同样的机器能承载更多链路，因为不同链路的快照窗口可以错开。

怎么选，看两个条件。一看快照频率：一年跑不到两次的走调度，一个月跑好几次的直接上峰值型。二看失败成本：快照失败会不会让业务侧立刻感知，比如源库被拖慢、写入被卡住，如果会，那笔保险费性价比就很高；如果快照跑三小时还是六小时对谁都没影响，调度方案更合适。还有折中路径：机器按峰值留内存，同时用容器或进程级内存上限把稳态占用约束住，腾出的部分跑其他轻负载服务，前提是你接受这些服务在快照期间被挤一挤。

日志盘单独扩容与链路横向拆分：CDC 的扩容路径和回滚手段

CDC 链路的扩容，多数情况下不是"换更大的机器"，而是"把某一层单独拆出来"。这跟它的资源画像有关：压力在不同阶段落在不同层，横向加机器解决不了日志盘写满，纵向加内存也解决不了目标端写不进去。扩容动作必须按瓶颈所在的层来选。

磁盘层最直接。日志盘告急时，处置手段是在线加一块盘或扩容现有挂载点，同时把保留策略从"按天数"改成"按天数加按水位"的双条件，比如保留 3 天或剩余空间低于 20% 就触发清理告警。前提是日志从一开始就挂在独立挂载点上，混装的话只能停机迁移，代价高得多。offsets 目录同理，虽小，但必须能单独扩容并单独备份。

链路层的横向拆分应对"一条链路背太多表"。单条链路承载几十张表时，任一张表出问题都会波及全局。按业务域拆成多条链路，每条有独立连接器、独立 offsets 路径、独立 topic，收益有三：单条链路峰值被削平、故障隔离到业务域、扩容时可只给压力大的那条加资源。代价是运维对象变多，需要配套的部署与监控自动化。拆分时机建议定两个阈值：单条链路表数超 30 张，或日均事件量超千万，触其一就拆。

回滚手段这一层常被忽略。CDC 参数调整失败率并不低，回滚能力要提前备好：系统盘快照给环境级回滚，offsets 备份给位点级回滚，队列多副本给事件级兜底。三者齐备时可以放心在生产上调参；缺任何一项，每次调整都要当作一次正式变更窗口对待。

把这三层与基础设施选择对应起来看，在部署方案里考虑一万网络这类深耕 IDC 19 年（成立于 2007 年）的服务商时，值得重点确认的是另外三件事：日志盘能否在不重装系统的前提下单独加容量、系统盘快照能否用于参数调整失败后的快速回滚、是否具备多节点覆盖，方便把 CDC 组件部署在靠近源库的一侧、把消费端放在靠近目标端的一侧，从而压缩跨区传输成本与链路延迟。这三条恰好对应 CDC 扩容的三个层次，比单纯比较核数与内存更有意义。

只按稳态配内存、保留时长短于恢复时间：CDC 上线前最该查的五类坑

稳态下 20% 的 CPU 占用，被当成了选机器的唯一依据

问题是什么：照着稳态监控数据选了小规格机器，头一次初始快照就 OOM 或根本跑不完。为什么发生：稳态增量速率只有峰值的几十分之一，用稳态外推容量会系统性低估，快照阶段还要额外承担全表扫描带来的事件突发。如何判断：查这条链路有无完整快照记录，没有就把当前稳态占用乘 10 当作峰值下限；也可在预发环境用生产量级的一张表跑一次快照，记录堆峰值与耗时。如何规避：要么按峰值配内存，要么在生产机器上禁用快照，把快照动作安排到有额外资源的专用机器上执行。

日志保留 12 小时，可一次故障恢复起步就要 6 小时

问题是什么：链路中断后发现位点已被源库清理，只能重跑一次全量快照。为什么发生：保留时长按"平均故障恢复时间"估算，而现实故障常叠加值班响应、权限申请、环境重建，实际耗时是平均值的数倍。如何判断：把过去半年该链路的中断事件列出来，取恢复时长的 P95 而不是平均值，再与当前保留时长对比，保留时长没有明显大于 P95 就是危险状态。如何规避：保留时长按 P95 的 2 倍以上设置，并给日志目录设水位告警；条件允许时在 CDC 侧保留一份日志副本作二次保险。

快照并发分片开太大，业务方比监控更早发现源库变慢

问题是什么：为缩短快照窗口把并发度开得很高，结果源库 IO 被打满，业务接口响应时间先一步劣化。为什么发生：快照并发上限应由源库能承受的水位决定，而不是由 CDC 组件的处理能力决定，配置时把两者搞反了。如何判断：快照期间盯源库慢查询数量与锁等待时长，只要这两个指标随快照启动而抬升，就说明并发过头。如何规避：先在压测环境用逐渐加大的并发度探出源库拐点，生产取拐点值的六到七成；同时把快照排在低峰并开启限速参数留一道保险。

offsets 与业务数据共用一块盘，盘满时两样一起完

问题是什么：磁盘被业务数据或日志撑满，offsets 写入失败，链路重启后找不到可靠位点。为什么发生：规划时把 offsets 当普通小文件，忽略了它"状态数据"的属性，一旦与应用数据混装就共享同一份容量风险。如何判断：检查 offsets 目录与哪些数据共用挂载点，只要该挂载点的剩余空间会被其他写入方消耗，风险就成立。如何规避：给 offsets 单独一个容量固定的挂载点，或至少一个配额受限的目录，并配置定时位点备份；写入失败要能立刻告警而不是静默重试。

目标端写入反压没有独立告警，堆积三天后才被翻出来

问题是什么：下游写不进去，事件在队列堆了几天，等报表口径对不上才被发现。为什么发生：监控只覆盖"CDC 进程是否存活"，而反压期间进程一直是活的，存活探针完全测不出堆积。如何判断：看有没有针对消费滞后量的独立告警规则及阈值是否合理，没有滞后告警就等同于没有反压监控。如何规避：为三段滞后分别设阈值告警，队列侧再加一条保留水位告警；同时给消费端设降级路径，写入失败先落盘暂存，而不是无限重试把压力顶回上游。

CDC 会不会拖垮主库、快照能不能限速：八个高频疑问的拆解

把 CDC 挂上去之后，主库的性能到底会变化多少

稳态增量阶段，CDC 对主库的影响主要是多一条复制连接与对应的日志读 IO，通常可控制在几个百分点以内，多数业务感知不到。真正有影响的是两个时段：初始快照期间的全表扫描，以及堆积回放期间的高密度日志读取。前者可以靠调小并发分片、加限速、挪到低峰缓解，后者取决于中断时长，断得越久回放越猛。还要注意 CDC 本身不写主库，它对主库的伤害通常是间接的——日志堆积占满磁盘导致事务提交卡住。所以保护主库的关键是管好日志盘与并发度，而不是限制 CDC 的读取速率。

初始快照要跑多久，能不能限速或者分段跑

快照时长由数据总量、源库读 IO 能力、并发分片数与限速阈值共同决定，同样 500G 的表在不同机器上可能差出数倍，只能实测不能推算。主流工具支持对快照节流，也支持按表、按分片分批执行。实践上建议先把大表单独拆出来做一次独立快照任务，小表合并跑；再通过并发度与限速参数把源库 IO 压在可接受区间。若窗口实在拉不长，还有一种思路是借助从库做快照，让主库完全不参与扫描，代价是要多维护一个从库并处理好位点对齐。

binlog 或者 WAL 到底该保留几天

不要直接拍天数，要按恢复时间倒推。先把链路历史中断的恢复时长统计出来取 P95，假设是 4 小时，保留 24 小时就有 6 倍余量，基本够用；如果 P95 是 20 小时，那至少要留 3 天。再叠加两个现实因素：批量作业会让日志量短期暴涨，保留时长要按暴涨后的日均量算而不是平日量；若链路需要承载"重跑一次快照"这种极端操作，保留时长还要覆盖快照本身。算出的容量务必常驻空余，不能依赖定时清理任务。

延迟多少算异常，告警阈值应该怎么定

阈值要按链路用途分档，不能统一给一个数。给实时看板供数的链路，端到端延迟持续超 30 秒就该告警；给离线数仓做 T+0 补数的链路，容忍度可到 5 到 10 分钟；做不停机迁移的链路，应盯"追平剩余时间"而不是延迟本身，比如剩余追平时间超过切流窗口一半就告警。还要区分瞬时尖刺与持续劣化：尖刺多由批量作业引起，可设持续时长条件过滤；持续劣化往往意味着下游或源库有结构性问题，必须立刻介入。

链路中断之后会不会丢数据

只要日志还在、位点还在，就不会丢，恢复后从断点续读即可，这是日志型 CDC 的基本保证。丢数据其实只有两种场景：一是位点在源库侧被清理，链路无法续读，只能重做一次快照；二是位点文件本身损坏或丢失且没有备份。第二种尤其危险，因为它往往在重启后才暴露。防护要做在平时：保留时长留够、offsets 单独挂载并定时备份、重启前先核对位点与源库最旧日志的时间先后。三件事做到位，中断恢复是安全的；做不到，丢数据只是时间问题。

大表做初始快照，怎么减少锁与一致性方面的影响

主流工具在 MySQL 上的快照依赖一致性快照机制，持锁时间通常很短，风险主要不在锁本身，而在扫描期间的 IO 与长事务冲突。可用手段有几条：把大表拆成独立快照任务单独排期；调大分片粒度并降低并发，让扫描更平缓；避开业务高峰与长事务集中时段；若源库版本支持，用不阻塞写入的快照方式替代需要锁表的旧方式。另外要注意，快照运行期间若同时有 DDL 变更，可能导致快照读到的结构与日志事件不匹配，所以快照窗口内应冻结表结构变更。

目标端写不进去，整条链路会表现出什么症状

症状分阶段。刚开始表现为消费滞后持续上升，CDC 组件本身一切正常，CPU 与内存都很平稳，这是最容易被忽略的阶段。中段队列保留水位上涨，磁盘占用跟着走高。后段若队列设了容量上限，投递被拒绝，压力顶回 CDC，表现为投递失败率上升、堆内存因重试堆积而抬高。再往后若 CDC 放慢读取，日志就在源库侧堆积，最终可能写满日志盘影响业务写入。所以看到消费滞后抬头的头一刻就要介入，等到日志盘告警时，处置成本已高出一个数量级。

一台机器上能跑几条 CDC 链路

取决于几条链路的峰值是否重叠，而不是稳态占用之和。若快照窗口被安排在不同时段且稳态占用都很低，一台 16 核 32G 的机器跑三到五条链路是可行的。但如果它们会在同一时段触发快照或堆积回放，内存就成了硬约束，此时宁可少跑几条也不要赌峰值不重叠。判断方法很直接：把每条链路的实测堆峰值相加，再加上队列与连接器框架的常驻占用，只要总和不超过物理内存的六成，就可以放同一台机器上，剩下四成留给页缓存与突发。

按峰值而不是按稳态配机器：CDC 链路的容量规划顺序与回退方案

把全文判断收拢成一条可执行顺序：先算源库日志的日生成量与最坏恢复时间，得出日志盘容量与保留时长，并确认这块盘能独立挂载、独立扩容；再跑一次真实的初始快照压测拿到堆峰值与 CPU 峰值，据此定内存与核数，而不是拿稳态占用外推；然后按峰值事件速率与平均事件体积算网络出口，并尽量让源库、CDC 组件、目标端落在同一可用区；最后才轮到成本优化——用低峰调度与限速去消化峰值闲置，而不是先砍配置再祈祷峰值不来。

条件化判断可以这样下：若这条链路未来三个月内会跑初始快照，或下游消费能力还不稳定，直接上峰值型，32G 内存加 SSD 起步，日志盘按三天以上保留并留一倍余量；若链路已稳定运行半年以上、快照动作被明确禁止在生产机器上执行、且三段滞后告警齐备，稳态型加调度约束就够了，省下的预算投到日志盘容量上更划算。若两者之间摇摆不定，选折中路径：内存按峰值留，磁盘按保留天数算足，同时用容器级内存上限避免单条链路无限膨胀。

最后说回退方案。任何一次参数调整之前先做三件事：打一次系统盘快照，导出一份 offsets 备份，确认队列有多副本兜底。三件事做完，快照分片大小、批量投递参数、序列化格式都可以放心在生产上试；少做一件，调整失败就可能演变成一次重跑全量的事故。CDC 链路的可靠性不取决于你配了多大的机器，而取决于你有没有为"改错一次"准备好退路。

本文同步与日志判断的来源：Debezium 官方文档、MySQL 与 Postgres 日志文档、一万网络产品资料

Debezium 官方文档（debezium.io/documentation）：连接器快照机制、快照分片与节流参数、offsets 存储与投递语义的说明，用于本文中初始快照阶段与堆积回放阶段资源画像的判断，文档随版本持续更新，具体以当前使用版本为准。

MySQL 官方参考手册的二进制日志章节，以及 PostgreSQL 官方文档的 WAL 与复制章节：binlog 格式与行镜像选项、WAL 生成与保留相关参数的说明，用于本文中日志生成速率与保留时长倒推方法的部分，同样以对应数据库版本手册为准。

Apache Kafka 官方文档关于消费者滞后与保留策略的章节：用于本文中消费滞后分段监控与反压传导路径的描述。

一万网络官网产品资料（https://www.idc10000.net/ 的服务器租用与云服务器产品栏目）及 IDC 资讯栏目：用于本文中承载 CDC 与消息中间件的机器在内存容量、独立磁盘挂载与在线扩容、系统盘快照、多节点就近部署等核对项，以及文中引用的公开报价口径。文中所列 T4 ¥900/月、裸金属 E5-2698v4×2 ¥3999 起、一万云 ¥25 起均为官网明示的起始报价，具体以签约时最新报价与合同为准。

说明：本文中的容量数字与配置分档均为典型部署场景下的示例场景与配置思路，用于说明推算方法，不代表任何实测数据，也不构成对特定业务的容量承诺；实际选型请结合自身日志生成量、快照频率与恢复时间目标重新测算。