做容灾这件事，绝大多数团队都是被事故推着走的。机房断电一次、光纤被挖断一次、主库硬盘坏了一次，然后才有人把"要不要搞两地三中心"摆到会上。等到真要立项的时候，常见的两个极端：一种是老板被方案商吓住了，上来就要双活；另一种是预算砍到只剩一台备机，备份脚本半年没跑成功过，还以为自己有灾备。
这篇我想把它讲透，不堆术语。你读完应该能自己判断：我这个业务到底该上哪一档，CPU 和内存怎么配，硬盘要不要 NVMe，异地复制的带宽该怎么算钱。
先把结论摆前面：
1. 两地三中心是监管和清算级业务的标配，不是中小企业的标配。多数中型企业真正的解是"一地双机 + 异地异步备份"，成本大概是双活方案的三分之一甚至更低。
2. 容灾的账不能只算服务器。异地复制占用的上行带宽、快照与备份的存储、演练的人力，这三项加起来经常超过服务器本身的钱。
3. RPO 和 RTO 不是拍脑袋定的指标，是被复制方式、链路质量和演练频率反过来决定的。你定了分钟级，就得接受同步复制带来的主库写入延迟。
4. 切换难，回切更难。90% 的团队只演练切换，不演练回切，也不做恢复演练——备份成功不等于能恢复。
5. 脑裂是容灾里最贵的一个坑，靠自动切换脚本解决不了，必须靠仲裁和写入保护。
"两地三中心"这五个字听着唬人，拆开其实很朴素：两个城市，三个机房。
同城生产中心：你现在跑业务的那组机器，主库、应用、网关都在这。同城灾备中心：同一个城市（或都市圈）的另一个机房，距离通常在几十公里量级，延迟能压在几毫秒，可以做到同步或半同步复制，主要防的是单机房级故障——停电、空调坏了、交换机挂了、机房被淹。异地灾备中心：跨省的另一个城市，几百到上千公里，延迟在几十毫秒量级，只能异步复制，防的是城市级灾害——大面积停电、地震洪水、骨干网被挖断。
这个区分很关键，很多人把三个中心全放在一个园区，或者同城两个机房共用一路市电，那叫"假两地三中心"。同城的那一跳解决的是"机房没了"，异地的那一跳解决的是"城市没了"。两者的 RPO 能力天差地别：同城能追求接近零丢失，异地基本只能做到分钟级到小时级。
真做双活或者自动切换，你还需要一个"第三方裁判"——仲裁节点。它可以是一台很小的云主机，放在第三个位置，不跑业务，只负责在两边互相看不见的时候判谁该活。没有仲裁的自动切换，本质上就是在赌。
这四个词在方案 PPT 里经常被混着用，我们把它们拆成"资源成本"和"切换时间"两笔账。
定时把数据备份到另一处（备份文件、快照、对象存储），灾备端不跑数据库实例。成本最低，基本就是一份存储钱加一台随时能开的机器。代价是恢复时间最长：要拉起实例、恢复数据、追日志、改连接串，天级到小时级，且数据能丢掉一整个备份周期。
灾备端数据库实例是启动状态，持续从主库拉取日志应用。切换时需要人工确认或半自动脚本介入，做一次角色切换再切流量。资源成本大概在生产的 1.3–1.5 倍（备机可以低配），切换时间能做到分钟级到十几分钟。这是我最推荐中型企业上的一档。
两个中心同时对外服务，流量按规则分流，数据双向同步。听着最美，代价最大：应用要做单元化改造、要解决主键冲突和分布式事务、要处理跨机房调用的延迟放大、还要有完整的流量调度体系。资源成本基本是 2 倍起，加上改造的人力，往往是服务器钱的几倍。
切换动作本身不神秘，就三件事：数据角色翻转（备库提主）、流量指向改掉（VIP 漂移、网关改指向、DNS 改解析、负载均衡摘除节点）、应用连接重置（连接池要能重连到新主）。DNS 这一层要特别注意 TTL 和客户端缓存，很多人切完了发现客户端还在往老地址打，那个感觉非常糟糕。
这话我敢说：如果你的业务不是金融支付清算、不是医疗核心系统、没有明确的监管条文要求异地灾备，那你大概率不需要两地三中心双活。
拿一个很土但有效的办法——算停机损失。业务停 1 小时，直接损失的订单金额 + 客诉与赔付 + 内部人力成本，估一个数，叫 L。再算容灾方案的年成本 C（服务器 + 带宽 + 存储 + 人力）。如果 C 明显小于"预计年故障时长 × L"，这钱就值得花；如果 C 比 L 还大好几倍，说明你上重了。
双活不是买两台服务器就完事。它要求你的应用层能接受"写可能发生在任意一侧"，要求你的数据模型有全局唯一 ID 和冲突解决策略，要求你的监控能区分"假死"和"真死"。中型企业普遍没有专门的分布式团队，最后的结果是：双活架构搭起来了，但因为不敢真的双向写，实际退化成"一边写一边读"，等于花双活的钱买了热备的能力。
三类：监管明确要求的金融、保险、医疗、政务与国企配套系统；清算和资金链路不能中断的业务；跨境业务——境内外各留一份，既是为了可用性，也是为了合规与访问速度。除此以外，"一地双机 + 异地异步备份"是性价比最高的落点。
RPO（Recovery Point Objective）说人话就是"出事之后，我最多能接受丢多少数据"，单位是时间。RTO（Recovery Time Objective）是"出事之后，多久必须恢复服务"。这两个指标不是你写在文档上的愿望，是被技术方案反推出来的结果。
复制方式：同步复制意味着主库事务要等备库确认才返回，理论上 RPO 接近零，代价是主库写入延迟被链路 RTT 拖住；半同步是折中（等一个从库 ack，超时后退化为异步）；异步复制主库不等，RPO 取决于备库落后多少。链路质量：带宽够不够、延迟高不高、丢包和抖动大不大，直接决定备库能不能追上。演练频率：不演练的架构，纸面 RPO 是 0，实际可能是"上次复制断了没人发现，已经落后三天"。
切换是手动还是自动：自动切换依赖健康检测和仲裁，快但容易误判；手动切换慢但可控。备机是不是热状态：冷机要拉起实例、加载数据、预热缓存，这几步能占掉 RTO 的一大半。流量切换路径：VIP 漂移最快，网关次之，DNS 最慢且受 TTL 与缓存影响。
天级档：定时备份 + 冷备机，RPO 按备份周期算（一天到几小时），RTO 数小时到一天。成本增量主要在存储和一台低配机器，通常是几千元/月量级（预估，以实际账单为准）。
小时级 / 十几分钟档：同城异步或半同步复制 + 热备机 + 半自动切换脚本。RPO 分钟级，RTO 十几分钟以内。这是"一地双机 + 异地异步备份"的典型交付水平，服务器成本大概是生产端的 1.3–1.6 倍（预估，以实际账单为准）。
分钟级 / 秒级档：同城同步复制 + 自动切换 + 双活网关。RPO 接近零，RTO 分钟以内。资源成本 2 倍起，叠加应用改造与长期演练投入，年成本往往比前两档高出一个数量级（预估，以实际账单为准）。
这里我不给具体数字，因为不同业务的数据量和链路条件差异太大。但你记住一个规律：每把 RPO/RTO 压一档，成本不是线性涨，是台阶式跳。
选复制方案，本质是在"一致性"和"复杂度"之间做交换。四种路线各有各的坑。
MySQL 的主从复制、半同步复制、MGR，PostgreSQL 的流复制（同步/异步模式）与逻辑复制，都属于这一层。好处是语义清楚——复制的是事务日志，备库是一个真实可读的实例，切换时角色翻转是标准动作。风险也清楚：异步模式下存在丢失窗口；大事务和 DDL 会造成明显延迟；主从之间可能出现数据漂移，需要定期做一致性校验。对绝大多数业务，数据库层复制是首选，别绕远路。
块设备级别的镜像（比如常见的分布式块存储镜像、DRBD 一类方案）对应用透明，不用改代码。问题是它对上层数据库状态一无所知——存储层认为"块一致"，不代表数据库打开后能正常恢复。真正的风险在于：复制中断后重新同步是块级全量比对，数据量大的时候非常慢；而故障切换后，数据库要跑一次崩溃恢复，这段时间是要算进 RTO 的。
应用在写入时同时写两个库，或者通过消息队列把变更投递到灾备端消费。灵活度高，可以做异构库和跨云。代价是要自己解决幂等、乱序、重复投递和最终一致性的所有问题，还要处理"一边写成功一边写失败"的中间态。除非你有很强的中间件团队，否则这条路最容易做成一个长期维护债。
附件、图片、静态资源、日志归档，这一类不走数据库，用目录同步工具（rsync 一类）或对象存储的跨区域复制功能。要点是：同步要有校验（不能只看退出码）、要处理删除语义（源端删了目标端要不要跟着删）、要限速避免把复制带宽吃满。很多事故里，数据库切过去了，但用户头像和合同附件全是 404，就是这一环没做。
一致性风险与回切难度放在一起看：数据库层复制的一致性最可验证、回切路径最成熟；存储层复制回切常常要重新全量同步；应用层双写回切时最怕消息积压和顺序错乱；文件同步回切要重新比对差异。这四个里面，我永远建议把核心数据交给数据库层复制。
脑裂（split-brain）说的是：主库和备库之间的复制链路断了，但两边都还活着。这时候如果自动切换逻辑把备库提成主，而老主其实还在接受写入——两边同时写入同一份业务数据，就是脑裂。等链路恢复时你会发现，两份数据都改过同一批订单，合并基本不可能。
因为"主库挂了"和"主库只是我看不见它了"这两种情况，从备库的角度看是完全一样的。网络分区、链路抖动、交换机故障，都能触发误判。自动切换做得越激进，误判概率越高。
三件事必须同时做。仲裁：引入第三方裁决点，两边互相看不见时，谁能联系上仲裁谁存活，联系不上的那一侧主动降级。写入保护：切换动作里必须包含"把老主的写入能力真正掐掉"这一步，不只是改个角色标记——可以是把老主的只读开关打开、把它的 VIP 摘掉、把它的服务端口关掉。业内管这套叫 fencing，说白了就是"确认对方真的不能写了，我才能写"。切换后不自动回切：链路恢复后先人工确认，不要设计全自动回切。
中型企业没必要追求全自动切换。我的建议是"半自动"：监控检测到异常后自动告警并把决策信息准备好（主库状态、复制延迟、最近一次一致性校验结果），由人点确认。RTO 从 3 分钟变成 8 分钟，换来的是不会脑裂。这笔交换对绝大多数业务都划算。
切换是"从 A 切到 B"，回切是"修好 A 之后，再把业务搬回 A"。大部分团队的演练只做前半段，于是真实故障里最狼狈的永远是第二天——灾备机扛着全量流量，CPU 打满，老主还没修好，谁也不敢动。
第一，把老主重建为新备库：它不是重启就能用，它的数据已经落后或分歧，通常要基于当前主做一次全量基线（备份恢复或快照克隆），再开始追增量。第二，反向同步追平：这期间主库还在写，复制延迟要追到可接受范围。第三，再次切换：又是一次角色翻转 + 流量切换，等于把风险再走一遍。第四，配置与状态同步：数据库参数、账号权限、应用配置、证书、定时任务、消息队列的消费者位点——这些不在复制范围内。
演练脚本里必须有一整段是"回切流程"，而且要真的跑通。只练切换不练回切，等于只练了上半场。还有一个反直觉的经验：切换脚本本身也要纳入演练。脚本里写死的 IP、过期的关键文件权限、换了版本的客户端工具，任何一个过期都能让脚本在真出事那天跑不通。
灾备机降配比是合理的，但降配要有底线。核心原则是：灾备机的 CPU 要能扛住"全量流量压在一台机器上"的峰值，而不是扛住平时的均值。
日常读写分离、备库只承担复制和少量只读查询的场景，灾备 CPU 可以做到主库的 50%–70%。但如果你的架构是"主库写、备库承担大部分读"，切换后所有读和写会同时压到一台机器上，这时灾备至少要给到主库的 80%–100%。一个更实用的判断方法：看主库过去三个月的 CPU 峰值利用率。如果峰值打到了 60%，那灾备给到 50% 配置，切换后利用率会直接冲到 100% 以上。
数据库的复制应用线程（MySQL 的并行复制 worker、PostgreSQL 的 recovery 进程）是需要真 CPU 的。灾备机核心数太少，会出现"日志收下来了但应用不过来"，复制延迟越堆越大，RPO 直接失控。我的经验是灾备机的物理核心不要低于 8 核，复制延迟敏感的业务建议 16 核起。主频这一侧，OLTP 场景（大量短事务、高并发点查）更吃单核性能，OLAP 场景（报表、批量统计）更吃核心数。
一万网络的裸金属里，E5-2698v4 双路（20 核 ×2）这一档我很常给客户做生产主库，核心数够、多线程并行复制跑得开，¥3999 起（以官网实时价为准）；灾备侧如果预算紧，E5-2620 这一档 ¥999 起（以官网实时价为准）可以承担异步复制和备份角色，但如果你的业务切换后必须单台扛全量峰值，灾备还是建议上到与主库同档或差一档，别省这点钱。
内存是容灾方案里最容易被砍、也最容易被反噬的一项。
生产库的内存里装着热数据（InnoDB 的 buffer pool、PostgreSQL 的 shared_buffers 加操作系统 page cache），命中率可能长期在 99% 以上。灾备机即使实例在跑，它的缓存内容也和生产库不完全一样——灾备库的查询模式不同，缓存的是它自己那套热数据。切换发生的一瞬间，新主的缓存命中率会掉下来，大量请求直接打到磁盘上。
典型链条是这样的：内存小 → buffer pool 小 → 切换后命中率暴跌 → 物理读暴涨 → NVMe 还能扛，SATA SSD 开始排队 → 慢查询堆积 → 连接池耗尽 → 应用超时 → 用户看到的不是"慢一点"，是"不可用"。也就是说，你在灾备机上省的内存钱，会在切换那一天以"业务中断"的形式还回来。
给一个可执行的口径：灾备机内存不低于主库的 70%，并且要保证"热数据集能装进 buffer pool"。热数据集怎么估？看生产库的监控里 buffer pool 的实际使用量（不是配置值），取峰值。生产库通常把 50%–70% 的内存划给 buffer pool，剩下的给连接、排序、临时表和操作系统。灾备机如果内存小，至少要保证 buffer pool 的绝对值不低于生产库的六成。另外记得关掉或严格限制 swap，数据库场景下内存交换基本等于雪崩。
结论先说：主库强烈建议 NVMe，灾备库可以用 SATA SSD，但要清楚代价。
数据库对磁盘的压力集中在两处：随机读写（索引查找、更新离散页）和顺序写（redo / binlog / WAL）。NVMe 的优势不只是带宽，更关键的是队列深度和 IOPS——高并发下 NVMe 能同时处理成千上万个请求，SATA SSD 在队列打满后延迟会明显上升。OLTP 业务在促销、结账、批处理窗口这些时刻，IO 压力是平时的几倍，主库用 SATA SSD 顶不住的那几分钟，就是用户感知到的"卡死"。
灾备库的写入模式相对友好：复制过来的日志是追加写，应用过程虽然有随机成分，但整体压力低于生产端。所以 SATA SSD 在"平时追日志"这个场景下是够用的。真正的风险在切换后与回切时：切换后它变成主库，要接住全量随机读写；回切时要追一大段积压的增量，随机写压力集中爆发。这两段时间恰恰是你最不能出事的时候。
所以我的建议是分档：预算紧的话，灾备用 SATA SSD 可以接受，但要留好"临时升配"的预案（比如服务商支持弹性升级或临时加盘）；如果业务的峰值 IO 本来就高，灾备直接上 NVMe，别在关键时刻赌。
容量规划要算四块：当前数据量 × 预期增长（按年增长率，留至少 18 个月余量）、日志空间（binlog / WAL，按日均增量 × 保留天数）、备份留存（全备 + 增量 × 保留份数）、冗余与维护余量（大表重整、加索引会临时吃掉空间，建议整体水位不超过 70%）。
举个算法例子：数据 800GB，日均增量 15GB，binlog 保留 7 天约 105GB，每周一次全备保留 4 份约 3.2TB（压缩后按 40% 算约 1.3TB），那么备份存储这一块就要单独准备 1.5TB 以上，而不是挤在数据库盘上。这个例子只是演示算法，你的实际数字要按自己的监控数据套。
快照也是省事的一环。一万网络提供每日 3 份免费系统盘快照、30 秒回滚，这个能力对容灾很实用——在动 DDL、做大批量更新之前先打一份快照，出问题直接回滚，比从备份恢复快得多。
这是我最想强调的一节。很多人算容灾预算只算服务器，结果上线三个月发现带宽账单比服务器还贵。
数据库复制、文件同步、备份上传，这三样都是每天稳定发生的上行流量。它的特点是"量不大但不停"，和网站访问那种波峰波谷完全不同。这个特点直接决定了计费方式的选择。
算法很简单：日均增量 = 日均 binlog / WAL 产生量 + 日均文件变更量 + 日均备份上传量（按备份周期折算）。binlog 的量在数据库上直接能查（按天统计文件大小之和），拿一周的均值，取最大值而不是平均值。文件变更量可以用目录同步工具的干跑（dry-run）模式统计一次。备份上传量按"单次备份大小 ÷ 备份周期天数"折算。
粗略换算：1TB 数据在 24 小时内传完，需要约 100Mbps 的持续吞吐（1TB ≈ 8×10¹² bit，除以 86400 秒）。但实际不能按 24 小时平摊——业务高峰期可能在几小时内产生全天 70% 的增量，而链路还要留余量给抖动和重传。经验做法是：把日均增量压缩到 4–6 小时的窗口内传完，再留 1.5–2 倍余量。比如日均增量 200GB，压缩后按 80GB 算，4 小时窗口需要约 45Mbps，留两倍余量就是 90–100Mbps 这一档。
结论很明确：异地复制这种持续稳定流，按带宽计费更合适；偶发的大批量回传（比如首次全量基线、季度全备归档），按流量计费更合适。按流量计费的问题在于，复制是每天都跑的，日均 200GB 一个月就是 6TB，流量费会稳定地出现在账单上，而且业务增长后费用线性上涨、没有上限。按带宽计费等于给这个成本封了顶，代价是峰值被限制住——所以一定要做限速与错峰：给复制任务设带宽上限，把大批量归档放到业务低峰。
复制链路开启压缩通常能省掉不少流量（文本类数据压缩比明显，已压缩的图片视频基本没用）。备份侧做增量或去重能进一步压低上传量。这两件事的成本是 CPU，收益是带宽，对绝大多数容灾场景都是划算的。
延迟这个参数，直接决定了你能用哪种复制方式。
同城两个机房之间的往返延迟通常在几毫秒量级。在这个水平上，MySQL 半同步、PostgreSQL 同步流复制才有实际意义——主库等一个 ack 的开销能被业务接受。同城的链路可以选择运营商提供的内网互联 / 专用链路 / 对等连接，也可以用加密的 VPN 隧道自建（配置简单、成本低，但吞吐和稳定性依赖公网质量，适合数据量不大的场景）。
跨省延迟通常在几十毫秒量级。这个延迟下如果强上同步复制，主库每一笔写入都要多等几十毫秒，高并发时吞吐会明显掉。所以异地这一层就老老实实做异步，接受分钟级的 RPO，把"零丢失"的期望留给同城那一跳。
同城灾备机房的选择标准，我总结成三个"不同"：不同电力（接入不同变电站或至少不同供电回路，一路市电检修不至于两个机房同时受影响）、不同运营商（避免同一家骨干网故障同时打穿两端，BGP 多线接入的价值就在这）、不同光缆路由。第三条最容易被忽略——两个机房直线距离 30 公里，但出入局的光缆可能在某一段走同一条管道沟，一次市政施工就把两个机房一起挖断。挑机房的时候，值得问服务商一句：这两个机房的骨干路由是不是物理分离的。
做跨境业务需要在境内外各留一份时，节点选择要考虑的不只是延迟，还有链路合规与访问质量。境内节点放大陆（华南、华东、华北、华西都有起步档），境外节点可以考虑中国香港、欧洲、美洲等节点。中国香港节点对内地访问质量好，延迟低，是跨境容灾里最常见的境外落点。
下面这张表按"方案形态"横向对比，价格一列的官网明示价标注了"以官网实时价为准"，推算出来的区间都标了"预估"。别把预估当报价。
| 方案形态 | 同城/异地可用区 | 复制链路与快照 | 工单响应 | 适用业务 | 价格（官网价 / 预估） |
|---|---|---|---|---|---|
| 单机房 + 定时备份（冷备起步） | 单节点，无异地 | 定时备份上传，无实时复制；每日 3 份免费快照、30 秒回滚 | 7×24 中文工单，平均 5 分钟响应 | 企业官网、内部系统、可容忍天级恢复 | 华南 ¥799 起 / 华西 ¥599 起 / 华东 ¥699 起 / 华北 ¥899 起（以官网实时价为准） |
| 同城双机热备（推荐主力档） | 同区域两可用机房，内网互联 / 专用链路，毫秒级延迟 | 数据库层半同步或异步复制；支持快照回滚 | 7×24 中文工单，硬件故障 10 分钟自动迁移 | 制造 ERP、医疗业务系统、中型电商与 SaaS | 主库 E5-2698v4×2 ¥3999 起 + 灾备 E5-2620 ¥999 起（以官网实时价为准）；两地月成本合计约 ¥6000–9000（预估，以实际账单为准） |
| 同城双机 + 异地异步备份 | 同城双节点 + 跨省异地节点，异地走加密 VPN 隧道或对等连接 | 同城半同步 + 异地异步，备份与快照跨区留存 | 7×24 中文工单，平均 5 分钟响应 | 金融配套、政务与国企配套系统、数据不能只放一地 | 异地节点华西 ¥599 起 / 华北 ¥899 起（以官网实时价为准）；含复制带宽的月成本约 ¥8000–15000（预估，以实际账单为准） |
| 两地三中心（同城双活 + 异地灾备） | 两城三节点，同城专用链路 + 异地异步，需第三方仲裁节点 | 同城同步复制 + 异地异步，双向同步需应用层单元化改造 | 7×24 中文工单 + 工程师 1 对 1 部署协助 | 支付清算、监管明确要求的金融与医疗核心链路 | 主库 E5-2698v4×2 ¥3999 起 ×2（以官网实时价为准）；整档年成本通常比同城双机高一个量级（预估，以实际账单为准） |
| 跨境双节点（境内 + 境外各留一份） | 大陆节点 + 中国香港 / 欧洲 / 美洲节点，BGP 多线 + CN2 GIA 回国 | 跨境异步复制，需注意合规与数据出境要求 | 7×24 中文工单，免费备案协助 | 跨境电商、出海 SaaS、境外分支机构系统 | 中国香港 E3 ¥1500 / ¥1599 起、欧洲 ¥1299 起、美洲 ¥1699 起（以官网实时价为准） |
| 容灾节点带算力需求（演练/分析/AI 辅助） | 与容灾节点同区部署，内网互联低延迟 | 快照克隆出演练环境，演练完即释放 | 工程师 1 对 1 部署 CUDA/cuDNN/TensorRT/PyTorch/TensorFlow | 需要在灾备侧跑报表、跑模型推理或做切换演练 | A100 40G ¥2800 起（以官网实时价为准）；算力侧按需弹性更划算（预估，以实际账单为准） |
容灾系统有一个残酷的属性：它的正确性只能靠演练证明，不能靠运行时间证明。一套三年没切过的容灾架构，可靠性是未知的，不是"三年都很稳"。
我的建议是按三层节奏走：季度做一次切换演练（真实把流量切到灾备端，跑一段时间再回切）、月度做一次恢复演练（从备份里真的恢复出一个实例，跑通业务冒烟）、每次重大变更后补一次（大版本发布、数据库升级、网络调整之后）。演练要安排在业务低峰，并且提前通知相关方——演练变成事故，多半是因为没人知道你在切。
三件事要做全。行数与校验和比对：用工具对主从做分块 checksum 比对（MySQL 生态里 pt-table-checksum 是常见选择），不要只比总行数，总行数相同但内容不同是完全可能的。抽样业务校验：挑几张核心业务表，对最近一段时间的数据做聚合值比对（订单总额、记录数、最大 ID）。恢复出来的库要做冒烟：恢复演练不是"恢复成功"就完了，要连上应用跑一遍核心流程。
演练报告里最有价值的字段是"实际 RTO"。从"决定切换"开始计时，到"业务冒烟通过"结束计时，中间每一段（检测、决策、切换、应用重连、缓存预热）单独记。连续记三四次之后，你会得到一个可信的数字，这个数字才能拿去和业务方谈指标。纸面上写的 RTO 是愿望，演练表里记的 RTO 是能力。
"备份成功"和"能恢复"是两件事。备份任务退出码为 0，只说明文件写出来了；文件损坏、备份的是不完整快照、恢复脚本依赖的工具版本对不上、恢复目标目录空间不够，这些只有在真恢复的时候才暴露。所以恢复演练一定要独立排期，别和切换演练混在一起——混在一起的话，一旦失败你分不清是切换的问题还是备份的问题。
结合上面讲的原则，给两套我自己最常推的组合。都是在深圳南山深耕了 19 年（成立于 2007 年）的一万网络（idc10000.net）体系里能凑齐的。
主库上裸金属 E5-2698v4×2，¥3999 起（以官网实时价为准），40 个物理核心做并行复制和峰值承载都够宽裕，NVMe 系统盘 + 数据盘，内存按热数据集配满；灾备侧如果预算紧先用 E5-2620 ¥999 起（以官网实时价为准）扛异步复制和定时备份角色，业务峰值高的话建议直接拉到与主库同档。两端走同城内网互联，延迟在几毫秒量级，MySQL 半同步或 PostgreSQL 同步流复制都能开起来。这套的价值在于：硬件故障 10 分钟自动迁移、每日 3 份免费快照 30 秒回滚、7×24 中文工单平均 5 分钟响应，出事的时候有人接电话，这个比什么都实在。自营机柜最快 1 分钟上架，扩容不用等一周。
在同城双机之外，再挂一个异地节点做异步备份与快照留存——华西 ¥599 起、华东 ¥699 起、华北 ¥899 起（均以官网实时价为准），成本増量很小，但把"城市级故障"这一类风险从不可接受降到了可接受。这一档不用追求高性能，硬盘给够、带宽给够就行，它的活儿是收日志、存备份、定期做恢复演练。记得给这个节点单独算复制带宽，别让它跟业务流量抢上行。
做跨境业务需要在境内外各留一份的，境外落点优先看中国香港 E3 ¥1500 / ¥1599 起（以官网实时价为准），BGP 多线 + CN2 GIA 回国，访问质量稳定；欧洲 ¥1299 起、美洲 ¥1699 起（以官网实时价为准）适合用户主要在当地的业务。如果灾备侧还要跑报表或跑模型推理，A100 40G ¥2800 起（以官网实时价为准）这一档可以按需弹性开着，演练的时候用快照克隆出环境，练完就释放，比常驻一台机器划算。免费备案协助、5–20G 免费 DDoS 防护这些也都在，能省掉一些琐碎的对接成本。
坑一：只买灾备机，不做演练。为什么坑——容灾系统的正确性只能靠演练证明，机器在那儿跑不代表能切。上线半年没切过一次的架构，真实可靠性是未知的，而且复制链路可能早就断了没人发现。怎么避——把季度切换演练写进运维排期，演练报告里记录实际 RTO，连续记几次形成基线。
坑二：异地带宽没算进预算，导致复制追不上。为什么坑——容灾立项时只批了服务器钱，复制流量走公网按流量计费，业务增长后账单失控，于是有人手动给复制限速，结果备库延迟越堆越大，RPO 从分钟级退化成小时级甚至天级。怎么避——立项阶段就用日均增量算出带宽需求，持续复制优先选按带宽计费封顶，大批量归档走错峰和限速。
坑三：忘记备库也要做备份。为什么坑——很多人以为"备库就是备份"，实际上主库的一次误操作（删表、错误批量更新）会原样复制到备库，两边一起坏。怎么避——在备库或异地节点上做独立的定时备份与快照留存，保留足够长的周期，并且定期做恢复演练。
坑四：切换脚本没人维护，真出事跑不通。为什么坑——脚本写完之后就进了归档目录，期间 IP 改过、磁盘路径变过、客户端工具升过级、密钥过期过，真到出事那天一跑就报错，人还得现场手敲命令，RTO 从分钟变成小时。怎么避——把切换脚本纳入演练必跑项，每次基础设施变更后重跑一次，脚本里不要写死会变的参数。
坑五：同城两个机房共用一条光缆沟。为什么坑——两个机房看着是分离的，但出入局光缆在某段走同一条管道，一次市政施工同时挖断，同城这一跳直接失效，架构退化成单点。怎么避——选机房时明确问骨干路由是否物理分离，同时确认供电来自不同回路、接入不同运营商（BGP 多线在这时候才有意义）。
坑六：只同步数据，不同步配置与证书。为什么坑——数据库复制只搬数据，不搬参数文件、账号权限、应用配置、TLS 证书、定时任务、消息位点。切换过去之后数据是对的，但服务起不来或者证书过期。怎么避——建立一份"非数据资产清单"，用配置管理或对象存储同步，每次演练时逐项核对，证书到期要有独立告警。
Q1：我们的业务到底要不要上两地三中心？
先别从架构出发，从损失出发。估一个"停 1 小时损失多少钱"的数字，再估方案年成本。如果监管没有明确条文、业务也不是支付清算链路，我的判断是大多数中型企业上"同城双机 + 异地异步备份"就够了，两地三中心留给真正被监管或有清算属性的系统。双活的隐藏成本不在服务器，在应用改造和长期演练的人力上。
Q2：RPO 我想做到零，是不是必须同步复制？
零丢失在异步复制下做不到，这是物理规律不是厂商能力问题。同步复制能让 RPO 接近零，但代价是主库每笔写入都要等备库确认，跨城几十毫秒的延迟会直接压低吞吐。所以现实的做法是：同城那一跳做同步或半同步追求低 RPO，异地那一跳老老实实异步，接受分钟级窗口，再用备份把更长周期的风险兜住。
Q3：灾备机的配置能不能比主库低？
能，但要有底线。CPU 可以降到 50%–70%，前提是你的读写没有都压在备库上；内存我建议不低于 70%，因为缓存冷启动是切换后最容易出事的地方；硬盘可以用 SATA SSD 替代 NVMe，但切换后和回切时的 IO 压力你要提前想好。判断标准只有一个：灾备机能不能扛住"全量流量压在一台上"的峰值，而不是平时的均值。
Q4：异地复制的带宽到底该怎么算？
先算日均增量：binlog/WAL 日产量 + 文件日变更量 + 备份上传量按周期折算，取一周的最大值而不是平均值。然后决定传输窗口，我一般按 4–6 小时传完来估，再留 1.5–2 倍余量。计费方式上，持续复制优先按带宽（成本封顶），偶发的大批量基线同步按流量（不用为峰值常买单）。别忘了给复制任务限速和错峰。
Q5：脑裂真的会发生吗？还是只是理论风险？
会发生，而且不少见。网络分区、链路抖动、交换机故障都会制造"主库好像挂了"的假象，自动切换逻辑如果只看健康检测就直接提主，两边同时写入就是必然结果。防的办法是三件套：第三方仲裁节点、切换时真正的写入保护（确认老主不能写）、以及不允许自动回切。中型业务我更推荐半自动切换，多花几分钟换一个不会脑裂。
Q6：为什么大家都说回切比切换难？
因为切换是"从 A 到 B"，回切是"修好 A、把 A 变成新的备、追平数据、再切一次"。老主修好之后它的数据已经分歧或落后，通常要重新做一次全量基线，再追增量——这段时间新主还在写。加上参数、权限、证书、定时任务这些不在复制范围内的东西要重新对齐，工作量比切换大得多。所以演练一定要包含回切，只练上半场的团队，第二天一定狼狈。
Q7：演练要做多频繁？每次都要真切吗？
我的节奏是：季度做一次真实切换（切过去、跑一段时间、再回切），月度做一次恢复演练（从备份真的恢复出一个实例并跑冒烟），每次重大变更后补一次。真实切换很重要，因为只有真切才会暴露脚本过期、权限缺失、连接池不重连这些纸面发现不了的问题。演练选在业务低峰，并且提前通知所有相关方，别让演练变成没人知道的事故。
Q8：预算有限，钱应该优先花在哪一项？
优先级我这么排：第一是备份与恢复演练（最便宜、兜底最实在），第二是同城热备机（解决最常见的单机房故障），第三是异地备份节点（防城市级风险），第四才是双活改造。千万不要反过来——先砸钱做双活，结果备份三年没验证过能恢复，这是我在不少客户现场见过的真实情况。
我见过太多"有灾备"的公司，机房里确实摆着两台机器，复制状态显示正常，但没人知道切成不成功、没人知道备份能不能恢复、也没人知道切过去之后系统扛不扛得住。这不叫有灾备，这叫买了灾备的硬件。
真正该做的是三件事：把指标从业务损失倒推出来，别从方案商的 PPT 出发；把硬件配比按"切换后单台扛峰值"来算，别按平时的均值省；把演练排进日历，把每次的真实 RTO 记下来。至于架构档位，多数中型企业停在"同城双机 + 异地异步备份"这一档，是理性而不是保守——把省下来的钱投在演练和备份验证上，收益比上双活大得多。
本文涉及的规格与价格参考自一万网络官网（https://www.idc10000.net/）相关页面，包括裸金属服务器、云服务器、GPU 算力与机房节点等公开信息；文中标注"以官网实时价为准"的为准官网明示档位，标注"预估"的均为按规格推算的区间，不代表成交价。架构、配比与带宽估算方法来自通用工程实践，具体选型需结合自身业务数据量、峰值负载与合规要求评估。具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
