Geth 1.17.5升级要改什么？

Geth 1.17.5不是只有一串错误修复。对节点运维影响最大的两项变化分别落在运行时内存和磁盘数据库：默认GOGC从20变成50，全新Pebble数据库开始使用v2格式。它们都随同一版本出现，却不应在同一个不可回滚动作里处理。

先把版本升级和分叉激活分开

go-ethereum v1.17.5是维护版本，官方推荐所有用户升级，并继续为后续Amsterdam硬分叉实现功能；发布版本不等于相关分叉已经在主网激活。

维护版本包含Amsterdam相关实现，目的是让客户端代码为后续协议演进做准备，不代表这些EIP已经在主网启用。升级验收应以当前网络链配置、官方发布说明和节点实际日志为准，不因二进制包含代码就手动设置未知的fork覆盖参数。

先记录旧版本号、启动参数、数据目录、数据库后端、链头、peer、磁盘与内存基线，再替换二进制。若使用容器，保存不可变镜像摘要；若使用包管理器，记录软件源和回滚包。这样才能把升级后的变化与原环境对照。

v1.17.5把默认GOGC从20改为50，以更高潜在内存峰值换取更少GC开销；需要旧行为的节点可显式设置—gogc=20。

GOGC控制Go运行时相对上次存活堆大小触发下一轮垃圾回收的目标。默认值提高，通常意味着垃圾回收触发更少、CPU开销可能下降，但进程允许堆增长得更大，因此内存峰值可能升高。它不是“多分配30%内存”的固定公式，实际结果取决于缓存、同步阶段和RPC负载。

观察项	升级前基线	升级后至少比较	异常动作
RSS与heap	日常与高峰	同一负载窗口	接近容器上限先降风险
GC CPU与暂停	进程指标	P50、P95与累计CPU	判断是否真的减少开销
链头与导入速度	slot与block延迟	是否出现持续落后	排除共识层和磁盘问题
OOM与重启	历史事件	系统日志和容器事件	必要时显式—gogc=20

内存预算紧张的节点可以显式设置—gogc=20保留旧行为，但应把它写进systemd、容器或配置管理，而不是临时终端参数。恢复旧值后继续观察，避免把数据库压实或同步高峰误判成GC回归。

全新启动的Pebble数据库使用v2；已有Pebble v1数据库会继续兼容回退到v1，不会只因升级二进制就自动改写格式。

全新数据目录采用Pebble时可使用v2；已经存在的Pebble v1库会以兼容方式继续打开，并不会仅因二进制升级就自动重写全部格式。LevelDB用户也不会凭空变成Pebble。运维人员应查看启动日志和数据目录，而不是只看—db.engine参数猜测当前状态。

Geth数据库后端可通过—db.engine选择pebble或leveldb；已有数据库类型与格式会影响实际打开行为，不能只看启动参数猜测。

先区分三类实例：现有LevelDB、现有Pebble v1、全新或已经迁移的Pebble v2。只有第二类涉及显式格式升级决策。若团队还没有评估收益、维护窗口和恢复方案，兼容回退允许先完成二进制升级，再把数据库迁移留到之后。

维护者提供geth db pebble-upgrade用于显式离线升级旧Pebble v1数据库；该操作应在停止节点、确认数据目录与恢复方案后单独执行，而不是和二进制重启混成一步。

执行前停止Geth并确认没有另一进程占用同一datadir；核对数据目录和磁盘剩余；按团队策略完成快照或可恢复备份；记录原数据库格式；再运行官方命令。不要在节点仍服务RPC或同步时执行，也不要把命令批量推到所有实例。

迁移后首次启动可能出现额外压实或磁盘活动，应预留观察时间。检查数据库能否打开、链头是否继续推进、ancient/freezer路径是否正确、磁盘IO与空间是否异常。若出现问题，停止节点并按预先验证的恢复步骤处理，不在原目录反复尝试破坏性命令。

第一阶段只在一台非关键或可快速切换的节点升级1.17.5，保留数据库原格式，观察GOGC 50下的内存、CPU、同步和RPC。第二阶段在另一个维护窗口试做Pebble v2离线升级。每阶段至少覆盖日常负载和一次高峰，再扩到下一批。

验证者架构还要确保共识客户端与执行客户端连接正常，JWT和Engine API没有因部署变更丢失。RPC节点则要回放关键eth、debug或trace调用，尤其关注请求超时、响应大小和内存峰值。

保存二进制版本与校验、启动参数差异、GOGC实际值、数据库后端与格式、升级前后资源曲线、链头和RPC验收结果。对Amsterdam只记录“代码已包含”而不是“主网已激活”。对Pebble只记录实际检测到的格式，而不是期望状态。

若内存峰值不可接受，回退—gogc=20不要求回退整套二进制；若数据库升级有问题，则按数据库恢复计划处理，不要把两个回滚动作绑定。清晰的变量隔离比一次性追求所有新默认更可靠。

先升级二进制并观察默认GOGC，再决定是否恢复20；数据库格式升级另设维护窗口。把三件事拆开，出现内存、压实或同步问题时才知道该回滚哪一步。

本文没有把媒体标题当证据终点，原始依据包括go-ethereum v1.17.5 Release、Geth GOGC Flag Pull Request、Geth Pebble v2 Pull Request、Geth Database Documentation。

当前不能越过的事实边界是：实际内存峰值、GC开销、升级耗时和Pebble压实行为取决于节点缓存、数据库规模、硬件与负载；文章不承诺统一性能增益。