尧图网页设计 
Kubo badgerds 已废弃如何把旧节点迁移到 flatfs 或 pebbleds【免费下载链接】kuboIPFS implementation in Go: a daemon that stores and serves content-addressed data, with a CLI, HTTP Gateway, and RPC API项目地址: https://gitcode.com/GitHub_Trending/ku/kubo如果你的 Kubo 节点当初是用ipfs init --profile badgerds初始化的那么它的块存储基于 badger 1.x。docs/datastores.md 中的badgerds章节明确标注Badger v1 datastore 已废弃deprecated并将在未来的 Kubo 版本中被移除。它基于多年来上游不再维护的 badger 1.x存在启动超时、关闭挂起、文件描述符耗尽等已知 bug官方不再建议用于新部署。Kubo 文档给出的迁移路径是创建一个使用flatfs或特定条件下pebbleds的新IPFS_PATH把旧节点的 pinned 数据导出并导入新仓库最后退役旧的 badger 节点。先确认你的节点是否受影响从 v0.40 起每次以 badger 仓库启动 daemon 时都会在 stderr 打印一条醒目的弃用错误。如果你启动节点时看到这条报错说明当前仓库就是待迁移的 badger 仓库。确认方式很简单查看IPFS_PATH默认为~/.ipfs见 docs/environment-variables.md下仓库的Datastore.Spec是否为badgerds类型。选择目标 datastore迁移不是原地转换而是新建仓库。选哪种目标存储文档给出的判断依据如下flatfs推荐主路径把每个块存为文件系统里的独立文件文档称其为最久经考验、最可靠的 datastore适合大多数用户。docs/config.md 的flatfsprofile 说明中还列出了适合场景需要简单可靠的存储、需要 GC 尽快释放磁盘空间、想最小化内存占用。pebbleds可选仅当确定 flatfs 不满足你的用例时pebbleds是实验性experimental的 pebble 键值存储面向性能和多 TB 数据集。文档原话是多数用户用现代flatfs完全够用。组合方案文档提到的另一种思路保留flatfs存块挂载在/blocks把元数据用的levelds换成pebble。块存储部分仍走 flatfs适合觉得 leveldb 不够用但块存储无需换型的场景组合方式见 docs/datastores.md 的mount章节。迁移步骤第 1 步创建新仓库在旧节点仍在运行的情况下为迁移准备一个全新的空目录并通过IPFS_PATH指向它IPFS_PATH决定 IPFS 仓库位置默认~/.ipfs。下面的new-ipfs-path请替换为本机上的一个空目录路径export IPFS_PATHnew-ipfs-path ipfs init --profileflatfs注意两点flatfs、pebbleds、badgerds等 profile只能在ipfs init首次初始化时应用见 docs/config.md 各 profile 的 WARNING 说明不能事后切换。如果你预期节点会增长到数百万块以上钉选集群、公共网关、镜像节点文档建议初始化时就用更深的分片next-to-last/3约 32,768 个目录而不是默认的next-to-last/2约 1,024 个目录。分片深度在ipfs init时固定Kubo 不提供原地重新分片工具事后改分片深度意味着再次导出导入。如果选择 pebbleds把 profile 换成pebbleds即可export IPFS_PATHnew-ipfs-path ipfs init --profilepebbleds第 2 步在旧节点上列出要迁移的根 CID切回旧仓库IPFS_PATH指回原目录列出全部递归 pinipfs pin ls -t recursive输出中的每一行 CID 就是一个待迁移的 pin 根。第 3 步把 pinned 数据迁移到新仓库文档给出两条路径任选其一。主路径ipfs dag export/ipfs dag import在旧节点上把每个 pin 根导出为 CAR 文件root-cid替换为第 2 步列出的每个根 CID逐个执行ipfs dag export root-cid root-cid.car导出针对本地已有的数据可以离线完成。然后把 CAR 文件拿到新节点导入。dag import会写入块并 pin 住根 CID导入成功后文档示例中的输出形如以下为文档示例实际 CID 以你的数据为准Pinned root QmQPeNsJPyVWPFDVHb77w8G42Fvo15z4bG2X8D2GhfbSXc success# 在新节点IPFS_PATH 指向新仓库执行 ipfs dag import root-cid.car替代路径重新 adddocs/datastores.md 和 docs/config.md 的迁移说明中同时给出的形式是ipfs pin ls -t recursive|add即把旧节点列出的递归 pin 逐个重新add到新节点需要新节点的 daemon 在运行。适合 pin 数量少、内容可从网络或本地重新获取的场景数据量大时逐根dag export/import更可控。第 4 步验证在新节点上执行ipfs pin ls与旧节点的 pin 清单比对确认每个根 CID 都在。对新节点上的某个根 CID 执行ipfs dag stat root-cid --offline检查完整性。文档中的一次实际输出示例v0.13 changelog$ ipfs dag stat bafybeiednzu62vskme5wpoj4bjjikeg3xovfpp4t7vxk5ty2jxdi4mv4bu --offline Size: 27684934, NumBlocks: 394上面是文档示例你的输出应与你自己的数据规模相符。导入过程中的失败信号如果某个 CAR 只包含部分块带 pin 的dag import会报错例如Error: pinning root ... FAILED: block was not found locally见 t0054-dag-car-import-export.sh 的测试用例。出现这种情况回到旧节点重新完整导出该根即可。第 5 步退役旧节点确认新节点上的 pin 清单和dag stat结果都无误后停止旧节点的 daemon不再使用旧的IPFS_PATH。文档的迁移流程到此结束decommission the old badger-based node。迁移过程中没有任何一步需要删除旧仓库内容旧仓库目录去留由你自行决定。选择 pebbleds 时的两个注意事项如果你最终选的是 pebbledsdocs/datastores.md 的 pebbleds 章节有两点值得先了解formatMajorVersionipfs init --profilepebbleds时配置中会写入当前最新的 pebble 磁盘格式版本目的是防止后续升级 kubo 时数据库格式被自动升级、导致无法回退旧版 kubo。如果配置中不带该字段数据库格式会被自动升级到最新版届时降级旧版 kubo 可能打不开该数据库。调优参数bytesPerSync、cacheSize、memTableSize等选项均可选未配置时使用默认值文档建议先只用默认值运行确有需求再按 pebble 版本见 Kubogo.mod的 Options 文档调优。限制与边界profileflatfs/pebbleds只能在ipfs init时指定现有仓库不能直接改Datastore.Spec换后端必须走新仓库 数据迁移。flatfs 只能作为块存储使用挂载在/blocks它只部分实现了 datastore 接口这一点由mount配置保证profile 初始化已处理好。分片深度在ipfs init时固定没有原地重分片工具请按节点预期的稳态规模保守选择。文档未提供 badger 仓库的在线热迁移工具迁移期间新旧两个IPFS_PATH是各自独立的仓库。更多背景可查 docs/datastores.md 的badgerds与flatfs章节、docs/config.md 的 profile 说明以及 docs/changelogs/v0.40.md 中关于 badger v1 弃用的条目。【免费下载链接】kuboIPFS implementation in Go: a daemon that stores and serves content-addressed data, with a CLI, HTTP Gateway, and RPC API项目地址: https://gitcode.com/GitHub_Trending/ku/kubo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubo badgerds 已废弃，如何把旧节点迁移到 flatfs 或 pebbleds？
Kubo badgerds 已废弃如何把旧节点迁移到 flatfs 或 pebbleds【免费下载链接】kuboIPFS implementation in Go: a daemon that stores and serves content-addressed data, with a CLI, HTTP Gateway, and RPC API项目地址: https://gitcode.com/GitHub_Trending/ku/kubo如果你的 Kubo 节点当初是用ipfs init --profile badgerds初始化的那么它的块存储基于 badger 1.x。docs/datastores.md 中的badgerds章节明确标注Badger v1 datastore 已废弃deprecated并将在未来的 Kubo 版本中被移除。它基于多年来上游不再维护的 badger 1.x存在启动超时、关闭挂起、文件描述符耗尽等已知 bug官方不再建议用于新部署。Kubo 文档给出的迁移路径是创建一个使用flatfs或特定条件下pebbleds的新IPFS_PATH把旧节点的 pinned 数据导出并导入新仓库最后退役旧的 badger 节点。先确认你的节点是否受影响从 v0.40 起每次以 badger 仓库启动 daemon 时都会在 stderr 打印一条醒目的弃用错误。如果你启动节点时看到这条报错说明当前仓库就是待迁移的 badger 仓库。确认方式很简单查看IPFS_PATH默认为~/.ipfs见 docs/environment-variables.md下仓库的Datastore.Spec是否为badgerds类型。选择目标 datastore迁移不是原地转换而是新建仓库。选哪种目标存储文档给出的判断依据如下flatfs推荐主路径把每个块存为文件系统里的独立文件文档称其为最久经考验、最可靠的 datastore适合大多数用户。docs/config.md 的flatfsprofile 说明中还列出了适合场景需要简单可靠的存储、需要 GC 尽快释放磁盘空间、想最小化内存占用。pebbleds可选仅当确定 flatfs 不满足你的用例时pebbleds是实验性experimental的 pebble 键值存储面向性能和多 TB 数据集。文档原话是多数用户用现代flatfs完全够用。组合方案文档提到的另一种思路保留flatfs存块挂载在/blocks把元数据用的levelds换成pebble。块存储部分仍走 flatfs适合觉得 leveldb 不够用但块存储无需换型的场景组合方式见 docs/datastores.md 的mount章节。迁移步骤第 1 步创建新仓库在旧节点仍在运行的情况下为迁移准备一个全新的空目录并通过IPFS_PATH指向它IPFS_PATH决定 IPFS 仓库位置默认~/.ipfs。下面的new-ipfs-path请替换为本机上的一个空目录路径export IPFS_PATHnew-ipfs-path ipfs init --profileflatfs注意两点flatfs、pebbleds、badgerds等 profile只能在ipfs init首次初始化时应用见 docs/config.md 各 profile 的 WARNING 说明不能事后切换。如果你预期节点会增长到数百万块以上钉选集群、公共网关、镜像节点文档建议初始化时就用更深的分片next-to-last/3约 32,768 个目录而不是默认的next-to-last/2约 1,024 个目录。分片深度在ipfs init时固定Kubo 不提供原地重新分片工具事后改分片深度意味着再次导出导入。如果选择 pebbleds把 profile 换成pebbleds即可export IPFS_PATHnew-ipfs-path ipfs init --profilepebbleds第 2 步在旧节点上列出要迁移的根 CID切回旧仓库IPFS_PATH指回原目录列出全部递归 pinipfs pin ls -t recursive输出中的每一行 CID 就是一个待迁移的 pin 根。第 3 步把 pinned 数据迁移到新仓库文档给出两条路径任选其一。主路径ipfs dag export/ipfs dag import在旧节点上把每个 pin 根导出为 CAR 文件root-cid替换为第 2 步列出的每个根 CID逐个执行ipfs dag export root-cid root-cid.car导出针对本地已有的数据可以离线完成。然后把 CAR 文件拿到新节点导入。dag import会写入块并 pin 住根 CID导入成功后文档示例中的输出形如以下为文档示例实际 CID 以你的数据为准Pinned root QmQPeNsJPyVWPFDVHb77w8G42Fvo15z4bG2X8D2GhfbSXc success# 在新节点IPFS_PATH 指向新仓库执行 ipfs dag import root-cid.car替代路径重新 adddocs/datastores.md 和 docs/config.md 的迁移说明中同时给出的形式是ipfs pin ls -t recursive|add即把旧节点列出的递归 pin 逐个重新add到新节点需要新节点的 daemon 在运行。适合 pin 数量少、内容可从网络或本地重新获取的场景数据量大时逐根dag export/import更可控。第 4 步验证在新节点上执行ipfs pin ls与旧节点的 pin 清单比对确认每个根 CID 都在。对新节点上的某个根 CID 执行ipfs dag stat root-cid --offline检查完整性。文档中的一次实际输出示例v0.13 changelog$ ipfs dag stat bafybeiednzu62vskme5wpoj4bjjikeg3xovfpp4t7vxk5ty2jxdi4mv4bu --offline Size: 27684934, NumBlocks: 394上面是文档示例你的输出应与你自己的数据规模相符。导入过程中的失败信号如果某个 CAR 只包含部分块带 pin 的dag import会报错例如Error: pinning root ... FAILED: block was not found locally见 t0054-dag-car-import-export.sh 的测试用例。出现这种情况回到旧节点重新完整导出该根即可。第 5 步退役旧节点确认新节点上的 pin 清单和dag stat结果都无误后停止旧节点的 daemon不再使用旧的IPFS_PATH。文档的迁移流程到此结束decommission the old badger-based node。迁移过程中没有任何一步需要删除旧仓库内容旧仓库目录去留由你自行决定。选择 pebbleds 时的两个注意事项如果你最终选的是 pebbledsdocs/datastores.md 的 pebbleds 章节有两点值得先了解formatMajorVersionipfs init --profilepebbleds时配置中会写入当前最新的 pebble 磁盘格式版本目的是防止后续升级 kubo 时数据库格式被自动升级、导致无法回退旧版 kubo。如果配置中不带该字段数据库格式会被自动升级到最新版届时降级旧版 kubo 可能打不开该数据库。调优参数bytesPerSync、cacheSize、memTableSize等选项均可选未配置时使用默认值文档建议先只用默认值运行确有需求再按 pebble 版本见 Kubogo.mod的 Options 文档调优。限制与边界profileflatfs/pebbleds只能在ipfs init时指定现有仓库不能直接改Datastore.Spec换后端必须走新仓库 数据迁移。flatfs 只能作为块存储使用挂载在/blocks它只部分实现了 datastore 接口这一点由mount配置保证profile 初始化已处理好。分片深度在ipfs init时固定没有原地重分片工具请按节点预期的稳态规模保守选择。文档未提供 badger 仓库的在线热迁移工具迁移期间新旧两个IPFS_PATH是各自独立的仓库。更多背景可查 docs/datastores.md 的badgerds与flatfs章节、docs/config.md 的 profile 说明以及 docs/changelogs/v0.40.md 中关于 badger v1 弃用的条目。【免费下载链接】kuboIPFS implementation in Go: a daemon that stores and serves content-addressed data, with a CLI, HTTP Gateway, and RPC API项目地址: https://gitcode.com/GitHub_Trending/ku/kubo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考