迁移完 30TB 数据你敢直接下线源集群吗【免费下载链接】cubefscloud-native distributed storage项目地址: https://gitcode.com/gh_mirrors/cu/cubefs刚跑完一轮跨集群迁移最让人睡不着的不是带宽而是那份没验证过的数据源集群还能留几天CubiFS 自带的cfs-fsck工具就是为这类CubiFS 数据一致性检查准备的一条命令对比多个元数据副本把孤立 inode 和悬空 dentry 挑出来迁移验证从玄学变成清单。工具能做什么一张表说清命令校验对象典型耗时适用阶段check inodeinode文件元数据大小、权限、硬链接数取决于卷内 inode 总量迁移前摸底check dentrydentry目录项目录与文件的父子关系取决于卷内 dentry 总量迁移前摸底check bothinode dentry 全量约前两者之和迁移后总校验clean inode清理已过时的 inode按垃圾 inode 数量校验通过后的收尾三种 check 的区别只有一句话inode 校验文件元数据dentry 校验目录项both 两者都跑。工具会在当前目录生成_export_卷名文件夹.obsolete后缀的文件就是检出的垃圾名单。跟着做从首次校验到清理第一步连通性自检./cfs-fsck get path --master 127.0.0.1:17010 --vol myvol --mport 17220 --inode 1这条命令查根 inode 的路径--master是 Master 的 HTTP 地址--mport是元数据节点的 profiling 端口能打印出路径说明 Master 和元数据节点都连得通。第二步执行全面校验./cfs-fsck check both --master 127.0.0.1:17010 --vol myvol --mport 17220它会把卷下所有元数据分区mp元数据分片的 inode 和 dentry 拉下来从根 inode 出发沿目录树标记可达项标不到的就是过时数据。输出里重点看三处终端的Obselete Total Count过时 inode 数和NLink Zero Total Count硬链接数为 0、可安全清理的数量_export_myvol/inode.dump.obsolete里是否有你认识的目录名有的话先排查再往下走控制台报 No root inode 或网络错误说明参数或连通性有问题回第一步第三步确认无误后清理残留⚠️ 执行前务必确认校验通过且 obsolete 名单里没有任何业务路径。./cfs-fsck clean inode --master 127.0.0.1:17010 --vol myvol --mport 17220清理有硬约束只处理 NLink 为 0、修改时间超过 24 小时且类型为普通文件的 inode其余会打印 cant be deleted 跳过。确实要强制清 NLink 非 0 的垃圾才加--force生产上能不加就不加。两类高频场景操作不一样跨集群搬迁搬迁的本质是新旧两个集群各跑一遍check both比对 obsolete 名单是否收敛到 0大卷一次拉全量容易超时用--inode-list、--dentry-list指定上次导出的名单做分批增量校验校验期间别停源集群业务工具只读元数据但清理只在验证完成后执行网络不稳时把超时调大、跑慢一点比中断后从头再来省时间版本升级后回归升级和搬迁的区别在于数据没动动的是元数据的格式兼容性和增量写入。升级后先跑check both确认旧元数据读得回来格式兼容不过关后面一切免谈只对升级窗口内新建、修改过的文件做增量校验把新 inode 清单导出来用--inode-list指定不必每次全量_export_卷名目录升级前留一份升级后覆盖出问题可以逐行 diff 定位上手前 30 秒检查清单工作机到 Master 和所有元数据节点网络可达Master 地址与元数据节点 profiling 端口--mport核对无误卷名与集群当前卷名完全一致_export_卷名目录已备份或放在不会误删的盘上清单打勾就可以跑check both了结果出来之前源集群一个节点都别动 【免费下载链接】cubefscloud-native distributed storage项目地址: https://gitcode.com/gh_mirrors/cu/cubefs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
迁移完 30TB 数据，你敢直接下线源集群吗
迁移完 30TB 数据你敢直接下线源集群吗【免费下载链接】cubefscloud-native distributed storage项目地址: https://gitcode.com/gh_mirrors/cu/cubefs刚跑完一轮跨集群迁移最让人睡不着的不是带宽而是那份没验证过的数据源集群还能留几天CubiFS 自带的cfs-fsck工具就是为这类CubiFS 数据一致性检查准备的一条命令对比多个元数据副本把孤立 inode 和悬空 dentry 挑出来迁移验证从玄学变成清单。工具能做什么一张表说清命令校验对象典型耗时适用阶段check inodeinode文件元数据大小、权限、硬链接数取决于卷内 inode 总量迁移前摸底check dentrydentry目录项目录与文件的父子关系取决于卷内 dentry 总量迁移前摸底check bothinode dentry 全量约前两者之和迁移后总校验clean inode清理已过时的 inode按垃圾 inode 数量校验通过后的收尾三种 check 的区别只有一句话inode 校验文件元数据dentry 校验目录项both 两者都跑。工具会在当前目录生成_export_卷名文件夹.obsolete后缀的文件就是检出的垃圾名单。跟着做从首次校验到清理第一步连通性自检./cfs-fsck get path --master 127.0.0.1:17010 --vol myvol --mport 17220 --inode 1这条命令查根 inode 的路径--master是 Master 的 HTTP 地址--mport是元数据节点的 profiling 端口能打印出路径说明 Master 和元数据节点都连得通。第二步执行全面校验./cfs-fsck check both --master 127.0.0.1:17010 --vol myvol --mport 17220它会把卷下所有元数据分区mp元数据分片的 inode 和 dentry 拉下来从根 inode 出发沿目录树标记可达项标不到的就是过时数据。输出里重点看三处终端的Obselete Total Count过时 inode 数和NLink Zero Total Count硬链接数为 0、可安全清理的数量_export_myvol/inode.dump.obsolete里是否有你认识的目录名有的话先排查再往下走控制台报 No root inode 或网络错误说明参数或连通性有问题回第一步第三步确认无误后清理残留⚠️ 执行前务必确认校验通过且 obsolete 名单里没有任何业务路径。./cfs-fsck clean inode --master 127.0.0.1:17010 --vol myvol --mport 17220清理有硬约束只处理 NLink 为 0、修改时间超过 24 小时且类型为普通文件的 inode其余会打印 cant be deleted 跳过。确实要强制清 NLink 非 0 的垃圾才加--force生产上能不加就不加。两类高频场景操作不一样跨集群搬迁搬迁的本质是新旧两个集群各跑一遍check both比对 obsolete 名单是否收敛到 0大卷一次拉全量容易超时用--inode-list、--dentry-list指定上次导出的名单做分批增量校验校验期间别停源集群业务工具只读元数据但清理只在验证完成后执行网络不稳时把超时调大、跑慢一点比中断后从头再来省时间版本升级后回归升级和搬迁的区别在于数据没动动的是元数据的格式兼容性和增量写入。升级后先跑check both确认旧元数据读得回来格式兼容不过关后面一切免谈只对升级窗口内新建、修改过的文件做增量校验把新 inode 清单导出来用--inode-list指定不必每次全量_export_卷名目录升级前留一份升级后覆盖出问题可以逐行 diff 定位上手前 30 秒检查清单工作机到 Master 和所有元数据节点网络可达Master 地址与元数据节点 profiling 端口--mport核对无误卷名与集群当前卷名完全一致_export_卷名目录已备份或放在不会误删的盘上清单打勾就可以跑check both了结果出来之前源集群一个节点都别动 【免费下载链接】cubefscloud-native distributed storage项目地址: https://gitcode.com/gh_mirrors/cu/cubefs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考