将我的 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）不应该自动从阵列中踢出受影响的驱动器吗？
由于它是 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
但是用 badblocks -wsv 重写整个磁盘没有错误。
因为它对我来说是一个非常重要的服务器，所以我用不同的模型替换了整个服务器，但错误仍然存在。我认为这可能是磁盘问题是否正确？
有没有办法知道哪个磁盘受到影响，也许是通过计算？
编辑：澄清一下：我没有得到的是从主站到从站的 1.5 TB 数据的初始同步如何导致两个不可恢复的 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
更新 2017-8-22 2 lsscsi 和 pastebin 上所有磁盘 smartctl 的输出：https ://pastebin.com/VUxKEKiF
更新-8/22
如果您想快速解决此问题，只需更换 smartctl 统计数据最差的两个驱动器并重新评估即可。一旦用完保留块，您的驱动器就停产了。看到我们一次购买所有这些，它们往往会在同一时间失败。因此，坏块固定到哪一个并不重要。一旦您更换了最严重的两个违规者（这意味着更换一个并重新同步并重复），您将提高阵列的整体运行状况，可能会更换出现故障的磁盘，并显着降低出现双重故障（导致您丢失所有内容）的风险。
最终，您的数据价值超过几百美元。
最终更新-8/22
更新-8/21
托尼 是的，您原来的帖子还有改进的空间。鉴于这些事实，这就是我得出的结论。直到现在还不清楚您是否已经遭受了数据损坏。
如果您在 smartctl 输出中包含标头，将会很有帮助。这在 scsi 上更容易，sg_reassign 会告诉您还剩下多少空闲块可以重新分配，一旦它变为零，您就完成了。看到 smartctl 在多个类别中报告“失败前”，听起来您也很快完成了。
很快您就会遇到硬介质错误，MD 将踢掉该驱动器。同时 fsck 将是一个好主意。当驱动器写入失败时，它们会从空闲块池中重新分配目标，当您用完时，它将成为不可恢复的介质错误。
还可以在 MD 上启用“磁盘清理器”并每周在 cron 上运行它，它将读取并重写每个扇区，并在它成为真正的问题之前将其阻止。请参阅内核中的 Documentation/md.txt。
[磁盘清理器示例] https://www.ogre.com/node/384
您仍然必须运行 smartmon 所有驱动器（每天一次，非工作时间），解析输出，并创建警报来阻止这个问题。
伙计们，这就是硬件袭击为你们做的事情。讽刺的是，我们拥有提供更好 MD 体验的所有工具，但没有人将其整合到一个集成解决方案中。
您几乎处于无声数据损坏的尾声。fsck 可能会帮助您，但实际上最好的做法是参考您的备份（您保留了备份吗？RAID 不是备份）并为该 RAID 开始下降做好准备。
然后你就会发现坏磁盘。
对不起。
最终更新-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 raid 阵列。因此，无论存在什么不存在的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 中启用“磁盘清理”来帮助防止将来发生这种情况，该功能会在维护窗口中读取和重写每个扇区，以准确发现此类问题并可能修复它们。
我希望这有帮助。
| 归档时间： |
|
| 查看次数： |
1846 次 |
| 最近记录： |