数掘科技数据库锁住该升CPU吗？预备事务与协调恢复先验什么

数据库还有空闲CPU，订单更新却排成队，这时给数掘科技节点加核心未必能缩短等待。如果应用使用两阶段提交，已经进入预备状态的事务会在客户端离开后继续存在，持有的锁也可能继续挡住其他事务。采购前先查有没有遗留预备事务，再追溯协调器能否作出最终决定，比直接把慢查询归因于共享硬件更有用。这里讨论的是订单系统准备采用数掘科技服务器时的验收方法，没有该商家的节点实测，也不把通用数据库能力当作套餐承诺。

先把“已经准备好”与“已经提交”分开

PostgreSQL的准备事务命令用于两阶段提交：数据库完成第一阶段后，把事务状态存到磁盘，使其可以在当前会话之外被提交或回滚。准备后的事务不再绑定原来的会话，后续需要使用对应事务标识作最终处理。官方还明确指出，预备事务继续持有原来的锁，并且长期不处理会干扰清理，因此不应把准备事务当作普通的事务保存功能。

这解释了一种容易误购的现场：应用连接已经消失，业务仍被挡住；监控上的活跃查询不多，换一台更多核心的服务器却没有解除锁依赖。更多资源可以加快获得执行机会后的计算，不能替协调器决定一笔跨系统交易究竟提交还是撤销。只要等待链的根因仍是未决事务，扩CPU并不能完成那个业务决定。反过来，如果并不存在预备事务，或者等待来自正常的大批量写入，就应转去核查实际锁链和执行计划，不能仅凭本文场景认定故障。

一条时间线比单张负载图更能解释故障

验收环境可以用测试账户完成一次受控演练：业务发起跨库操作，协调器让参与方进入准备状态，然后人为中断协调器到参与方的后续通信。记录准备时间、业务请求结果、仍被阻塞的操作及恢复协调器后的处理过程。这是建议执行的测试，不是已经发生在数掘科技上的结果。演练必须使用隔离数据，并事先准备恢复办法，不能直接在生产订单上随意中断。

图中的约束关系只是机制示意。定位时需要把应用的全局事务号与数据库预备事务标识对应起来；仅凭一段标识看起来很旧，无法确定它对应的交易已经失败。协调器可能在恢复过程中重试最终决定，人工过早回滚会让数据库状态与支付、库存或其他参与方不一致。数据库管理员需要的是可核对的业务决定和可重复执行的恢复流程，而不是看到锁就清除。

把未决时间写进验收门槛

官方视图pg_prepared_xacts提供事务标识、全局标识、准备时间、所属用户及数据库等字段，可以用于清点等待最终处理的事务。验收记录至少保存每笔的存续时长、对应业务号和负责人，再检查协调器日志中是否已有最终决定。若业务系统设计中根本没有两阶段提交，却出现预备事务，首先确认是谁开启了它，而不是先提高允许的数量。

一个可操作的门槛是：由业务确定正常协调时限，再为超时事务设置告警和人工升级路径。假设设计允许协调器在故障后十五分钟内恢复，监控可以分别记录接近期限和超过期限的事务；十五分钟是这里的设计示例，并非数据库默认值、商家服务等级或通用安全上限。期限只能触发调查，不能自动证明应当回滚。自动处理必须建立在协调器保存的最终决定上。

容量也可以算清楚。假设每秒有两笔跨库交易进入准备状态，协调器短暂不可用九十秒，并且期间没有任何事务完成最终处理，那么积压会增加一百八十笔。这只是到达率乘以停顿时间的上界示例，不包含原有积压和流量突增。恢复后若最终处理速率每秒五笔，而新增仍为每秒两笔，净消化速率每秒三笔，一百八十笔积压理论上还需六十秒。只有处理速率持续高于新增速率，扩大槽位才可能换来可恢复的缓冲时间。

可配置数量不等于业务可以无限等待

PostgreSQL的max_prepared_transactions控制同时可处于预备状态的事务数量；设为零会禁用预备事务。官方资源配置还要求，若使用备用服务器，该值应不低于主服务器，否则某些查询在备用端可能不被允许。具体版本和托管权限必须核对，不能把可修改主机配置与可修改数据库参数混为一谈。没有使用两阶段提交的应用，不应为了“预留性能”随意开启并增大这个值。

允许数量过小会让故障期间的新交易更早失败，数量加大又可能把更多业务留在持锁状态。采购评估应同时观察受影响的行或表、后续请求等待时间、事务日志与磁盘增长、清理受阻的持续时间。这里没有给出一个把事务数换算成内存大小的固定比例，因为事务触及的数据和锁数量不同，统一比例会造成假精确。应拿代表性订单路径做测试，再把实际峰值计入整机余量。

买主备节点时，协调器也需要被采购

数掘科技的推广入口来自本地保存的渠道通网站17接口响应，采集快照日期为2026年10月30日。本轮实时接口超时，尚未同步核实当前价格、库存、数据库托管权限、备份与故障接手范围；因此这里没有给出套餐价格，也不宣称购买节点就获得跨系统事务协调服务。需要询价时可通过数掘科技服务器推广入口：核对节点与管理权限查看商家页面，这是推广链接，最终配置和条款以订单确认内容为准。

如果应用已经有能持久记录决定的协调器、明确的业务标识映射和故障恢复演练，自主管理的数据库节点可以作为候选；采购重点是权限、可靠存储、主备配置一致性和支持边界。若团队只希望把现有单库应用迁上去，却没有跨系统一致性设计，也没有处理未决事务的人，额外购买两台机器不会补齐这些职责。这个场景更适合先简化交易边界或采购明确包含相应管理责任的服务。

图中两条路径对应需要共同完成决定的参与方，而非某家服务器的真实架构。协调器与数据库若放在同一台主机，机器故障时可能同时丢失决策入口和可用节点；分开部署能减少这种故障重合，但会增加网络、监控和维护成本。不能只把两台节点的月租相加就称为完整方案。还应纳入协调记录的备份、恢复演练工时、跨区传输和发生不一致时的人工处置成本。

下单前让商家逐项回答责任边界

向商家确认能否自行修改数据库启动参数和重启服务、主备节点是否允许按要求配置、存储故障后的数据恢复由谁负责，以及售后是否只覆盖主机可达。若购买的是托管数据库，还要问是否支持预备事务、允许的数量、故障切换后怎样保留未决状态。退款或迁移条款没有核实就应保留为空，不能拿技术演练成功推导商家会承担业务不一致损失。

向自己的应用团队确认另一组问题：最终决定在哪里持久保存、重启后怎样找回、重复执行提交如何识别、失去协调器时由谁批准人工处理。这些答案决定需要购买多少节点、多少磁盘与多少运维支持。验收材料应包含一笔完整的故障演练时间线、一份预备事务与业务号的对应记录，以及恢复后业务一致性的核对结果；缺少其中任一项，都应先补证据，再讨论升档。

资料来源

PostgreSQL官方：准备事务

PostgreSQL官方：预备事务视图

PostgreSQL官方：资源限制