最近负责了一起数据迁移的项目，因为机器硬件过保，因为资源存在冗余，因为。。。总之话还没说完，就得到了项目组的支持，所以迁移的需求是明确的。
那么涉及的服务器数量还真是不少，当然我只是列出来虚拟的图说明意思即可。需要把多套业务进行整合，涉及Oracle和MySQL。
Oracle的架构如下所示。需要把db1和db2的业务进行整合，因为服务器资源老旧，所以就有了新主库和新备库的服务器，异地备库暂且不变，所以目前的主库是一主四备。图中打红叉的服务器都是计划要替换掉的服务器。
整合的力度还是很大的，整合后的预计架构图如下，看起来简单清晰多了。
当然迁移的过程自己也算是老司机了，复杂的场面都经历过了，这类迁移自然也不在话下，不过不管怎么样，每次实践都会发现一些值得改进的地方。因为是数据整合式迁移，有几个小问题尤其需要注意。
1)业务2的数据要整合到业务1，在Oracle中也就意味着要迁移schema,对于全局业务而言，这类问题就需要提前安排，计划，确认。我发现业务1和业务2里面竟然有一个同名的用户，如果密码不同，那在迁移的时候可就出了大问题，临时协调应用，修改密码是一件很闹心的事情。
2）这类迁移相对要快捷一些，切换的是数据库的状态，所以数据流动性不大。但是有一点需要注意的是，先迁移数据，再切换，还是先切换再迁移数据，听起来好像都差不多，但是实践起来还是大大不同。有几个技巧可以注意，首先代表原备库1从图中来看，其实完全可以删掉，这样可以减少归档同步的量级，其次如果是先迁移数据再切换，对于原主库的压力还是不小，服务器资源老化，我还是带有一丝的顾虑，所以果断使用了先切换再迁移的方式。
在向原主库同步归档的时候，原主库开始报警，已经开始扛不住压力了，SWAP也很高，这些在新服务器上全然没有压力。
3）因为迁移的是schema,在这类迁移中需要注意的还是profile,假设我们使用如下的方式来导出数据。
impdp '/ as sysdba' directory=dp_dir parallel=4 dumpfile=exp_order_%U.dmp logfile=exp_order.log schemas=test1,test2,test3,test4
那么导出的dump中是不包含profile的信息的，再导入的过程中就会创建用户失败。还有默认的表空间等，这类信息也需要注意，提前准备好。当然role的信息也很可能会遗漏，需要提前准备好。
而MySQL的迁移相对来说思路就简单多了。当然服务器规模还是不小，简单列出一个虚拟的示意图。
迁移整合后的图就很简单了，一主一从。
迁移的数据量不是很大，所以就是直接导出导入，没什么特别之处。
mysqldump -f -hlocalhost -uroot --default-character-set=utf8 --single-transaction -R --triggers -q -B test|gzip>test.sql.gz
但是看起来很简单的操作竟然还是有一些坑。
有一个应用之前需要连接两个业务数据库，假设IP为10.11.2.182
因为MySQL侧是使用了主机名解析的方式，在业务1的主库上创建的用户为testuser1@'app1_test%',在业务2的主库上创建的用户为testuser2@'app2_test%'
这样一来需要整合的时候，在新的服务器上/etc/hosts就会存在两条记录。
# cat /etc/hosts|grep 2.182
10.11.2.182 app1_test_2.182
10.11.2.182 app2_test_2.182
这样一来原本在业务2的主库上连接正常的应用抛出了错误。
[Note] Access denied for user 'testuser2'@'app1_test_2_182' (using password: YES)
这个问题刚开始看到，还是有点懵，还以为是应用端修改了密码，配置的问题，还以为是源库的权限没有迁移完整，最后才发现，这类问题如果在/etc/hosts中存在两条同样IP的记录，是优先解析第一条的。所以配置‘testuser2’@app1_test%'的权限即可。
整个过程虽然思路清晰，步骤明确，但是还是需要很多的细节需要注意，小心驶得万年船。
写到最后，突然想到明天就是第1000天的笔记了，咱继续来点实在的，送几本我的书吧，书已经备好（自己花钱已经买好了），明天咱们来互动一下，送出一些福利。
