在 Debian 系统上，我的主目录位于 raid1 md 阵列上。创建后，它运行了一段时间，但第二个驱动器从阵列中消失了。
# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda3[1]
1843414335 blocks super 1.2 [2/1] [U_]
当我手动添加丢失的磁盘时，它被检测为备用磁盘，并重建阵列。直到下次重新启动...
我设法通过重新创建阵列（使用相同的分区）修复了这个问题。重启几次后，这个问题又出现了。
两个磁盘都是新的，SMART检查正常。
我已经检查过dmesg，这里是完整的“失败”序列：良好同步的 RAID：
Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 19 1 active sync /dev/sdb3
重启时（更多dmesg信息请见：http://pastebin.com/q1Du95Tv)：
[ 8.175247] sda: sda1 sda2 sda3 sda4
...
[ 8.644777] md: md0 stopped.
[ 8.645248] md: bind<sda3>
[ 8.646198] md: raid1 personality registered for level 1
[ 8.646377] md/raid1:md0: active with 1 out of 2 mirrors
[ 8.646391] md0: detected capacity change from 0 to 42916118528
[ 8.646407] RAID1 conf printout:
[ 8.646409] --- wd:1 rd:2
[ 8.646411] disk 0, wo:0, o:1, dev:sda3
[ 8.648749] md0: unknown partition table
[ 8.753331] usb 4-3: new full-speed USB device number 7 using ohci-pci
[ 8.840857] sdb: sdb1 sdb2 sdb3 sdb4
[ 8.841175] sd 1:0:0:0: [sdb] Attached SCSI disk
在这之后：
Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
2 0 0 2 removed
mdadm -E结果：http://pastebin.com/cp65mNQh
答案1
我也遇到了同样的问题。我发现奇怪的是设备的编号是 0 和 2。最后我只好重新创建整个 raid 设置。
mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1
现在数字又变成了 0 和 1。（根据 mdadm --detail /dev/md0）
之后我稍微修改了我的 /etc/mdadm/mdadm.conf 文件。
ARRAY /dev/md0 level=raid1 num-devices=2 devices=/dev/sda1,/dev/sdb1 UUID=<uuid of your raid setup>
我还在 /boot/cmdline.txt 中添加了一个小延迟，rootdelay=5
总的来说，这似乎解决了我的问题。
答案2
在 Linux 上，/dev/sdXY 名称不能保证持久。也就是说，对于给定的一组物理磁盘，设备节点不能保证从一次启动到下一次启动都以相同的顺序出现。
如果您有一个磁盘，您可以几乎 100% 确定它将始终显示为相同的设备节点（例如，/dev/sda）。
如果您有两个磁盘，那么您可以确信它们将始终以相同的顺序显示（这样，对于任何两次连续的启动，“/dev/sda on boot 1”与“/dev/sda on boot 2”是相同的物理设备）。
如果你有 100 个磁盘，那么两个磁盘交换的概率会突然增加很多。这可能是许多不规则现象的结果，但最终归结为 /dev/sdX 设备节点的创建按磁盘检测顺序并且检测顺序无法保证。
如果要保证同一个磁盘始终由给定名称引用，则应使用持久标识符。每个人都对守护进程 udev 又爱又恨，它使这一点变得容易，因为它通常配置为在 /dev/disk/by-* 目录中创建符号链接，这些链接指向磁盘的各个方面（总线/制造商/型号/串行四元组、总线拓扑位置、世界网络, ...) 到内核检测到的设备节点。您还可以添加自定义规则来创建您喜欢的任何命名方案。我遇到了类似的事情（但不完全相同）我，通过迁移到 WWN 名称已解决该问题。
在大型存储阵列中，这实际上是一个非常现实的问题，也是在引用存储时始终使用持久设备名称的强烈主张的原因。
你的问题应该会消失（或者至少可以大大减少，除非出现实际的磁盘问题）如果你将磁盘重新添加到阵列，例如/dev/磁盘/按 ID/wwn-*-part*而不是 /dev/sdXY。这样做不会对其他任何事情产生任何负面影响。