同步我的postgres主从服务器导致从站（journalctl）写入I / O错误：
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）不应该从arrays中自动启动受影响的驱动器吗？
因为它是一个Raid6（上面的LVM和ext4），我已经试图用坏块重写每个SSD几次，以引发错误（从RAID中移除一个接一个的磁盘），不幸的是没有成功。
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
但是用坏块重写整个磁盘-wsv没有错误地工作。
由于它对我来说是一个非常重要的服务器，我用一个不同的模型replace了整个服务器，但错误仍然存在。 我是否正确认为这可能是一个磁盘问题？
有什么办法可以通过计算来知道哪个磁盘受到影响？
编辑：澄清：我没有得到的是如何初始同步的1.5TB数据从主机到从机可能导致两个不可恢复的I / O错误，但手动运行破坏性读写testing在每个涉及的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
更新2017-8-22 2 pastecs上的lsscsi和所有磁盘smartctl的输出： https ：//pastebin.com/VUxKEKiF
UPDATE-22分之8
如果您想快速解决这个问题，只需更换那些最差的smartctl统计数据并重新评估的两个驱动器 。 一旦你没有保留块你的驱动器是EOL。 看到我们立刻购买这些东西，他们往往会在同一时间失败。 所以不pipe哪块坏块被固定在哪里都没关系。 一旦你取代了最糟糕的两个罪犯（这意味着replace一个，重新同步和重复），你会增加arrays的整体健康状况，可能取代了抱怨磁盘，并大大降低了双失败的风险，你失去了一切。
在一天结束的时候，你的数据价值超过几百美元。
ENDUPDATE-22分之8
UPDATE-21分之8
托尼是的，你原来的职位有改进的余地。 鉴于这些事实，这是我到达的结论。 目前还不清楚您是否已经遭受数据损坏。
如果您将标头包含在smartctl输出中，将会很有帮助。 这在scsi上比较容易，sg_reassign会告诉你有多less个空闲块可以重新分配，一旦归零，就完成了。 看到smartctl正在报告几个类别的“prefail”，这听起来很快就完成了。
很快你会遇到硬盘媒体的错误，医学博士将踢开硬盘。 同时fsck会是个好主意。 当驱动器写入失败时，它们将从空闲块池中重新分配目标，当用完时，它将成为不可恢复的介质错误。
同时启用MD上的“磁盘清理程序”并在每周一次的cron上运行它，它会读取并重写每个扇区，并在这个问题成为真正的问题之前将其closures。 请参阅内核中的Documentation / md.txt。
[磁盘清理程序示例] https://www.ogre.com/node/384
您仍然必须运行smartmon所有的驱动器（每天一次，小时），parsing输出，并创build警报来解决这个问题。
伙计们，这是硬件袭击为你做的。 具有讽刺意味的是，我们拥有所有的工具来提供更好的MD体验，但没有人把它们整合到一个整体解决scheme中。
你几乎在沉默的数据损坏的尾声。 fsck可能对你有所帮助，但是最好的办法是指你的备份（你保存备份的权利？RAID不是备份），并准备好这个RAID开始沉没。
然后你会发现坏的磁盘。
抱歉。
ENDUPDATE-21分之8
对于初学者，您是否阅读过使用选项的badblocks手册页？
-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 RAIDarrays。 所以，不pipe什么不存在的lvm“raid”工具可以帮助你从这个简单的失败中恢复过来，这就是你需要弄清楚的。
我会说，大多数用户使用MD的RAID解决scheme。 其余的人被“这是什么东西？ 或者“哦，这是LVM，这是我应该做的，对不对？ 后来结束了你现在的地方。 我用可怕的pipe理工具突袭实施，实际上创build的风险比您尝试通过构buildRAID 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
至于这个部门在你的arrays。 那么，你将不得不考虑平价轮换，这是一个PITA。 我build议你只是validation每个驱动器，直到你发现问题。
您可以通过在MD中启用“磁盘清理”function来帮助防止这种情况的发生，即在维护窗口中读取和重写每个扇区，以准确发现这些问题并进行修复。
我希望这有帮助。