Синхронизация моего мастера postgres с подчиненным сервером привела к ошибкам ввода-вывода записи на подчиненном (journalctl):
Aug 18 03:09:23 db01a kernel: EXT4-fs warning (device dm-3):
**ext4_end_bio:330: I/O error -5 writing to inode 86772956 (offset 905969664 size 8388608 starting block 368694016)**
Aug 18 03:09:23 db01a kernel: buffer_io_error: 326 callbacks suppressed
....
Чтение затронутого файла, конечно, тоже не работает:
cat base/96628250/96737718 >> /dev/null
cat: 96737718: Input/output error
Разве ядро Linux (ubuntu 16.04 4.4.0-87-generic) не должно автоматически удалять затронутый диск из массива?
Поскольку это Raid6 (LVM и ext4 сверху), я уже пытался несколько раз перезаписать каждый SSD с помощью плохих блоков, чтобы спровоцировать ошибку (для этого удалял один диск за другим из рейда), к сожалению, безуспешно.
smartctl сообщает, что на одном диске раньше были ошибки (остальные чистые):
smartctl -a /dev/sda
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 099 099 010 Pre-fail Always - 2
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 099 099 010 Pre-fail Always - 2
183 Runtime_Bad_Block 0x0013 099 099 010 Pre-fail Always - 2
187 Uncorrectable_Error_Cnt 0x0032 099 099 000 Old_age Always - 3
195 ECC_Error_Rate 0x001a 199 199 000 Old_age Always - 3
Но перезапись всего диска с помощью badblocks -wsv прошла без ошибок.
Поскольку для меня это очень важный сервер, я заменил весь сервер другой моделью, но ошибка не исчезла. Правильно ли я думаю, что это, вероятно, проблема с диском?
Есть ли способ узнать, какой диск затронут, может быть, посчитав?
РЕДАКТИРОВАТЬ: Для пояснения: я не понимаю, как первоначальная синхронизация данных 1,5 ТБ от ведущего к ведомому может привести к двум неисправимым ошибкам ввода-вывода, но ручное выполнение деструктивных тестов чтения-записи на каждом задействованном SSD завершается без любая ошибка.
EDIT2: вывод lsblk (идентичен sda-sdf); пвс; vgs; lvs;
lsblk:
sda1 8:16 0 953.9G 0 disk
├─sda1 8:17 0 4.7G 0 part
│ └─md0 9:0 0 4.7G 0 raid1
└─sda5 8:21 0 949.2G 0 part
└─md1 9:1 0 2.8T 0 raid6
├─vgdb01a-lvroot 252:0 0 18.6G 0 lvm /
├─vgdb01a-lvvar 252:1 0 28G 0 lvm /var
├─vgdb01a-lvtmp 252:2 0 4.7G 0 lvm /tmp
└─vgdb01a-lvpostgres 252:3 0 2.6T 0 lvm /postgres
pvs:
PV VG Fmt Attr PSize PFree
/dev/md1 vgdb01a lvm2 a-- 2.78t 133.64g
vgs:
VG #PV #LV #SN Attr VSize VFree
vgdb01a 1 4 0 wz--n- 2.78t 133.64g
lvs:
lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
lvpostgres vgdb01a -wi-ao---- 2.60t
lvroot vgdb01a -wi-ao---- 18.62g
lvtmp vgdb01a -wi-ao---- 4.66g
lvvar vgdb01a -wi-ao---- 27.94g
Обновление 2017-8-22
echo check > /sys/block/md1/md/sync_action
[Mon Aug 21 16:10:22 2017] md: data-check of RAID array md1
[Mon Aug 21 16:10:22 2017] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
[Mon Aug 21 16:10:22 2017] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check.
[Mon Aug 21 16:10:22 2017] md: using 128k window, over a total of 995189760k.
[Mon Aug 21 18:58:18 2017] md: md1: data-check done.
echo repair > /sys/block/md1/md/sync_action [Tue Aug 22 12:54:11 2017] md: requested-resync of RAID array md1
[Tue Aug 22 12:54:11 2017] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
[Tue Aug 22 12:54:11 2017] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for requested-resync.
[Tue Aug 22 12:54:11 2017] md: using 128k window, over a total of 995189760k.
[2160302.241701] md: md1: requested-resync done.
e2fsck -y -f /dev/mapper/vgdb01a-lvpostgres
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/vgdb01a-lvpostgres: 693517/174489600 files (1.6% non-contiguous), 608333768/697932800 blocks
Обновление 2017-8-22 2 Вывод lsscsi и всего диска smartctl на pastebin: https://pastebin.com/VUxKEKiF
ОБНОВЛЕНИЕ-8/22
Если вы хотите быстро решить эту проблему, просто замените два диска которые имеют худшие характеристики smartctl и переоценивают. Как только у вас закончились зарезервированные блоки, ваш диск - EOL. Видя, что мы покупаем их все сразу, они обычно выходят из строя примерно в одно и то же время. Так что не имеет значения, к какому из них прикреплен плохой блок. После того, как вы замените двух наихудших нарушителей (что означает замену одного, повторную синхронизацию и повторение), вы увеличите общее состояние массива, возможно, замените диск с жалобами и резко снизите риск двойной ошибки, когда вы потеряете все.
В конце концов, ваши данные стоят более нескольких сотен долларов.
ENDUPDATE-8/22
ОБНОВЛЕНИЕ-8/21
Тони: Да, ваш исходный пост можно улучшить. Учитывая эти факты, я пришел к такому выводу. Также до сих пор не было ясно, что вы уже пострадали от повреждения данных.
Было бы полезно, если бы вы включили заголовки в вывод smartctl. В scsi это проще, sg_reassign сообщит вам, сколько свободных блоков вам осталось переназначить, как только оно станет равным нулю, все готово. Увидев, что smartctl сообщает о предварительном сбое в нескольких категориях, похоже, что вы тоже скоро закончили.
Вскоре вы столкнетесь с ошибками жесткого диска, и MD вынет диск. Тем временем, fsck будет хорошей идеей. Когда диски терпят неудачу при записи, они переназначают место назначения из пула свободных блоков, когда вы заканчиваете, это становится неустранимой ошибкой носителя.
Также включите «очиститель диска» на MD и запускайте его на cron еженедельно, он будет читать и перезаписывать каждый сектор и блокировать это, прежде чем это станет реальной проблемой. См. Документацию / md.txt в ядре.
[пример очистки диска] https://www.ogre.com/node/384
Вам все равно нужно запускать smartmon на всех дисках (один раз в день, в нерабочее время), анализировать вывод и создавать аварийные сигналы, чтобы предотвратить эту проблему.
Ребята, вот что делают для вас аппаратные рейды. Ирония заключается в том, что у нас есть все инструменты для улучшения работы с MD, но никто не объединяет их в единое решение.
Вы в значительной степени находитесь в хвостовой части скрытого повреждения данных. Вам может помочь fsck, но на самом деле лучше всего обратиться к вашим резервным копиям (вы правильно сохранили резервные копии? RAID не являются резервными копиями) и подготовиться к тому, что этот RAID начнет тонуть.
Тогда вы найдете плохой диск.
Сожалею.
ENDUPDATE-8/21
Для начала, читали ли вы справочную страницу о плохих блоках для используемых вами опций?
-w Use write-mode test. With this option, badblocks scans for bad blocks by writing
some patterns (0xaa, 0x55, 0xff, 0x00) on every block of the device, reading every
block and comparing the contents. This option may not be combined with the -n
option, as they are mutually exclusive.
Итак, ваши данные исчезли, -n была неразрушающей версией. Может быть, вы действительно вытащили диск из массива, запустили на нем плохие блоки, а затем снова вставили его? Просьба уточнить.
То, что вы не знаете, какой диск вышел из строя, говорит мне, что это не рейд-массив MD. Итак, какие бы несуществующие инструменты lvm «raid» не существовали, чтобы помочь вам восстановиться после этого простого сбоя, это то, что вам нужно выяснить.
Я бы сказал, что большинство пользователей используют решение MD raid. Остальные отвлекаются на "что это за штука?" или "о, это LVM, это то, что я должен делать, верно?" и позже окажетесь там, где вы сейчас. Я совершаю набег с помощью ужасных инструментов управления, которые на самом деле создают больший риск, чем вы пытались уменьшить, создав для начала RAID 6.
Это не твоя вина, ты не знал. Честно говоря, именно по этой причине они должны вывести эту штуку из строя.
По поводу ремонта плохих блоков. Вы можете сделать это перевод машины в автономный режим и загрузка с живого USB-накопителя и выполнение одной из следующих процедур ремонта.
https://sites.google.com/site/itmyshare/storage/storage-disk/bad-blocks-how-to
http://linuxtroops.blogspot.com/2013/07/how-to-find-bad-block-on-linux-harddisk.html
Что касается того, где этот сектор находится в вашем массиве. Что ж, вам придется учитывать ротацию паритета, которая является PITA. Я бы посоветовал вам просто проверять каждый диск, пока не обнаружите проблему.
Вы можете помочь предотвратить это в будущем, включив «очистку диска» в MD, которая считывает и перезаписывает каждый сектор в окне обслуживания, чтобы обнаружить именно такого рода проблемы и потенциально исправить их.
Надеюсь, это поможет.