为韩国业务采购VPC.kr服务器时，如果数据库主机的磁盘持续上涨，而备用节点已经离线，先加一块盘可能只换来更晚的一次告警。PostgreSQL复制槽会替尚未追上的接收端保留日志；保留量没有合适边界时，备用节点的一次故障就可能转化为主库的容量压力。采购决定应围绕能够容忍的断连时间和重新建立副本的代价展开。本文讨论自行管理的PostgreSQL，不假定VPC.kr提供托管数据库，也没有进行该商家的性能实测。
副本停了，主库还需要为它留多久的位置
PostgreSQL官方复制参数文档明确，max_slot_wal_keep_size限制复制槽在检查点时可以保留的WAL文件规模；默认值为-1，即允许无限量保留。设置有限值后，如果槽需要的起点落后太多，所需日志可能被移除，接收端就可能无法继续复制。因而这项配置同时牵涉主库可用空间与副本恢复方式，不能直接套一个“安全数值”。
复制槽造成的保留，与业务表本身增大不是同一种增长。业务可以不断更新已有记录，最终表大小变化有限，但这些修改仍会产生WAL。看到表目录没有明显变化就判断磁盘报警误报，会遗漏日志目录的消耗。排查时应同时记录文件系统剩余空间、WAL目录实际占用、各槽需要的最早日志位置和接收端状态，观察一段有代表性的写入负载，而不是只留一张空闲时刻的容量截图。
主库是否还有备份、旧日志是否完成归档，也应另列检查项。官方WAL文档说明，启用归档时，日志需要先成功归档才能回收或移除。因此删除一个不用的复制槽后空间仍未马上下降，并不能反推槽没有影响；还可能存在归档保留、检查点节奏和其他槽的约束。先认清谁仍需要最旧的一段日志，再决定保留多少空间，比把磁盘总容量翻倍更接近问题本身。
一小时断连能欠下多少日志
下面是一份规划用的假设账，所有数值均为示例，并非VPC.kr实测或套餐承诺。假设写入高峰每秒产生8MiB WAL，副本断连60分钟，那么该时段新增日志约为8×3600＝28800MiB，即28.125GiB。若主库可供这类积压使用的空闲空间只有40GiB，并预留10GiB应对业务数据、临时文件及处置过程，30GiB日志预算在同样速率下约能支撑64分钟。这里用GiB和MiB保持二进制单位一致，不把商家标注的GB磁盘直接当作同样大小的可用文件系统。
这个64分钟不是可以放心等待的告警时间。值班人员确认、连接故障排查和采取措施都要时间；如果这些步骤合计需要20分钟，报警必须更早触发。还应给突发写入留余地：一次批量导入改变的是日志产生速率，平均日用量会掩盖这一段压力。可执行的门槛是：预计剩余可用时长，应大于发现、响应和完成处置所需时长之和。算不出后者时，先把恢复演练做完，不能把报警阈值当作已经交付的保障。
连上以后，要靠净追赶速度归还欠账
断线期间留下28.125GiB日志，恢复连接后并不等于积压立刻清零。再假设接收端持续处理能力为每秒20MiB，主库仍以每秒8MiB产生新日志，能够消化旧账的净速度只有每秒12MiB。28800MiB除以12MiB每秒，约为2400秒，也就是40分钟。若端到端处理速率只有每秒6MiB，积压反而会继续增加。此时更大的主库磁盘能延长时间，却无法让副本追平。
这里的处理能力需要沿完整链路验证。网络带宽够用，接收端磁盘或回放过程仍可能较慢；链路传得快，也不代表业务读到的数据已经更新。规划时可以把接收、持久化和回放分别记录，再用实际限制恢复的阶段安排预算。验收应包含一段受控断连，观察恢复后的积压斜率是否转负，以及业务允许的落后程度能否按期限恢复。生产环境不应为了演练直接拔掉唯一可用副本。
限制保留量之前，先决定副本能否重建
给槽设置有限保留量，可以把“尽力保住副本连续性”改成“达到边界后优先保护主库空间”，但它不是数据库目录的硬容量配额。官方定义把参数生效的观察点放在检查点，并说明超过条件可能移除接收端需要的日志。不能把限额设到距离文件系统耗尽只剩很薄的余量，再假设每个字节都会在越线瞬间停止增长。
采取这项取舍前，应明确失去日志后的重建流程：需要传多少基础数据、由谁发起、是否要临时保留旧副本、重新上线前怎样核对状态。如果副本是报表用途，允许长时间重建，有限保留通常更容易纳入运行方案；如果它承担严格的恢复目标，就需要更充足的存储和更可靠的恢复链路，或重新设计容灾方式。副本承担什么责任，决定采购边界，不能只凭“主从已经连通”验收。
监控也要保留状态含义。pg_replication_slots文档列出的wal_status中，lost表示槽已经不可用；unreserved与lost含义不同，前者不能被当成已经永久失效。safe_wal_size表示还能写入多少WAL而不使槽面临进入lost状态的风险；槽已经lost，或者保留参数为-1时，它都可能为空。 空值不能解释成还有无限的安全磁盘，它甚至无法单独区分这些原因，必须连同参数、槽状态和实际空闲空间一起判断。
对于长期闲置的槽，可依据部署版本评估空闲失效机制。当前读取的PostgreSQL 18文档说明，idle_replication_slot_timeout默认零，即关闭该失效机制；触发失效同样与检查点有关，并且存在适用范围限制。这不等于所有旧版本都有该参数，也不等于一个仍连接但跟不上的接收端能靠空闲超时治理。先核对已安装版本和实际槽类型，再安排配置变更。
把这份恢复账交给VPC.kr询价
渠道通2026年10月30日保存的推广资料将VPC.kr列为韩国基础设施候选商家。本次渠道通实时接口、推广跳转和商家首页均未在请求时限内完成响应，因此以下采购讨论使用接口采集快照，没有确认现价、库存、节点或服务限制的变化；文中的计算也不代表其某一档套餐的容量或速度。尤其不能把资料里的网络宣传转换成持续复制吞吐或故障恢复保证。
若团队需要在韩国部署自管数据库，并能管理操作系统、备份与复制，VPC.kr可以进入询价名单，前提是订单确认可用磁盘、扩容方式和恢复管理条件。若需求是商家负责数据库故障切换、按明确恢复目标交付服务，现有资料不足以证明它符合要求，应要求单独的托管合同或比较其他已确认的服务。应用可以使用哪国节点，与数据库副本是否满足恢复目标，是两项不同的验收内容。
在付款前，向商家逐项确认：磁盘标称容量和系统可用空间分别如何计量；是否能在线扩容、需不需要停机以及扩容后如何计费；网络流量是否把副本重建传输计入额度，超额后如何处理；宿主机故障时能否通过独立控制台恢复；快照是否另收费以及怎样导出；订单的退款范围和验收期限是什么。答案应对应具体产品和账单周期，不能用首页上的一般性表述代替。未答复的项目保留为未确认，而非推定免费或不限量。
总成本也不只是一台主库的月费。至少把主库与副本租金、额外日志空间、异地备份、重建传输以及维护工时分别列账。若临时扩盘需要升级整档套餐，还应计算连带增加的固定支出；若重建期间要保留两台接收端，则要计入交叠费用。没有最新报价时保留这些项目，等待正式报价后填入，胜过用旧价算出一个看似精确的总额。
需要取得最新订单条件的读者，可通过VPC.kr服务器推广入口，查看并向商家确认当前方案联系商家；这是推广链接，本轮未核实跳转终点的实时可达性。下单前先取得“可容忍断连时间、净追赶能力、超限后的副本重建步骤”三项验收约定。商家若只能给出磁盘和端口数字，团队仍需自行补齐这份恢复方案，不能把采购完成当作容灾交付完成。
用户评论