md-deviceのバッファI / Oエラー-故障したドライブを識別できません
Postgresマスターをスレーブサーバーに同期すると、スレーブで書き込みI/Oエラーが発生しました（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をbadblockで数回上書きしようとしましたが（そのために次々とディスクをレイドから削除しました）、残念ながら成功しませんでした。
smartctlは、1つのディスクに以前にエラーがあったと言います（他のディスクはクリーンです）：
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の最初の同期TBマスターからスレーブへのデータが2つの回復不能なI/Oエラーが発生しましたが、関連するすべてのSSDで破壊的な読み取り/書き込みテストを手動で実行すると、エラーなしで完了します。
EDIT2：lsblkの出力（sda-sdfと同じ）; pvs; 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
Update 2017-8-22 2Pastebin上のlsscsiおよびすべてのディスクsmartctlの出力： https://Pastebin.com/VUxKEKiF =
更新-8/22
この問題をすばやく解決したい場合は、smartctlの統計情報が最悪の2台のドライブを交換して再評価してください。予約ブロックがなくなると、ドライブはEOLになります。これらを一度に購入するのを見ると、ほぼ同時に失敗する傾向があります。したがって、どちらが不良ブロックに固定されているかは関係ありません。最悪の2人の違反者を置き換えると（つまり、1人を置き換えて再同期して繰り返す）、アレイの全体的な状態が向上し、おそらく不平を言っているディスクが置き換えられ、すべてを失うという二重障害のリスクが劇的に減少します。
結局のところ、データは数百ドル以上の価値があります。
ENDUPDATE-8/22
更新-8/21
Toniはい、元の投稿には改善の余地があります。これらの事実を考えると、これは私が到達した結論です。また、データの破損がすでに発生していることも、これまで明らかにされていませんでした。
ヘッダーをsmartctl出力に含めた場合、それは役に立ちます。これはscsiの方が簡単です。sg_reassignは、再割り当てするために残っている空きブロックの数を示します。それがゼロになると、完了です。 smartctlがいくつかのカテゴリで「prefail」を報告しているのを見ると、もうすぐ完了したように思えます。
すぐにハードメディアエラーが発生し、MDがドライブをキックします。それまでの間、fsckを使用することをお勧めします。ドライブが書き込みに失敗すると、空きブロックプールから宛先が再割り当てされます。ドライブがなくなると、回復不能なメディアエラーになります。
また、MDで「ディスクスクラバー」を有効にして、毎週cronで実行します。これにより、すべてのセクターが読み取られて書き換えられ、実際の問題になる前にこれが回避されます。カーネルのDocumentation/md.txtを参照してください。
[ディスクスクラバーの例] https://www.ogre.com/node/384
それでも、すべてのドライブ（1日1回、営業時間外）をsmartmonで実行し、出力を解析して、この非常に問題を回避するアラームを作成する必要があります。
皆さん、これはハードウェアレイドがあなたのために行うことです。皮肉なことに、私たちはより良いMDエクスペリエンスを提供するためのすべてのツールを持っていますが、それを統合ソリューションにまとめる人はいません。
あなたはほとんどサイレントデータ破損の最後尾にいます。 fsckが役立つかもしれませんが、実際に最善のことは、バックアップを参照して（バックアップは正しく保持されていますか？RAIDはバックアップではありません）、このRAIDがシンクを開始する準備をします。
次に、不良ディスクを見つけます。
ごめんなさい。
ENDUPDATE-8/21
手始めに、使用したオプションのbadblockのmanページを読みましたか？
-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は非破壊的なバージョンでした。たぶん、あなたが実際にしたことは、アレイからディスクを引き出し、その上で不良ブロックを実行してから、それを再度挿入したことでしょうか？どうか明らかにしてください。
どのディスクが最初から失敗しているかわからないということは、それがMDRAIDアレイではないことを教えてくれます。したがって、この単純な障害からの回復を支援するために存在しないlvm「raid」ツールが存在する場合は、それを理解する必要があります。
大多数のユーザーはMDRAIDソリューションを使用していると思います。残りは「これは何？」に気を取られます。または「ああ、これはLVMです。私がやるべきことですよね？」そして、後であなたが今いるところに行き着く。ひどい管理ツールを使用して実装を急襲しました。これは、最初にRAID6を構築することで軽減しようとしたよりも実際に多くのリスクを生み出しました。
それはあなたのせいではありません、あなたは知りませんでした。率直に言って、彼らはまさにこの理由で事を無効にするべきです。
不良ブロックの修復について。これを行うには、マシンをオフラインにして、ライブ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で「ディスクスクラビング」を有効にして、メンテナンスウィンドウで各セクターを読み書きし、これらの種類の問題を正確に発見して潜在的に修復することで、これを防ぐことができます。
これがお役に立てば幸いです。