[root@msyql ~]#mysql
mysql>grant all on quanzhen_equipment.* to ……
还要记得给MySQL空密码消除掉。
源库与目标库，比对一下表的数量，以及随机抽取一些大表，对记录数进行比较。确认数据完整以后，一帮去调试应用，后续工作就没我什么事。
3、第三次分拆迁移
有了上一次的成功经验，这次信心满满了，不过担心还是有的，就是那个目标库导入时，要求数据目录为空。小弟在未开始时，就来征求我的意见，我担心可能会有障碍，就对他说，你只要把源站数据导出准备好，放到目标数据库，余下的我亲自搞定。
自己的选择有两个，一个是使用选项“--force-non-empty-directories”，如果不行，就再弄一个MySQL实例，启用3307端口，双实例运行。先尝试第一个选项，看能不能进行下去，具体指令为：
[root@msyql db_bk]# pwd
/data/db_bk
[root@msyql db_bk]#innobackupex --defaults-file=/etc/my.cnf --copy-back \
--force-non-empty-directories 2018-06-22_00-24-52
180623 23:31:57 innobackupex: Starting the copy-back operation
IMPORTANT: Please check that the copy-back run completes successfully.
At the end of a successful copy-back run innobackupex
prints "completed OK!".
innobackupex version 2.4.11 based on MySQL server 5.7.19 Linux (x86_64) (revision id: b4e0db5)
innobackupex: Can't create/write to file '/data/mysql_db/ib_logfile0' (Errcode: 17 - File exists)
[01] error: cannot open the destination stream for ib_logfile0
[01] Error: copy_file failed.
悲催了，有同名文件存在，不行！直接终止运行。好吧，我把文件“ib_logfile0、ib_logfile1”挪走，再执行，还是不行，提示文件“ibdata1”存在，这可是个大家伙。虽然担心新导入的ibdata1可能不包含现有数据库相关信息，但忍不住想试一把。可能有读者会问，这样搞可能把数据库原有的数据破坏掉了，其实我想到这一层了，老早我就把整个库做了备份，买了保险的。
正全神贯注盯着屏幕查看输出，希望进展顺利，突然，qq群有消息传来，问进展如何，啥时能完成。一看时间，六点了，北方大地已经一片光明。时间来不及了，停掉进程，试试直接复制文件，不使用Innobuckupex。心中没底，就去仔细比较了数据库目录与导出数据目录中的三个文件“ibdata1、ib_logfile0、ib_logfile1”，发现其大小完全相同。不管了，把现有数据库里的这几个文件搬走，从导出目录cp来着三个文件。复制完，执行mysqld_safe启动服务，失败，提示ib_logfile0无写入权限；这好办，一条chown指令而已。再执行启动MySQL服务，正常。
那么数据对不对呢？我不能确定，万一不对，就再配一个MySQL，导入数据，以双实例启动，后边再想法整合；阿里云购买的服务器，相互通信是内网，不会在传输上浪费太多时间。
既然服务正常，就对一下数据吧，万一运气爆棚（前几天夜里梦到自己能飞，抓住一只巨型天鹅，我美美地搂着天鹅的脖子…），数据完整可用呢？
我自己悄悄对比了一阵，没发现差异，又到qq群呼叫其它人，说导入有障碍，数次不成功，后边采取了一些不确定的手段，MySQL服务是起来了，请大家核实一下数据，看是否完整可用。几个程序员一阵忙碌，得到答复，数据是完整可用的。到此，我的工作完成了。
有人可能要鄙视我一番，为什么不先测试？不制定完善的流程？这个问题问得好！我数次建议决策人，准备点资源，说白了就是准备1台空闲服务器，再内网演练，就算白天也能能进行（复制数据走内网，不在用户访问的带宽），但是，没有资源给我啊，事情又不得不做。虽然累点，折腾一番，反过来想，咱玩悬的也获得经验，不然也没有这个文章问世，你们觉得呢？
閱讀更多 DBAplus社群 的文章
