Làm thế nào để thiết bị RAID không hoạt động hoạt động trở lại?

Sau khi khởi động, thiết bị RAID1 của tôi ( /dev/md_d0*) đôi khi rơi vào trạng thái buồn cười và tôi không thể gắn kết được.

^{* Ban đầu tôi tạo ra /dev/md0nhưng nó bằng cách nào đó đã tự thay đổi thành /dev/md_d0.}

# mount /opt
mount: wrong fs type, bad option, bad superblock on /dev/md_d0,
       missing codepage or helper program, or other error
       (could this be the IDE device where you in fact use
       ide-scsi so that sr0 or sda or so is needed?)
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Thiết bị RAID dường như không hoạt động bằng cách nào đó:

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] 
                [raid4] [raid10] 
md_d0 : inactive sda4[0](S)
      241095104 blocks

# mdadm --detail /dev/md_d0
mdadm: md device /dev/md_d0 does not appear to be active.

Câu hỏi là, làm thế nào để thiết bị hoạt động trở lại (sử dụng mdmadm, tôi đoán)?

(Những lần khác, nó vẫn ổn (hoạt động) sau khi khởi động và tôi có thể gắn nó bằng tay mà không gặp vấn đề gì. Nhưng nó vẫn không tự động gắn kết mặc dù tôi có nó trong /etc/fstab:

/dev/md_d0        /opt           ext4    defaults        0       0

Vì vậy, một câu hỏi bổ sung: tôi nên làm gì để thiết bị RAID tự động gắn vào /optlúc khởi động? )

Đây là một máy trạm Ubuntu 9.10. Thông tin cơ bản về thiết lập RAID của tôi trong câu hỏi này .

Chỉnh sửa : Tôi /etc/mdadm/mdadm.conftrông như thế này. Tôi chưa bao giờ chạm vào tập tin này, ít nhất là bằng tay.

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR <my mail address>

# definitions of existing MD arrays

# This file was auto-generated on Wed, 27 Jan 2010 17:14:36 +0200

Trong /proc/partitionsmục cuối cùng md_d0ít nhất là bây giờ, sau khi khởi động lại, khi thiết bị tình cờ hoạt động trở lại. (Tôi không chắc liệu nó có giống như vậy khi nó không hoạt động không.)

Giải quyết : như Jimmy Hedman đề xuất , tôi đã lấy đầu ra của mdadm --examine --scan:

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=de8fbd92[...]

và thêm nó vào /etc/mdadm/mdadm.conf, dường như đã khắc phục vấn đề chính. Sau khi thay đổi /etc/fstabđể sử dụng /dev/md0lại (thay vì /dev/md_d0), thiết bị RAID cũng sẽ tự động được gắn!

Đối với câu hỏi tiền thưởng của bạn:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Tôi đã thấy rằng tôi phải thêm mảng thủ công /etc/mdadm/mdadm.confđể làm cho Linux gắn kết nó khi khởi động lại. Nếu không thì tôi nhận được chính xác những gì bạn có ở đây - md_d1những thứ không hoạt động, v.v.

Tệp conf sẽ trông giống như bên dưới - tức là một ARRAYdòng cho mỗi thiết bị md. Trong trường hợp của tôi, các mảng mới bị thiếu trong tệp này, nhưng nếu bạn có chúng được liệt kê thì đây có lẽ không phải là một sửa chữa cho vấn đề của bạn.

# definitions of existing MD arrays
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Thêm một mảng trên mỗi thiết bị md và thêm chúng sau khi nhận xét được bao gồm ở trên hoặc nếu không có nhận xét nào như vậy ở cuối tệp. Bạn nhận được UUID bằng cách thực hiện sudo mdadm -E --scan:

$ sudo mdadm -E --scan
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Như bạn có thể thấy, bạn có thể sao chép đầu ra từ kết quả quét vào tệp.

Tôi chạy máy tính để bàn Ubuntu 10.04 LTS và theo tôi nhớ hành vi này khác với phiên bản máy chủ của Ubuntu, tuy nhiên cách đây rất lâu tôi đã tạo các thiết bị md của mình trên máy chủ, tôi có thể sai. Nó cũng có thể là tôi chỉ bỏ lỡ một số tùy chọn.

Dù sao, việc thêm mảng trong tập tin conf dường như thực hiện thủ thuật. Tôi đã chạy cuộc đột kích 1 và đột kích 5 trong nhiều năm mà không gặp vấn đề gì.

Cảnh báo: Trước hết hãy để tôi nói rằng phần bên dưới (do sử dụng "--force") có vẻ nguy hiểm đối với tôi và nếu bạn có dữ liệu không thể phục hồi, tôi khuyên bạn nên tạo các bản sao của các phân vùng có liên quan trước khi bạn bắt đầu thử bất kỳ những điều dưới đây. Tuy nhiên, điều này làm việc cho tôi.

Tôi gặp vấn đề tương tự, với một mảng hiển thị là không hoạt động, và tôi không làm gì cả, kể cả "mdadm --examine --scan> /etc/mdadm.conf", như được đề xuất bởi những người khác ở đây, đã giúp đỡ tất cả.

Trong trường hợp của tôi, khi nó cố khởi động mảng RAID-5 sau khi thay thế ổ đĩa, nó đã nói rằng nó bị bẩn (thông qua dmesg):

md/raid:md2: not clean -- starting background reconstruction
md/raid:md2: device sda4 operational as raid disk 0
md/raid:md2: device sdd4 operational as raid disk 3
md/raid:md2: device sdc4 operational as raid disk 2
md/raid:md2: device sde4 operational as raid disk 4
md/raid:md2: allocated 5334kB
md/raid:md2: cannot start dirty degraded array.

Làm cho nó hiển thị là không hoạt động trong /proc/mdstat:

md2 : inactive sda4[0] sdd4[3] sdc4[2] sde4[5]
      3888504544 blocks super 1.2

Tôi đã thấy rằng tất cả các thiết bị đều có cùng một sự kiện trên chúng, ngoại trừ ổ đĩa tôi đã thay thế ( /dev/sdb4):

[root@nfs1 sr]# mdadm -E /dev/sd*4 | grep Event
mdadm: No md superblock detected on /dev/sdb4.
         Events : 8448
         Events : 8448
         Events : 8448
         Events : 8448

Tuy nhiên, các chi tiết mảng cho thấy nó có sẵn 4 trên 5 thiết bị:

[root@nfs1 sr]# mdadm --detail /dev/md2
/dev/md2:
[...]
   Raid Devices : 5
  Total Devices : 4
[...]
 Active Devices : 4
Working Devices : 4
[...]
    Number   Major   Minor   RaidDevice State
       0       8        4        0      inactive dirty  /dev/sda4
       2       8       36        2      inactive dirty  /dev/sdc4
       3       8       52        3      inactive dirty  /dev/sdd4
       5       8       68        4      inactive dirty  /dev/sde4

(Trên đây là từ bộ nhớ trên cột "Trạng thái", tôi không thể tìm thấy nó trong bộ đệm cuộn lại của mình).

Tôi đã có thể giải quyết điều này bằng cách dừng mảng và sau đó lắp ráp lại:

mdadm --stop /dev/md2
mdadm -A --force /dev/md2 /dev/sd[acde]4

Vào thời điểm đó, mảng đã hoạt động, chạy với 4 trong số 5 thiết bị và tôi đã có thể thêm thiết bị thay thế và nó đang được xây dựng lại. Tôi có thể truy cập hệ thống tập tin mà không gặp vấn đề gì.

Tôi gặp sự cố với Ubuntu 10.04 khi lỗi trong FStab khiến máy chủ không thể khởi động.

Tôi đã chạy lệnh này như đã đề cập trong các giải pháp trên:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Điều này sẽ nối các kết quả từ "mdadm --examine --scan" vào "/etc/mdadm/mdadm.conf"

Trong trường hợp của tôi, đây là:

ARRAY /dev/md/0 metadata=1.2 UUID=2660925e:6d2c43a7:4b95519e:b6d110e7 name=localhost:0

Đây là một fakeraid 0. Lệnh của tôi trong / etc / fstab để tự động gắn kết là:

/dev/md0 /home/shared/BigDrive ext3 defaults,nobootwait,nofail 0 0

Điều quan trọng ở đây là bạn có "nobootwait" và "nofail". Nobootwait sẽ bỏ qua bất kỳ thông báo hệ thống nào ngăn bạn khởi động. Trong trường hợp của tôi, đây là trên một máy chủ từ xa nên nó rất cần thiết.

Hy vọng điều này sẽ giúp một số người.

Bạn có thể kích hoạt thiết bị md của mình với

mdadm -A /dev/md_d0

Tôi cho rằng một số tập lệnh khởi động bắt đầu quá sớm, trước khi một trong những thành viên RAID được phát hiện hoặc một số vấn đề tương tự. Là một cách giải quyết nhanh chóng và bẩn thỉu, bạn sẽ có thể thêm dòng này vào /etc/rc.local:

mdadm -A /dev/md_d0 && mount /dev/md_d0

Chỉnh sửa: rõ ràng /etc/mdadm/mdadm.conf của bạn vẫn chứa tên cấu hình cũ. Chỉnh sửa tệp này và thay thế các lần xuất hiện của md0 bằng md_d0.

Tôi gặp vấn đề tương tự ... máy chủ của tôi sẽ không gắn kết md2 sau khi tôi đã phát triển các phân vùng thiết bị được liên kết. Khi đọc chủ đề này, tôi thấy rằng thiết bị RAID md2 có UUID mới và máy đang cố sử dụng cái cũ.

Như đã đề xuất ... sử dụng đầu ra 'md2' từ

mdadm --examine --scan

Tôi đã chỉnh sửa /etc/mdadm/mdadm.confvà thay thế dòng UUID cũ bằng một đầu ra từ lệnh trên và vấn đề của tôi đã biến mất.

Khi bạn giả vờ làm một cái gì đó với /dev/md[012346789}nó đi đến /dev/md{126,127...}. /dev/md0tiếp tục gắn kết tại /dev/md126hoặc /dev/md127bạn phải:

umount /dev/md127 hoặc umount /dev/md126.

Điều này là tạm thời để cho phép bạn thực thi các lệnh và một số ứng dụng mà không dừng hệ thống của bạn.

md_d0 : inactive sda4[0](S)có vẻ sai cho một mảng RAID1. Dường như gợi ý rằng mảng không có thiết bị hoạt động và một thiết bị dự phòng ^{_{(được biểu thị bằng (S), bạn sẽ thấy (F) ở đó cho thiết bị bị lỗi và không có gì cho thiết bị OK / hoạt động)}} - đối với mảng RAID1 không phải là Khi chạy xuống cấp, phải có ít nhất hai thiết bị OK / hoạt động ^{_{(và đối với mảng bị xuống cấp, ít nhất một thiết bị OK / hoạt động)}} và bạn không thể kích hoạt mảng RAID1 mà không có thiết bị dự phòng nào không bị lỗi (như dự phòng không chứa bản sao dữ liệu cho đến khi chúng được kích hoạt khi ổ đĩa khác bị lỗi). Nếu tôi đọc /proc/mdstatđúng đầu ra đó , bạn sẽ không thể kích hoạt mảng ở trạng thái hiện tại.

Bạn có bất kỳ ổ đĩa vật lý nào trong máy bị lỗi không? Có ls /dev/sd*liệt kê tất cả các ổ đĩa và phân vùng mà bạn thường thấy trên máy đó không?

Một cách đơn giản để có được mảng chạy với giả sử không có vấn đề về phần cứng và bạn có đủ ổ đĩa / phân vùng để bắt đầu mảng là như sau:

md20 : inactive sdf1[2](S)
      732442488 blocks super 1.2

 sudo mdadm --manage /dev/md20  --run

Nó có thể là vì lý do nào đó mảng là tốt nhưng một cái gì đó ngăn nó bắt đầu hoặc xây dựng. Trong trường hợp của tôi, điều này là do mdadm không biết tên mảng ban đầu là md127 và tất cả các ổ đĩa đều được rút ra cho mảng đó. Khi cắm lại tôi phải tự lắp ráp (có thể là một lỗi trong đó mdadm nghĩ rằng mảng đã hoạt động do tên mảng cũ ngoại tuyến).