URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 86905
[ Назад ]
Исходное сообщение
"Проблема с рейдом mdadm"
Отправлено ESP , 15-Окт-09 10:09 
Добрый день.
Отрубили свет, а apcupsd отключил комп несколько ранее, чем остановились все процессы. В результате, при ресинхорнизации sdb=>sda получил 18 ошибок, они же вылезли и при smartctl --all /dev/sda.

smartctl --all /dev/sda

smartctl version 5.38 [i686-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Barracuda 7200.10 family
Device Model:     ST3250310AS
Serial Number:    9RY01C4W
Firmware Version: 3.AAA
User Capacity:    250 059 350 016 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Thu Oct 15 11:31:03 2009 NOVST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82)    Offline data collection activity
                    was completed without error.
                    Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0)    The previous self-test routine completed
                    without error or no self-test has ever
                    been run.
Total time to complete Offline
data collection:          ( 430) seconds.
Offline data collection
capabilities:              (0x5b) SMART execute Offline immediate.
                    Auto Offline data collection on/off support.
                    Suspend Offline collection upon new
                    command.
                    Offline surface scan supported.
                    Self-test supported.
                    No Conveyance Self-test supported.
                    Selective Self-test supported.
SMART capabilities:            (0x0003)    Saves SMART data before entering
                    power-saving mode.
                    Supports SMART auto save timer.
Error logging capability:        (0x01)    Error logging supported.
                    General Purpose Logging supported.
Short self-test routine
recommended polling time:      (   1) minutes.
Extended self-test routine
recommended polling time:      (  92) minutes.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   106   100   006    Pre-fail  Always       -       11304615
  3 Spin_Up_Time            0x0003   097   097   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       87
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   067   060   030    Pre-fail  Always       -       5805208
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       1223
10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       87
187 Reported_Uncorrect      0x0032   082   082   000    Old_age   Always       -       18
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   064   057   045    Old_age   Always       -       36 (Lifetime Min/Max 33/36)
194 Temperature_Celsius     0x0022   036   043   000    Old_age   Always       -       36 (0 22 0 0)
195 Hardware_ECC_Recovered  0x001a   068   064   000    Old_age   Always       -       2613598
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0000   100   253   000    Old_age   Offline      -       0
202 TA_Increase_Count       0x0032   100   253   000    Old_age   Always       -       0

SMART Error Log Version: 1
ATA Error Count: 18 (device log contains only the most recent five errors)
    CR = Command Register [HEX]
    FR = Features Register [HEX]
    SC = Sector Count Register [HEX]
    SN = Sector Number Register [HEX]
    CL = Cylinder Low Register [HEX]
    CH = Cylinder High Register [HEX]
    DH = Device/Head Register [HEX]
    DC = Device Command Register [HEX]
    ER = Error register [HEX]
    ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 18 occurred at disk power-on lifetime: 1222 hours (50 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 49 4c 40 e4  Error: UNC at LBA = 0x04404c49 = 71322697

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 47 4c 40 e4 00      00:08:40.753  READ DMA
  27 00 00 00 00 00 e0 00      00:08:40.750  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 00      00:08:40.750  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 00      00:08:40.747  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 e0 00      00:08:37.186  READ NATIVE MAX ADDRESS EXT

Error 17 occurred at disk power-on lifetime: 1222 hours (50 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 49 4c 40 e4  Error: UNC at LBA = 0x04404c49 = 71322697

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 47 4c 40 e4 00      00:08:40.753  READ DMA
  27 00 00 00 00 00 e0 00      00:08:40.750  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 00      00:08:40.750  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 00      00:08:40.747  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 e0 00      00:08:37.186  READ NATIVE MAX ADDRESS EXT

Error 16 occurred at disk power-on lifetime: 1222 hours (50 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 49 4c 40 e4  Error: UNC at LBA = 0x04404c49 = 71322697

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 47 4c 40 e4 00      00:08:33.605  READ DMA
  27 00 00 00 00 00 e0 00      00:08:30.028  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 00      00:08:30.028  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 00      00:08:30.015  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 e0 00      00:08:37.186  READ NATIVE MAX ADDRESS EXT

Error 15 occurred at disk power-on lifetime: 1222 hours (50 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 49 4c 40 e4  Error: UNC at LBA = 0x04404c49 = 71322697

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 47 4c 40 e4 00      00:08:33.605  READ DMA
  27 00 00 00 00 00 e0 00      00:08:30.028  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 00      00:08:30.028  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 00      00:08:30.015  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 e0 00      00:08:30.004  READ NATIVE MAX ADDRESS EXT

Error 14 occurred at disk power-on lifetime: 1222 hours (50 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 49 4c 40 e4  Error: UNC at LBA = 0x04404c49 = 71322697

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 47 4c 40 e4 00      00:08:22.735  READ DMA
  27 00 00 00 00 00 e0 00      00:08:30.028  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 00      00:08:30.028  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 00      00:08:30.015  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 e0 00      00:08:30.004  READ NATIVE MAX ADDRESS EXT

SMART Self-test log structure revision number 1

SMART Selective self-test log data structure revision number 1
SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.


Сейчас не стартует один из сервисов - база данных. Прошу помощи, т.к. опыта пока маловато.
Насколько я понял, бэдов пока нет, раз   Reallocated_Sector_Ct 0. Но все же, чего делать далее?

Содержание
Сообщения в этом обсуждении
"Проблема с рейдом mdadm"
Отправлено ALex_hha , 15-Окт-09 12:28 
А при чем тут smart к ошибкам на ФС?

показывай

# cat /proc/mdstat

# mdadm --examine --scan

# mdadm --detail /dev/mdX

"Проблема с рейдом mdadm"
Отправлено ESP , 15-Окт-09 12:43 
>А при чем тут smart к ошибкам на ФС?

Ошибки выскочили в процессе синхронизации, да и сейчас если смарт запускаешь - выдает эти 18 ошибок.

>показывай
>
># cat /proc/mdstat

Personalities : [raid1]
md1 : active raid1 sdb2[1] sda2[0]
      4096448 blocks [2/2] [UU]
      
md2 : active raid1 sdb3[1] sda3[0]
      127459584 blocks [2/2] [UU]
      
md0 : active raid1 sdb1[1] sda1[0]
      112639616 blocks [2/2] [UU]
      
unused devices: <none>

># mdadm --examine --scan

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=aab816ab:c8722d2d:5c3f933a:fd6a24ed
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=4416014a:3b19b92b:1659efbf:d0c9ecd0
ARRAY /dev/md2 level=raid1 num-devices=2 UUID=2615cdf2:a1904686:c72dc049:7d84a763

># mdadm --detail /dev/mdX

mdadm --detail /dev/md0

/dev/md0:
        Version : 00.90.03
  Creation Time : Fri Aug 28 17:36:58 2009
     Raid Level : raid1
     Array Size : 112639616 (107.42 GiB 115.34 GB)
  Used Dev Size : 112639616 (107.42 GiB 115.34 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Thu Oct 15 15:41:06 2009
          State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
  Spare Devices : 0

           UUID : aab816ab:c8722d2d:5c3f933a:fd6a24ed
         Events : 0.22

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


mdadm --detail /dev/md1

/dev/md1:
        Version : 00.90.03
  Creation Time : Fri Aug 28 17:36:58 2009
     Raid Level : raid1
     Array Size : 4096448 (3.91 GiB 4.19 GB)
  Used Dev Size : 4096448 (3.91 GiB 4.19 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Wed Sep  9 13:24:20 2009
          State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
  Spare Devices : 0

           UUID : 4416014a:3b19b92b:1659efbf:d0c9ecd0
         Events : 0.4

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


mdadm --detail /dev/md2

/dev/md2:
        Version : 00.90.03
  Creation Time : Fri Aug 28 17:37:54 2009
     Raid Level : raid1
     Array Size : 127459584 (121.55 GiB 130.52 GB)
  Used Dev Size : 127459584 (121.55 GiB 130.52 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 2
    Persistence : Superblock is persistent

    Update Time : Thu Oct 15 15:41:15 2009
          State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
  Spare Devices : 0

           UUID : 2615cdf2:a1904686:c72dc049:7d84a763
         Events : 0.20

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

"Проблема с рейдом mdadm"
Отправлено ALex_hha , 15-Окт-09 13:54 
Из строк
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0

на всех разделах рейда, следует что нет никакой рассинхронизации. С чего ты это взял?

"Проблема с рейдом mdadm"
Отправлено ESP , 15-Окт-09 14:01 
>на всех разделах рейда, следует что нет никакой рассинхронизации. С чего ты
>это взял?

Я и не утверждаю, что она есть. Я вижу проблему по smartctl - есть ошибки на диске, о которых было сообщено во время синхронизации после сбоя питания. В результате имею незапускающуюся субд - спец по субд сказал, ее теперь надо восстанавливать из бекапа.

А пока я хочу понять, как исправить ошибки на диске и чем они грозят. Буду признателен за помощь.

PS. наверно, не слишком удачно обозвал тему.

"Проблема с рейдом mdadm"
Отправлено ALex_hha , 15-Окт-09 14:32 
>[оверквотинг удален]
>
>Я и не утверждаю, что она есть. Я вижу проблему по smartctl
>- есть ошибки на диске, о которых было сообщено во время
>синхронизации после сбоя питания. В результате имею незапускающуюся субд - спец
>по субд сказал, ее теперь надо восстанавливать из бекапа.
>
>А пока я хочу понять, как исправить ошибки на диске и чем
>они грозят. Буду признателен за помощь.
>
>PS. наверно, не слишком удачно обозвал тему.

fsck запускал? Что она говорит?

Smart мог ругаться только, если какие то проблемы с физикой диска, до фс ему нет никакого дела

Я бы сделал так

fsck - чтобы убедиться что на фс нет ошибок
victoria/mhdd - чтобы убедиться, что физика у винтов номральная

"Проблема с рейдом mdadm"
Отправлено ESP , 15-Окт-09 14:39 
>fsck запускал? Что она говорит?

fsck /dev/sda - не дает, говорит, что устройство занято. Его придется из рейда выводить и проверять, или взять да и проверить весь массив fsck /dev/md0 ?

>Smart мог ругаться только, если какие то проблемы с физикой диска, до
>фс ему нет никакого дела
>Я бы сделал так
>
>fsck - чтобы убедиться что на фс нет ошибок
>victoria/mhdd - чтобы убедиться, что физика у винтов номральная

"Проблема с рейдом mdadm"
Отправлено ze6ra , 15-Окт-09 17:28 
>[оверквотинг удален]
>fsck /dev/sda - не дает, говорит, что устройство занято. Его придется из
>рейда выводить и проверять, или взять да и проверить весь массив
>fsck /dev/md0 ?
>
>>Smart мог ругаться только, если какие то проблемы с физикой диска, до
>>фс ему нет никакого дела
>>Я бы сделал так
>>
>>fsck - чтобы убедиться что на фс нет ошибок
>>victoria/mhdd - чтобы убедиться, что физика у винтов номральная

Базы хранят много данных в память и данные на диск пишутся не сразу поэтому не корректная остановка сервиса БД может привести к не рабочей базе или рабочей но стартовать придется методами отличными от штатных поскольку движок СУБД будет видеть что сервис не был завершён нормально и соответственно без  вмешательства администратора БД не запустится. fsck проверяет ФС которая на /dev/mdX соответственно по частям проверить,  после синхронизации, бессмысленно эти диски уже точные копии друг друга. Лучше разберитесь как служба бесперебойника смогла не корректно вырубить систему так что даже RAID рассенхронизировались. Может стоит проверить батарею или таймауты да бесперебойник вещь весьма ненадёжная раз в полгода желательно проверить что он ещё держит нагрузку иначе всё может плохо кончится.

"Проблема с рейдом mdadm"
Отправлено ESP , 15-Окт-09 18:07 
>Базы хранят много данных в память и данные на диск пишутся не
>сразу поэтому не корректная остановка сервиса БД может привести к не
>рабочей базе или рабочей но стартовать придется методами отличными от штатных
>поскольку движок СУБД будет видеть что сервис не был завершён нормально
>и соответственно без  вмешательства администратора БД не запустится.

Тут разобрались - восстановил из бекапа без проблем.

> fsck проверяет ФС которая на /dev/mdX соответственно по частям проверить,  после синхронизации, бессмысленно эти диски уже точные копии друг друга.

я чего-то недопонимаю) если они точные копии, как и должно быть, по идее, то почему smartctl находит 18 ошибок на sda и не находит ничего на sdb?

Все же, в голове пока нет четкого алгоритма, что делать. Пока представляю так.

Пометить все, что касается sba как сбойное:
mdadm --manage /dev/md0 --fail /dev/sda1
mdadm --manage /dev/md1 --fail /dev/sda2
mdadm --manage /dev/md2 --fail /dev/sda3

Убрать из рейда sda:
mdadm --manage /dev/md0 --remove /dev/sda1
mdadm --manage /dev/md1 --remove /dev/sda2
mdadm --manage /dev/md2 --remove /dev/sda3

Проверить:
fsck /dev/sda - или он не даст проверить смонтированное устройство?

Если все исправится, то добавить в рейд:
mdadm --manage /dev/md0 --add /dev/sda1
mdadm --manage /dev/md1 --add /dev/sda2
mdadm --manage /dev/md2 --add /dev/sda3

После этого ресинхронизация будет производиться с sdb, поскольку sda пометили как сбойный.

Хотелось бы, чтобы кто-нибудь с опытом такой порядок действий подтвердил или меня поправил.

> Лучше разберитесь как
>служба бесперебойника смогла не корректно вырубить систему так что даже RAID
>рассенхронизировались. Может стоит проверить батарею или таймауты да бесперебойник вещь весьма
>ненадёжная раз в полгода желательно проверить что он ещё держит нагрузку
>иначе всё может плохо кончится.

Собственно, это мой первый сервер, а apcupsd я только вчера вечером поставил, не успел толком настроить. Как я понял, неверно определилось время работы от батареи, т.к. вчера заметил, что было написано что-то около 40 минут, а света сегодня не было минут 5 всего...

"Проблема с рейдом mdadm"
Отправлено аноним , 15-Окт-09 19:04 
>я чего-то недопонимаю) если они точные копии, как и должно быть, по идее, то почему smartctl находит 18 ошибок на sda и не находит ничего на sdb?

1. это ошибки железные, а не программные
2. ошибки эти говорят о том, что в какой-то момент у тебя сбоил винт или контрошка на мамке

"Проблема с рейдом mdadm"
Отправлено ALex_hha , 15-Окт-09 19:07 
>[оверквотинг удален]
>>>Я бы сделал так
>>>
>>>fsck - чтобы убедиться что на фс нет ошибок
>>>victoria/mhdd - чтобы убедиться, что физика у винтов номральная
>
>Базы хранят много данных в память и данные на диск пишутся не
>сразу поэтому не корректная остановка сервиса БД может привести к не
>рабочей базе или рабочей но стартовать придется методами отличными от штатных
>поскольку движок СУБД будет видеть что сервис не был завершён нормально
>и соответственно без  вмешательства администратора БД не запустится.

при чем тут это? В таком случае, максисмум что ты получишь - не достоверные данные в БД, но никак "не битую" БД, которая даже стартовать не может. И то, в этом случае есть понятие транзакций.

> Лучше разберитесь как служба бесперебойника смогла не корректно вырубить систему так что даже RAID рассенхронизировались.

если сервис критический, то лучше купить аппаратный рейд с т.н. батарейкой (BBU)

"Проблема с рейдом mdadm"
Отправлено ze6ra , 15-Окт-09 19:31 

>при чем тут это? В таком случае, максисмум что ты получишь -
>не достоверные данные в БД, но никак "не битую" БД, которая
>даже стартовать не может. И то, в этом случае есть понятие
>транзакций.
>

не стартует ещё не значит "битая", а не достоверные данные в БД это как раз то что и не должно там быть, если БД не может по какимто причинам быть уверена в достоверности данных то она просто не стартует и транзакции здесь особо не причем, тут есть журналы и т.д. не стартуте если требуется вмешательство человека, есть утилиты проверки специальные ключи запуска и главное специалист знающий как работает данная БД и что можно делать чтоб там не оказалось не дай бог не достоверных данных,что не всегда имеется.  

>если сервис критический, то лучше купить аппаратный рейд с т.н. батарейкой (BBU)
>

у них походу денег даже на админа нет. Так что видать не очень критический.

"Проблема с рейдом mdadm"
Отправлено ALex_hha , 15-Окт-09 19:36 
>[оверквотинг удален]
>>при чем тут это? В таком случае, максисмум что ты получишь -
>>не достоверные данные в БД, но никак "не битую" БД, которая
>>даже стартовать не может. И то, в этом случае есть понятие
>>транзакций.
>>
>
>не стартует ещё не значит "битая", а не достоверные данные в БД
>это как раз то что и не должно там быть, если
>БД не может по каким то причинам быть уверена в достоверности данных
>то она просто не стартует и транзакции здесь особо не причем,

транзакции как раз и предназначены для избежания несогласованности данных, если мне не изменяет память из курса теория реляционных БД :)

Тогда по твоему получается, если я в поле с возрастом человека запишу его имя, то MySQL не запустится?

Давай все таки не путать логическую и физическую целостности БД.

Если я правильно понимаю, после запуска fsck и успешной отработки, мы отбрасываем физическую составляющую и остается только логическая, из-за которой СУБД не может не запускаться. Или я не прав?

"Проблема с рейдом mdadm"
Отправлено ze6ra , 15-Окт-09 19:59 
>транзакции как раз и предназначены для избежания несогласованности данных, если мне не
>изменяет память из курса теория реляционных БД :)
>

именно так, но это когда субд всё контролирует. А когда тухнет свет и пара гибайт памяти резко исчезает часть из которой еще не оказалась на диске, тут хорошо если удалось откатится к последней checkpoint.
>Тогда по твоему получается, если я в поле с возрастом человека запишу
>его имя, то MySQL не запустится?
>

если hex редактором то может нет, не уверен.
>Давай все таки не путать логическую и физическую целостности БД.
>

если служба субд при запуске видит что одно может не соответсвовать другому то она не пустится с соответствующей ошибкой наприме в сегменте такомто таблицы такой-то какаято хрень, разберитесь сами если вас всё устраивает то запустите меня с такимто ключиком и буду работать, тут надо почитать манул по запуску базы после сбоя и он как правило содержит много технических тонкостей.
>Если я правильно понимаю, после запуска fsck и успешной отработки, мы отбрасываем
>физическую составляющую и остается только логическая, из-за которой СУБД не может
>не запускаться. Или я не прав?

fsck покажет челостность структур фс тоже почти БД, но данных в нутри файлов она не проверяет, но поскольку фс проектировалась с учётом таких сбоев и там тоже есть свой журнал и транзакции то дума что если fsck не нашла ошибок, то ошибка скорей из-за того что не был корректно основлен сервис БД (а возможно и запускался потом тоже неизвестно как, в практике были печальные случаи доступа к кнопке питания железки с базой людей
с желанием все выключить).
А глючить может и контроллер на плате, а может и винт.

"Проблема с рейдом mdadm"
Отправлено ALex_hha , 15-Окт-09 19:02 
>>fsck запускал? Что она говорит?
>
>fsck /dev/sda - не дает, говорит, что устройство занято. Его придется из
>рейда выводить и проверять, или взять да и проверить весь массив
>fsck /dev/md0 ?

это очень желательно делать в single mode, когда у вас ничего не смонтировано

И проверять надо было sda1/sda2/sdb3. В выводе

# mdadm --detail /dev/md1
...
...
...

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

четко видно имена устройств.

"Проблема с рейдом mdadm"
Отправлено ESP , 16-Окт-09 07:27 
в общем, попробовал
1. перегрузился в однопользовательском режиме
2. перемонировал все фс на чтение
3. разобрал рейд
4. fsck -yvf /dev/sdaX
5. smartctl --all /dev/sda говорит о все тех же 18 ошибках Reported Uncorrect (UNC at LBA)

какие будут мысли?

"Проблема с рейдом mdadm"
Отправлено ESP , 16-Окт-09 08:32 
badblocks -v /dev/sda
Pass completed, 0 bad blocks found.

Может, за эти ошибки и беспокоиться не надо? Или, наоборот, винт пора на помойку?

"Проблема с рейдом mdadm"
Отправлено ALex_hha , 16-Окт-09 13:54 
>badblocks -v /dev/sda
>Pass completed, 0 bad blocks found.
>
>Может, за эти ошибки и беспокоиться не надо? Или, наоборот, винт пора
>на помойку?

Я же говорил, физику проверь victoria или mhdd. Ну и найди описание тех ошибок смарта, о чем вообще они говорят

"Проблема с рейдом mdadm"
Отправлено ESP , 16-Окт-09 15:20 
Спасибо, что помогаешь!

>Я же говорил, физику проверь victoria или mhdd. Ну и найди описание
>тех ошибок смарта, о чем вообще они говорят

Виктория в линейном тесте говорит - дефектов не найдено.

http://en.wikipedia.org/wiki/Self-Monitoring%2C_Analysi...

Reported Uncorrectable Errors  A number of errors that could not be recovered using hardware ECC (see attribute 195).  Как я понял, число ошибок передачи данных по шине данных, которые НЕ удалось восстановить аппаратно, исходя из противоположного параметра №195 в русской википедии.

О чем это может говорить? Шлейфы может САТАшные проверить?

"Проблема с рейдом mdadm"
Отправлено sHaggY_caT , 16-Окт-09 15:37 
>[оверквотинг удален]
>Виктория в линейном тесте говорит - дефектов не найдено.
>
>http://en.wikipedia.org/wiki/Self-Monitoring%2C_Analysi...
>
>Reported Uncorrectable Errors  A number of errors that could not be
>recovered using hardware ECC (see attribute 195).  Как я понял,
>число ошибок передачи данных по шине данных, которые НЕ удалось восстановить
>аппаратно, исходя из противоположного параметра №195 в русской википедии.
>
>О чем это может говорить? Шлейфы может САТАшные проверить?

А нет запасного диска? Если с запасным проблем не будет, то виноват диск. Я бы в такой ситуации сперва выкинула винт из боевого сервера, поставила бы заведомо рабочий, а уже потом разбиралась бы с этим, гоняла бы на тестах, и т д

Если с другим диском будут проблемы, то контроллер или шлейфы.
А бэкапы рулят, рада за Вас, что все восстановили :)

"Проблема с рейдом mdadm"
Отправлено ALex_hha , 19-Окт-09 01:18 
>[оверквотинг удален]
>Виктория в линейном тесте говорит - дефектов не найдено.
>
>http://en.wikipedia.org/wiki/Self-Monitoring%2C_Analysi...
>
>Reported Uncorrectable Errors  A number of errors that could not be
>recovered using hardware ECC (see attribute 195).  Как я понял,
>число ошибок передачи данных по шине данных, которые НЕ удалось восстановить
>аппаратно, исходя из противоположного параметра №195 в русской википедии.
>
>О чем это может говорить? Шлейфы может САТАшные проверить?

если их количество не увеличивается, то это вполне может быть нормальным состоянием, с у четом того, что ошибки появились из-за того, что выключили свет

"Проблема с рейдом mdadm"
Отправлено ESP , 19-Окт-09 10:29 
>если их количество не увеличивается, то это вполне может быть нормальным состоянием,
>с у четом того, что ошибки появились из-за того, что выключили
>свет

В википедии написано, что параметр не является критическим. В большинстве мануалов по смарту пишут, что главное, чтобы общий результат теста бы PASSED.

Шлейф менял, не помогло. Сейчас вот собрал обратно рейд. Ресинхронизация прошла без проблем и ошибок. Хотя смарт по-прежнему эти 18 ошибок пишет.