背景
我在公司用过很多服务商的对象存储或者云存储功能，阿里云的OSS，七牛云的Kodo，网宿的WCS，金山云的KS3，小米云平台的FDS，亚马逊的S3等等。之所以用过这么多存储服务，是因为公司有大文件下载的业务需求，为了向遍布全球很多国家的设备提供稳定、优质的下载加速，具备突发性超大流量承载能力。在海外主要设备集中地架构了20多个节点，所以用到了不同服务商的存储服务，来做镜像回源。
首先会将大文件上传到国内阿里云的OSS上，当海外设备来请求对应资源时，会先向最近的节点存储服务上获取资源，若没有，节点存储服务会直接向国内阿里云的OSS拉取对应资源并返回，等下一次其它设备再来该节点请求同样资源时，该节点会直接返回资源。
但是因为存储了很多之前的资源文件，不可能建立新节点后，每次都让新节点来拉取资源，这样也会造成巨大的流量费用，所以在每次建立资源节点时，会先将已有的资源提前同步到资源节点上，再有新增的才会走镜像回源拉取。因此一个对象存储的迁移工具必不可少，这里我使用的是 migration-tool，它支持迁移 fds/oss/s3/ks3 等对象存储。
使用
第三方对象存储引擎迁移的命令行工具。工具下载地址：migration-tool.tar.gz
将它上传到服务器解压后，进入 bin 目录，运行 sh migration-tool.sh
这里举例说明将 阿里云OSS 的对象存储资源迁移到小米云平台的 FDS 上，命令如下：
sh migration-tool.sh
-st oss
-se http://oss-cn-hangzhou.aliyuncs.com(OSS的endpoint)
-sak OSS的accessKey
-ssk OSS的secretKey
-sb OSS的bucket
-de FDS的endpoint
-dak FDS的accessKey
-dsk FDS的secretKey
-db FDS的bucket
参数说明
| 参数 | 可选值 | 含义 | 例子 |
|---|---|---|---|
| -st | fds或oss(必填) | 迁移源端的对象存储名称 fds/oss/s3/ks3 | sh migration-tool.sh -st oss |
| -se | 必填 | 源端对象存储系统的endpoint | sh migration-tool.sh -se http://oss-cn-beijing.aliyuncs.com |
| -sak | 必填 | 源端对象存储的accessKey | |
| -ssk | 必填 | 源端对象存储的secretKey | |
| -sb | 必填 | 源端对象存储的bucket | |
| -de | 必填 | 目标fds的endpoint | sh migration-tool.sh -de cnbj1-fds.api.xiaomi.net |
| -dak | 必填 | 目标fds的accessKey | |
| -dsk | 必填 | 目标fds的secretKey | |
| -db | 必填 | 目标fds的bucket | |
| -bw | 可选 | 每个线程最大带宽，单位MB，默认10MB | |
| -ps | 可选 | 迁移的线程数， 默认是10 | |
| -nsle | 可选 | 不跳过已存在的object,即覆盖已存在的文件 | sh migration-tool.sh -nsle |
| -sm | 可选 | 指定起始的object(指定后包含该object)，默认为null，即从头开始 | |
| -em | 可选 | 指定结束的object(指定后不包含该object)，默认为null，即到bucket的最后 | |
| -p | 可选 | 指定要迁移的object前缀，默认为null，即bucket下的所有object | |
| -fp | 可选 | 指定objects列表的文件路径 |
注意事项
迁移过程中，可能出现迁移失败的 object。
它会自动在你的文件夹中生成 log 文件，在 log 中，每分钟会打印一次迁移统计的 log，copiedBad 是指拷贝了，但是损坏了的文件数(迁移工具会自动删掉)，copiedFailed 是指迁移失败的文件数，可以通过在log中搜关键词 “Copied bad” 和 “Failed to copy object” 找到对应的object名。
迁移时间过长可以加个 nohup 让它在后台运行。
注意服务器的内存大小，当时我就只在 1核1G 的容器里，执行该脚本，过一段时间会被Kill掉，就是因为内存给的不够。
棒