pycharm导入mysql时间为空_蚂蚁搬家式迁移mysql数据库

作者：sery来源：https://blog.51cto.com/sery/2132133

趁机房搬迁的机会，打算做一次业务整合。现有的架构是在2010年规划并运营起来的，随着时间的推移，项目也越来越多。打开Nginx配置文件，有四十多行Include包含存在，每一个包含就是一个项目(有些是Web，有些是APP)。一整个机柜，老旧的设备，负载均衡高可用架构。

为保证业务一致性和降低成本，业务数据(包括开发的应用程序及用户上传数据)共享一套NFS；各业务共享同一套物理数据库(一台物理服务器MySQL创建多个库)。随着业务和访问量的增长，这种隐患越来越令人担忧，主要表现在安全问题及性能问题这两个方面。

1、安全问题

数十个站点共享目录，以NFS方式共享给各物理服务器，这几十个项目，只要任何一个有安全漏洞存在，有心人都能进来为所欲为，让站点全部沦陷。时不时的被人注入恶意代码，针对性地进行清除，但没多久又被注入篡改。

大家心里都有数，存在漏洞的地方，不一定是被篡改的那个。但站点太多，又没有隔离，根本无法用安全工具扫描(一个站点进行扫描，平均花费一天)。

2、性能问题

性能问题主要集中在数据库上边，只要有一个库出现问题，引起锁表或者其它竞争，全部相关业务都会挂起，大伙儿都是烦不胜烦。

迁移过程

想进行拆分，决策人认为，本来就满机柜了，如果再新家机器，得另租机柜，考虑到成本等其它问题，只求不出事即可。

整合的计划是，迁移部分业务到公有云上，腾出服务器后，对现有的设备进行扩充配置(拼内存、硬盘等，古旧的机器直接下架)。留下配置高的，进行虚拟化，既能减少设备数量(托管费降低)，又有利于日常维护。

前边说了这么多，似乎与技术关系不大，但对于一些有遗留问题的项目，还是具有参考意义。接下来，我们就进入正题，看看我们要迁移的项目状况。要往云上迁移的数据包括网站数据及数据库数据，网站数据比较好办，rsync同步到对应的目录，而数据库相对而言要麻烦不少。

两个数据库，一个容量38G，另一个29G，不算太大，但公用的IBData1文件却有123G，最初是尝试把这两个库，直接导入到阿里云的RDS，在进行数次操作失败后，咨询客服得到的答复是RDS暂时不支持分表的数据库。为节省成本，购买一个配置高一点的云主机(cpu 8core，内存32G，1T高效云盘)，部署上MySQL5.6，供两个数据库使用。

1、第一次尝试

预估了一下，200G的数据，贪心一把，看一次性能不能迁移完。提前几天，把云上的环境全部准备妥当(能出来测试页)，运营部门把通知发下去，然后某天夜里0:30分，一些人在办公室，一些人在家里，眯着眼，庄重地在键盘敲入“screen”这几个字符。在qq群里得到一致许可，可以进行数据库导出操作以后，小弟小心翼翼地发来一条指令：

乐观估计，上午7点前，能完成整个迁移，几个人商量轮流监看进展程度，等进行完一步后叫醒休息的人，以便进行下一步。结果，到凌晨六点多，才执行完这个innobackupex，还差好几步呢，每一步都同样耗时，只能宣告迁移暂时失败，选个黄道吉日，分两次进行迁移。

2、第二次分拆迁移

万年历排除近期诸事不宜的日子，再摇卦选利用用神的地支，选定日志，约上相关人等，继续进行迁移。有了上一次的教训，在迁移前又对要迁移的库做了清理，删掉了一些无用的数据，省出来好几个G的空间。在源数据库，执行指令：

[root@db-209 ~]#innobackupex --user=root --passwor='i%=KGb76' --defaults-file=/etc/my.cnf --databases=“quanzhen_equipment” /data/bakmysql/

我交代好以后，就躺下睡觉，到凌晨三点电话响了，告知第一步完成。

[root@db-209 ~]#innobackupex --apply-log /data/bakmysql/2018-06-18_00-30-37

日志应用倒是执行的很快，回车即完。然后进行tar打包和复制文件到目标服务器，由于租赁的出口带宽太小(总带宽30M，现在读者知道为什么要夜间访问低谷进行迁移了吧？)，复制文件到目标服务花了一些时间。

目标服务器，仅仅需要安装好MySQL软件，创建好目录/data/mysql_db，不需要执行数据库初始化操作，因为Innobackupex导入时，要求数据目录必须为空。阿里云的配置比源服务器配置高，解压文件很快就完成。

检查一下MySQL选项文件/etc/my.cnf，注意是选项文件。

设定“—datadir=/data/mysql_db”，就可执行导入操作，指令如下：

[root@msyql mysql_db]# innobackupex --defaults-file=/etc/my.cnf --copy-back /data/db_bk/2018-06-18_00-30-37

源数据导出时，没有把库MySQL一并导出，这倒不是什么要紧的事情，反正只有一个账户需要创建。接下来，初始化数据库并创建应用帐号，具体操做如下：

还要记得给MySQL空密码消除掉。

源库与目标库，比对一下表的数量，以及随机抽取一些大表，对记录数进行比较。确认数据完整以后，一帮去调试应用，后续工作就没我什么事。

3、第三次分拆迁移

有了上一次的成功经验，这次信心满满了，不过担心还是有的，就是那个目标库导入时，要求数据目录为空。小弟在未开始时，就来征求我的意见，我担心可能会有障碍，就对他说，你只要把源站数据导出准备好，放到目标数据库，余下的我亲自搞定。

自己的选择有两个，一个是使用选项“--force-non-empty-directories”，如果不行，就再弄一个MySQL实例，启用3307端口，双实例运行。先尝试第一个选项，看能不能进行下去，具体指令为：

悲催了，有同名文件存在，不行！直接终止运行。好吧，我把文件“ib_logfile0、ib_logfile1”挪走，再执行，还是不行，提示文件“ibdata1”存在，这可是个大家伙。虽然担心新导入的ibdata1可能不包含现有数据库相关信息，但忍不住想试一把。可能有读者会问，这样搞可能把数据库原有的数据破坏掉了，其实我想到这一层了，老早我就把整个库做了备份，买了保险的。

正全神贯注盯着屏幕查看输出，希望进展顺利，突然，qq群有消息传来，问进展如何，啥时能完成。一看时间，六点了，北方大地已经一片光明。时间来不及了，停掉进程，试试直接复制文件，不使用Innobuckupex。心中没底，就去仔细比较了数据库目录与导出数据目录中的三个文件“ibdata1、ib_logfile0、ib_logfile1”，发现其大小完全相同。不管了，把现有数据库里的这几个文件搬走，从导出目录cp来着三个文件。复制完，执行mysqld_safe启动服务，失败，提示ib_logfile0无写入权限；这好办，一条chown指令而已。再执行启动MySQL服务，正常。

那么数据对不对呢？我不能确定，万一不对，就再配一个MySQL，导入数据，以双实例启动，后边再想法整合；阿里云购买的服务器，相互通信是内网，不会在传输上浪费太多时间。

既然服务正常，就对一下数据吧，万一运气爆棚(前几天夜里梦到自己能飞，抓住一只巨型天鹅，我美美地搂着天鹅的脖子…)，数据完整可用呢？

我自己悄悄对比了一阵，没发现差异，又到qq群呼叫其它人，说导入有障碍，数次不成功，后边采取了一些不确定的手段，MySQL服务是起来了，请大家核实一下数据，看是否完整可用。几个程序员一阵忙碌，得到答复，数据是完整可用的。到此，我的工作完成了。

有人可能要鄙视我一番，为什么不先测试？不制定完善的流程？这个问题问得好！我数次建议决策人，准备点资源，说白了就是准备1台空闲服务器，再内网演练，就算白天也能能进行(复制数据走内网，不在用户访问的带宽)，但是，没有资源给我啊，事情又不得不做。虽然累点，折腾一番，反过来想，咱玩悬的也获得经验，不然也没有这个文章问世，你们觉得呢？