以逻辑卷方式挂载已安装的MySQL目录

这篇博客介绍了如何关闭MySQL服务,创建卷组和逻辑卷,然后挂载到MySQL目录。接着,作者备份了原有MySQL数据,新建目录并设置权限,将备份复制到挂载点。最后,重新启动MySQL服务,确保数据迁移成功。整个过程详细地展示了Linux系统下MySQL数据的安全迁移步骤。

一、关闭MySQL

systemctl stop mysqld
ls -ld /var/lib/mysql

二、创建一个卷组、创建一个逻辑卷用于挂载MySQL目录

[root@docker ~]# vgs
VG #PV #LV #SN Attr VSize VFree
centos 1 4 0 wz–n- 98.00g 0
vg-docker 9 1 0 wz–n- 449.96g 49.96g
vg-mysql 9 1 0 wz–n- 179.96g 29.96g
[root@docker ~]# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home centos -wi-ao---- 10.00g
root centos -wi-ao---- 58.00g
swap centos -wi-ao---- 20.00g
var centos -wi-ao---- 10.00g
lv_docker vg-docker -wi-ao---- 400.00g
lv_mysql vg-mysql -wi-a----- 150.00g
[root@docker ~]# ls -l /dev/vg-mysql/lv_mysql
lrwxrwxrwx. 1 root root 7 5月 21 19:53 /dev/vg-mysql/lv_mysql -> …/dm-5

mkfs -t ext4 /dev/vg-mysql/lv_mysql

三、将源目录备份,后面复制会用到

[root@docker ~]# mv /var/lib/mysql /var/lib/mysql_bak
[root@docker ~]# mkdir -p /var/lib/mysql
[root@docker ~]# ls -l /var/lib/mysql
chown -R mysql.mysql /var/lib/mysql

四、 挂载并复制MySQL备份目录到挂点

mount /dev/vg-mysql/lv_mysql /var/lib/mysql

[root@docker ~]# echo “/dev/vg-mysql/lv_mysql /var/lib/mysql ext4 defaults 0 0” >> /etc/fstab
[root@docker ~]# mount –a

带权限复制,不然会报错

cp -r -p /var/lib/mysql_bak/* /var/lib/mysql

五、重新启动MySQL

systemctl start mysqld

[root@docker mysql]# df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/mapper/centos-root 57G 14G 41G 26% /
devtmpfs 3.8G 0 3.8G 0% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 3.9G 13M 3.9G 1% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/sda2 976M 149M 761M 17% /boot
/dev/mapper/centos-home 9.8G 41M 9.2G 1% /home
/dev/mapper/centos-var 9.8G 612M 8.7G 7% /var
/dev/mapper/vg–mysql-lv_mysql 148G 248M 140G 1% /var/lib/mysql
/dev/mapper/vg–docker-lv_docker 394G 44G 331G 12% /var/lib/docker
tmpfs 782M 8.0K 782M 1% /run/user/42
tmpfs 782M 0 782M 0% /run/user/0

### MySQL 不推荐使用逻辑卷的原因及影响 尽管逻辑卷(LVM)在许多场景下提供了灵活性和可扩展性,但在某些情况下,MySQL 并不推荐直接使用 LVM。以下是主要原因及其潜在影响: #### 1. 性能开销 LVM 的抽象层可能会引入额外的性能开销。由于 LVM 在物理磁盘和文件系统之间增加了一层管理逻辑,数据的读写操作需要经过更多的中间步骤[^5]。这种额外的复杂性可能导致 I/O 性能下降,尤其是在高并发或大容量数据处理的场景中。 #### 2. 数据一致性问题 当对逻辑卷进行扩容或快照操作时,如果未正确同步文件系统,可能会导致数据一致性问题。例如,在扩容逻辑卷后,如果没有使用 `-r` 参数刷新文件系统,`df -Th` 显示的容量可能与实际逻辑卷大小不符[^3]。这会误导数据库管理员对存储空间的判断,并可能引发存储溢出等问题。 #### 3. 快照备份的局限性 虽然 LVM 提供了快照功能,可以用于 MySQL 的备份,但这种方式存在一定的局限性。例如,LVM 快照是基于文件系统的快照,而不是基于 MySQL 数据库状态的快照。如果 MySQL 数据库在快照期间正在进行写入操作,快照可能会捕获到不一致的状态[^4]。为了解决这一问题,通常需要在创建快照前停止 MySQL 或使用 `FLUSH TABLES WITH READ LOCK` 等命令锁定表,但这会影响数据库的可用性。 #### 4. 复杂性和维护成本 使用 LVM 需要额外的配置和管理知识,增加了系统的复杂性。例如,创建、调整和监控逻辑卷都需要熟悉相关命令(如 `lvcreate`、`lvextend` 等),并且需要定期检查卷组和逻辑卷的状态[^2]。对于小型系统或缺乏专业运维人员的团队来说,这可能是一个负担。 #### 5. 容灾能力有限 LVM 的设计初衷是为了提高存储管理的灵活性,但它本身并不提供容灾能力。如果底层物理磁盘发生故障,LVM 无法自动恢复数据。因此,在需要高可用性和容灾能力的场景中,仅依赖 LVM 可能不够全面,还需要结合其他技术(如 RAID、分布式存储等)。 #### 示例代码:创建 LVM 并挂载MySQL 容器 以下是一个示例,展示如何使用 LVM 创建逻辑卷并将其挂载到 Docker 容器中运行 MySQL: ```bash # 创建卷组 pvcreate /dev/sdb vgcreate vg_mysql /dev/sdb # 创建逻辑卷 lvcreate -n mysql_data -L 10G vg_mysql # 格式化并挂载逻辑卷 mkfs.ext4 /dev/vg_mysql/mysql_data mkdir -p /mnt/mysql_data mount /dev/vg_mysql/mysql_data /mnt/mysql_data # 启动容器并挂载数据卷 docker run -d --name mysql_db \ -e MYSQL_ROOT_PASSWORD=my-secret-pw \ -v /mnt/mysql_data:/var/lib/mysql \ mysql:latest ``` ### 结论 尽管 LVM 在某些场景下具有优势,但在 MySQL 中使用时需要权衡其带来的性能开销、复杂性和潜在的数据一致性问题。如果系统对性能和一致性要求较高,建议结合其他存储解决方案(如分布式文件系统或云存储服务)以弥补 LVM 的不足。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值