持续1个多月的迁移失败了，谁的锅

        笔者最近经历了一次持续1个多月的数据库迁移，数据量高达80多T，跨架构，跨版本，跨城市的数据库迁移，但是最终，这次迁移失败了，谁的锅呢

        失败的原因很简单，在传输的过程中，网络异常导致传输中断了，而由于这是一次边导边传的操作，传输中断了，导出也随之中断，而如果重新导出，还很有可能再次出现网络异常导致传输中断，可以这样说，这个数据库迁移失败了，只能重新想办法迁移。

        在整个迁移过程中，开发商（开发和维护业务系统的厂家）属于需求方，也是牵头主导本次迁移的负责方，根据客户要求，该数据库是业务方10多年来累计下来的数据资产，必须全部迁移过去，在开发商清理了一些临时数据后，数据库最终还有89T的数据。

        迁移方式选择，由于源服务器是AIX系统，目标端服务器是Linux系统，而且是从10G迁移导11G，另外需要迁移80多T的数据，因此选择了XTTS传输表空间方式迁移。之前我们也多次使用XTTS迁移数据库，算是比较有经验的，提出了一些要求和风险点。

        主要风险点就一个：本次迁移不是同一个机房内网迁移，而是从g市迁移导j市，通过跨地市的共享网络迁移，无法保障速度，而且在传输过程中，很可能出现网络抖动等原因导致传输失败。

        现在果然遇到这个风险了，要追责了，板子打在谁身上呢。。。

        网络组说，这个不关我们事，网络抖动是没法控制的，因为用的是共享网络，很有可能其他业务会爆发，把带宽抢占完了。

        数据库组说，我们在迁移之前就提出了会可能遇到这个风险，如果要避免这个风险，那必须加快传输速度，现在30M/S的速度，要持续一个多月导出，出问题的几率太大了。

        业务组说，这个共享带宽是1000M/S的，我们在其他机器上面测试都可以达到100多M/s，怎么就数据库服务器这么慢呢。

        主机组说，我们没做任何限制策略，防火墙也是关闭的，有限制也是网络组那边做了限制。

        接着网络组又说，没有对任何IP进行带宽限制，其他主机没问题，偏偏就这台服务器不行，肯定是服务器的问题。

        总之，公说公有理，婆说婆有理，互相推诿。

        没办法，客户只能拍板，重新再来，先导出到本地，再通过另外一个速度较快的中转机器，FTP到目标库。