磁盘爆满与IO瓶颈：热迁移数据到NVMe SSD的完整实战方案

1. 先说背景：66万商品数据迁移完，磁盘怎么就满了？

1.1 上一次迁移埋下的雷

上一篇文章里，我写过把66万条商品数据从老库热迁移到新集群的全过程，当时主流程跑得还算顺，切换也控制在几分钟内。但有一件事我当时没细说，就是迁移的目标机器是一台库存机器，磁盘是两块1.8T的SATA机械盘做的RAID1，系统盘和数据盘混在一起，分区规划也比较粗糙。说白了，当时只想着先把数据落下来，没仔细算后续增量、日志和索引文件的空间增长。

结果上线跑了两周，问题就来了。

商品数据本身只有不到200G，但ES的索引副本、MySQL的binlog、还有接口层打印的访问日志，全堆在同一块数据盘上。第二周周五晚上，监控告警直接弹出来：数据盘使用率98%。我当时第一反应是"不对，昨天看才83%"。上去一查，原来是商品详情页的静态化文件——每个商品详情都生成了一份HTML缓存，66万商品就是66万个文件，平均每个文件50到80K，加起来快40G，这还只是当天的量，加上历史遗留和清理脚本没跑干净，磁盘直接被塞爆了。

这次我学到的第一个教训是：预估磁盘空间时，永远要把数据体积乘以3到5倍，尤其是带全文索引、日志和静态文件的应用，光算业务数据是最典型的翻车姿势。

1.2 磁盘告警的完整排查链路

磁盘爆满这种事，最忌讳一上来就直接删文件。我当时的排查链路是这样的：

第一步，df -h确认哪个分区满了，顺便看inode是否耗尽。有些情况下df显示还有空间但应用报磁盘满，那就是inode满了，这是两个不同维度的问题。

第二步，用du逐层往下钻，找到占空间的大头目录。命令大概是du -sh /data/* | sort -rh，先看一级目录，再往里钻。这一步能快速定位是哪个应用目录在吃空间。

第三步，用lsof +L1找出"已删除但仍被进程占用"的文件。这种文件很阴，你明明删了，但空间不释放，因为进程还握着文件描述符。我排查的时候发现，Nginx的access.log被logrotate切割了，但主进程还开着旧文件句柄，导致旧日志占的空间一直没释放。

第四步，top和iostat一起看，确认磁盘IO是否也到了瓶颈。当时iostat显示util一直在85%以上，连正常的数据库查询都开始受影响。

排查完之后的结论很清晰：不只是空间不够，磁盘本身的IO能力也已经顶不住了。机械盘做RAID1，随机读写本来就弱，再加上ES索引频繁刷盘和大量小文件写入，整个数据盘的IO队列长期处于排队状态。这就不是简单的清日志能解决的问题了，得从硬件层面做一次升级——给机器加一块NVMe SSD，把热数据挪到SSD上，机械盘只留冷数据和备份。

2. 换SSD之前，先把方案想清楚

2.1 热迁移的硬约束：为什么不能直接停机拷贝

我给这台机器定的原则是：业务不允许中断，数据不允许丢失。这就决定了整个迁移动作必须是热迁移，不能搞"先把服务停了，慢慢拷数据，拷完再启动"那套——66万商品数据虽然不算天文数字，但全量拷贝加上校验，在机械盘上怎么也要一两个小时，这个窗口业务方肯定不接受。

而且，这批商品数据是持续在变的：用户下单会改库存，运营后台会改价格和上下架状态，ES索引在持续接收更新。你拷贝的时候数据在变，拷完如果不做增量同步和校验，肯定会有数据不一致的问题。

所以方案的核心思路是：利用rsync做"全量同步+增量同步+最终切换"三阶段迁移。第一次rsync把现有数据全量拷到SSD，这个阶段不切流，两边同时跑；之后每隔一段时间做一次增量rsync，把变化的数据补过去；最后找一个业务低峰窗口，再做一次增量同步，然后快速切换挂载点和配置文件，完成割接。整个过程里，对外服务始终没有长时间中断。

这个思路的关键点是：SSD必须能挂载成独立的文件系统，并且要能承载当前数据盘上所有的"热数据目录"；机械盘上剩余空间要足以维持增量数据的短暂增长，撑到切换那一刻。

2.2 冷热分层：不是把整个盘搬到SSD就完事

加了一块1T的NVMe SSD之后，我面临一个选择：是把整个数据盘的内容全搬过去，还是只挑热数据？

我的判断是只搬热数据，做冷热分层。原因是：第一，1T容量装不下全部数据，机械盘上还有老备份、离线日志、历史静态化文件，这些加起来超过600G；第二，把冷数据也搬到SSD没有任何意义，白白浪费SSD的高IO能力；第三，混合存放会让后续的容量规划和性能分析变得混乱。

最终的分层方案是这样的：

• MySQL数据文件：热，搬到SSD
• ES索引目录：热，搬到SSD
• 商品静态化HTML文件：热，搬到SSD
• 应用日志：半热，把当天和昨天的日志放到SSD，历史日志压缩后放回机械盘
• 数据库备份文件：冷，留在机械盘
• 系统盘和安装包：不动，留在原盘

这样做的好处是：SSD只需要承载大约300G的热数据，剩余空间可以作为buffer；机械盘的压力立刻减下来，只做顺序读写的冷数据存储，性能瓶颈彻底缓解。

2.3 方案选型：软链接、mount bind还是直接改配置

把数据"挪"到新的SSD分区，落地时有三种做法，我一个个说清楚它们的区别和适用场景。

第一种是软链接（symlink）。把数据目录搬到SSD后，在原位置ln -s一个软链接指向新位置。优点是操作简单、对应用完全透明，缺点是一旦有程序用realpath解析路径，或者某些容器/服务对软链接支持不好，就会出幺蛾子。我实测发现，Java应用和MySQL对软链接基本没什么问题，但如果目录结构里混合了socket文件和pid文件，软链接有时会导致权限校验失败。

第二种是mount bind。用mount --bind把SSD上的目录绑定挂载到原路径，效果和软链接类似，但对应用来说是完全真实的路径，不涉及符号链接解析。这个方案更稳，但要求原路径必须存在且为空，绑定后不能随便卸载，系统重启后需要写入/etc/fstab保证自动挂载。

第三种是直接改应用的配置文件，把数据目录指向新路径。这是最彻底的方案，但需要重启应用才能生效，对MySQL和ES来说，改配置重启的成本有点高，不够"热"。

我的选择是：MySQL数据目录和ES索引目录用mount bind，商品静态化文件用软链接，日志目录直接改logrotate配置指向新路径。混合使用的原因是：MySQL和ES对目录的稳定性要求最高，接受不了任何路径解析层面的意外；静态化文件是纯读写，软链接完全够用；日志本来就要改轮转策略，顺带改路径最省事。

3. 实操全记录：SSD接入、分区、搬迁与切换

3.1 SSD物理安装与系统识别

先说物理安装。这台机器是2U机架式服务器，机箱里有空闲的NVMe槽位。插好SSD之后进系统，lspci应该能看到对应的NVMe控制器，lsblk能看到新的块设备。我这边识别出来是/dev/nvme0n1，大小1T。

如果lsblk看不到设备，可能是两个原因：一是主板BIOS里NVMe没开启，进BIOS把NVMe相关的选项设为Enabled；二是内核版本太老，NVMe驱动没加载或有问题。我建议先把内核升级到4.4以上，这个版本开始NVMe驱动才算比较稳定。

识别到设备之后，先做一个快速健康检查。用smartctl -a /dev/nvme0n1看温度、通电时间和坏块信息。新盘一般没什么问题，但这一步不能省，我见过有人新硬盘上机就是坏的，装完系统才发现，白白折腾半天。

3.2 分区与文件系统：为什么我坚持用XFS

分区方案我比较直接：整块盘分成一个区，全给数据用。因为1T的NVMe盘如果做多个分区，反而会造成空间碎片化，管理和扩容都麻烦。

用parted做GPT分区，命令序列是这样的：

bash复制parted /dev/nvme0n1 mklabel gpt
parted /dev/nvme0n1 mkpart primary xfs 0% 100%
parted /dev/nvme0n1 name 1 nvme_data
mkfs.xfs -f -L nvme_data /dev/nvme0n1p1

文件系统我坚持用XFS，不用ext4。原因有二：第一，XFS对大数据量和高并发的处理能力强，尤其在文件数多、单个文件大的场景下，XFS的元数据性能比ext4好；第二，XFS支持在线扩容，以后空间不够了，直接growfs就能扩，不用卸载分区，这对生产环境是很大的优势。

而且，XFS的分配组（allocation group）机制在做并行写入时优势明显。我这边商品静态化文件的生成是并发任务，多个进程同时写同一个目录，XFS的并发表现比ext4稳很多，没有出现明显的写放大和碎片化问题。

挂载点的规划我是这样做的：先建一个临时的挂载点/data_ssd，挂载新分区，等数据拷贝完成后再做bind mount。这样可以避免在拷贝过程中就影响到原路径，回滚也更方便。

bash复制mkdir /data_ssd
mount /dev/nvme0n1p1 /data_ssd
echo "/dev/nvme0n1p1 /data_ssd xfs defaults,noatime 0 0" >> /etc/fstab

这里要注意，noatime这个挂载参数很重要。商品详情页是高频读取的，如果每次读都更新atime，会产生大量额外写IO。加上noatime可以显著减少不必要的磁盘写入，对SSD寿命也有好处。

3.3 用rsync做在线数据同步：全量、增量与限速

数据搬迁我用的rsync，核心命令长这样：

bash复制rsync -avz --delete --exclude 'lost+found' \
  --bwlimit=50000 \
  /data/mysql/ /data_ssd/mysql/

参数说明：

• -a：归档模式，保留权限、属主、时间戳等所有元数据
• -v：显示进度
• -z：传输时压缩。这里有个细节：对于MySQL数据文件，压缩往往没什么效果，因为数据已经比较随机，压缩率很低；但对静态化HTML文件，压缩率很高，能显著降低传输时间
• --delete：删除目标端多余的文件，保证两边最终完全一致。这个参数在全量阶段不要加，等到最后一次增量同步时再加，否则中途如果源端有文件被临时清理，会影响目标端
• --bwlimit=50000：限制带宽为50MB/s。这是因为rsync全量拷数据时，如果带宽不限制，会把机械盘的读IO打满，影响正在对外服务的MySQL性能。我实测把带宽限制在50MB/s左右，对线上影响可以忽略

全量同步大约花了40分钟，因为MySQL数据加上ES索引和静态化文件加起来接近300G，虽然有压缩和限速，机械盘读的能力摆在那，快不了。

全量同步完成之后，我先在SSD上启动了一个只读校验，把两张关键表的行数、最新的订单ID、商品的上下架状态字段做了一遍对比，确认没有缺漏。校验通过后，进入增量同步阶段。

增量同步我设置了每5分钟跑一次cron，把过去5分钟内变化的数据同步到SSD。这里有个坑：MySQL的数据文件和ES的索引文件在运行状态下的文件内容一直在变，直接用rsync同步可能会拷到一半的文件，导致目标端文件不一致。解决方法是：MySQL用mysqldump的binlog补齐机制，或者用xtrabackup做物理备份；ES要先关闭索引刷新或者用快照API。我当时为了省事，用的是最朴素的办法——先做rsync到SSD，然后在切换窗口前，把MySQL设置成只读模式（read_only=1），ES设置成index.refresh_interval=-1，停掉静态化任务，再做最后一次rsync，保证源端文件静止后再同步，这样拷过去的一定是完整一致的。

3.4 切换窗口：一次低调的"秒级"割接

切换到SSD的窗口我选在凌晨2点到2点半。这个时段商品管理的操作最少，下单量也很低。具体的切换步骤是这样的：

第一步，提前15分钟在前端加一层维护提示，同时把后台的商品管理入口暂时关闭。这个动作是为了尽量降低用户操作和后台操作造成的数据变更。

第二步，把MySQL设置为只读，ES索引刷新关闭，静态化生成脚本暂停。这两分钟里，前端还是可以读，但不能写。

第三步，做最后一次增量rsync。因为前面已经有几乎实时的增量同步了，这最后一次同步的数据量非常小，基本只花了不到1分钟。

第四步，执行bind mount切换。把原来的数据目录先备份一下路径信息，然后清空原目录内容，把SSD分区bind上去：

bash复制# 备份原目录的配置信息
cp -a /data/mysql /data/mysql_backup_path_info
# 清空原目录
rm -rf /data/mysql/*
# bind mount
mount --bind /data_ssd/mysql /data/mysql
# 写进fstab
echo "/data_ssd/mysql /data/mysql none bind 0 0" >> /etc/fstab

ES索引目录和静态化目录也做了类似操作。静态化目录我用的是软链接方案，切换更快：

bash复制mv /data/html_static /data/html_static_old
ln -s /data_ssd/html_static /data/html_static

第五步，恢复MySQL的读写，ES索引刷新恢复，静态化脚本重启。业务验证完成之后，解除维护提示。

整个切换过程从只读到恢复写，耗时大概3分钟，对C端用户的影响窗口其实很短，基本算一次无感知的割接。

3.5 验证与秒级回滚预案

切换完之后，我留了一个完整的回滚预案。因为bind mount只是改变了挂载点的指向，原数据在机械盘上其实还在，只是路径被覆盖了，并没有真正删除。只要在切换前保留一份路径备份，回滚动作就是反方向的unmount和重新挂载。

回滚的命令很简单：

bash复制umount /data/mysql
mount /dev/md0 /data/mysql   # md0是原来机械盘的RAID设备

当然，回滚的前提是增量同步期间没有大量写入，否则回滚后会丢失这两个小时的新增数据。所以我在切换窗口内做了两件事：一是严格记录只读时间和恢复写的时间点，明确回滚会导致哪些数据丢失；二是在回滚预案里写明"回滚仅限切换后10分钟内执行，超过10分钟建议走重建流程而不是回滚"。

验证方面，我重点查了三类指标：

• 数据完整性：商品总数、SKU数、上下架状态分布，和发布前对账
• 接口可用性：商品详情、搜索、加购三个核心接口的响应码和耗时
• 系统层面的IO：iostat里的await和util，以及ES的search latency和bulk latency

实测下来，所有接口的P99延迟从原来的800ms附近降到了200ms以内，数据库慢查询数量肉眼可见地变少了。

4. 迁移后的性能对比与持续优化

4.1 数据说话：IO延迟与吞吐的前后对比

割接完成后的24小时，我持续采集了系统指标，和迁移前做了对比。

这个结果其实不意外，但看着监控面板上的数字，心里还是踏实了不少。最明显的变化是磁盘util从经常打满降到30%以下，说明IO队列不再长期积压了。之前那种"服务器访问慢，但CPU和内存都低，一查磁盘IO在飙"的尴尬情况彻底消失了。

还有一个细节我觉得值得说：ES的segment merge时间大幅缩短。之前机械盘做一次较大的segment merge可能要几十秒，导致写入经常抖动；换SSD之后，merge时间降到几秒内，写入链路稳了很多。这个对搜索业务的影响很大，因为merge期间ES会占用大量磁盘IO，直接影响搜索响应。

4.2 顺带把历史欠账一起清了

换完SSD之后，我并没有马上收工。既然IO瓶颈解决了，我开始处理之前积累的"历史欠账"。

第一件事是日志改造。之前日志轮转策略是每天一切，保留30天，导致日志文件散落在机械盘上，查询的时候各种慢。现在我把日志路径迁到了SSD，并把日志轮转策略改成每6小时一切，同时启用gzip压缩。这样日志占用的空间小了，排查问题的时候也不用再grep一个几个G的大文件了。

第二件事是MySQL的binlog策略。之前因为空间紧张，binlog只保留2天，恢复窗口很短。现在SSD空间充裕，把binlog保留期调到了7天，这意味着如果发生误操作，我可以回滚到更早的时间点，数据安全系数高了不少。

第三件事是给ES的索引做了冷热分离架构。SSD上只保留近7天的热索引，超过7天的索引定期迁移到机械盘。原因很简单：搜索流量主要集中在新数据上，旧数据查询频率低，没必要占着SSD的空间。这个用ES的ILM（Index Lifecycle Management）就能实现，设置好策略自动执行即可。

这三件事做完之后，整个系统的健康状态才算真正稳定下来，而不只是把数据搬了个家。

5. 常见问题与避坑速查

5.1 十几个实操坑浓缩成一张表

我把这次迁移过程中遇到的所有问题整理成了下表，方便以后自己和读者快速查阅：

5.2 三个值得记住的判断经验

第一，硬盘空间问题永远不要只看容量。容量只是表面指标，深层的IO能力、文件数量、inode情况都要一起看。这次如果不是机械盘IO先撑不住，我也许能靠清日志再撑一阵，但那样只是治标不治本，业务增长后一样会爆。

第二，热迁移的核心不是"拷贝数据"，而是"控制变化"。数据文件在运行状态下永远在变，你要做的是在设计方案时就想清楚：哪些时刻允许源端短暂静止，哪些时刻可以接受少量增量延迟，哪些环节需要实时同步。想清楚了再做，就不会在切换时手忙脚乱。

第三，回滚预案一定是在切换前写好，而不是出了问题再想。我在切换前把"什么条件下可以回滚、回滚后丢多少数据、回滚的操作命令是什么"都写在运维文档里了。虽然最终没有用到，但这个预案让我在切换时非常有底气，因为我知道就算出了问题，也能在几分钟内恢复原状。

这次迁移做完，我的实际体会是：SSD不是什么神秘的东西，它只是把IO瓶颈这个盖子掀开了。真正让系统稳定下来的，是迁移前想清楚的热冷分层方案、迁移中严格执行的增量同步和校验、以及迁移后端掉的一堆历史包袱。如果你也遇到了磁盘爆满、IO打满、业务被拖慢的情况，可以参考这个思路，先把数据分好层，再动手搬，别一上来就整个盘拷过去，那样大概率还要返工。