首页 / MYSQL / 蚂蚁搬家式迁移mysql数据库
蚂蚁搬家式迁移mysql数据库
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了蚂蚁搬家式迁移mysql数据库，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含9330字，纯文字阅读大概需要14分钟。
内容图文
乘机房搬迁的机会，打算做一次业务整合。现有的架构是在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台空闲服务器，再内网演练，就算白天也能能进行（复制数据走内网，不在用户访问的带宽），但是，没有资源给我啊，但事情又不得不做。虽然累点，折腾一番，翻过来想，咱玩悬的也获得经验，不然也没有这个文章问世，你们觉得觉呢？
道长有话说
最近受邀在51CTO博客专栏出版《负载均衡高手炼成记》，依托自己十余年的IT运维经验，以实际工作经验为基础，介绍不同场景下，负载均衡的实现方式，以及负载均衡的日常维护。
本专栏适合于一直徘徊在运维初级未找到入佳境之门的运维工程师，也适合对负载均衡有兴趣了解和学习的技术爱好者。跟着田道长学完这个系列课程，不仅学知识，更是涨薪、升职、进心仪公司的一大捷径！
负载均衡高手炼成记
原文：http://blog.51cto.com/sery/2132133
内容总结
以上是互联网集市为您收集整理的蚂蚁搬家式迁移mysql数据库全部内容，希望文章能够帮你解决蚂蚁搬家式迁移mysql数据库所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。