1. 磁盘设备识别与分区基础
在运维和数据库管理场景中，快速准确地识别磁盘及其分区结构是后续操作的基础。正确的设备识别可以避免误操作造成数据丢失。常用工具包括 lsblk、blkid、fdisk -l 等，它们能显示设备名、分区、文件系统类型等关键信息。
通过对磁盘的识别，可以确定需要扩容、新建分区还是迁移数据。lsblk -f 能同时显示分区的文件系统和挂载点，有助于快速定位当前数据路径。
下面给出常用识别命令的示例，帮助你在运维任务中快速定位目标磁盘：
# 查看系统磁盘树与挂载点
lsblk -f# 查看分区详细信息及 UUID
blkid# 查看所有磁盘及其容量信息（含分区表类型）
fdisk -l /dev/sda# 查看 SCSI 设备及路径，便于查找物理磁盘
lsscsi
1.1 设备识别命令
在实际工作中，设备路径的稳定性比驱动名称更可靠，特别是在云环境与热插拔场景中。udev 相关信息也能帮助确定设备属性以及分区信息。
通过以下命令，可以快速确认当前系统中的新磁盘并准备分区操作：
# 扫描新的 SCSI 存储设备
echo "- - -" > /sys/class/scsi_host/host*/scan# 显示分区表类型，便于选择分区方案
parted /dev/sdb print# 为分区表创建或更改分区表类型（GPT 示例）
parted /dev/sdb mklabel gpt
1.2 分区与分区表类型
分区表类型直接关系到可用分区数量与容量上限。对于大容量磁盘，GPT分区表能够支持更高数量和更大容量的分区，通常推荐用于现代环境；MBR在老旧系统或对向后兼容有强需求时仍会使用。
常见分区操作工具有 fdisk、parted、gdisk（GPT 版本的 GPT fdisk）。在执行分区前，务必备份数据并确保分区表类型符合目标数据库的写入特性。
# 使用 fdisk 在 /dev/sdb 上创建一个新的分区（MBR 示例）
fdisk /dev/sdb# 使用 parted 创建 GPT 分区表并新建分区
parted /dev/sdb mklabel gpt
parted -a optimal /dev/sdb mkpart primary xfs 0% 100%
2. LVM与RAID盘管理
对运维和数据库管理员而言，逻辑卷管理（LVM）与 软件 RAID（mdadm）是实现灵活扩展、数据冗余和高可用的重要手段。通过 LVM，可以在不中断服务的情况下扩展存储容量；通过 mdadm，可以实现 RAID 1、RAID 5/6 等冗余方案，提升数据安全性。
合理的分区+LVM+RAID组合，可以将数据分离到独立的卷组与逻辑卷，便于快照、备份与容量规划。下面的章节给出常用操作示例与注意点。
2.1 LVM 基础操作
LVM 的核心思想是将物理卷（PV）聚合成卷组（VG），再在 VG 上创建逻辑卷（LV）。这使得容量扩展和动态分配变得更为灵活。PV → VG → LV 的流程是日常运维的基础。
在数据库环境中，常见做法是将数据库数据目录放在独立的 LV 上，以便分区扩容和性能控制。以下是典型的创建与挂载过程片段：
# 将新磁盘分区 /dev/sdb1 作为物理卷
pvcreate /dev/sdb1# 创建卷组 vg_db
vgcreate vg_db /dev/sdb1# 在卷组中创建逻辑卷 lv_db，初始容量 100G
lvcreate -n lv_db -L 100G vg_db# 将逻辑卷格式化为 XFS（或 ext4 等）
mkfs.xfs /dev/vg_db/lv_db# 挂载到数据目录
mkdir -p /data/db
mount /dev/vg_db/lv_db /data/db
扩展场景下，LV 的扩容与 FS 的扩展同样重要。如下命令演示了在不影响服务的前提下，动态扩容逻辑卷和文件系统：
# 扩展逻辑卷 50G
lvextend -L +50G /dev/vg_db/lv_db# 对 XFS 文件系统进行扩容
xfs_growfs /data/db
2.2 软件RAID（mdadm）
软件 RAID 能在多磁盘之间提供冗余和性能提升。常见场景包括 RAID 1（镜像）与 RAID 5/6（带校验的分布式冗余）。mdadm 是大多数 Linux 发行版中实现软件 RAID 的核心工具。
创建和管理 RAID 的核心步骤包括：创建阵列、查看阵列状态、配置启动时的自动组装，以及监控健康状态。
# 使用两块磁盘创建 RAID 1 阵列
mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc# 查看阵列详情
mdadm --detail /dev/md0# 生成 mdadm 配置文件以便开机自动组装
mdadm --detail --scan | tee -a /etc/mdadm/mdadm.conf# 更新 initramfs 以包含 RAID 信息（不同发行版命令可能略有差异）
update-initramfs -u
RAID 阵列的维护还包括监控与故障恢复。适时地替换故障磁盘、重建阵列以及验证数据一致性，是运维日常的一部分。
3. 文件系统选择与优化
数据库工作负载对文件系统的选择与优化有直接影响。常用的 Linux 文件系统包括 ext4、XFS、Btrfs 等。XFS 通常在大文件/高并发场景下表现稳定且可扩展；ext4 稳定性高、健壮性强，适合通用场景；Btrfs 在快照与自带子卷方面具有优势，但在写密集型数据库环境中需谨慎评估。
选择合适的文件系统，并结合合适的挂载选项，是提升数据库 I/O 的关键。一些常用的性能优化点包括 noatime、数据信息写入策略、以及 kv/元数据的分离等。
3.1 常见文件系统对比
EXT4：成熟稳定，广泛兼容，支持在线扩容和较好的日志机制，适合通用数据库目录。XFS：对大文件和并发写入有较好表现，适合数据仓库和日志密集型场景；对元数据操作友好，易于按需扩展。Btrfs：自带快照与子卷，适合需要频繁快照和时间点还原的场景，但在高并发写入下需评估实际性能。
3.2 挂载选项与性能优化
挂载选项直接影响 I/O 性能和数据一致性。常见的优化包括 noatime/diratime、data=ordered、barrier 等，以及针对具体文件系统的参数配置。
下面给出一个常用的挂载示例，结合 LVM 上的 XFS 卷：
# 查看目标卷的文件系统类型与 UUID
blkid /dev/vg_db/lv_db# 将 XFS 卷以 noatime、log 势态优化方式挂载
mkdir -p /data/db
mount -t xfs -o noatime,logbufs=8 /dev/vg_db/lv_db /data/db# 将挂载信息写入 /etc/fstab，确保重启保持挂载
echo '/dev/vg_db/lv_db /data/db xfs noatime,logbufs=8 0 2' >> /etc/fstab
EXT4 的一些优化项包括：使用 data=ordered（默认）、journal_checksum、stride/stripe 设定等。以下是对 EXT4 的简单优化思路：
# 如果使用 EXT4，考虑追加 noatime 与对齐
mount -t ext4 -o noatime,barrier=1 /dev/vg_db/lv_db /data/db
<4. 磁盘性能监控与调优
持续的监控是确保数据库性能稳定的关键。常用的监控工具包括 iostat、iotop、vmstat、sar，以及更细粒度的工具，如 blktrace、fio 等。通过监控可以定位到 I/O 瓶颈、队列深度、以及对不同设备的压力分布。
以下内容介绍了常用工具及基本用法，帮助运维和数据库管理员快速诊断磁盘相关问题。
4.1 监控工具
使用 iostat、iotop、sar 等工具，可以获取 I/O 使用率、吞吐量、I/O 等待时间等指标，从而判断是磁盘性能、数据库查询还是缓存策略导致的瓶颈。
监控示例片段如下，可以帮助你在日常运维中快速获取关键指标：
# 以秒为单位持续监控磁盘 I/O（扩展名 x, y）
iostat -xz 1 3# 实时查看 I/O 等待最高的进程（需要 root 权限）
iotop -eoP# 收集系统统计信息，生成 1 分钟采样数据
sar -o /var/log/sa/sa10 600 6
结合具体数据库引擎的特性，可以将监控与告警规则对接到运维平台，例如 PostgreSQL 的 WAL 写入延迟、MySQL 的 InnoDB 日志 I/O 等待等。
4.2 调优策略
调优通常从 I/O 调度器、队列深度、进程优先级、以及文件系统参数等方面入手。常见的调优动作包括：
1) 选择合适的 I/O 调度器并应用到目标磁盘上。常见的调度器包括 mq-deadline、bfq、none 等。对数据库服务器，推荐使用 mq-deadline 或 bfq。
2) 调整 I/O 队列深度和进程优先级，确保数据库相关进程获得稳定的磁盘写入资源，例如使用 ionice 设置优先级。
3) 监控并调整挂载选项与文件系统参数，结合具体数据库负载进行针对性优化。
# 查看当前磁盘调度器
cat /sys/block/sda/queue/scheduler# 设置调度器为 mq-deadline（可根据实际环境调整）
echo mq-deadline > /sys/block/sda/queue/scheduler# 为数据库进程设置 I/O 优先级（示例：PID 1234）
ionice -c2 -n 0 -p 1234
在进行破坏性调整前，务必在测试环境进行基准测试（如使用 fio 进行读写基准），以避免对生产环境造成不可控影响。
5. 实战案例：数据库维护中的磁盘管理
5.1 数据库分区与表空间管理
在数据库维护场景中，将数据、日志和临时文件分离到独立的磁盘/卷组，可以显著降低 I/O 队列冲突、提升并发写入能力，并便于容量规划与备份策略的实施。常见做法是为数据目录创建单独的 LV，并对 WAL 日志、索引和临时表空间进行独立分区或挂载。
下面给出一个实战片段，展示如何通过 LVM 将数据库数据目录放在独立卷上并挂载到数据库数据目录：
# 创建用于数据库数据的 LV
pvcreate /dev/sdd1
vgcreate vg_dbdata /dev/sdd1
lvcreate -n lv_pgdata -L 200G vg_dbdata# 格式化并挂载
mkfs.xfs /dev/vg_dbdata/lv_pgdata
mkdir -p /var/lib/postgres/pgdata
mount /dev/vg_dbdata/lv_pgdata /var/lib/postgres/pgdata# PostgreSQL 通过 tablespace 使用新路径
psql -d postgres -c "CREATE TABLESPACE ts_data LOCATION '/var/lib/postgres/pgdata';"
通过分离表空间，数据库管理员可以在无需停机的情况下进行容量扩容和性能调优，并可对不同表空间设定不同的备份策略与快照点。
此外，定期对数据目录进行容量评估、预留增长空间，以及在 critical 路径上配置热备份策略，是确保长期稳定运行的重要步骤。
5.2 断电与故障恢复场景下的磁盘操作
在断电或磁盘故障场景下，合适的恢复流程能最大限度减小数据损失与服务中断。基本原则包括：先确保系统可启动、再检查文件系统、最后进行数据恢复/重建。常用流程如下：
# 首先尝试卸载可能受影响的挂载点
umount /data/db# 在安全模式下进行文件系统检查（以 EXT4 为例）
e2fsck -f -y /dev/mapper/vg_db-lv_db# 重新挂载并验证数据完整性
mount /dev/mapper/vg_db-lv_db /data/db# 如使用 RAID，重新组装阵列并检查一致性
mdadm --assemble --scan
mdadm --detail /dev/md0
另外，在灾难恢复场景中，使用镜像备份、云端快照或热备份策略，是提升系统韧性的重要方式。对关键数据库，建议结合快照、备份和测试还原流程，确保在故障后可快速回到稳定状态。
