迁移背景

存储服务一般情况下是不会做迁移操作的，因为一来数据量大，迁移速度慢，二来有状态的数据迁移比无状态的应用迁移难度更大，三来迁移的完整性和正确性需要保证，否则就会出问题。需要迁移的情况就更多了，机房搬迁、硬件性能优化扩容、项目切割交接等都可能会导致迁移。

以下迁移方案不仅迁移storage server, 也包含迁移tracker server

迁移工具

使用rsync迁移，好处是比对校验很方便，工具也是现成的，还可以限速。缺点是速度一般。
使用tar工具迁移，好处是所有文件打包，保证不遗漏，打包后的文件作为一个整体方便做比对校验。缺点是打包需要占用额外空间。
使用http下载，清单可以从storage/data/sync/binlog.000下获取，好处是下载速度挺快，并且可以并发执行。缺点是一旦有文件不在storage/data/sync/binlog.000中，有可能就下载不到，这个时候可以使用find storage/data/[0-F][0-F] -type f的方式取文件清单。
使用Fastdfs storage节点自身的文件同步机制，新增某个group的节点，这个group就会同步数据到这个新节点中，缺点是一旦有文件不在storage/data/sync/binlog.000中，有可能就同步不到，这个时候可以使用根据storage/data/sync/binlog.000文件最早的时间戳，用find storage/data/[0-F][0-F] -type f -mtime +123的方式获取清单之外的文件清单，这部分再以http方式下载。

数据迁移时，storage/data/fdfs_storaged.pid, storage/data/.data_init_flag这两个文件不要迁移，一个是pid，是一个变化的值，一个是本地ip配置，迁移了也没用。
storage/data/sync目录存放关于数据同步的文件，存储了其他storage节点的数据同步信息和自身的binlog，操作前需及其谨慎，同步之后不得随意更改，特别是binlog.000记载了所有文件的清单、时间戳、类型。

该方案中规中矩，按部就班操作，不会出任何问题，但是一旦数据量过大，会导致停服时间较长，业务需要较长的停服窗口期。

该方案在方案一的基础上，做了些许变化，在不停服的情况下，rsync同步数据，因为文件存储之后，一般不会发生变化，因此首次同步完成之后，增量同步时就只有少量的文件需要同步了，可以极大地缩短停服时间。缺点是操作步骤增加，需要反复多次同步数据。

新增两台storage server，开始数据同步
确保所有使用fastdfs的应用，配置的trace_server参数都是主机名而不是IP，如果是IP，最好提前更换。
停服，切换操作时，运维修改fastdfs01, fastdfs02的映射IP，并使之生效。
同步原tracker_server上tracker/data/目录下的 storage_servers_new.dat和storage_sync_timestamp.dat到新tracker_server服务器相同目录下。
重启新节点上 fastdfs自身的docker，建议重启使用fastdfs的应用，确保DNS缓存刷新。
下掉原fastdfs节点
验证

该方案相比方案二，还可以进一步缩短迁移停服窗口期。利用storage新节点自动同步旧节点数据的原理，可以将文件全部同步过来，并且后续有新增的文件变化，也可以及时地传输到新节点。缺点在于执行迁移的人员需要对Fastdfs的运维很熟悉，才能把握其中的原理和细节。