不能直接对从库停机做磁盘扩容，因为会中断复制、丢失GTID或binlog位置导致主从不一致，且造成客户端连接拒绝；必须采用xtrabackup热拷贝迁移方案实现真正在线扩容。
为什么不能直接对从库停机做磁盘扩容
MySQL 从库停机扩容磁盘（比如 lvextend + resize2fs 后重启 mysqld）看似简单，但实际会中断复制、丢失 GTID 或 binlog position，导致主从不一致；更关键的是，mysqld 进程停止期间，应用若依赖该从库读取（如分库分表中间件路由到此节点），就会出现连接拒绝或查询失败——这就不满足“在线不宕机”前提。
物理层扩容本身不涉及 MySQL 数据逻辑，真正要保的是：复制持续运行、SQL 线程不中断、客户端连接不掉、数据目录路径与权限不变。
- 停机操作会让
Seconds_Behind_Master突变为NULL，且SHOW SLAVE STATUS中Slave_IO_Running和Slave_SQL_Running都变成No - 即使快速重启，也可能因 relay log 文件被轮换或清理而无法续传，需手动
CHANGE MASTER TO指定新 position - 某些高可用架构（如 MHA、Orchestrator）会将异常从库自动下线，触发故障转移误判
用 xtrabackup 做“热拷贝迁移”才是真在线方案
核心思路不是扩原盘，而是新建更大空间的目录，用 xtrabackup 把当前从库数据（含 relay log、master info、gtid_executed）完整热拷贝过去，再原子切换 datadir。整个过程 mysqld 不停，复制线程照常工作，客户端无感知。
关键点在于：必须使用 --slave-info 和 --safe-slave-backup，且恢复时保留原始 relay-log.info 和 master.info（MySQL 5.7+ 默认已弃用后者，改用 mysql.slave_master_info 表，但 xtrabackup 仍会备份）。
-
xtrabackup --backup --target-dir=/backup/full --slave-info --safe-slave-backup --datadir=/var/lib/mysql：确保备份时刻 SQL 线程已暂停并刷新 relay log，记录准确的Exec_Master_Log_Pos - 拷贝完成后，先
innobackupex --apply-log /backup/full，再rsync -av --delete /backup/full/ /new/mysql-data/（注意末尾斜杠） - 修改
/etc/my.cnf中datadir指向新路径，确保mysql用户有读写权限，然后systemctl restart mysqld—— 此时复制会自动从原 position 继续
容易被忽略的三个细节
很多人按流程走完发现复制报错，问题往往出在这些地方：
-
innodb_log_file_size必须和原实例完全一致，否则mysqld启动失败报错InnoDB: The log file size is different；xtrabackup 备份不包含日志文件，需手动校验并保留原ib_logfile*或按配置重建 - 新目录下
mysql子目录权限必须是mysql:mysql，且socket、pid-file路径需同步更新，否则mysqladmin ping失败 - 如果启用了
relay_log_recovery=ON（推荐），MySQL 重启后会自动重建 relay log，但前提是relay-log-index文件存在且内容正确；xtrabackup 默认不备份它，需额外cp /var/lib/mysql/relay-bin.index /new/mysql-data/
验证是否真正“不宕机”的检查项
切完 datadir 后别急着撤备份，跑几条命令确认状态干净：
-
SELECT @@read_only;应为ON（保证仍是只读从库） -
SHOW SLAVE STATUS\G中Seconds_Behind_Master应为非负整数且缓慢增长，Slave_IO_Running和Slave_SQL_Running都是Yes -
tail -n 1 /new/mysql-data/relay-bin.000001查看最新 relay log 是否有新事件写入（而非停留在备份时刻） - 用
mysql -h 从库IP -e "SELECT SLEEP(1)"模拟客户端连接，确认响应时间未明显升高
最麻烦的不是操作步骤，而是误以为“服务没挂”就等于“业务无损”——真实场景中，连接池超时、长事务阻塞、监控告警抖动，都可能藏在平滑切换的表象之下。
