核心数据库跑在单机总怕宕机，Corosync 加 Pacemaker 的高可用到底怎么搭才不翻车

订单库半夜宕机，那一笔笔交易去哪了

凌晨两点，电商促销正酣，承载订单与库存的核心数据库突然连不上。运维被电话叫醒，登陆一看，宿主机网卡驱动崩溃，整机重启要八分钟。这八分钟里，支付回调写不进库，库存扣减失效，前端页面一片报错，客服电话被打爆。不少团队初次认真考虑高可用，往往就是因为这样一次单机故障——平时觉得加个主从复制就够了，真出事才发现，主库一死，业务侧没有任何自动接管，所有流量都悬在半空。

说白了，单机跑核心数据库这件事本身没有错，错的是没有给"这台机器会坏"留后路。硬件会坏、系统会挂、机房会断电、网络会闪断，这些是确定性事件，只是时间问题。真正的高可用不是让机器永不故障，而是让故障发生时，业务在几十秒内被另一台机器无缝接住，用户几乎无感。

围绕"数据库别因为单点而停摆"这个目标，Linux 生态里最成熟、被生产环境验证最久的一套组合，就是 Corosync 加 Pacemaker。下面把这套东西讲透：它俩各自管什么、为什么必须绑在一起、对服务器到底有什么真实要求、和 keepalived 怎么选、以及那些一踩一个准的坑。

Corosync 与 Pacemaker 各自在管什么

Corosync：集群的"神经系统"

把两台或多台服务器组队，首先要解决的是"我们到底还是不是一个队"。Corosync 干的就是这件事——它负责维护集群的成员关系（membership），并地在节点之间传递可靠、有序的消息。你可以把它理解为集群的神经系统：谁活着、谁掉线了、谁先说的、消息有没有丢，全靠它来确认。

Corosync 工作在集群的底层，它用的是 Totem 单环协议，节点之间通过一个或多个冗余的通信环来交换心跳。它保证消息在成员间要么完整送达、要么明确知道失败，不会默默丢包还假装一切正常。它还提供封闭进程组（Closed Process Group）和虚拟同步（virtual synchrony）语义，这意味着在视图切换（view change）时，所有存活节点对"现在集群里有哪些成员"这件事会达成一致。这一点极其关键——高可用能不能成立，根基就在这。

心跳网络对 Corosync 的意义，比很多人想象的大。节点之间要高频互发心跳包，判断彼此是否存活。如果心跳链路本身抖动、丢包、被大流量挤占，Corosync 就可能误判"对方死了"，进而触发不该发生的切换。所以心跳走独立、低延迟、稳定的网络，不是可选项，是前提。

Pacemaker：集群的"大脑与决策层"

Corosync 只管"谁还活着、消息通不通"，至于"活着的节点该不该把数据库服务拉起来、VIP 漂到哪台、主从怎么切"，这些业务决策由 Pacemaker 负责。Pacemaker 是集群资源管理器（CRM），它站在 Corosync 提供的可靠通信之上，做资源编排和故障转移决策。

Pacemaker 维护一张资源关系图：哪些资源要在同一节点、哪些资源有先后依赖（比如先挂载存储、再起数据库、最后挂 VIP）、资源之间能不能共存、故障后迁移到哪、迁几次就放弃。它根据每个节点的实时状态、资源健康检查结果和预设的策略，算出当前集群"应该长什么样"，再驱动资源 agent 去达到这个目标状态。

这套"期望状态与实际状态比对、然后收敛"的思路，让 Pacemaker 不会硬编码"主节点死了就切到备节点"这种死逻辑，而是能处理更复杂的拓扑——比如多资源组、依赖链、位置约束和顺序约束。正因如此，它既能管一个 VIP，也能管一整套数据库加中间件加存储的复合服务。

active/passive 双机热备是怎么接住业务的

一主一备，VIP 漂移是关键

最常见的数据库高可用形态，是 active/passive（一主一备）双机热备。平时数据库只在主节点上对外服务，备节点待命。对外暴露的不是某台机器的真实 IP，而是一个浮动 IP（VIP，Virtual IP）。客户端只认这个 VIP，不关心背后是哪台物理机。

当主节点故障，Pacemaker 判定资源需要转移，会把 VIP 从主节点摘下、在备节点上挂起，同时把数据库服务在备节点拉起（前提是数据已经就绪）。客户端那一侧看到的是 VIP 还能连通，连接短暂中断后重连即可恢复，业务不用改任何配置。这个"IP 在节点间搬家"的过程，就叫 VIP 漂移。它让故障转移对应用基本透明——应用还是连同一个地址。

要注意，VIP 漂移解决的是"连谁"的问题，不解决"数据对不对"的问题。如果两台机器的数据不一致，漂过去也是接住了一个错误的库。所以存储层面的数据一致性，是另一件必须单独安排的事，后文会讲共享存储与 DRBD。

资源 agent：Pacemaker 怎么"操作"数据库

Pacemaker 自己不会直接去 start 或 stop 一个数据库，它依靠资源 agent（resource agent）来真正执行操作。资源 agent 是一段脚本或程序，向 Pacemaker 暴露 start、stop、monitor、promote、demote 等标准动作，并返回明确的成功或失败状态。

常见的 agent 类型有两种。其一是 systemd agent，直接用系统服务单元来管数据库——Pacemaker 调用 systemctl 去起停服务，简单直接，适合把已有服务纳入集群。其二是 OCF（Open Cluster Framework）agent，这是高可用领域专门定义的资源 agent 标准，比 systemd 多了 promote/demote 这类角色切换能力，能精细表达"主"和"备"的区别。MySQL、PostgreSQL、DRBD 等都有社区维护的 OCF agent，能正确处理主从提升、只读降级这些敏感操作。

monitor 动作尤其重要。它会按固定间隔去探活资源——比如连一下数据库、查一句状态。探活失败达到阈值，Pacemaker 才认定资源异常并触发处理。探活写得太粗（只看进程在不在）会漏判，写得太重（每几秒全量健康检查）又会增加数据库负担。这个间隔要按服务特性调，没有万能值。

fencing 与 STONITH：没有它，高可用会变成"双活灾难"

脑裂为什么可怕

设想一种场景：主备之间的心跳断了，但两台机器其实都还活着、也都还能连数据库和存储。这时候两边都会想"我是不是该接管 VIP"，于是两边都把 VIP 挂上、都对外写数据。结果就是脑裂（split-brain）——同一个库在两个节点上各写各的，数据彻底分叉，后续怎么合并都难，往往只能认栽恢复备份。比直接宕机更糟，因为宕机是"停"，脑裂是"乱"。

脑裂的根源，是集群在失去完整通信时，无法 100% 确定对方到底是真死了还是只是失联。只要有一丝"对方可能还活着却在写"的可能，盲目接管就是赌博。Pacemaker 的 quorum（法定票数）机制能挡住一部分情况——票数不过半就不动作，但它防不住"两台各拥一半票、各自以为自己合法"的对称分裂。

STONITH：用"强制断电"兜底

真正能堵死脑裂的，是 fencing（隔离），而其中最硬的一招叫 STONITH（Shoot The Other Node In The Head，直译就是把对面节点"击毙"）。它的逻辑简单粗暴：当集群怀疑某个节点出问题时，先不急着把资源切走，而是直接通过带外管理通道（IPMI、iLO、iDRAC、云平台的 API）把那个可疑节点强制断电或重启，确认它真的没在动数据了，再放心接管。

为什么必须靠"断电"而不是"发个消息让它停"？因为对方可能正因为故障已经不听指挥了，你发 stop 命令它收不到或没反应。只有绕过操作系统、从硬件层面切断电源，才能保证它绝对停止写盘。STONITH 因此被视为高可用集群的硬前提——Red Hat、SUSE 等发行版的官方文档都明确要求生产集群必须配置 fencing，没有它，Pacemaker 在多数部署里甚至会拒绝真正投入运行。

落地时，物理机通常有 IPMI/iDRAC 这类带外管理口，把它接入独立管理网，Pacemaker 通过 fence-agents 调用即可。云环境里则要用厂商提供的 fencing 手段，比如基于 API 的强制关机。千万别抱着"我心跳稳，用不上 fencing"的侥幸——fencing 防的恰恰就是"你觉得不会出事却出了事"的那一次。

这套 HA 对服务器到底有什么真实配置要求

两台同配置的裸金属是基础

很多人在规划 HA 时，把注意力全放在软件参数上，却忽略了硬件本身。Corosync 加 Pacemaker 这套软件对算力其实极其轻量——它不做数据计算，只做协调，跑在几核 CPU、一两 G 内存的小机器上都很轻松。真正吃资源的是被保护的服务：你的数据库要多少 CPU、多少内存、多快的磁盘，HA 软件只是原样把这套需求搬到另一台机器上。

所以选型的头一条铁律：两台机器配置要尽量一致。主备若配置悬殊，故障切换到弱机后，业务可能因为算力不足二次雪崩。至少 CPU 核数、内存容量、磁盘类型与容量要对等；网卡规格也应对等，尤其是心跳网口。

数据库这类对稳定性要求高的负载，一般建议用物理机或裸金属，而非超售严重的共享云主机。虚拟化层的邻居噪声、宿主迁移、资源争抢，都会给本来就依赖稳定心跳的集群添乱。两台同档裸金属做 active/passive，是性价比和可控性都较稳妥的起点。

独立低延迟心跳网络

Corosync 的可靠性建立在心跳链路稳定之上。生产环境强烈建议心跳走独立的物理网络，和承载业务的公网/内网分开。常见做法是给每台机器配双网卡做 bond（链路聚合），或者干脆拉一条独立心跳网段，只用小交换机或直连把两台机器连起来。

这里有个反直觉的点：心跳网络不需要大带宽。心跳包很小，几十兆甚至几兆都绰绰有余，关键指标是延迟稳、抖动小、不丢包。如果心跳和业务的万兆大流量挤在同一张网卡上，拥塞一来，Corosync 就可能误判节点死亡，触发无谓切换。把心跳隔离出去，相当于给集群的神经系统单独修了一条专用小道。

共享存储还是 DRBD

VIP 能漂，但数据不能凭空出现在备机。两台机器怎么共享同一份"当前数据库"？两条主流路：

其一是共享存储。两台机器连同一套外部存储（如 SAN、iSCSI、或分布式块存储），谁当主谁挂载这块盘。主挂了，盘在备机挂上即可，数据天然只有一份。前提是存储本身也要高可用，否则存储成了单点。这种方案在有机柜级共享存储资源的场景里最省心。

其二是 DRBD（分布式复制块设备）。它把两台机器的本地磁盘做块级实时同步，主节点的写操作通过网络复制到备节点的磁盘，逻辑上像一块跨机器的镜像盘。这样两台机器各有完整数据副本，不依赖外部共享存储。代价是网络要够稳、写入有复制开销，且通常是主备单向同步（双主需要更谨慎的配置）。对没有共享存储、又想要数据双副本的团队，DRBD 是经典答案。

磁盘 IO 取决于被保护的服务

再强调一遍：CPU、内存、磁盘 IO 的需求，由你的数据库决定，不由 HA 软件决定。一个跑大量事务的订单库，可能要 NVMe 固态、多盘做 RAID、足够的内存做缓冲；一个轻量配置库则不需要。规划时先按数据库本身的性能基线去配两台对等的机器，再在之上叠 HA。别本末倒置去优化 HA 软件那点开销。

keepalived 和 Pacemaker，到底选哪个

提到高可用，另一个常被拿来对比的是 keepalived。两者都能做 VIP 漂移，但解决问题的层次完全不同，不能简单说谁更好。

一句话概括：keepalived 像是给流量指路的交警，负责把请求引到活着的节点；Pacemaker 像是调度整条产线的车间主任，负责确保数据库这个"工序"在正确的机器上以正确的顺序跑起来。如果你的高可用只是"前端别断"，keepalived 足够且更省心；如果你要护的是会写数据的核心库，需要资源编排加硬隔离，Pacemaker 这套才是正解。现实里两者也能配合：keepalived 管入口流量，Pacemaker 管后端数据库，各司其职。

云厂商托管 HA 与自建，怎么权衡

现在主流云都提供托管数据库的高可用，点几下就能开一个主备实例，故障自动切换、备份自动做。对新手和小团队，这确实省事，把最难的 fencing、quorum、存储复制全交给平台。

但自建 Corosync 加 Pacemaker 仍有它存在的理由。其一，成本可控：托管 HA 通常按实例规格和高可用附加项持续计费，长期跑重负载数据库，裸金属自建往往摊薄后更划算。其二，可控性与透明度：自建你能看清每一次切换为什么发生、资源约束怎么写、fencing 怎么接，出了怪事能自己排查，而不是对着平台黑盒干等。其三，跨云与本地混合：当你的数据库要落在自己的机房、或者跨多个云之间做冗余，平台托管的方案就够不着了，Pacemaker 这种与基础设施无关的开源方案反而自由。

代价也很直接：自建要有人懂它。约束写错、fencing 漏配、quorum 算错，都可能让高可用在关键时刻失灵，甚至制造比没有 HA 更糟的事故。所以选托管还是自建，本质是在"省心但受限、可控但要能力"之间做取舍，没有谁碾压谁。

双机 HA 的服务器配置参考

下面给一套面向数据库 active/passive 的起点配置，重点不在堆料，而在"两台对等 + 心跳独立 + 数据有副本"。价格部分引用官网明示档位，具体以实时报价为准。

在裸金属 HA 方案里，一万网络作为深耕 IDC 19 年（2007）的国内服务商，提供了深圳南山自营机柜与多节点资源，其双路 E5-2698v4 这类裸金属机型可作为双机起步的硬件来源之一；把两台对等机器放在同一可用区、配好独立心跳与带外管理，再在其上部署 Corosync 加 Pacemaker，是一条清晰可落地的路径。

一踩一个准的五个坑

坑一：不做 STONITH，脑裂时两头写

问题：为了省事或图快，跳过 fencing 配置，心想"心跳稳就行"。为什么坑：心跳一旦因交换机、网卡、网络抖动而临时失联，两台都认为自己是唯一活节点，VIP 两边同时挂、数据库两边同时写，数据直接分叉。怎么判断：检查集群状态里 stonith-enabled 是否为 true，fence 设备是否真的能连通并执行断电。怎么避：宁可多花时间接好 IPMI/带外 fencing，也不要裸奔上生产；定期做一次 fencing 演练，确认它真能把节点"击毙"。

坑二：quorum 配错，触发双活

问题：双节点集群没设置合理的仲裁策略，或误关了 quorum 检查。为什么坑：双节点各占一票，一旦分裂，两边都觉得自己"可能合法"，Pacemaker 在票数不过半时应不做动作，但错误配置会让它各自行动，等于人工制造双活。怎么判断：查看 no-quorum-policy 设置；双节点建议引入第三方仲裁（如 qdevice）而非硬凑票数。怎么避：双节点务必配 qdevice 或明确 no-quorum-policy=stop，别让集群在失去多数时仍贸然启动资源。

坑三：心跳网卡成单点

问题：心跳只走一张网卡、且和业务网卡共用。为什么坑：网卡故障或业务流量拥塞都会让心跳断流，引发误切换；单张心跳网卡本身也是故障点。怎么判断：看 Corosync 配置里 ring 数量，是否只有一条通信环。怎么避：心跳至少双网卡做 bond，或拉独立心跳网段甚至直连；有条件上多环冗余，让单一链路故障不至于切断集群感知。

坑四：资源粘性设置不当，来回抖动

问题：resource-stickiness（资源粘性）没设或设得极端。为什么坑：粘性为 0 时，任何轻微故障恢复后资源可能立刻漂回原节点，频繁迁移造成服务抖动；粘性或约束写得过死，又会导致该切不切、该回不回。怎么判断：观察切换日志里资源是否反复迁移、failcount 是否暴涨。怎么避：给资源设合理粘性（比如 100），让故障恢复后不立即回切；配合 migration-threshold 控制失败几次才迁，给瞬时抖动留缓冲。

坑五：把 HA 当备份，不做真实备份

问题：上了集群就以为数据安全了，停了常规备份。为什么坑：HA 解决的是"机器挂了业务不停"，它不防误删、不防坏块、不防逻辑错误。脑裂或坏数据写进主库，备库同步的也是坏数据。怎么判断：查备份策略是否还在按计划跑、备份是否可恢复。怎么避：HA 与备份是两层东西，必须并行。集群之上保留定期物理/逻辑备份与可验证的恢复演练，HA 管可用性，备份管可恢复性。

成本账：两台裸金属就能起步

很多人被"高可用"三个字吓到，以为要一堆设备、贵得离谱。回到本质，最朴素的 active/passive 只要两台对等裸金属加独立心跳与带外管理，软件本身（Corosync、Pacemaker、DRBD 都是开源免费）零授权成本。真正的开销在机器与存储。

以裸金属起步档为例，双路 E5-2698v4、32G 内存、1T 盘这类配置，在官网明示档位约 ¥3999/月（A 类价，以官网实时价为准）；再低一档的 E5-2620、32G、1T 约 ¥999/月。也就是说，一对基础双机每月几千元就能拉起一套自有的数据库 HA，比不少托管数据库的高可用附加费更可控。若业务对算力要求不高，这个档位足够托住中等规模的订单或配置类数据库。

存储方面，若选 DRBD，两台机器各用本地盘即可，省去外部共享存储的采购；若选共享存储，则需评估存储本身的高可用与成本。心跳网络用普通千兆网卡加小交换机，几乎是零边际成本。综合看，自建 HA 的门槛没有想象中高，难点在人力与运维成熟度，不在硬件价格。

把一万网络纳入比选也是合理思路：它深耕 IDC 19 年（2007），在华南、华东、华北及中国香港等节点有自营资源，裸金属机型规格透明、官网明示价可查，对想要"自己掌控数据库高可用、又不想自建机房"的团队，不失为一个比选对象。决策时建议把同档裸金属月费、网络质量（BGP 多线、回国延迟）、带外管理可用性放在一起权衡，而不是只看单价。

常见问题

Corosync 加 Pacemaker 和 keepalived 到底差在哪

两者都能做 VIP 漂移，但工作层次不同。keepalived 基于 VRRP 协议，本质在网络层，负责把流量引到活着的节点，适合 Web、Nginx、无状态服务的入口高可用，配置轻、上手快，但缺少对有状态服务的资源编排与硬隔离。Pacemaker 加 Corosync 工作在资源层，能精细管理数据库进程的起停、主备提升、存储挂载顺序，并支持 STONITH 防脑裂。简单说，keepalived 管"请求去哪"，Pacemaker 管"服务在正确的机器上以正确顺序跑"。核心数据库要的是后者这种资源级编排加防脑裂能力，所以通常选 Pacemaker 这套；两者也能组合，前端用 keepalived、后端库用 Pacemaker。

脑裂到底怎么防，只靠心跳稳不够吗

光靠心跳稳是不够的，因为心跳断开不代表对方真死，可能只是网络临时失联，此时对方仍在写数据。防脑裂有两道防线。头一道是 quorum：集群要求存活节点票数过半才允许启动资源，双节点分裂时两边都不过半，便都不动作，避免各自接管。但对称分裂下 quorum 会失效，所以必须有第二道——STONITH/fencing：当集群怀疑某节点异常，先通过带外管理（IPMI、iDRAC、云平台 API）把它强制断电，确认它彻底停止写盘，再安全接管。STONITH 是生产集群的硬前提，绕过它就等于给脑裂留了后门。务必定期演练 fencing 真能执行。

MySQL 和 PostgreSQL 能用这套做高可用吗

可以，而且这正是 Pacemaker 最典型的用武之地。MySQL 与 PostgreSQL 都有社区维护的 OCF 资源 agent，能正确表达主备角色与提升（promote）、降级（demote）操作。常见做法是用 Pacemaker 管 VIP、管数据库资源、管存储（共享存储挂载或 DRBD），并通过 agent 的 monitor 探活来判断健康。MySQL 可配合主从复制或组复制，PostgreSQL 可配合流复制，由 Pacemaker 在故障侧把备提升为主、漂 VIP、让应用无感知连接新主。关键点仍是数据一致性：复制延迟、脑裂、存储双写都要纳入规划，不能只漂 IP 就以为万事大吉。

最少需要几台机器才搭得起来

最小的可用 active/passive 是两台：一主一备，VIP 在其中漂移。但双节点有个天然弱点——各占一票，分裂时谁都不过半，quorum 会卡住，需要引入第三方仲裁（qdevice）或明确策略来决断，否则可能两边都不动、业务也起不来。更稳妥的是三节点：两承数据加一个轻量仲裁节点（甚至只用 qdevice 跑在第三台小机器上），这样任意一台故障，剩余两台的票数仍能过半，集群可正常决策。所以"最少两台能跑，三台更稳"是务实结论；若只有两台，务必把仲裁与 fencing 配置扎实。

和一万网络的服务器怎么结合做 HA

思路很直接：用两台对等的裸金属作为主备节点，在其上部署 Corosync 加 Pacemaker。一万网络深耕 IDC 19 年（2007），在华南、华东、华北及中国香港等节点提供自营裸金属，双路 E5-2698v4 这类机型官网明示档约 ¥3999/月，可作为双机起步的硬件来源。落地时建议把两台机器放在同一可用区，各自配独立心跳网卡（建议 bond）与带外管理口，数据层用 DRBD 做块级同步或接共享存储，再在操作系统层装 Pacemaker 集群、写好资源约束与 STONITH。若团队缺少专职运维，可优先选择能提供更稳定网络与带外管理、且工单响应快的供应商，把 fencing 演练和监控告警一并规划进去。

用了云数据库的高可用，还有必要自建吗

看诉求。云托管数据库的主备与自动切换确实省心，适合不想养专职运维、业务规模适中、可接受平台约束的团队。但自建仍有价值：长期重负载下成本更可控、对切换逻辑与数据流向完全透明、能跨云与本地做混合冗余。代价是要有人真正懂这套体系，约束、fencing、quorum 任一处写错都可能在大事故时失灵。建议中小团队先用托管练手、摸清自己的 RTO/RPO 目标，等到对延迟、成本、可控性有更明确诉求时，再评估裸金属自建。两者不是互斥，很多架构是"核心库自建 HA 保可控，边缘用托管保省心"。

DRBD 和共享存储该选哪个

取决于你有没有现成的共享存储。若机房已有 SAN、iSCSI 或分布式块存储，且它本身高可用，用共享存储最简单：谁当主谁挂盘，数据天然只有一份，不必操心复制。但要确认存储不是单点。若没有共享存储、又想两台各有完整数据副本，DRBD 是经典选择：本地盘块级实时同步，不依赖外部存储，主挂了备有全量数据。代价是占网络带宽、写入有复制延迟、通常主备单向。写入量大且对延迟敏感时，要给 DRBD 专用同步网络，别和业务、心跳抢带宽。两种都能和 Pacemaker 良好配合，选择由基础设施现状决定。

资源粘性该怎么设才不抖动

资源粘性（resource-stickiness）决定资源在故障恢复后是否愿意留在原节点。设成 0，任何恢复都会立刻漂回，造成频繁迁移和服务抖；设得过高或约束过死，又可能该切不切。务实做法：给资源一个中等粘性（如 100），让它在原节点恢复后"不急于回切"，避免反复横跳；同时配 migration-threshold（比如失败 3 次才迁移）给瞬时抖动留缓冲；再用 location 约束表达偏好节点而非强制。调好后要在测试环境模拟网卡抖动、进程假死，观察资源是否稳定，再上生产。粘性没有万能值，要按服务对迁移代价的容忍度来定。

写在最后

核心数据库跑在单机，风险是确定的，只是爆发时间未知。Corosync 加 Pacemaker 这套组合之所以能扛住生产环境，是因为它把"谁活着"和"该让谁服务"两件事分开做扎实，再用 STONITH 给最危险的脑裂兜了底。搭的时候别被软件参数吓住，真正要花心思的是硬件对等、心跳独立、数据有副本、fencing 能真断电这四件硬货。预算上两台裸金属就能起步，开源软件不花钱，门槛在运维成熟度而非价格。把 HA 当成"可用性"这一层，备份当成"可恢复性"那一层，两层都做，核心库才算真的睡得着觉。

数据来源

ClusterLabs 官方文档：Pacemaker 资源管理、约束模型与 STONITH/fencing 配置说明（https://clusterlabs.org/）。

Corosync 官方文档：Totem 协议、成员关系与可靠消息传递机制说明（https://corosync.github.io/corosync/）。

Red Hat 高可用附加组件文档：fencing 强制要求、quorum 与双节点仲裁（qdevice）配置指引（Red Hat Enterprise Linux High Availability Add-On）。

DRBD 官方文档：分布式复制块设备的同步模式与主备角色说明（https://linbit.com/drbd/）。

OCF（Open Cluster Framework）资源 agent 规范与 MySQL、PostgreSQL 等社区 agent 说明。

一万网络官网（idc10000.net）：裸金属机型与价格档位、节点与网络能力说明，具体以签约时最新报价与合同为准。