正文
分为三个阶段：
1）建立主从复制，将原集群的数据复制到新集群。
2）在原集群上加一层 proxy，用于流量转发，通过 proxy 来控制流量分发到哪个集群；此时，通知业务开发，修改连接到 proxy（连接方式可以是虚 IP、域名、服务名等）。
3）接下来就是 DBA 的工作，观察流量，业务流量都切到 proxy 之后，切断 Source 到 Target 的主从复制，确保数据一致之后，使用代理，将流量打到目的端数据库。需要注意的是，在切流量和断复制时，要保证时间足够短，并且复制没有延时。最后通过切换虚拟 ip 或修改 DNS 解析等，下掉 proxy，最终程序直接访问目的端数据库。或者通知业务在修改一次连接方式，从 proxy 到目的端数据库。
总结一下迁移方案的优劣势。
优势：该方案的优势在于，加入 proxy 之后，可以由 DBA 来控制入口流量的分发。开发在发布程序修改连接方式时，支持滚动发布，两种访问方式并存，不需要停服；另一方面，DBA 和开发工作解藕，不需要在某个固定时间发布程序，进行割接，DBA 可以通过流量来源来判断业务通过哪种方式来访问数据库，确保流量是否切干净。
劣势：架构相对复杂，对 DBA 来说增加了运维成本和难度。业务中断时间取决于 proxy 重启时间，也就是将流量从 Source 集群切到 Target 集群的中断时间，不过一般来说非常快，可以控制在秒级以内。数据库连接会出现闪断，需要确保业务能够重连，同时还要保证主从数据的一致性。
对比上面的两种迁移方案，可以说各有千秋，有各自适用的场景，第一种方案比较适用于业务能够接受中断，数据库集群使用方比较明确，不存在多个业务混用情况，否则停机维护将会是一个巨大的工程。另一方面，需要业务方值得
信赖
。
这里信赖为什么要加粗显示呢？一定是有故事在其中。前面也说到，需要业务在特定的时间内，完成连接方式的修改，从老集群地址修改到访问新集群。流量切换干净与否完全取决于业务方，在停服期间，DBA 没有办法判断业务流量是否切换干净，是否还有残余的流量在老的集群中写入，只有业务启动之后才能判断。如果流量没有切干净，那一切都晚了，业务开始双写，数据不一致了，想想怎么回滚或者补数据去吧。但对于有“心机”的 DBA 来说，可能不那么信任业务，会悄悄的留一手，通过老集群设置只读、回收用户权限等方式，让业务没法再往老集群写入。通过损失业务的方式来保证数据一致性，这样下来，第二种方案优势就非常明显了。
第二种方案最核心的思想就在于让数据库可同时提供两种访问方式，两种访问方式同时指向一个数据库实例，可以让业务平滑的在两种方式之间过渡。业务开发和 DBA 工作解藕，有充足的时间去发布程序，DBA 也有相应的手段来判断业务流量是否切彻底，确保数据一致。
基于上述的第二种方案的思想，下面介绍 Qunar 内部架构升级迁移方案。先来了解下去哪儿网的数据库架构。
集群架构图如下：
MMM（Master-Master replication manager for MySQL）是一套比较老的数据库高可用架构了，早期在 Qunar 内部使用比较广泛。采用 Monitor 和 Agent 来监控和管理 MySQL 的双向复制。业务同一时刻只允许对一个主进行写入，另一台备选主上只提供读服务，还可增加 Slave 节点，用于读负载均衡，使用虚拟IP对外提供服务，不受客户端的限制。
MMM 采用 VIP 漂移方式实现的故障转移，由于使用的是异步复制，无法完全的保证数据一致性，所以适用于对数据的一致性要求不是很高，但是又想最大程度的保证业务可用性的场景。对于那些对数据的一致性要求很高的业务，不建议采用 MMM 这种高可用架构，并且 MMM 不支持网络分区，无法实现跨机房部署。
详细介绍请移步到官网：
https://mysql-mmm.org
