进行数据库迁移时，最让人担忧的并非技术层面存在难度，而是在迁移进程当中，陡然出现一个状况，让你在毫无防备的情况下，被其阻碍得毫无应对之策。近期为客户开展了一回迁移工作，将三套业务库整合成为两套，其间遭遇了诸多问题，现将其撰写出来，以此给大家敲响一个警钟。

迁移前准备 清单一定要列清楚

未动手开展行动之前呀，得先把整个环境彻彻底底地摸清楚。我精心列了一份详尽的清单，将迁移之前以及迁移之后的环境信息全部仔仔细细地记录下来，这里面涵盖了主从关系，还有 MySQL 版本，各个实例的 IP 地址也都在其中。业务 A 是单独进行迁移的，业务 B 和业务 C 则要合并到一套全新的实例里面。清单之上还清楚地标明了哪些属于旧主实例、哪些属于旧从实例，哪些又是新主实例、哪些是新从实例。如此这般，后续在进行操作的时候呀，一眼看过去就能够清晰明了，不会出现混淆搞乱的状况。

那清单当中是有着配置文件对比项的，当进行新实例创建之际，我特意将旧实例的配置文件取出，逐条去做对比，特别是字符集、sql_mode这些极易出现问题的参数，要是配置不一致的话，便会致使数据迁移过去以后出现乱码或者SQL执行失败的状况，而这种问题排查起来是极为花费时间的，因而提前做好对比比任何事情都要重要。

数据同步 备份还原有讲究

业务A具备着相对简单的特性，仅仅直接进行全库备份即可实现目标。然而全库备份并不单单局限于备份数据，诸如触发器、存储过程以及事件等这些内容，其中任何一个都断断不能有所遗漏。我所选用的乃是客户环境予以允许的备份工具，在备份工作完成之后，将文件拷贝至新实例的服务器之上进行导入操作。导入任务达成以后，存在一个细节方面需要加以留意：MySQL 5.7版本的全库备份不会对mysql.proc之下的系统存储过程进行备份操作，因而在导入之后需要执行一次升级命令，否则存储过程极有可能出现问题。

业务B仅有一个库，业务C也仅有一个库，这两个库要合并到同一套全新的实例当中，我所采用的是单库备份的方式 ，将业务B的库备份出来 ，再把业务C的库也备份出来 ，之后把业务B库的备份导入到新实例的一个数据库里 ，把业务C库的备份导入到新实例的另一个数据库中。合并存在的难点在于两个库里面 ，表名以及字段名是否存在冲突 ，还好客户较早就进行了确认 ，表明不存在重名的问题 ，所以这一步进行得还算顺利。

建立复制 多源复制解决合并需求

#全库备份
mysqldump -h127.0.0.1 -P3306 -uroot -p --default-character-set=utf8mb4 --single-transaction --master-data=2 --flush-logs --hex-blob --triggers --routines --events --all-databases > all_db.sql

#单库备份
mysqldump -h127.0.0.1 -uroot -P3306 -p --default-character-set=utf8mb4 --master-data=2 --flush-logs --single-transaction --set-gtid-purged=off --hex-blob --databases  databasename  > one_database.sql

为确保迁移窗口时段数据实时处在同步状态下，所要做的是于旧实例跟新实例之间构建复制方面的关系业务A是那种最为简便的，仅需径直如常去完成主从复制即可对于复制地址一提我得出的建议是采用VIP，如此一来就算旧实例的主库出现了切换，复制这一行为也不会中断倘若不存在VIP，运用从库地址来开展级联复制同样可行，但务必要保证每一级复制都能够正常运转起来，不然一旦中间出现中断数据就会变得不一致了。

#导入数据
mysql -h127.0.0.1 -P3306 -uroot < all_db.sql

需将业务B与业务C合并至一套全新实例之中，如此便无法运用普通的复制方式。我选用了多源复制，致使新实例同步数据时，能同时从业务B以及业务C的旧实例进行操作。多源复制要求预先制作好复制用户，每个源对应一条复制通道，配置期间务必格外留意通道名称以及复制规则的设定。迁移完成之后，这些临时塑造的复制用户要即刻回收，以免产生安全隐患。

#执行升级
mysql_upgrade --upgrade-system-tables --skip-verbose --force

迁移前确认 多次检查不嫌多

我在迁移之前确认，自己同样列出了清单，且将其分成了好多项目，其中OM代表着旧主实例，NM是新主实例，OS是旧从实例，NS是新从实例，确认事项涵盖GTID是否一致，以及主从延迟是否为0，还有各实例状态是否正常，这些检查并非只做一回，在迁移准备完成之际我确认了一回，在迁移正式开始之前我又确认了一回，以此确保万无一失。

#新实例的主库执行，建立旧实例到新实例的复制
CHANGE MASTER TO MASTER_HOST='10.186.60.201',
MASTER_USER='repl',
MASTER_PORT=3307,
MASTER_PASSWORD='repl',
MASTER_AUTO_POSITION = 1;
start slave;

有一个关键确认要点是配置文件存在差异，新实例创建时期虽已将配置做过对比，不过在迁移先前仍需再度进行确认，尤其针对那些会对数据写入产生影响的参数，像innodb_strict_mode、sql_mode这般情况。要是新老实例配置并不相同，一经迁移后业务SQL执行结果或许会有所不同，届时业务部门找上门来时恐怕就会徒增麻烦了。

#在新实例的主库执行，将业务B与C的数据都复制到新实例中。
CHANGE MASTER TO MASTER_HOST='10.186.60.209',
MASTER_USER='repl',
MASTER_PORT=3307,
MASTER_PASSWORD='repl',
MASTER_AUTO_POSITION = 1 FOR CHANNEL 'channel1';
 
CHANGE MASTER TO MASTER_HOST='10.186.60.210',
MASTER_USER='repl',
MASTER_PORT=3307,
MASTER_PASSWORD='repl',
MASTER_AUTO_POSITION = 1 FOR CHANNEL 'channel2';
start slave;

迁移执行 三步切断写入流量

迁移窗口开启之后，首要步骤是证实业务全然终止。我查验了GTID的变动情形，要是GTID不再增长，表明已然没有流量写入。与此同时还得同业务部门核实他们的确已停下所有写操作，不可仅依赖监控判定，因为有些定时任务或许还在后台运行着。

首先，要在确定不存在流量之后，进行第二步操作，也就是解除旧集群的VIP绑定，接着将旧实例设定为只读模式。之所以如此操作是采取双保险措施，哪怕存在遗漏的写入请求，也会因处于只读状态而导致失败，进而不会生成新的数据。之后进行第三步，即切断新老集群之间的复制关系。完成这一步骤后，新老集群的数据状态理应是全然相同的，随后我对双方的GTID以及表数据量展开对比，在确认不存在差异之后才交付给业务部门去做验证。

数据验证 业务部门主导我们协助

#查看实例状态
 show master status\G

数据验证主要是由业务部门去做，业务部门对自身的数据模样最为清楚，我们的角色是在业务部门发现问题之际提供技术支撑，在此次迁移当中，业务部门验证时察觉到业务 A 存在几张表的数据不相符的情况，经过排查是由于备份的时候遗漏了两个事件，进而致使增量同步未能跟上，重新补充事件之后再次验证便通过了。

#解绑vip
ip addr del 10.186.60.201/25 dev eth0

#设置旧实例为只读库，防止数据写入
show global variables like '%read_on%';
set global super_read_only=1;
show global variables like '%read_on%';

将业务B运用业务C合并之后的验证会更麻烦一点，业务部门得去检查跨库进行查询的结果是不是精准，关联查询有没有出现数据缺失的情况。我们跟他们一起运行了几个核心业务场景里头的SQL，对合并之前与合并后的返回结果加以对比，确定二者一致之后才算是达成。整个流程耗费了大概两个小时，相比预期多出了一个小时，主要原因是排查事件时有所遗漏从而平白浪费了时间。

#断开复制
stop slave;

末了问诸位一个问题，你于处置数据库迁移之际，所遭遇的最为巨大的阻碍是何种，欢迎于评论区域分享你的经历，点赞收藏此篇文章，待到下回迁移之前翻找出来瞧上一眼，能够少走诸多的弯路。