蚂蚁搬家式迁移mysql数据库-低调大师

蚂蚁搬家式迁移mysql数据库

2018-06-23 643

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

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: 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)

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

乐观估计，上午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运维经验，以实际工作经验为基础，介绍不同场景下，负载均衡的实现方式，以及负载均衡的日常维护。
本专栏适合于一直徘徊在运维初级未找到入佳境之门的运维工程师，也适合对负载均衡有兴趣了解和学习的技术爱好者。跟着田道长学完这个系列课程，不仅学知识，更是涨薪、升职、进心仪公司的一大捷径！
负载均衡高手炼成记

微信关注我们

原文链接：https://blog.51cto.com/sery/2132133

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

一次walle项目错误处理--巨坑

一次walle项目错误处理--巨坑 Walle的简介我就不多说了它主要是一个web部署系统工具，具有一键快速回滚的功能，它能清晰的记录上线单申请、审核、部署和实时操作日志，能支持各种web代码发布和回滚,对于jenkins来说应用时比较简单一点。对于walle,我现在的公司主要是使用walle实现代码发布,(搭建可参考 walle搭建)下面是我配置的一个项目,(有修改,理解意思就好)先给大家贴个图. 各配置的理解如下： · 代码的检测仓库目录：如 /data/code/api · 项目的用户权限管理 www · 生产环境的web目录，该目录的最后一个目录不需要创建，发布时自动软连生成如：/data/www/www.api.com · Walle的发布临时目录，存放web的版本如： /data/publish/www/api · 部署前准备任务:pre-deploy （前置检查） · 代码检出后处理任务post-deploy：如vendor和处理php命令 · 同步后更新软链前置任务pre-release · 发布完毕后收尾任务post-release：如重启、一些文件的操作 ...

2018-06-21

649

前言最近一年使用 Elasticsearch 完成亿级别日志搜索平台「ELK」，亿级别的分布式跟踪系统。在设计这些系统的过程中，底层都是采用 Elasticsearch 来做数据的存储，并且数据量都超过亿级别，甚至达到百亿级别。所以趁着有空，就花点时间整理一下具体怎么做 Elasticsearch 性能优化，希望能对 Elasticsearch 感兴趣的同学有所帮助。背景 Elasticsearch 是一个基于 Lucene 的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于 RESTful web 接口。Elasticsearch 是用 Java 开发的，并作为 Apache 许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。作为一个开箱即用的产品，在生产环境上线之后，我们其实不一定能确保其的性能和稳定性。如何根据实际情况提高服务的性能，其实有很多技巧。下面我就从三个方面分别来讲解下优化服务的性能：索引效率优化查询效率优化 JVM 配置优化索引效率优化索引优化主要是在 Elastic...

2018-06-24

631

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。