Near indexer同步时archive设为false仍占用大量空间是什么原因？

核心原因是你混淆了底层链节点的archive配置作用范围和indexer的独立同步规则：

• config.json中的archive参数仅作用于你部署的底层全节点：设置为false时，节点只会保留最近2.5个epoch的状态快照用于交易验证，会自动裁剪更早的历史状态数据，但这个规则不会同步作用于indexer服务。
• indexer是独立于节点的结构化数据同步进程，默认逻辑为从创世块开始拉取所有区块的交易、事件、执行回执等全量账本数据做结构化存储，完全不受节点archive参数的控制。

你需要补充调整的配置项 #

• 首先找到indexer服务的专属配置文件（多数公链的indexer配置与节点config.json是相互独立的），添加start_epoch或者同步起始高度配置，手动指定从当前最新epoch往前推2~3个epoch的位置开始同步，不要使用默认的创世块起始点。
• 检查indexer配置中是否存在prune/历史数据裁剪相关开关，开启后设置裁剪阈值为2.5个epoch，避免indexer存储持续膨胀。
• 若你把节点和indexer部署在同一数据目录，可分别统计节点存储目录、indexer数据库目录的占用大小，确认当前30G占用是否来自indexer的全量数据存储，确认节点本身已经按archive=false的规则完成了状态裁剪。

修复操作步骤 #

1. 停止当前运行的indexer进程，按需备份数据后清空indexer的已有数据库文件
2. 按上述要求调整indexer的专属配置
3. 重启indexer服务，查看启动日志确认同步起始高度符合预期，而非从0高度开始同步

内容的提问来源于stack exchange，提问作者François Richard