MySQL迁移方案(后续再补充)

出处：黑洞中的奇点 的博客 http://www.cnblogs.com/kelvin19840813/ 您的支持是对博主最大的鼓励，感谢您的认真阅读。本文版权归作者所有，欢迎转载，但请保留该声明。

1 Master - 1 Slave 结构迁移Slave

• 查看监控在业务低访问量时Master 压力大还是Slave压力大, 使用xtrabackup 备份 , 如果是从Slave备份带上 " --slave-info " 参数 , SCP 传输到 C-Slave ( 后备从库 )  , 然后在 C-Slave 进行恢复操作并且Change Master 到 Master , 停Slave ,
• 使用pt-table-sync , pt-table-checksum 数据校验 ,最后把读业务的应用切换到C-Slave ,
• 这样做主从库受影响少,对Slave进行备份读库操作和流备份写盘操作,流备份只对网络有影响 ,一般服务器都有多个网卡, 有划分为业务端口,管理端口,其他用途端口

解决  rsync 从库前要把应用切换读操作到Master , 增加Master访问压力,没有人能够预计在低访问量时候会不会突然增加.

1 Master - 1 Slave 结构完整迁移1 Master - 1 Slave

• 查看监控在业务低访问量时Master 压力大还是Slave压力大, 使用xtrabackup 备份 , 如果是从Slave备份 带上 " --slave-info " 参数 , SCP 传输到 C-Master ( 后备主库 ) 和  C-Slave ( 后备从库 )
• 然后在 C-Master 进行恢复操作并且Change Master 到 Master 、 C-Slave 进行恢复操作并且reset master 和 Change Master 到 C-Master , 这时候 C-Master 和 C-Slave 数据是一样的 ,待C-Master跟Master数据同步完成把业务应用切换到C-Master 和C-Slave
• 这样做主从库受影响少,对Slave进行备份读库操作和流备份写盘操作,流备份只对网络有影响 ,一般服务器都有多个网卡, 有划分为业务端口,管理端口,其他用途端口

为什么不使用mydumper 或者mysqldump 导出库呢？

针对水平和垂直分库分表进行指定库或者指定表迁移

原Master – Slave 已经进行对库垂直拆分和水平拆分 ， 由于业务访问量增长过多，服务器硬件限制，再对库和表进行垂直拆分和水平拆分也不能解决访问压力，从而进行物理上水平拆分，也需要应用上进行跨库跨节点进行join

• 查看监控在业务低访问量时Master 压力大还是Slave压力大, 使用xtrabackup 备份 , 如果是Slave 带上 " --slave-info " 参数 , 另外使用 ‘ --databases="database1.mytable1 .... mysql" ‘ 参数进行指定库和指定表进行备份但不能进行流备份，两个功能暂时有冲突，只能文件级别备份再用rsync或者scp 进行复制，此时C-Master-1和C-Slave-1备份数据是一样的, C-Master-2和C-Slave-2备份数据一样。
• 分别对表和库进行备份传输到C-Master-*和C-Slave-*后进行恢复，C-Slave-* 要reset master , C-Master-1和C-Master-2要change master 到 Master , C-Slave-* 要change master 到所连接的C-Master
• 待C-Master-*跟Master数据同步完成把业务应用切换
• 这样做影响业务最少, 还是那句话 没有人能够预计在低访问量时候会不会突然增加.

注意事项：

每台机器的 server_id 必须保证不一致，否则会出现同步异常的情况 , 配置 replicate-ignore-db 和 replicate-wild-do-table , 从库记得把 read_only = 1 加上