把业务库迁到易科云的候选服务器后，历史订单已经同步，新增订单也能到达，偏偏修改地址、取消订单开始报错。这时先加核心、换线路，很可能买错东西。PostgreSQL逻辑复制需要知道旧记录在订阅端对应哪一行，首次拷贝和插入成功并不能替这项条件作担保。采购验收应把插入、更新、删除拆开，先证明行能被正确定位，再测持续吞吐和追赶时间。否则，一台看起来资源充足的新机器，可能在业务第一次修改旧订单时才暴露问题。
先把失败定位到哪一端
PostgreSQL官方发布文档说明，表要复制UPDATE和DELETE，必须配置复制标识；通常使用已有主键，也可以选择满足条件的唯一索引。没有合适键时可以使用FULL，把整行作为标识。INSERT不受同样条件限制。因此，验收只有“历史数据量一致”和“新增一条成功”，覆盖不了旧记录的变更路径。
应先保存应用收到的原始错误、发生时间、发布端表定义和发布操作类型，再去看订阅端日志。如果表被加入了会发布更新或删除的publication，但没有可用标识，相关操作可以直接在发布端报错。这和网络传输慢、订阅端磁盘忙不同：前者连原业务事务是否成功都要核对，不能统称为“复制延迟”。官方文档明确列出DEFAULT无主键、NOTHING和指定索引被删除等情况。
这一步的采购含义很直接：缺少复制标识是正确性门槛，增加CPU或带宽不能补出业务行身份。若原事务没有提交，恢复同步也不会凭空补回那笔修改；应用需要按自己的重试与业务核对流程处理。若发布端已成功、订阅端应用失败，则应按订阅端的具体错误处理，不能把两个方向混为一次故障。
选择主键、唯一索引，还是整行
已有稳定主键时，应先确认发布端和订阅端的相关定义，而不是为了消除一条报错就切到FULL。官方文档要求：发布端使用非FULL标识时，订阅端也要有由相同或更少列组成的复制标识。主键若只是新迁移时临时补出来的序号，还要验证历史行的映射，不能在两边分别生成后便假定编号一致。
选择USING INDEX也不是任意唯一索引都可以。ALTER TABLE文档规定，这个索引必须唯一、非部分、不可延迟，并且其列都带NOT NULL约束；删除该索引后，行为会退回NOTHING。交付时应把索引名称、列顺序、空值约束和后续维护责任一起记录。日后清理“看似重复”的索引，可能连带移除复制依赖，单独测试普通查询不会发现这个后果。
FULL能解门槛，采购账也会改变
FULL会记录旧行各列的值。但它不是适用于所有表的统一保险。PostgreSQL 18文档说明，订阅端查找行可使用满足要求的B-tree或Hash索引：索引不能是部分索引，最左字段必须是引用已发布列的普通列，而不是表达式。没有适合的索引时，查找可能很低效，官方因此把FULL定位为缺少其他方案时的兜底。此处依据本轮读取的18版文档，部署旧版时必须核对对应版本，不能照搬当前能力。
一个包含宽文本的订单详情表，如果大量更新仅改一个小状态字段，选择FULL之后仍要考虑旧行记录及订阅端定位的成本。这里没有商家测试，不能据此给出放大倍数或吞吐保证。可执行的比较方法是：取经过脱敏的真实行宽分布，在同样更新比例下，分别记录发布端新增日志量、订阅端每秒完成变更数、CPU和磁盘等待。正常时的平均值与最忙时段应分开，不用只有短小测试行的结果代表生产。
设业务持续产生每秒200次变更，故障后有12万次待应用变更，要求20分钟追平。以每次变更工作量相近、输入速率稳定为假设，所需持续应用能力至少是200加120000除以1200，即每秒300次；只做到每秒200次，积压不会缩短。这是采购门槛示例，不是易科云跑分。实际存在大事务、不同索引命中和宽行时，应按实测工作量重算，另留波动余量。
如果把FULL改为稳定的窄键后，订阅端应用能力明显提高，再比较服务器档位才有意义。反过来，身份条件已满足、索引查找合理，持续处理仍达不到追赶门槛，才应检查CPU持续使用限制、存储延迟和两端网络，再决定升档或拆分订阅任务。不要把所有改变一次做完，否则无法判断月费增加究竟换来了什么。
易科云入口能确认什么，订单还缺什么
本轮渠道通网站17返回了易科云推广入口，官网也可以读取。首页展示香港CN2、美西精品网和美西4837-ISP等产品入口，但渠道通没有该商家的结构化套餐记录。因此，本稿不把广告文案转换成已核实的核心数、可用内存、磁盘性能或数据库托管承诺；也没有验证当前库存、支付金额和续费价格。
下图保留官网香港产品卡片中的原价与优惠文案，仅说明首页展示内容。价格使用删除线，卡片本身没有写清完整配置和计费周期，不能把“25元”直接写成一台满足复制要求的数据库服务器月费。优惠码是否适用于目标订单、是否仅首期有效，都应到确认页核对。退款保障也需逐条阅读服务条款，不能仅凭首页短句假定任何原因均可全额退。
在先验证复制路径的前提下，可通过易科云套餐与下单入口（推广链接）查看候选配置。适合考虑的是能够自行维护PostgreSQL、确认具备所需系统权限，并愿意先做小规模验收的团队。若需要商家负责表结构设计、逻辑复制故障恢复或业务数据核对，则必须先拿到明确服务范围；VPS交付不自动包含这些工作。
总成本也应从单机月费扩展到两端资源和迁移工时：目标服务器、迁移期间并存的原机器、备份保留、必要外网流量，以及给订阅端建立或维护索引的时间。因本轮未获得可核验订单配置，不能填出总金额。建议比较同一验收目标下的两张报价，而不是比较广告起价：方案一保留现有行键并补齐索引，方案二采用FULL并购买更高配置。若第二种只是绕开数据建模工作，它增加的长期月费未必合理。
用一份变更验收单结束试用
先在隔离环境准备包含正常记录、重复业务字段、空值边界和宽行的样本，确认发布包含哪些操作，再对同一主键完成插入、普通字段更新、标识字段更新和删除。每次保存发布端提交结果与订阅端最终值，不以两边总行数相等替代内容核对。对失败事务和已提交但尚未应用的事务分别记账；这比只看订阅进程是否在线更能说明业务是否可迁移。
接着用接近真实更新比例的负载验证追赶公式，记录测试版本、表定义、索引、积压起点和恢复时长。若决定用FULL，还应核对列类型：官方限制文档指出，缺少默认B-tree或Hash操作符类的某些类型，例如point、box，可能使订阅端无法应用相关更新或删除；建立主键或复制标识可用于解决这类限制。没有拿业务表测试之前，不能仅根据建订阅成功签收。
最后给售前或交付人员的询问应具体到能落在订单上：是否有修改数据库参数及重启服务的权限；CPU是共享还是保证可持续使用，持续负载限制如何执行；磁盘和快照是否包含在报价中，快照恢复如何收费；两端复制流量怎样统计；退款窗口起点、扣费项目与不适用条件是什么。把这些答案与实际配置截图、变更验收记录一起保存，缺项就保留为未核实，而不是用商家宣传词代填。
接管写业务前还要处理复制范围之外的东西。PostgreSQL逻辑复制不复制DDL和序列状态，表结构变更需要另行协调；序列列中的数据可以复制，但序列自身仍需在切换时校准。这不是再买一档配置能解决的问题。到期能交出的应是可核对的记录：旧行修改已正确到达，积压在约定时间消除，切换后的新写入也不会因结构或序列遗漏失败。满足这些条件后，才有依据接受候选服务器及其长期费用。
核验资料
本轮于2026年11月2日读取商家首页及PostgreSQL 18官方文档；无商家性能实测，订单配置、价格及退款适用范围仍需付款前核对。
用户评论