Wir haben einen Kafka-Cluster mit RHEL 7.6, alle Kafka sind VM-Maschinen
Auf einer der Kafka-Maschinen stellten wir fest, dass die SDB-Festplatte schreibgeschützt war (wobei SDA die Betriebssystemfestplatte ist).
mount | grep sdb
/dev/sdb on /var/data/kafka_DB type ext4 (ro,noatime,data=ordered)
aus meiner Sicht ist es etwas seltsam, dass DISK VMDK schreibgeschützt wurde (weil es keine mechanische Festplatte ist)
von red-hat finde ich folgendes
https://access.redhat.com/solutions/1273213
https://access.redhat.com/solutions/35329
aber ich bin nicht sicher, ob die obigen Vorschläge von Redhat die Antwort darauf sind, warum die Festplatte schreibgeschützt wurde
noch andere Meinungen?
Aus den Kernel-Protokollen können wir Folgendes ersehen:
[1642397.157193] sd 0:0:2:0: [sdb] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
[1642397.157200] sd 0:0:2:0: [sdb] CDB: Write(10) 2a 00 12 c0 01 00 00 00 08 00
[1642397.157214] blk_update_request: I/O error, dev sdb, sector 314573056
[1642397.157242] Buffer I/O error on dev sdb, logical block 39321632, lost async page write
[1642397.157806] sd 0:0:2:0: [sdb] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
[1642397.157808] sd 0:0:2:0: [sdb] CDB: Read(10) 28 00 12 c4 03 58 00 00 08 00
[1642397.157810] blk_update_request: I/O error, dev sdb, sector 314835800
[1642397.157843] sd 0:0:2:0: [sdb] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
[1642397.157845] sd 0:0:2:0: [sdb] CDB: Read(10) 28 00 12 c4 0b a0 00 00 08 00
[1642397.157847] blk_update_request: I/O error, dev sdb, sector 314837920
[1642578.412306] sd 0:0:2:0: [sdb] task abort on host 0, ffff8c147c189880
[1642924.513605] sd 0:0:2:0: [sdb] task abort on host 0, ffff8c16a4f01880
[1643034.935334] JBD2: Detected IO errors while flushing file data on sdb-8
[1643035.002651] EXT4-fs error (device sdb): __ext4_new_inode:989: comm pool-6-thread-1: failed to insert inode 8126474: doubly allocated?
[1643036.753397] Aborting journal on device sdb-8.
[1643036.754490] EXT4-fs error (device sdb): ext4_journal_check_start:56: Detected aborted journal
[1643036.754496] EXT4-fs (sdb): Remounting filesystem read-only
[1643226.599854] sd 0:0:2:0: [sdb] task abort on host 0, ffff8c14a4bd3800
[1694249.598258] EXT4-fs (sdb): error count since last fsck: 17
[1694249.598269] EXT4-fs (sdb): initial error at time 1629844995: ext4_find_entry:1312: inode 656236
[1694249.598273] EXT4-fs (sdb): last error at time 1630003886: ext4_journal_check_start:56
[1780756.527074] EXT4-fs (sdb): error count since last fsck: 17
[1780756.527086] EXT4-fs (sdb): initial error at time 1629844995: ext4_find_entry:1312: inode 656236
[1780756.527088] EXT4-fs (sdb): last error at time 1630003886: ext4_journal_check_start:56
/sys/block/Wir denken darüber nach, den Basisnamen /dev/sdb zu aktualisieren./device/timeout
Der Standardwert ist beispielsweise 180
und wir denken daran, den neuen Wert wie folgt zu setzen:
echo 3600 > /sys/block/`basename /dev/sda`/device/timeout
Wir möchten wissen, ob wir mit der obigen Lösung auf dem richtigen Weg sind.