linux raid 1:在更换和同步一个驱动器后,另一个磁盘发生故障 - 了解 mdstat/mdadm 发生了什么

linux raid 1:在更换和同步一个驱动器后,另一个磁盘发生故障 - 了解 mdstat/mdadm 发生了什么

我们有一台旧的 RAID 1 Linux 服务器(Ubuntu Lucid 10.04),有四个分区。几天前 /dev/sdb 发生故障,今天我们注意到 /dev/sda 有预故障的不祥 SMART 标志(重新分配的扇区数约为 4000)。我们今天早上更换了 /dev/sdb,并按照以下指南在新驱动器上重建了 RAID:

http://www.howtoforge.com/replacing_hard_disks_in_a_raid1_array

一切都很顺利,直到最后。当它看起来要完成同步最后一个分区时,另一个旧分区失败了。此时,我对系统的状态非常不确定。一切似乎工作正常,并且文件似乎都可以访问,就像它同步了所有内容一样,但我对 RAID 还不熟悉,我很担心发生了什么。

/proc/mdstat 输出是:

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md3 : active raid1 sdb4[2](S) sda4[0]
      478713792 blocks [2/1] [U_]

md2 : active raid1 sdb3[1] sda3[2](F)
      244140992 blocks [2/1] [_U]

md1 : active raid1 sdb2[1] sda2[2](F)
      244140992 blocks [2/1] [_U]

md0 : active raid1 sdb1[1] sda1[2](F)
      9764800 blocks [2/1] [_U]

unused devices: <none>

[_U]vs的顺序[U_]。为什么它们在整个阵列中不一致?第一个是U/dev/sda 还是 /dev/sdb?(我尝试在网上寻找这些琐碎的信息,但没有找到明确的指示)如果我正确读取了 md0,[_U]应该是 /dev/sda1(关闭)和 /dev/sdb1(启动)。但如果 /dev/sda 失败了,它怎么可能是对面的对于 md3 ?我知道 /dev/sdb4 现在是备用的,因为它可能无法 100% 同步它,但为什么它显示 /dev/sda4 为向上?难道不应该吗[__]?或者[_U]无论如何?/dev/sda 驱动器现在显然无法再被 SMART 访问,所以我不指望它能启动。我对输出的解释有什么问题?

mdadm --detail我还附上了四个分区的输出:

/dev/md0:
        Version : 00.90
  Creation Time : Fri Jan 21 18:43:07 2011
     Raid Level : raid1
     Array Size : 9764800 (9.31 GiB 10.00 GB)
  Used Dev Size : 9764800 (9.31 GiB 10.00 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Nov  5 17:27:33 2013
          State : clean, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 1
  Spare Devices : 0

           UUID : a3b4dbbd:859bf7f2:bde36644:fcef85e2
         Events : 0.7704

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8       17        1      active sync   /dev/sdb1

       2       8        1        -      faulty spare   /dev/sda1

/dev/md1:
        Version : 00.90
  Creation Time : Fri Jan 21 18:43:15 2011
     Raid Level : raid1
     Array Size : 244140992 (232.83 GiB 250.00 GB)
  Used Dev Size : 244140992 (232.83 GiB 250.00 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Tue Nov  5 17:39:06 2013
          State : clean, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 1
  Spare Devices : 0

           UUID : 8bcd5765:90dc93d5:cc70849c:224ced45
         Events : 0.1508280

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8       18        1      active sync   /dev/sdb2

       2       8        2        -      faulty spare   /dev/sda2


/dev/md2:
        Version : 00.90
  Creation Time : Fri Jan 21 18:43:19 2011
     Raid Level : raid1
     Array Size : 244140992 (232.83 GiB 250.00 GB)
  Used Dev Size : 244140992 (232.83 GiB 250.00 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 2
    Persistence : Superblock is persistent

    Update Time : Tue Nov  5 17:46:44 2013
          State : clean, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 1
  Spare Devices : 0

           UUID : 2885668b:881cafed:b8275ae8:16bc7171
         Events : 0.2289636

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8       19        1      active sync   /dev/sdb3

       2       8        3        -      faulty spare   /dev/sda3

/dev/md3:
        Version : 00.90
  Creation Time : Fri Jan 21 18:43:22 2011
     Raid Level : raid1
     Array Size : 478713792 (456.54 GiB 490.20 GB)
  Used Dev Size : 478713792 (456.54 GiB 490.20 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 3
    Persistence : Superblock is persistent

    Update Time : Tue Nov  5 17:19:20 2013
          State : clean, degraded
 Active Devices : 1
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 1

    Number   Major   Minor   RaidDevice State
       0       8        4        0      active sync   /dev/sda4
       1       0        0        1      removed

       2       8       20        -      spare   /dev/sdb4

/dev/sda4 上的主动同步令我困惑。

我很担心,因为如果明天早上我必须更换 /dev/sda,我想确定我应该同步什么以及发生了什么。/dev/sda 决定失败的事实也让我很困惑确切地当团队完成重新同步时。我想了解到底发生了什么。

非常感谢您的耐心和帮助。

马西莫

答案1

问题 1:的顺序 [U] 与 [U]]。为什么它们在整个阵列中不一致?第一个 U 是 /dev/sda 还是 /dev/sdb?

顺序基于 RaidDevice 编号。这些是行方括号中的数字,如下所示:

md3 : active raid1 sdb4[2](S) sda4[0]
      478713792 blocks [2/1] [U_]

md2 : active raid1 sdb3[1] sda3[2](F)
      244140992 blocks [2/1] [_U]

md1 : active raid1 sdb2[1] sda2[2](F)
      244140992 blocks [2/1] [_U]

...

对于 md3,sda4 设备是 #0。sdb4 设备是 #2。因此 U 代表 sba4 设备。对于 md2,U 代表设备 sda3,#2。因此,似乎您的驱动器 sdb 是存在问题的一个,因为这些分区均未列为“UP”(即“U”)。它们均报告为“DOWN”(即“_”)。

问题2:难道不应该是 [__] 吗?或者 [_U]?

的输出/proc/mdstat应为全部[UU],也就是说,它们全部处于“UP”状态。例如,这是我的 RAID1 阵列,有 2 个成员。

$ cat /proc/mdstat
Personalities : [raid1] 
md0 : active raid1 sdb1[1] sda1[0]
      976759936 blocks [2/2] [UU]

unused devices: <none>

参考

相关内容