一段三次分拆的蚂蚁搬家式MySQL迁移经历

sery 2018-07-02 11:00:22

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

 

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

 

1、安全问题
 

 

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

 

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

 

 

[root@web57 ~]# more   /usr/local/nginx/conf/nginx.conf

user  www   www;

worker_processes    6;

worker_rlimit_nofile 51200;

events {

 use epoll;

 #use   kqueue;   #FreeBSD system

 worker_connections 51200;

}

http {

 include         mime.types;

 default_type    application/octet-stream;

 #charset    gb2312;

 server_names_hash_bucket_size 256;

 client_header_buffer_size 256k;

 large_client_header_buffers 4 256k;

 client_max_body_size 500m;

…………………………………………省略若干…………………………………

include vhosts/faxian.quanzhen.com.conf;

include vhosts/www.quanzhen.com.conf;

include vhosts/news.quanzhen.com.conf;

include vhosts/s.quanzhen.com.conf;

include vhosts/down.quanzhen.com.conf;

include vhosts/static.quanzhen.com.conf;

include vhosts/image.quanzhen.com.conf;

include vhosts/3g.quanzhen.com.conf;

include vhosts/mini.quanzhen.com.conf;

include vhosts/xml.quanzhen.com.conf;

include vhosts/mayiapi.quanzhen.com.conf;

include vhosts/www.android77.com.conf;

include vhosts/fahongbao.android77.com.conf;

include vhosts/update.android77.com.conf;

include vhosts/dev.quanzhen.com.conf;

include vhosts/qr.110.cc.conf;

include vhosts/110.cc.conf;

include vhosts/eggserver.quanzhen.com.conf;

include vhosts/apkegg.quanzhen.com.conf;

include vhosts/eggserver.yidong7.cn.conf;

include vhosts/www.yidong7.cn.conf;

include vhosts/down.yidong7.cn.conf;

include vhosts/wan.quanzhen.com.conf;

include vhosts/open.quanzhen.com.conf;

include vhosts/bakdown.yidong7.cn.conf ;

include vhosts/hanhua.quanzhen.com.conf;

include vhosts/mpk.quanzhen.com.conf;

include vhosts/android.quanzhen.com.conf;

include vhosts/pay.quanzhen.com.conf;

include vhosts/cmstop.quanzhen.cn.conf;

include vhosts/news.quanzhen.cn.conf;

include vhosts/pingce.quanzhen.cn.conf;

include vhosts/gonglue.quanzhen.cn.conf;

include vhosts/hao.quanzhen.cn.conf;

include vhosts/all.quanzhen.cn.conf;

include vhosts/s.quanzhen.cn.conf;

include vhosts/apkz.quanzhen.com.conf;

include vhosts/ajax.quanzhen.com.conf;

include vhosts/union.quanzhen.com.conf;

include vhosts/mai.quanzhen.com.conf;

include vhosts/blog.quanzhen.com.conf;

include vhosts/guazi.quanzhen.com.conf;

include vhosts/lockscreen.yidong7.cn.conf;

include vhosts/dsp.pujia8.com.conf;

include vhosts/3svx4haii9.quanzhen.com.conf;

include vhosts/u.quanzhen.com.conf;

include vhosts/bianji.quanzhen.com.conf;

include vhosts/default.conf;

}

 

2、性能问题
 

 

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

 

 

迁移过程

 

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

 

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

 

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

 

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

 

1、第一次尝试
 

 

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

 

 

[root@db-209   ~]# innobackupex    --user=root  --passwor='i%=KGb76'   \

--defaults-file=/etc/my.cnf  \

--databases=“quanzhen_mobile7lockscreen   quanzhen_equipment” /data/bakmysql/

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright   2003, 2009 Innobase Oy

and Percona Ireland Ltd 2009-2012.  All Rights Reserved.

This software is published under

the GNU GENERAL PUBLIC LICENSE Version 2, June   1991.

180618 00:30:31    innobackupex: Starting mysql with options:  --defaults-file='/etc/my.cnf'   --password=xxxxxxxx --user='root' --unbuffered --

180618 00:30:31    innobackupex: Connected to database with mysql child process   (pid=20090)

180618 00:30:37    innobackupex: Connection to database server closed

IMPORTANT: Please check that the backup run   completes successfully.

             At the end of a successful backup run innobackupex

             prints "completed OK!".

innobackupex: Using mysql  Ver 14.12 Distrib 5.0.95, for   redhat-linux-gnu (x86_64) using readline 5.1

innobackupex: Using mysql server version Copyright   (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.

innobackupex: Created backup directory   /data/bakmysql/2018-06-18_00-30-37

180618 00:30:37    innobackupex: Starting mysql with options:  --defaults-file='/etc/my.cnf'   --password=xxxxxxxx --user='root' --unbuffered --

180618 00:30:37    innobackupex: Connected to database with mysql child process   (pid=20123)

180618 00:30:39    innobackupex: Connection to database server closed

180618 00:30:39    innobackupex: Starting ibbackup with command: xtrabackup_55  --defaults-file="/etc/my.cnf"  --defaults-group="mysqld"   --backup --suspend-at-end --target-dir=/data/bakmysql/2018-06-18_00-30-37   --tmpdir=/tmp

innobackupex: Waiting for ibbackup (pid=20132) to   suspend

innobackupex: Suspend file   '/data/bakmysql/2018-06-18_00-30-37/xtrabackup_suspended'

xtrabackup_55 version 2.0.7 for Percona Server   5.5.16 Linux (x86_64) (revision id: 552)

xtrabackup: uses posix_fadvise().

xtrabackup: cd to /data/mysql_db

xtrabackup: Target instance is assumed as   followings.

xtrabackup:     innodb_data_home_dir = ./

xtrabackup:     innodb_data_file_path = ibdata1:10M:autoextend

xtrabackup:     innodb_log_group_home_dir = ./

xtrabackup:     innodb_log_files_in_group = 2

xtrabackup:     innodb_log_file_size = 5242880

>> log scanned up to (601191481892)

[01] Copying ./ibdata1 to /data/bakmysql/2018-06-18_00-30-37/ibdata1

>> log scanned up to (601191481892)

>> log scanned up to (601191481892)

>> log scanned up to (601191481892)

>> log scanned up to (601191481892)

>> log scanned up to (601191481892)

>> log scanned up to (601191481892)

>> log scanned up to (601191481892)

…………………………………省略……………………………………………

 

乐观估计,上午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一并导出,这倒不是什么要紧的事情,反正只有一个账户需要创建。接下来,初始化数据库并创建应用帐号,具体操做如下:

 

 

[root@msyql mysql_db]#cd /usr/local/mysql/

[root@msyql ~]#scripts/mysql_install_db  --user=mysql --datadir=/data/mysql_db

[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台空闲服务器,再内网演练,就算白天也能能进行(复制数据走内网,不在用户访问的带宽),但是,没有资源给我啊,事情又不得不做。虽然累点,折腾一番,反过来想,咱玩悬的也获得经验,不然也没有这个文章问世,你们觉得呢?

 

作者:sery

来源:http://blog.51cto.com/sery/2132133

DBAplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn

 
活动预告