蚂蚁搬家式迁移mysql数据库

发布时间：2022-03-21 10:58 所属栏目：115 来源：互联网

导读：乘机房搬迁的机会，打算做一次业务整合。现有的架构是在2010年规划并运营起来的，随着时间的推移，项目也越来越多。打开nginx配置文件，有四十多行include包含存在，每一个包含就是一个项目（有些是web，有些是app）。一整个机柜，老旧的设备，负载均衡高可

乘机房搬迁的机会，打算做一次业务整合。现有的架构是在2010年规划并运营起来的，随着时间的推移，项目也越来越多。打开nginx配置文件，有四十多行include包含存在，每一个包含就是一个项目（有些是web，有些是app）。一整个机柜，老旧的设备，负载均衡高可用架构。为保证业务一致性和降低成本，业务数据（开发的应用程序及用户上传数据）共享一套NFS；各业务共享同一套物理数据库（一台物理服务器mysql创建多个库）。随着业务和访问量的增长，这种隐患越来越令人担忧,主要表现在以下几个方面:

◆安全问题

数十个站点共享目录，以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;

}

◆性能问题

主要集中在数据库上边，只要有一个库出现问题，引起锁表或者其它竞争，全部相关业务都会挂起，烦不胜烦啊。想进行拆分，决策人认为，本来就满机柜了，如果再新家机器，得另租机柜，考虑到成本等其它问题，只求不出事即可。

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

前边说了这么多，似乎与技术关系不大，但对于一些有遗留问题的项目，还是具有参考意义。接下来，我们就进入正题，看看我们要迁移的项目状况。要往云上迁移的数据包括网站数据及数据库数据，网站数据比较好办，rsync同步到对应的目录，而数据库相对而言，要麻烦不少。两个数据库，一个容量38G，另一个29G，不算太大，但公用的ibdata1文件却有123G，最初是尝试把这两个库，直接导入到阿里云的RDS，在进行数次操作失败后，咨询客服得到的答复是RDS暂时不支持分表的数据库。为节省成本，购买一个配置高一点的云主机（cpu 8core，内存32G，1T高效云盘），部署上mysql5.6，供两个数据库使用。

第一次尝试

预估了一下，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,还差好几步呢，每一步都同样耗时，只能宣告迁移暂时失败，选个黄道吉日，分两次进行迁移。

第二次分拆迁移

万年历排除近期诸事不宜的日子，再摇卦选利用用神的地支，选定日志，约上相关人等，继续进行迁移。有了上一次的教训，在迁移前又对要迁移的库做了清理，删掉了一些无用的数据，省出来好几个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空密码消除掉。

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

第三次分拆迁移

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

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

（编辑：ASP站长网）