臭鼠标1. MariaDB系统盘数据迁移至数据盘实战指南
作为一款广受欢迎的开源关系型数据库，MariaDB在各类生产环境中承担着重要角色。但在实际运维中，很多DBA都会遇到一个典型问题：初期将MariaDB安装在系统盘上，随着业务增长，系统盘空间不足导致性能下降甚至服务中断。我最近就处理了一个线上案例，某电商平台的MariaDB实例因系统盘爆满导致订单服务瘫痪2小时，损失惨重。本文将分享如何安全高效地将MariaDB从系统盘迁移至专用数据盘的全过程。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 迁移前的关键准备工作
2.1 环境检查与风险评估
在开始迁移前，必须进行完整的系统检查：
- 使用
df -h确认当前数据库目录所在分区及剩余空间 - 通过
mysql -V记录当前MariaDB版本（例如10.5.8） - 执行
SHOW VARIABLES LIKE 'datadir'获取当前数据目录位置 - 用
SHOW STATUS查看数据库运行状态和连接数
重要提示：务必在业务低峰期操作，并提前通知相关团队。我曾遇到迁移过程中突发大流量导致锁表现象，后来养成了在操作前用
pt-kill设置查询超时阈值的习惯。
2.2 新数据盘配置要点
新数据盘的选型和配置直接影响后期性能：
- 对于SSD盘，建议使用
fio工具测试实际IOPS（随机读写应＞3000） - 分区时建议采用GPT格式，使用
parted工具更可靠 - 文件系统推荐XFS（特别是大表场景），格式化命令示例：
bash复制
mkfs.xfs -f -L mariadb_data /dev/sdb1 - 若使用LVM，可预留20%空间方便后期扩展：
bash复制
lvcreate -L 500G -n mariadb-lv vg-data
3. 分步迁移实施方案
3.1 数据全量备份策略
即使后续使用增量同步，全量备份仍是必须的：
bash复制# 使用mariabackup进行热备（需提前安装）
mariabackup --backup --target-dir=/backups/full \
--user=backup_user --password='complex_pwd'
# 验证备份一致性
mariabackup --prepare --target-dir=/backups/full
3.2 数据目录迁移实操
-
停止MariaDB服务（不同系统命令可能不同）：
bash复制
systemctl stop mariadb -
同步数据到新位置（保持权限不变）：
bash复制
rsync -avzP /var/lib/mysql/ /mnt/data/mariadb/ -
修改配置文件：
ini复制[mysqld] datadir=/mnt/data/mariadb socket=/mnt/data/mariadb/mysql.sock -
更新SELinux上下文（如启用）：
bash复制semanage fcontext -a -t mysqld_db_t "/mnt/data/mariadb(/.*)?" restorecon -Rv /mnt/data/mariadb
3.3 服务恢复与验证
-
启动服务并检查状态：
bash复制
systemctl start mariadb systemctl status mariadb -
连接验证：
sql复制SHOW DATABASES; SELECT TABLE_SCHEMA, SUM(data_length)/1024/1024 AS MB FROM information_schema.TABLES GROUP BY TABLE_SCHEMA;
4. 高级场景处理方案
4.1 最小停机时间迁移
对于不能长时间停机的业务，可采用主从复制方案：
- 在新数据盘部署从库并同步数据
- 主库短暂停机执行
FLUSH TABLES WITH READ LOCK - 记录主库binlog位置后解锁
- 将从库提升为主库并切换应用连接
4.2 云环境特殊处理
在AWS/Aliyun等云平台需注意：
- 避免直接挂载新盘到/mnt，推荐使用
/data目录 - 云盘性能突发限制需要特别关注
- 安全组规则需允许新端口访问（如切换了socket位置）
5. 故障排查与性能优化
5.1 常见问题速查表
| 故障现象 | 可能原因 | 解决方案 |
|---|---|---|
| 启动报错"Can't create/write to file" | 目录权限问题 | 检查mysql用户权限和SELinux上下文 |
| 连接时报"socket not found" | socket路径未更新 | 确认my.cnf和客户端配置一致 |
| 性能下降明显 | 新磁盘IO瓶颈 | 使用iostat -x 1检查await值 |
5.2 迁移后性能调优
-
调整InnoDB参数适应新硬件：
ini复制innodb_io_capacity = 2000 # 对SSD可提高到2000-4000 innodb_flush_neighbors = 0 # SSD建议关闭 -
配置合适的deadline调度器：
bash复制echo deadline > /sys/block/sdb/queue/scheduler -
定期维护脚本示例：
bash复制# 每周优化表 mysqlcheck --optimize --all-databases
6. 自动化运维建议
对于经常需要处理的环境，可以编写自动化脚本：
bash复制#!/bin/bash
# 自动检测数据盘使用率，超过阈值自动扩展
THRESHOLD=90
USAGE=$(df -h /mnt/data | awk 'NR==2{print $5}' | tr -d '%')
if [ $USAGE -gt $THRESHOLD ]; then
lvextend -r -L +50G /dev/vg-data/mariadb-lv
systemctl restart mariadb
echo "$(date) 已自动扩展数据盘" >> /var/log/mariadb_autoextend.log
fi
实际运维中，我发现很多团队忽略了迁移后的长期监控。建议部署Prometheus+Granfa监控体系，特别关注：
- 磁盘空间增长趋势
- InnoDB缓冲池命中率
- 慢查询数量变化