不同场景下 MySQL 的迁移方案
不同场景下 MySQL 的迁移方案
阅读(38.7k) 书签 赞(0) 我要纠错

四 MySQL 迁移实战

2018-02-24 15:45 更新

四 MySQL 迁移实战

我们搞明白为什么要做迁移，以及迁移怎么做以后，接下来看看生产环境是怎样操作的。不同的应用场景，有不同的解决方案。

阅读具体的实战之前，假设和读者有如下约定：

  1. 为了保护隐私，本文中的服务器 IP 等信息经过处理；
  2. 如果服务器在同一机房，用服务器 IP 的 D 段代替服务器，具体的 IP 请参考架构图；
  3. 如果服务器在不同机房，用服务器 IP 的 C 段 和 D 段代替服务器，具体的 IP 请参考架构图；
  4. 每个场景给出方法，但不会详细地给出每一步执行什么命令，因为一方面，这会导致文章过长；另一方面，我认为只要知道方法，具体的做法就会迎面扑来的，只取决于掌握知识的程度和获取信息的能力；
  5. 实战过程中的注意事项请参考第五节。

4.1 场景一 一主一从结构迁移从库

遵循从易到难的思路，我们从简单的结构入手。A 项目，原本是一主一从结构。101 是主节点，102 是从节点。因业务需要，把 102 从节点迁移至 103，架构图如图一。102 从节点的数据容量过大，不能使用 mysqldump 的形式备份。和研发沟通后，形成一致的方案。

001-a-plan
图一 一主一从结构迁移从库架构图

具体做法是这样：

  • 研发将 102 的读业务切到主库；
  • 确认 102 MySQL 状态（主要看 PROCESS LIST），观察机器流量，确认无误后，停止 102 从节点的服务；
  • 103 新建 MySQL 实例，建成以后，停止 MySQL 服务，并且将整个数据目录 mv 到其他地方做备份；
  • 将 102 的整个 mysql 数据目录使用 rsync 拷贝到 103；
  • 拷贝的同时，在 101 授权，使 103 有拉取 binlog 的权限（REPLICATION SLAVE, REPLICATION CLIENT）；
  • 待拷贝完成，修改 103 配置文件中的 server_id，注意不要和 102 上的一致；
  • 在 103 启动 MySQL 实例，注意配置文件中的数据文件路径以及数据目录的权限；
  • 进入 103 MySQL 实例，使用 SHOW SLAVE STATUS 检查从库状态，可以看到 Seconds_Behind_Master 在递减；
  • Seconds_Behind_Master 变为 0 后，表示同步完成，此时可以用 pt-table-checksum 检查 101 和 103 的数据一致，但比较耗时，而且对主节点有影响，可以和开发一起进行数据一致性的验证；
  • 和研发沟通，除了做数据一致性验证外，还需要验证账号权限，以防业务迁回后访问出错；
  • 做完上述步骤，可以和研发协调，把 101 的部分读业务切到 103，观察业务状态；
  • 如果业务没有问题，证明迁移成功。

4.2 场景二 一主一从结构迁移指定库

我们知道一主一从只迁移从库怎么做之后，接下来看看怎样同时迁移主从节点。因不同业务同时访问同一服务器，导致单个库压力过大，还不便管理。于是，打算将主节点 101 和从节点 102 同时迁移至新的机器 103 和 104，103 充当主节点，104 充当从节点，架构图如图二。此次迁移只需要迁移指定库，这些库容量不是太大，并且可以保证数据不是实时的。

002-b-plan
图二 一主一从结构迁移指定库架构图

具体的做法如下：

  • 103 和 104 新建实例，搭建主从关系，此时的主节点和从节点处于空载；
  • 102 导出数据，正确的做法是配置定时任务，在业务低峰做导出操作，此处选择的是 mysqldump；
  • 102 收集指定库需要的账号以及权限；
  • 102 导出数据完毕，使用 rsync 传输到 103，必要时做压缩操作；
  • 103 导入数据，此时数据会自动同步到 104，监控服务器状态以及 MySQL 状态；
  • 103 导入完成，104 同步完成，103 根据 102 收集的账号授权，完成后，通知研发检查数据以及账户权限；
  • 上述完成后，可研发协作，将 101 和 102 的业务迁移到 103 和 104，观察业务状态；
  • 如果业务没有问题，证明迁移成功。

4.3 场景三 一主一从结构双边迁移指定库

接下来看看一主一从结构双边迁移指定库怎么做。同样是因为业务共用，导致服务器压力大，管理混乱。于是，打算将主节点 101 和从节点 102 同时迁移至新的机器 103、104、105、106，103 充当 104 的主节点，104 充当 103 的从节点，105 充当 106 的主节点，106 充当 105 的从节点，架构图如图三。此次迁移只需要迁移指定库，这些库容量不是太大，并且可以保证数据不是实时的。我们可以看到，此次迁移和场景二很类似，无非做了两次迁移。

003-c-plan
图三 一主一从结构双边迁移指定库架构图

具体的做法如下：

  • 103 和 104 新建实例，搭建主从关系，此时的主节点和从节点处于空载；
  • 102 导出 103 需要的指定库数据，正确的做法是配置定时任务，在业务低峰做导出操作，此处选择的是 mysqldump；
  • 102 收集 103 需要的指定库需要的账号以及权限；
  • 102 导出103 需要的指定库数据完毕，使用 rsync 传输到 103，必要时做压缩操作；
  • 103 导入数据，此时数据会自动同步到 104，监控服务器状态以及 MySQL 状态；
  • 103 导入完成，104 同步完成，103 根据 102 收集的账号授权，完成后，通知研发检查数据以及账户权限；
  • 上述完成后，和研发协作，将 101 和 102 的业务迁移到 103 和 104，观察业务状态；
  • 105 和 106 新建实例，搭建主从关系，此时的主节点和从节点处于空载；
  • 102 导出 105 需要的指定库数据，正确的做法是配置定时任务，在业务低峰做导出操作，此处选择的是 mysqldump；
  • 102 收集 105 需要的指定库需要的账号以及权限；
  • 102 导出 105 需要的指定库数据完毕，使用 rsync 传输到 105，必要时做压缩操作；
  • 105 导入数据，此时数据会自动同步到 106，监控服务器状态以及 MySQL 状态；
  • 105 导入完成，106 同步完成，105 根据 102 收集的账号授权，完成后，通知研发检查数据以及账户权限；
  • 上述完成后，和研发协作，将 101 和 102 的业务迁移到 105 和 106，观察业务状态；
  • 如果所有业务没有问题，证明迁移成功。

4.4 场景四 一主一从结构完整迁移主从

接下来看看一主一从结构完整迁移主从怎么做。和场景二类似，不过此处是迁移所有库。因 101 主节点 IO 出现瓶颈，打算将主节点 101 和从节点 102 同时迁移至新的机器 103 和 104，103 充当主节点，104 充当从节点。迁移完成后，以前的主节点和从节点废弃，架构图如图四。此次迁移是全库迁移，容量大，并且需要保证实时。这次的迁移比较特殊，因为采取的策略是先替换新的从库，再替换新的主库。所以做法稍微复杂些。

004-d-plan
图四 一主一从结构完整迁移主从架构图

具体的做法是这样：

  • 研发将 102 的读业务切到主库；
  • 确认 102 MySQL 状态（主要看 PROCESS LIST，MASTER STATUS），观察机器流量，确认无误后，停止 102 从节点的服务；
  • 104 新建 MySQL 实例，建成以后，停止 MySQL 服务，并且将整个数据目录 mv 到其他地方做备份，注意，此处操作的是 104，也就是未来的从库；
  • 将 102 的整个 mysql 数据目录使用 rsync 拷贝到 104；
  • 拷贝的同时，在 101 授权，使 104 有拉取 binlog 的权限（REPLICATION SLAVE, REPLICATION CLIENT）；
  • 待拷贝完成，修改 104 配置文件中的 server_id，注意不要和 102 上的一致；
  • 在 104 启动 MySQL 实例，注意配置文件中的数据文件路径以及数据目录的权限；
  • 进入 104 MySQL 实例，使用 SHOW SLAVE STATUS 检查从库状态，可以看到 Seconds_Behind_Master 在递减；
  • Seconds_Behind_Master 变为 0 后，表示同步完成，此时可以用 pt-table-checksum 检查 101 和 104 的数据一致，但比较耗时，而且对主节点有影响，可以和开发一起进行数据一致性的验证；
  • 除了做数据一致性验证外，还需要验证账号权限，以防业务迁走后访问出错；
  • 和研发协作，将之前 102 从节点的读业务切到 104；
  • 利用 102 的数据，将 103 变为 101 的从节点，方法同上；
  • 接下来到了关键的地方了，我们需要把 104 变成 103 的从库；
    • 104 STOP SLAVE；
    • 103 STOP SLAVE IO_THREAD;
    • 103 STOP SLAVE SQL_THREAD，记住 MASTER_LOG_FILE 和 MASTER_LOG_POS；
    • 104 START SLAVE UNTIL 到上述 MASTER_LOG_FILE 和 MASTER_LOG_POS；
    • 104 再次 STOP SLAVE；
    • 104 RESET SLAVE ALL 清除从库配置信息；
    • 103 SHOW MASTER STATUS，记住 MASTER_LOG_FILE 和 MASTER_LOG_POS；
    • 103 授权给 104 访问 binlog 的权限；
    • 104 CHANGE MASTER TO 103；
    • 104 重启 MySQL，因为 RESET SLAVE ALL 后，查看 SLAVE STATUS，Master_Server_Id 仍然为 101，而不是 103；
    • 104 MySQL 重启后，SLAVE 回自动重启，此时查看 IO_THREAD 和 SQL_THREAD 是否为 YES；
    • 103 START SLAVE；
    • 此时查看 103 和 104 的状态，可以发现，以前 104 是 101 的从节点，如今变成 103 的从节点了。
  • 业务迁移之前，断掉 103 和 101 的同步关系；
  • 做完上述步骤，可以和研发协调，把 101 的读写业务切回 102，读业务切到 104。需要注意的是，此时 101 和 103 均可以写，需要保证 101 在没有写入的情况下切到 103，可以使用 FLUSH TABLES WITH READ LOCK 锁住 101，然后业务切到 103。注意，一定要业务低峰执行，切记；
  • 切换完成后，观察业务状态；
  • 如果业务没有问题，证明迁移成功。

4.5 场景五 双主结构跨机房迁移

接下来看看双主结构跨机房迁移怎么做。某项目出于容灾考虑，使用了跨机房，采用了双主结构，双边均可以写。因为磁盘空间问题，需要对 A 地的机器进行替换。打算将主节点 1.101 和从节点 1.102 同时迁移至新的机器 1.103 和 1.104，1.103 充当主节点，1.104 充当从节点。B 地的 2.101 和 2.102 保持不变，但迁移完成后，1.103 和 2.101 互为双主。架构图如图五。因为是双主结构，两边同时写，如果要替换主节点，单方必须有节点停止服务。

005-e-plan
图五 双主结构跨机房迁移架构图

具体的做法如下：

  • 1.103 和 1.104 新建实例，搭建主从关系，此时的主节点和从节点处于空载；
  • 确认 1.102 MySQL 状态（主要看 PROCESS LIST），注意观察 MASTER STATUS 不再变化。观察机器流量，确认无误后，停止 1.102 从节点的服务；
  • 1.103 新建 MySQL 实例，建成以后，停止 MySQL 服务，并且将整个数据目录 mv 到其他地方做备份；
  • 将 1.102 的整个 mysql 数据目录使用 rsync 拷贝到 1.103；
  • 拷贝的同时，在 1.101 授权，使 1.103 有拉取 binlog 的权限（REPLICATION SLAVE, REPLICATION CLIENT）；
  • 待拷贝完成，修改 1.103 配置文件中的 server_id，注意不要和 1.102 上的一致；
  • 在 1.103 启动 MySQL 实例，注意配置文件中的数据文件路径以及数据目录的权限；
  • 进入 1.103 MySQL 实例，使用 SHOW SLAVE STATUS 检查从库状态，可以看到 Seconds_Behind_Master 在递减；
  • Seconds_Behind_Master 变为 0 后，表示同步完成，此时可以用 pt-table-checksum 检查 1.101 和 1.103 的数据一致，但比较耗时，而且对主节点有影响，可以和开发一起进行数据一致性的验证；
  • 我们使用相同的办法，使 1.104 变成 1.103 的从库；
  • 和研发沟通，除了做数据一致性验证外，还需要验证账号权限，以防业务迁走后访问出错；
  • 此时，我们要做的就是将 1.103 变成 2.101 的从库，具体的做法可以参考场景四；
  • 需要注意的是，1.103 的单双号配置需要和 1.101 一致；
  • 做完上述步骤，可以和研发协调，把 1.101 的读写业务切到 1.103，把 1.102 的读业务切到 1.104。观察业务状态；
  • 如果业务没有问题，证明迁移成功。

4.6 场景六 多实例跨机房迁移

接下来我们看看多实例跨机房迁移证明做。每台机器的实例关系，我们可以参考图六。此次迁移的目的是为了做数据修复。在 2.117 上建立 7938 和 7939 实例，替换之前数据异常的实例。因为业务的原因，某些库只在 A 地写，某些库只在 B 地写，所以存在同步过滤的情况。

006-f-plan
图六 多实例跨机房迁移架构图

具体的做法如下：

  • 1.113 针对 7936 实例使用 innobackupex 做数据备份，注意需要指定数据库，并且加上 slave-info 参数；
  • 备份完成后，将压缩文件拷贝到 2.117；
  • 2.117 创建数据目录以及配置文件涉及的相关目录；
  • 2.117 使用 innobackupex 恢复日志；
  • 2.117 使用 innobackupex 拷贝数据；
  • 2.117 修改配置文件，注意如下参数：replicate-ignore-db、innodb_file_per_table = 1、read_only = 1、 server_id；
  • 2.117 更改数据目录权限；
  • 1.112 授权，使 2.117 有拉取 binlog 的权限（REPLICATION SLAVE, REPLICATION CLIENT）；
  • 2.117 CHANGE MASTE TO 1.112，LOG FILE 和 LOG POS 参考 xtrabackup_slave_info；
  • 2.117 START SLAVE，查看从库状态；
  • 2.117 上建立 7939 的方法类似，不过配置文件需要指定 replicate-wild-do-table；
  • 和开发一起进行数据一致性的验证和验证账号权限，以防业务迁走后访问出错；
  • 做完上述步骤，可以和研发协调，把相应业务迁移到 2.117 的 7938 实例和 7939 实例。观察业务状态；
  • 如果业务没有问题，证明迁移成功。
以上内容是否对您有帮助：
← 三 MySQL 迁移方案概览
五 注意事项 →

推荐文章

推荐教程

推荐课程

在线笔记
App下载
App下载

扫描二维码

下载编程狮App

公众号
微信公众号

编程狮公众号