数据迁移实际操作中的感受分享，欢迎大家补充讨论！

对于数据迁移实施，我个人觉得：在实施之前，再繁琐的准备都不算过分！就个人参与过的经验简单分享一下：

1，环境调研要做充足，包括源数据库环境，版本，数据量大小，业务场景，操作系统版本，源数据库环境与目的数据库环境的差异等等

      在实际案例中遇到过多重很奇葩的情况，比如，迁移数据时，才发现客户的网速奇慢，传备份集只能达到3,5M的速率，整个迁移过程被传输占了大部分时间，没想到客户的数据中心的交换机那么差，源数据库和目的数据库是都在一个数据中心的。

2，迁移方案准备，尽量优化细节，最好能在测试环境测试其可行性以及实际耗时后，才到生产环境实施。

      就碰到过实施时间安排的貌似很合理，结果上去第一步操作停库竟然等了好久。

3，确保数据备份，回退可行，不能存在侥幸心理。有次迁移失败，紧急回退，发现源数据库竟然起不来了，深更半夜的又对源数据库折腾了将近一个小时。

4，人员角色齐备，数据迁移一般是晚上实施，最好是A/B角一起参与，以免晚上精神不好，敲错指令。最好是主机工程师和存储工程师都在。曾经有一次，发现导入数据非常慢，后来发现是存储的问题。结果存储工程师不在现场，紧急call过来处理。

重复一下：在实施之前，再繁琐的准备都不算过分！

我们去年做了几十套大系统迁移，各种方法都用了，简单说说

1、压缩（tar）+copy（scp）

2、ogg

3、dg

4、svc

5、镜像

前提，不管做什么方法考虑的问题

1、必须在迁移开始迁备份。

2、对业务影响范围充分了解。

3、风险考虑。

4、停机窗口。

5、操作步骤提前提前准备。

6、回退方案。

7、应急方案。（无法回退）

我在去年十一的时候，做过一次迁移，倒库备份出来，用了24小时多，具体我让别人操作的，然后，在新购置的服务器上安装操作系统，linux；然后，导入也花了很长时间，第二次，我9月30日过去了一趟增量备份，完成后，关停系统；并与10月2日，增量导入新设备，测试没问题，整体迁移了。其中，原来的刀片设备，作为完全备份设备，原封不动放在机房，以作为如果出现问题的马上还原。好像有点奢侈，不过，这样最安全了。

所以大数据，一定要有完全，有增量，这样安全。

工作要点：

环境准备工作做足，数据迁移方案做清晰，数据迁移步骤哦做细，回退切换方案做的有保障。

作为一个存储和备份工程师，参与了很多次的数据迁移，个人感觉有几个方面问题必须特别注意：

1、前期的调研工作必须充分，准备工作一定到位。

2、必须预留备份时间窗口

3、迁移就做迁移，不能去夹杂其他的升级或者变更。

4、方案一定要扎实，要全面；一定要要有回退方案或者保底方案。

5、有条件的一定要各方面的专家给予现场支持。

举一个迁移升级失败的例子：

更换存储和服务器：原环境：IBM小型机，HDS存储用HACMP 做的oracle双机（非RAC机构）

新环境：新IBM小型机（升级系统），新的HDS存储有POWERHA做oracle（版本不变）双机（非RAC机构），

迁移方案：新的服务器上按照原服务器的配置按照oracle配置powerha；用存储之之间的同步复制完成数据迁移；复制完成的数据卷添加到powerha后，启动，不停的抱IO 操作错误；但是能够启动数据库；但是做failover；数据库就死机；找了4个小时才发现powerha的卷要求和hacmp不一样，用户很生气；超出的时间，而且迁移也没有成果。幸好原环境没有破坏。这个方案有几个主要的问题：1、powerha当时刚出的新产品，大家对功能不是很熟悉就想用于生产，想做小白鼠；2、迁移和升级混合一起做，加大排错难度。3、前期准备工作不到位

迁移的几点考虑：

1. 主要也是非常重要一点是梳理用户环境，制定比较有针对性的迁移方案。比如说可以线下迁移尽量要线下迁移，不要为凸显技术的高超，记住凡是都有风险，还有bug。

2. 技术辅助业务，支持业务。在充分测试前提下，梳理步骤，谨慎操作，运用适当的技术进行迁移。

3. 制定每一套的迁移不成功或回退方案，给自己多一种方案选择。

4. 报领导审批方案，提前协调窗口，切勿想当然直接就上，不要我以为没事，最终出大事。

迁移前肯定要完全备份一次吖，不然迁移失败咋办？？？尤其是金融系统的业务数据，必须永久保存，一旦丢了，那你可以跑路了。。。。

一句话，迁移方案要详细！

可以慢点，可以重来，可以。。。。

只要数据还在，一切都有可能

迁移的方法很多，存储层面，数据库层面，系统层面，往往迁移伴随着基础软件升级改造等，所以采用什么方式要根据需求而定，总之备份，风险控制是一定要注意。有任何问题欢迎骚扰