* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。
一、前提
在一套非常老的系统上，有一套GreatSQL主从集群（1主1从），主从复制采用的是FILE+POS方式复制，磁盘使用紧张需要扩容，只能在该台机器上添加更大的磁盘，将原数据盘替换，也没有其他的机器资源替换。这套系统没有VIP，没有高可用切换工具，业务读写直连主节点，从节点可供读，允许有一定的延迟，全程磁盘扩容需要手动操作，以下方案步骤是模拟最快的方式去进行磁盘扩容。
二、整体思路是
在主节点机器上挂载一块新磁盘，在新磁盘上搭建一个新的从节点，旧从节点的主变为新从节点，最后将主节点与新从节点准备好配置文件后，关闭主节点，将新从节点使用新的配置文件重启，端口号为旧主port，新主实例顶替旧主成功。
三、模拟环境
主从架构
db01:master，172.17.135.81:3306
db02:slave02，172.17.134.225:3306
原主从db01 master复制数据到db02 slave02，现在在db01上搭建新的从节点slave01，并将slave01提升为新的主节点master02
db01：IP为172.17.135.81
master ：port 3306
slave01：port 3307
db02：IP为172.17.134.225
slave02：port 3306
四、以下操作为模拟切换流程
1）.在db01上master 数据放在磁盘 /data/
使用xtrabackup工具备份并搭建db01 slave01 数据放在磁盘/data2/上
2）.改变db02 slave02 数据源为 db01 slave01（即db02 slave02 从db01-slave01同步数据），后期切换数据库
操作过程
01.停掉db02 slave02 复制线程
先停slave02目的是，slave02获取执行的binlog比db01 slave01上的binlog少，方便后续db02 slave02 追数据到db01 slave01 指定的位点
![]()
02.观察db02 slave02（一定要小于04步骤的位置）
greatsql> show slave status\G
Relay_Master_Log_File: mysql-bin.000002
Exec_Master_Log_Pos: 61781270
![]()
03.停掉db01 slave01主从线程
观察主从复制情况，确认 db01 slave01 获取主节点位点比db02 slave02 大,然后停掉主从，方便方便获取db01 slave01上的binlog位置信息（show master status）
观察标记部分比db02 slave02大
![]()
停止复制
![]()
04.观察db01 slave01
greatsql> show slave status\GRelay_Master_Log_File: mysql-bin.000002Exec_Master_Log_Pos:73110158
![]()
05.观察db01 slave01
与获取主节点过来的binlog位点信息与当前节点上binlog位点信息对应关系
greatsql> show master status;
File :mysql-bin.000003
Position : 48396034
![]()
06.开启db01 slave01 主从线程
使db01 slave01 正常追数据
greatsql> start slave;
07.db02 slave02 执行 until 的位置 为（04步骤）得到的值
追binlog至指定位点，该位点对应着db01 slave01 节点上show master status获取的位点信息
greatsql> start slave until MASTER_LOG_FILE ='mysql-bin.000002',MASTER_LOG_POS =73110158;
![]()
观察状态，是否到指定位点停止
greatsql> show slave status \G
![]()
到指定位点停止后，停掉主从复制
greatsql> stop slave;
![]()
08.db02 slave02 从db01 slave01获取数据源（即重新指定db02 slave02 主库信息）
根据04 、05 获取的主binlog位点与db01 slave01 binlog位点对应关系，将db02 slave02复制关系指定位从db01 slave01获取binlog数据,重启主从复制，并观察主从状态
在db02 slave02 重新指定复制关系
greatsql> reset slave all;
greatsql> CHANGE MASTER TO MASTER_HOST= '172.17.135.81',MASTER_USER='rpl', MASTER_PASSWORD='rpl123!',MASTER_PORT=3307,MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=48396034;
greatsql> start slave;
![]()
观察复制状态，等待复制正常之后在进行下一步，避免数据丢失
greatsql> show slave status \G
![]()
09.通知将业务停止，避免数据更新，观察全部节点是否处于同一binlog位点状态
在db01 master节点上观察
![]()
观察db01 slave01 主从是否正常，且无延迟
greatsql> show slave status\G
![]()
greatsql> show master status；
![]()
观察 db02 slave02
![]()
10.停止db02 slave 02
greatsql> stop slave；
11.在db02 slave 02观察
greatsql> show slave status\G
Relay_Master_Log_File: mysql-bin.000003
Exec_Master_Log_Pos: 114096916
12.先后正常关闭 db01 master，然后关闭db01 slave01
修改配置文件db01 slave01 端口号为3306
13.启动db01 slave01（不要启动db01 master）
登录db01 slave01 清除复制信息
greatsql> reset slave all;
14.重置db02 slave02主从复制信息,从新的主节点拉取数据
greatsql> CHANGE MASTER TO MASTER_HOST= '172.17.135.81',MASTER_USER='rpl', MASTER_PASSWORD='rpl123!',MASTER_PORT=3306,MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=114096916;
greatsql> show slave status\G
![]()
15、通知业务重连，磁盘扩容完成
五、案例总结
本案例主要是针对非GTID复制、无自动切换、无VIP、无新机器、磁盘无法动态扩容的场景。
核心思想是找到对应的binlog位点信息，在重新指定主从信息，在重新指定主从信息之前，可以做准备工作，例如主节点上的新备主节点可以提前准备，配置文件可以提前准备，命令提前准备好，通过填补的方式将关键信息填到对应的命令中，尽量的去节省时间以及追数时间，促使业务宕机时间达到最短。
一、前提
在一套非常老的系统上，有一套GreatSQL主从集群（1主1从），主从复制采用的是FILE+POS方式复制，磁盘使用紧张需要扩容，只能在该台机器上添加更大的磁盘，将原数据盘替换，也没有其他的机器资源替换。这套系统没有VIP，没有高可用切换工具，业务读写直连主节点，从节点可供读，允许有一定的延迟，全程磁盘扩容需要手动操作，以下方案步骤是模拟最快的方式去进行磁盘扩容。
二、整体思路是
在主节点机器上挂载一块新磁盘，在新磁盘上搭建一个新的从节点，旧从节点的主变为新从节点，最后将主节点与新从节点准备好配置文件后，关闭主节点，将新从节点使用新的配置文件重启，端口号为旧主port，新主实例顶替旧主成功。
三、模拟环境
主从架构
db01:master，172.17.135.81:3306
db02:slave02，172.17.134.225:3306
原主从db01 master复制数据到db02 slave02，现在在db01上搭建新的从节点slave01，并将slave01提升为新的主节点master02
db01：IP为172.17.135.81
master ：port 3306
slave01：port 3307
db02：IP为172.17.134.225
slave02：port 3306
四、以下操作为模拟切换流程
1）.在db01上master 数据放在磁盘 /data/
使用xtrabackup工具备份并搭建db01 slave01 数据放在磁盘/data2/上
2）.改变db02 slave02 数据源为 db01 slave01（即db02 slave02 从db01-slave01同步数据），后期切换数据库
操作过程
01.停掉db02 slave02 复制线程
先停slave02目的是，slave02获取执行的binlog比db01 slave01上的binlog少，方便后续db02 slave02 追数据到db01 slave01 指定的位点
02.观察db02 slave02（一定要小于04步骤的位置）
greatsql> show slave status\G
Relay_Master_Log_File: mysql-bin.000002
Exec_Master_Log_Pos: 61781270
03.停掉db01 slave01主从线程
观察主从复制情况，确认 db01 slave01 获取主节点位点比db02 slave02 大,然后停掉主从，方便方便获取db01 slave01上的binlog位置信息（show master status）
观察标记部分比db02 slave02大
停止复制
04.观察db01 slave01
greatsql> show slave status\GRelay_Master_Log_File: mysql-bin.000002Exec_Master_Log_Pos:7311015805.观察db01 slave01
与获取主节点过来的binlog位点信息与当前节点上binlog位点信息对应关系
greatsql> show master status;
File :mysql-bin.000003
Position : 48396034
06.开启db01 slave01 主从线程
使db01 slave01 正常追数据
greatsql> start slave;
07.db02 slave02 执行 until 的位置 为（04步骤）得到的值
追binlog至指定位点，该位点对应着db01 slave01 节点上show master status获取的位点信息
greatsql> start slave until MASTER_LOG_FILE ='mysql-bin.000002',MASTER_LOG_POS =73110158;
观察状态，是否到指定位点停止
greatsql> show slave status \G
到指定位点停止后，停掉主从复制
greatsql> stop slave;
08.db02 slave02 从db01 slave01获取数据源（即重新指定db02 slave02 主库信息）
根据04 、05 获取的主binlog位点与db01 slave01 binlog位点对应关系，将db02 slave02复制关系指定位从db01 slave01获取binlog数据,重启主从复制，并观察主从状态
在db02 slave02 重新指定复制关系
greatsql> reset slave all;
greatsql> CHANGE MASTER TO MASTER_HOST= '172.17.135.81',MASTER_USER='rpl', MASTER_PASSWORD='rpl123!',MASTER_PORT=3307,MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=48396034;
greatsql> start slave;
观察复制状态，等待复制正常之后在进行下一步，避免数据丢失
greatsql> show slave status \G
09.通知将业务停止，避免数据更新，观察全部节点是否处于同一binlog位点状态
在db01 master节点上观察
观察db01 slave01 主从是否正常，且无延迟
greatsql> show slave status\G
greatsql> show master status；
观察 db02 slave02
10.停止db02 slave 02
greatsql> stop slave；
11.在db02 slave 02观察
greatsql> show slave status\G
Relay_Master_Log_File: mysql-bin.000003
Exec_Master_Log_Pos: 114096916
12.先后正常关闭 db01 master，然后关闭db01 slave01
修改配置文件db01 slave01 端口号为3306
13.启动db01 slave01（不要启动db01 master）
登录db01 slave01 清除复制信息
greatsql> reset slave all;
14.重置db02 slave02主从复制信息,从新的主节点拉取数据
greatsql> CHANGE MASTER TO MASTER_HOST= '172.17.135.81',MASTER_USER='rpl', MASTER_PASSWORD='rpl123!',MASTER_PORT=3306,MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=114096916;
greatsql> show slave status\G
15、通知业务重连，磁盘扩容完成
五、案例总结
本案例主要是针对非GTID复制、无自动切换、无VIP、无新机器、磁盘无法动态扩容的场景。
核心思想是找到对应的binlog位点信息，在重新指定主从信息，在重新指定主从信息之前，可以做准备工作，例如主节点上的新备主节点可以提前准备，配置文件可以提前准备，命令提前准备好，通过填补的方式将关键信息填到对应的命令中，尽量的去节省时间以及追数时间，促使业务宕机时间达到最短。
《GreatSQL运维实战》视频课程
GreatSQL数据库是一款开源免费数据库，可在普通硬件上满足金融级应用场景，具有高可用、高性能、高兼容、高安全等特性，可作为MySQL或Percona Server for MySQL的理想可选替换。
⏩GitHub : https://github.com/GreatSQL/
🆙BiliBili : https://space.bilibili.com/1363850082
（对文章有疑问或见解可去社区官网提出哦~）
| 加入微信交流群 | 加入QQ交流群 |
