导读：将一个实例上面的MySQL请求转向另外一个MySQL实例上面。

源服务：172.16.3.6:3306 主库

目标服务：172.16.3.7:3306 从库

访问账户: test_01@172.16.3.15

新旧实例以及搭建主从

1. 在源服务上面开启端口转发服务：

shell>> sudo vim /etc/sysctl.conf
vim>> net.ipv4.ip_forward=1 ##在文件中修改这个选项为1
shell>> sudo sysctl -p
shell>> sudo /etc/ini.d/iptables start
shell>> sudo iptables -t nat -A PREROUTING -d 172.16.3.6 -p tcp --dport 3306 -j DNAT --to-destination 172.16.3.7:3306
shell>> sudo iptables -t nat -A POSTROUTING -j MASQUERADE
或者    sudo iptables -t nat -A POSTROUTING -d 172.16.3.7 -p tcp --dport 3306 -j SNAT -to-source 172.16.3.6
shell>> sudo service iptables save
shell>> sudo service iptables restart

2. 在目标服务上面开启3306服务和创建访问账户：

shell>> sudo iptables -A INPUT -s 172.16.3.0/24 -m state --state NEW  -m tcp -p tcp --dport 3306 -j ACCEPT
shell>> sudo service iptables save
shell>> sudo service iptables restart

mysql>> grant select,update,insert,delete on *.* to 'test_01'@'172.16.3.6' identified by 'new_password';
mysql>> flush privileges;
mysql>> \q

切记：端口转发设置完毕之后，在172.16.3.15上面使用账号test_01@172.16.3.15 去连接172.16.3.6，这个时候172.16.3.6的iptables会将请求转发到172.16.3.7上面的MySQL服务上面，这个时候连接的账号由test_01@172.16.3.15变成了test_01@172.16.3.6，所以我才会在第二步的时候在172.16.3.7上面创建账号test_01@172.16.3.6，并且这账号的密码必须和账号test_01@172.16.3.15这个账号的密码一致。实际上在目标服务172.16.3.7:3306上面可以不需要创建test_01@172.16.3.15这个账号，并且在源服务172.16.3.6:3306这个服务在做好端口转发之后可以关掉这个实例。

3.总结

在整个业务迁移的过程中，存在的情况有如下：

a.旧的MySQL实例上面存在多个业务。

b.旧的MySQL实例上面存在长连接。

c.不同的业务存在针对同一张表的修改操作。

d.所有业务的连接使用都是精确匹配，即都是test@ip这种情况。

e.binlog_format是statement格式，但是有写SQL使用了类似与now()的函数，导致主从数据有些table的时间字段数据不一致。

使用iptables做转发的目的和缺陷(新旧实例以及搭建主从)：

目的：主要是为了在避免不同的业务针对同一张表的修改导致数据不一致。例如：业务A和业务B都可以针对表table_01有修改的权限,并且test_01的主键是自增主键，业务插入的时候不会显示的插入主键键值。当业务A先切换过去的时候,业务B还没有切换，这个时候业务先插入数据到table_01，然后一段时间之后业务B插入数据到table_01。这个时候就会出现1062主键冲突，并且这个时候是以旧的MySQL实例为主还是以新的MySQL实例为主。

缺陷：1.但是假如业务B是长连接的话，在没有重启业务B的情况下，业务B还是存在和旧的MySQL实例连接的情况，那么上诉所说的情况还是可能会发生；2.因为所有的业务的账号都是精确匹配的，所以有在旧的实例上面有些业务的username是一样的,但是ip可能不一样，那么它们的权限和账号也是不一样的。但是在使用iptables转发之后，所有的账号的匹配的ip地址全部变更成了172.16.3.6，所以有些业务它们最后连接到172.16.3.7:3306实例的账号就是一摸一样的，但是又有一个问题出现了，就是所有业务的账号密码肯定存在不一样的情况，这个时候它们发起请求的密码也是不一样的，但是它们最后连接到172.16.3.7:3306的账号是一摸一样，一个账号只能对应一个账号密码信息，那么就会出现所有的业务只有密码是一样的才能正常的请求访问，密码不一致的请求就会被拒绝掉。

解决方案：重启新的MySQL实例，重启的时候加上--skip-grant-tables 。等所有的业务切换之后再次重启新的MySQL实例。