社区所有版块导航
Python
python开源   Django   Python   DjangoApp   pycharm  
DATA
docker   Elasticsearch  
aigc
aigc   chatgpt  
WEB开发
linux   MongoDB   Redis   DATABASE   NGINX   其他Web框架   web工具   zookeeper   tornado   NoSql   Bootstrap   js   peewee   Git   bottle   IE   MQ   Jquery  
机器学习
机器学习算法  
Python88.com
反馈   公告   社区推广  
产品
短视频  
印度
印度  
Py学习  »  DATABASE

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

DBAplus社群 • 8 年前 • 851 次点击  


趁机房搬迁的机会,打算做一次业务整合。现有的架构是在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



近期热文

详解主流分布式架构选型与高可用设计

不做保姆式运维,从容接手新业务运维工作

从技术管理的困惑,看IT人中年危机怎么破

京东金融以应用为中心的DevOps体系建设

修补DBA短板:监控SQL优化案例两则


近期活动

2018 DAMS中国数据资产管理峰会


今天看啥 - 高品质阅读平台
本文地址:http://www.jintiankansha.me/t/qU48y08SVk
Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/19645