Server Disk 100% ເຕັມ (0 Bytes ຟຣີ): ກູ້ຄືນຖານຂໍ້ມູນທີ່ຂັດຂ້ອງເມື່ອ rm ແລະ apt ລົ້ມເຫລວສໍາລັບການຂາດ Inodes / Space¶

ການຄົ້ນພົບວ່າເຄື່ອງແມ່ຂ່າຍຂອງ Linux ການຜະລິດໄດ້ຕີ 100% ການ​ນໍາ​ໃຊ້​ແຜ່ນ (0 bytes free) ຫຼື 100% ການ​ນໍາ​ໃຊ້ inode (df -i) ໃນຂະນະທີ່ແລ່ນຖານຂໍ້ມູນ PostgreSQL, MySQL/InnoDB, MariaDB, ຫຼື SQLite ທີ່ໃຊ້ວຽກແມ່ນໜຶ່ງໃນໂຫມດຄວາມລົ້ມເຫຼວທີ່ອັນຕະລາຍທີ່ສຸດໃນການບໍລິຫານລະບົບ. ຢູ່ທີ່ສູນ bytes ຫຼືສູນ inodes ຟຣີ, ວິກິດການ cascades ຢ່າງໄວວາ: kernel ລະບົບປະຕິບັດການບໍ່ສາມາດສ້າງ sockets ໂດເມນ Unix ອີກຕໍ່ໄປ. /tmp ຫຼື /var/run, bash ລົ້ມເຫລວໃນ tab-complete ເນື່ອງຈາກວ່າມັນບໍ່ສາມາດຂຽນທໍ່ shell ຊົ່ວຄາວ, apt ຫຼື dnf ບໍ່​ສາ​ມາດ​ແລ່ນ​ເພື່ອ​ທໍາ​ຄວາມ​ສະ​ອາດ​ຫຸ້ມ​ຫໍ່​ເນື່ອງ​ຈາກ​ວ່າ​ຜູ້​ຈັດ​ການ​ຊຸດ​ຕ້ອງ​ການ​ໄຟລ​໌​ລັອກ​ຊົ່ວ​ຄາວ​, ແລະ​ເຄື່ອງ​ຈັກ​ຖານ​ຂໍ້​ມູນ​ຂອງ​ທ່ານ​ຂັດ​ໃນ​ກາງ​ຂອງ​ບັນ​ທຶກ​ການ​ຂຽນ​ລ່ວງ​ຫນ້າ (WAL) ຈຸດກວດກາຫຼືປະຕິເສດທີ່ຈະປິດຢ່າງສະອາດເນື່ອງຈາກວ່າມັນບໍ່ສາມາດຈັດສັນ 4 ກິໂລໄບດຽວ (0.004 megabyte) block ສໍາລັບຂອງຕົນ. .pid ຫຼືລັອກໄຟລ໌. ຮ້າຍແຮງໄປກວ່ານັ້ນ, ຜູ້ບໍລິຫານທີ່ຕົກໃຈມັກຈະແລ່ນ rm -rf /var/log/*.log ໃນໄຟລ໌ບັນທຶກຫຼາຍ gigabyte ແລະເບິ່ງໃນ horror ເປັນ df -h ຍັງລາຍງານ 100% Use% (0 Avail), ຫຼືພວກເຂົາລຶບຢ່າງຕາຍ pg_wal (pg_xlog) ຫຼື ib_logfile0 ພື້ນທີ່ຫວ່າງ, ທໍາລາຍຖານຂໍ້ມູນຢ່າງຖາວອນນອກເຫນືອການຟື້ນຕົວຂອງທຸລະກໍາ. ຖ້າທ່ານໄດ້ລຶບໄຟລ໌ຖານຂໍ້ມູນທີ່ສໍາຄັນໂດຍບັງເອີນໃນລະຫວ່າງການພະຍາຍາມທໍາຄວາມສະອາດ, ໃຫ້ຢຸດທັນທີແລະປ່ຽນເປັນ ອຸບັດເຫດ rm -rf ຫຼື Shift-Delete remount ແບບອ່ານເທົ່ານັ້ນແລະການແກະສະຫຼັກ inode; ຖ້າຮາດແວບ່ອນເກັບຂໍ້ມູນພື້ນຖານຂອງທ່ານຖິ້ມຄວາມຜິດພາດ I/O ຫຼືໄດ້ລັອກຕົວເອງບໍ່ໃຫ້ຂຽນ, ໃຫ້ປຶກສາ ໂໝດອ່ານເທົ່ານັ້ນແບບກະທັນຫັນ SSD ແລະ NVMe ແລະ TRIM ປິດໃຊ້ງານການກູ້ຂໍ້ມູນ ຫຼື ເສຍຫາຍ Word, Excel, PDF, ແລະການຟື້ນຟູໄຟລ໌ຖານຂໍ້ມູນ. ຖ້າ​ໄຟ​ໄໝ້​ນີ້​ສົ່ງ​ຜົນ​ກະທົບ​ຕໍ່​ລະບົບ​ຄວາມ​ປອດ​ໄພ​ຊີວິດ​ຂອງ​ໂຮງ​ໝໍ, ການ​ສົ່ງ​ໜ່ວຍ​ງານ​ສຸກ​ເສີນ, ຫຼື​ສາທາ​ລະນະ​ສຸກ​ທີ່​ສຳຄັນ, ໃຫ້​ໂທຫາ​ເບີ​ສຸກ​ເສີນ​ທ້ອງ​ຖິ່ນ​ຂອງ​ເຈົ້າ (911 ໃນສະຫະລັດແລະການາດາ, 112 ໃນ​ທົ່ວ​ສະ​ຫະ​ພາບ​ເອີ​ຣົບ​, 999 ໃນສະຫະລາດຊະອານາຈັກ) ຫຼືປຶກສາກັບໄດເລກະທໍລີທົ່ວໂລກຂອງພວກເຮົາ ຕົວເລກສຸກເສີນ.

ເຮັດອັນນີ້ດຽວນີ້¶

1. ** ຢ່າ​ລົບ​ pg_wal/, pg_xlog/, pg_multixact/, ib_logfile*, undo_*, ຫຼື -wal / -shm ໄຟລ໌ເພື່ອສ້າງພື້ນທີ່ **: ການລຶບບັນທຶກການຂຽນລ່ວງໜ້າ ຫຼື InnoDB redo/undo ໄຟລ໌ບັນທຶກໃນຂະນະທີ່ຖານຂໍ້ມູນຖືກຂັດຂ້ອງຫຼືບໍ່ມີຈຸດກວດກາຈະທໍາລາຍບັນທຶກດຽວຂອງຫນ້າທີ່ບໍ່ໄດ້ຕົກລົງແລະຢູ່ໃນການບິນ. ຖານຂໍ້ມູນທີ່ມີແຜ່ນເຕັມແມ່ນສາມາດກູ້ຄືນໄດ້ 100 ເປີເຊັນເມື່ອພື້ນທີ່ຖືກປົດປ່ອຍ; ຖານຂໍ້ມູນທີ່ໄຟລ໌ WAL ຖືກລຶບດ້ວຍຕົນເອງ rm ຈະທົນທຸກທໍລະມານ B-tree irreversible ແລະການສໍ້ລາດບັງຫຼວງ heap.
2. ** ກວດ​ສອບ​ໃນ 5 ວິ​ນາ​ທີ​ບໍ່​ວ່າ​ທ່ານ​ຈະ​ອອກ​ຈາກ​ການ​ຕັນ​ແຜ່ນ (df -h), ອອກຈາກ inodes ລະບົບໄຟລ໌ (df -i), ຫຼືຖືໄຟລ໌ທີ່ບໍ່ໄດ້ເຊື່ອມຕໍ່ເປີດ (lsof +L1)**:
3. ແລ່ນ df -h ການກວດສອບຄວາມອາດສາມາດຂອງຕັນແລະ df -i ເພື່ອກວດສອບຄວາມສາມາດຂອງ inode. ເຊີບເວີທີ່ມີພື້ນທີ່ດິສກ໌ຟຣີ 50 gigabytes (53.6 ຕື້ໄບຕ໌) ຍັງຈະຖິ້ມຢູ່ No space left on device (ENOSPC) ຖ້າ df -i ການສະແດງ IUse% = 100% (ໂດຍປົກກະຕິແມ່ນເກີດມາຈາກຫຼາຍລ້ານເຊດຊັນ, ແຄດ, ຫຼືໄຟລ໌ mail spool).
4. ຖ້າ df -h ການສະແດງ 100% ໃຊ້ (0 Avail) ເຖິງ​ແມ່ນ​ວ່າ​ຫຼັງ​ຈາກ​ທີ່​ທ່ານ​ໄດ້​ແລ່ນ​ rm ໃນໄຟລ໌ບັນທຶກຂະຫນາດໃຫຍ່, ດໍາເນີນການ sudo lsof +L1. ໄຟລ​໌​ໃດ​ຫນຶ່ງ​ທີ່​ຖືກ​ລົບ​ກັບ​ rm ໃນຂະນະທີ່ nginx, rsyslog, docker, postgres, ຫຼື mysqld ຍັງຖືຕົວອະທິບາຍໄຟລ໌ເປີດສືບຕໍ່ໃຊ້ 100 ເປີເຊັນຂອງຕັນດິສກ໌ຂອງມັນຈົນກວ່າຂະບວນການຈະເລີ່ມໃໝ່ ຫຼືທ່ານຕັດຕົວອະທິບາຍໂດຍກົງ.
5. ພື້ນທີ່ຫວ່າງ gigabytes ໃນ 1 ວິນາທີ ໂດຍບໍ່ມີການ restart daemons ໂດຍການຕັດໄຟລ໌ທີ່ເປີດຢູ່ໃນບ່ອນ (: > /path/to/logfile ຫຼື : > /proc/<pid>/fd/<n>):
6. ແທນ rm /var/log/syslog (ຊຶ່ງເຮັດໃຫ້ບລັອກຖືກລັອກໂດຍຜູ້ຕັດໄມ້ທີ່ແລ່ນຢູ່), ສູນໄຟລ໌ຢູ່ໃນສະຖານທີ່ໂດຍໃຊ້ shell null redirect: sudo sh -c ': > /var/log/syslog' ຫຼື sudo truncate -s 0 /var/log/syslog.
7. ຖ້າເຈົ້າແລ່ນແລ້ວ rm ໃນໄຟລ໌ບັນທຶກຂະຫນາດໃຫຍ່ແລະ df -h ບໍ່ໄດ້ຫຼຸດລົງ, ຊອກຫາ ID ຂະບວນການຂອງມັນ (PID) ແລະ​ຕົວ​ອະ​ທິ​ບາຍ​ໄຟລ​໌ (FD) ໃນ sudo lsof +L1 ແລະຕັດມັນກົງຜ່ານ kernel procfs interface: sudo sh -c ': > /proc/<PID>/fd/<FD>'. Space ຈະກັບຄືນສູ່ df -h ທັນທີ.
8. ** ເປີດ​ການ​ປົດ​ລັອກ​ຫ້ອງ​ຫາຍ​ໃຈ​ສຸກ​ເສີນ​ທັນ​ທີ​ທັນ​ໃດ​ ext4 / ext3 ໂດຍ​ການ​ຫຼຸດ​ຜ່ອນ​ອັດ​ຕາ​ສ່ວນ block ຮາກ​ທີ່​ຖືກ​ຈອງ​ໄວ້ (tune2fs -m 1)**: ໂດຍຄ່າເລີ່ມຕົ້ນ, ext4 ສະຫງວນ 5 ເປີເຊັນຂອງການແບ່ງປັນທັງໝົດ (25 gigabytes ສຸດ a 500 gigabyte ແຜ່ນ) ສະເພາະສໍາລັບ UID 0 (root), ຊຶ່ງຫມາຍຄວາມວ່າການບໍລິການທີ່ບໍ່ແມ່ນຮາກເຊັ່ນ postgres (UID 109), mysql, ແລະ www-data ຕີ No space left on device ການນຳໃຊ້ 95 ເປີເຊັນ. ຮຽກຄືນ 80 ເປີເຊັນຂອງສະຫງວນໄວ້ທາງອອນລາຍໃນ 1 ວິນາທີ ໂດຍບໍ່ມີການຢຸດເຮັດວຽກໂດຍການແລ່ນ sudo tune2fs -m 1 /dev/sda1 (ຫຼືອຸປະກອນຕັນຮາກຂອງທ່ານຈາກ findmnt /).
9. **ສູນຍາກາດ systemd-journald ບັນ​ທຶກ​ຖານ​ສອງ​ແລະ​ຖານ​ຄວາມ​ຈໍາ​ຊຸດ​ອາ​ຍຸ​ຢ່າງ​ປອດ​ໄພ **​: ດໍາ​ເນີນ​ການ​ sudo journalctl --vacuum-size=50M (ຊຶ່ງຢ່າງປອດໄພ rotates ແລະ pururges binary /var/log/journal ຮວບຮວມລົງເຖິງ 50 megabytes) ແລະ sudo apt-get clean (ຫຼື sudo dnf clean all), ເຊິ່ງລຶບການດາວໂຫຼດ .deb / .rpm ຮວບຮວມຢູ່ໃນ /var/cache/apt/archives/ ໂດຍບໍ່ຈໍາເປັນຕ້ອງຂຽນໃສ່ຖານຂໍ້ມູນ dpkg.
10. **ເມື່ອຢ່າງໜ້ອຍ 1 gigabyte ຫາ 5 gigabytes (1.07 ຕື້ຫາ 5.36 ຕື້ bytes) ຂອງພື້ນທີ່ຫວ່າງແມ່ນບໍ່ເສຍຄ່າ, ເອົາຖານຂໍ້ມູນຂຶ້ນໃນໂຫມດຜູ້ໃຊ້ດຽວຫຼືການຟື້ນຕົວເພື່ອເຮັດສໍາເລັດຈຸດກວດກາ WAL ຂອງມັນກ່ອນທີ່ຈະອະນຸຍາດໃຫ້ການເຂົ້າຊົມລູກຄ້າ **: ໃຫ້ PostgreSQL, MySQL / InnoDB, ຫຼື SQLite replay ບັນທຶກການຂຽນກ່ອນຫນ້າ (WAL), ລ້າງໜ້າທີ່ເປື້ອນໄປໃສ່ໄຟລ໌ຂໍ້ມູນຫຼັກ, ແລະເອົາສ່ວນ WAL ຂອງມັນຄືນມາໃໝ່ໃຫ້ສະອາດກ່ອນທີ່ຈະເປີດໄຟວໍ ຫຼືເຊີບເວີຂອງແອັບພລິເຄຊັນຂອງທ່ານຄືນໃໝ່.

ຕົ້ນໄມ້ການຕັດສິນໃຈ: ເຊີບເວີສູນພື້ນທີ່ ແລະ triage ຖານຂໍ້ມູນ crashed¶

ໃຊ້ຕົ້ນໄມ້ການຕັດສິນໃຈນີ້ເພື່ອກໍານົດວ່າເປັນຫຍັງລະບົບປະຕິບັດງານກໍາລັງລາຍງານ ENOSPC (No space left on device) ແລະເລືອກເສັ້ນທາງການຟື້ນຕົວທີ່ບໍ່ທໍາລາຍທີ່ແນ່ນອນ:

flowchart TD
    Start["ການຖິ້ມເຊີບເວີ ຫຼືຖານຂໍ້ມູນ: ບໍ່ມີພື້ນທີ່ເຫຼືອຢູ່ໃນອຸປະກອນ (ENOSPC)"] --> CheckDF["ແລ່ນ: df -h AND df -i"]

    CheckDF --> DiagType{"df ລາຍງານຫຍັງ?"}

    DiagType -->|"df -h ສະແດງ 100% ການນໍາໃຊ້ (0 Avail) ແລະ df -i < 95%"| BlockFull["Block Exhaustion: ກວດເບິ່ງວ່າ du -shx / Matches df -h"]
    DiagType -->|"df -h ສະແດງ GBs ຟຣີ ແຕ່ df -i ສະແດງ 100% IUse"| InodeFull["Inode Exhaustion: ລ້ານໄຟລ໌ຂະໜາດນ້ອຍ 0-to-4KB"]
    DiagType -->|"ທັງ df -h ແລະ df -i ສະແດງ < 90% ໃຊ້ແລ້ວ"| RamOrQuota["ຂີດຈຳກັດທີ່ເຊື່ອງໄວ້: ກວດເບິ່ງ df -h /tmp (tmpfs RAM ເຕັມ), Docker Overlay2, ຫຼື XFS/ext4 Disk Quotas"]

    BlockFull --> GhostCheck{"ທ່ານໄດ້ດໍາເນີນການ rm ໃນໄຟລ໌ໃຫຍ່ແລ້ວໂດຍບໍ່ມີການ df ຫຼຸດລົງບໍ?"}
    GhostCheck -->|"ແມ່ນແລ້ວ: du ແມ່ນນ້ອຍກວ່າ df ຫຼາຍ"| UnlinkedFD["ແລ່ນ: sudo lsof +L1 -> ຕັດໄຟລ໌ Ghost ຜ່ານ :> /proc/PID/fd/FD"]
    GhostCheck -->|"ບໍ່: ໄຟລ໌ທີ່ແທ້ຈິງແມ່ນການຕື່ມຂໍ້ມູນໃສ່ແຜ່ນ"| EmergencySpace["ສ້າງຫ້ອງຫາຍໃຈທັນທີ (1 GB ຫາ 5 GB)"]

    EmergencySpace --> Ext4Check{"ລະບົບໄຟລ໌ ext4 / ext3 ແມ່ນບໍ?"}
    Ext4Check -->|"ແມ່ນແລ້ວ"| Tune2fs["ແລ່ນ: sudo tune2fs -m 1 /dev/root_dev (ປົດປ່ອຍທັນທີ 4% ຂອງ Disk ສໍາລັບຜູ້ໃຊ້ທີ່ບໍ່ແມ່ນ Root DB)"]
    Ext4Check -->|"ບໍ່ (XFS / Btrfs / ZFS)"| TruncLogs["ຕັດບັນທຶກໃນສະຖານທີ່ (: > /var/log/syslog) ແລະແລ່ນ journalctl --vacuum-size=50M"]

    InodeFull --> InodeClean["ຊອກຫາໄດເລກະທໍລີທີ່ມີລ້ານໄຟລ໌ໂດຍໃຊ້ find / -xdev -printf '%h\n' | ຄັດ | uniq -c | sort -k 1 -r | head -20 -> ລຶບດ້ວຍ find -delete"]

    UnlinkedFD --> DBRecover["ດໍາເນີນການກັບ Database Engine WAL & B-Tree Recovery"]
    Tune2fs --> DBRecover
    TruncLogs --> DBRecover
    InodeClean --> DBRecover
    RamOrQuota --> DBRecover

    DBRecover --> WhichDB{"ເຄື່ອງຈັກຖານຂໍ້ມູນໃດຂັດຂ້ອງ?"}
    WhichDB -->|"PostgreSQL"| PGFlow["ຮັກສາ pg_wal Intact -> ເລີ່ມ Postgres ເພື່ອ Replay WAL -> ດໍາເນີນການ CHECKPOINT; -> Drop Stale Replication Slots"]
    WhichDB -->|"MySQL / MariaDB (InnoDB)"| MyFlow["Keep ib_logfile* Intact -> Start mysqld -> Purge Binary Logs via PURGE BINARY LOGS -> Optimize Tables"]
    WhichDB -->|"SQLite3"| SqFlow["Back Up .db + .db-wal + .db-shm -> ແລ່ນ PRAGMA wal_checkpoint(TRUNCATE) ຫຼື sqlite3 break.db '.recover'"]

ໄລຍະທີ 1: ເປັນຫຍັງຄຳສັ່ງມາດຕະຖານ (rm, apt, tab-completion) ລົ້ມເຫລວຢູ່ທີ່ 0 bytes ຟຣີ¶

ເມື່ອພາທິຊັນ Linux ໂຈມຕີ 100 ເປີເຊັນຫຼື inode ຫມົດ, ຄໍາສັ່ງການແກ້ໄຂມາດຕະຖານລົ້ມເຫລວໃນວິທີທີ່ບໍ່ຄາດຄິດ: - ** ກົດ​ Tab ໃນ bash ຖິ້ມ cannot create temp file for here-document: No space left on device**: ທັນ​ສະ​ໄຫມ​ bash-completion scripts ສ້າງໄຟລ໌ຊົ່ວຄາວໃນ /tmp. ຖ້າ /tmp ອາໃສຢູ່ໃນຮາກ / partition ແທນ a tmpfs ການຕິດຕັ້ງ RAM, ການສໍາເລັດຮູບແກະແລະ heredocs (<<EOF) ລົ້ມເຫລວ. ແກ້ໄຂນີ້ທັນທີໂດຍການຊີ້ TMPDIR ກັບ RAM ຫນ່ວຍຄວາມຈໍາທີ່ໃຊ້ຮ່ວມກັນ:

export TMPDIR=/dev/shm

sudo find /var/lib/php/sessions -type f -delete

5 ສາເຫດທີ່ແຕກຕ່າງກັນຂອງ No space left on device (ENOSPC)¶

ກ່ອນທີ່ຈະສໍາຜັດກັບໄຟລ໌ຖານຂໍ້ມູນໃດໆ, ໃຫ້ສົມທຽບຫ້າສະຖານະການເຫຼົ່ານີ້ເພື່ອຢືນຢັນວ່າຊັບພະຍາກອນອັນໃດທີ່ຫມົດໄປ:

ໄລຍະທີ 2: ກູ້ພື້ນທີ່ດິສກ໌ຄືນມາຢ່າງປອດໄພພາຍໃນ 60 ວິນາທີ¶

ປະຕິບັດຕາມຂັ້ນຕອນທີ່ແນ່ນອນເຫຼົ່ານີ້ເພື່ອເອົາພື້ນທີ່ຫວ່າງລະຫວ່າງ 500 megabytes ແລະ 50 gigabyte (0.53 ຕື້ຫາ 53.6 ຕື້ໄບຕ໌) ຂອງພື້ນທີ່ໂດຍບໍ່ມີການທໍາລາຍຂະບວນການເຄື່ອນໄຫວ:

ຂັ້ນ​ຕອນ​ທີ 1​: ຕັດ​ເປີດ​ລຶບ​ໄຟລ​໌ ("ຜີ​"​) ຜ່ານ​ /proc/<pid>/fd/¶

ຖ້າທ່ານຫຼືສະຄິບ logrotate ອັດຕະໂນມັດໄດ້ລຶບໄຟລ໌ຂະຫນາດໃຫຍ່ແລ້ວແຕ່ພື້ນທີ່ດິດບໍ່ໄດ້ຖືກສົ່ງຄືນ, ໃຫ້ກວດເບິ່ງຕາຕະລາງໄຟລ໌ເປີດທີ່ບໍ່ໄດ້ເຊື່ອມຕໍ່ຂອງ kernel:

sudo lsof +L1

COMMAND    PID     USER   FD   TYPE DEVICE    SIZE/OFF NLINK    NODE NAME
mysqld    1942    mysql    6u   REG  259,1 34896609280     0  918273 /tmp/ibXz91aB (deleted)
rsyslogd   612   syslog    7w   REG  259,1 18253611008     0  131092 /var/log/syslog.1 (deleted)

sudo sh -c ': > /proc/612/fd/7'

ຂັ້ນຕອນທີ 2: ຖອນຄືນ ext4 ບລັອກສະຫງວນອອນໄລນ໌ກັບ tune2fs¶

ສຸດໃດ ext4 ຫຼື ext3 ລະບົບໄຟລ໌, ກວດເບິ່ງຈໍານວນບລັອກທີ່ສະຫງວນໄວ້ໃນປະຈຸບັນ:

df -h /
sudo tune2fs -l /dev/nvme0n1p1 | grep -i "reserved block"

sudo tune2fs -m 1 /dev/nvme0n1p1

ຂັ້ນ​ຕອນ​ທີ 3​: ຕັດ​ບັນ​ທຶກ​ຂໍ້​ຄວາມ​ທີ່​ມີ​ຢູ່​ໃນ​ສະ​ຖານ​ທີ່​ແລະ​ສູນ​ຍາ​ກາດ​ journald¶

ຊອກຫາໄຟລ໌ທີ່ໃຫຍ່ທີ່ສຸດໃນລະບົບໄຟລ໌ຮາກ (ຢູ່ໃນລະບົບໄຟລ໌ດຽວກັນກັບ -xdev ດັ່ງນັ້ນທ່ານບໍ່ເສຍເວລາສະແກນ /proc ຫຼື mounts ພາຍນອກ):

sudo find / -xdev -type f -size +100M -exec ls -lh {} + 2>/dev/null | sort -k 5 -hr | head -n 25

sudo truncate -s 0 /var/log/nginx/error.log
sudo truncate -s 0 /var/lib/docker/containers/*/*-json.log

sudo journalctl --vacuum-size=50M

ໄລຍະທີ 3: ການຟື້ນຕົວ PostgreSQL ຫຼັງຈາກອຸປະຕິເຫດເຕັມແຜ່ນ 100% (pg_wal ບວມ)¶

ເມື່ອເຊີບເວີ PostgreSQL ໝົດພື້ນທີ່ດິດ, ມັນຈະບັນທຶກ PANIC: could not write to file "pg_wal/xlogtemp.1234": No space left on device, ທັນທີ aborts ຂະບວນການເດັກ postmaster, ແລະປະຕິເສດທີ່ຈະເລີ່ມຕົ້ນ.

ເປັນຫຍັງ pg_wal (pg_xlog ໃນ PostgreSQL 9.6 ແລະເກົ່າກວ່າ) ຕື່ມຂໍ້ມູນໃສ່ແຜ່ນທັງຫມົດ¶

ໃນການເຮັດວຽກປົກກະຕິ, PostgreSQL ຂຽນທຸກໆການປ່ຽນແປງໄປຫາໄຟລ໌ 16 megabyte (16.7 ລ້ານ byte) ພາຍໃນ. $PGDATA/pg_wal/ ແລະ recycles ໃຫ້ເຂົາເຈົ້າຫຼັງຈາກແຕ່ລະຄົນ CHECKPOINT ເມື່ອເກີນ max_wal_size. ຢ່າງໃດກໍຕາມ, PostgreSQL ** ຖືກຫ້າມບໍ່ໃຫ້ລຶບຫຼືລີໄຊເຄີນເກົ່າ pg_wal ໄຟລ​໌ ** ພາຍ​ໃຕ້​ສາມ​ເງື່ອນ​ໄຂ​: 1. ສະລັອດຕິງການຈຳລອງທາງກາຍຍະພາບ/ຕາມເຫດຜົນ: ເຊີບເວີແບບຈຳລອງ (standby), ຕົວເຊື່ອມຕໍ່ Debezium/Kafka, ຫຼື pg_receivewal ລູກ​ຄ້າ​ໄດ້​ຕັດ​ການ​ເຊື່ອມ​ຕໍ່​ມື້​ກ່ອນ​ຫນ້າ​ນີ້​, ແຕ່​ຊ່ອງ​ການ​ຈໍາ​ລອງ​ຂອງ​ຕົນ (pg_replication_slots) ຍັງ active = false ໃນຂັ້ນຕົ້ນ, ແນະນໍາໃຫ້ PostgreSQL ຮັກສາທຸກໆ WAL segment ທີ່ສ້າງຂຶ້ນນັບຕັ້ງແຕ່ການຕັດການເຊື່ອມຕໍ່. 2. ** ຄວາມ​ລົ້ມ​ເຫຼວ​ archive_command**: archive_mode = on ຖືກເປີດໃຊ້ໃນ postgresql.conf, ແລະສະຄິບສໍາຮອງ (pgBackRest, WAL-G, Barman, ຫຼື aws s3 cp) ກໍາລັງສົ່ງຄືນລະຫັດອອກທີ່ບໍ່ແມ່ນສູນ (ຕົວຢ່າງ: ລະຫັດ S3 ທີ່ໝົດອາຍຸ ຫຼືແມ່ຂ່າຍສຳຮອງທີ່ບໍ່ສາມາດເຂົ້າຫາໄດ້). PostgreSQL ຮັກສາທຸກໆສ່ວນ WAL ທີ່ບໍ່ໄດ້ເກັບໄວ້ໃນ pg_wal/ ຈົນກ່ວາ archive_command ກັບຄືນ 0. 3. ການປິດກັ້ນເຕັມແຜ່ນ: pg_wal ຂະຫຍາຍຕົວຈົນກ່ວາ 0 bytes ຍັງຄົງຢູ່ /var/lib/postgresql, ແລະໃນປັດຈຸບັນ PostgreSQL ບໍ່ສາມາດແມ້ແຕ່ເລີ່ມຕົ້ນທີ່ຈະລຸດຊ່ອງ replication ຫຼືສໍາເລັດການກວດກາເນື່ອງຈາກວ່າການເລີ່ມຕົ້ນການຟື້ນຕົວຕົວມັນເອງຕ້ອງການຫຼາຍ megabytes ຂອງພື້ນທີ່ດິດຟຣີເພື່ອຂຽນໄຟລ໌ລັດຊົ່ວຄາວ.

PostgreSQL ການ​ກູ້​ໄພ​ສູນ​ອະ​ວະ​ກາດ​ຂັ້ນ​ຕອນ​ທີ (ສູນ​ເສຍ​ຂໍ້​ມູນ​)¶

1. ສ້າງ 1 gigabyte ຫາ 5 gigabyte (1.07 ຕື້ຫາ 5.36 ຕື້ bytes) ຂອງພື້ນທີ່ຊົ່ວຄາວພາຍນອກ pg_wal/:
2. ການນໍາໃຊ້ຄັ້ງທໍາອິດ sudo tune2fs -m 0 /dev/<partition> ແລະຕັດບັນທຶກຂໍ້ຄວາມລະບົບ/PostgreSQL (sudo truncate -s 0 /var/lib/postgresql/*/main/log/*.log ຫຼື /var/log/postgresql/*.log).
3. ** ຈະ​ເປັນ​ແນວ​ໃດ​ຖ້າ​ຫາກ​ວ່າ​ຖານ​ຂໍ້​ມູນ​ມີ​ການ​ແບ່ງ​ປັນ​ທີ່​ອຸ​ທິດ​ຕົນ​ຂອງ​ຕົນ​ໂດຍ​ມີ​ສູນ​ຂໍ້​ຄວາມ​ບັນ​ທຶກ​ແລະ XFS (ສະ​ນັ້ນ​ tune2fs ບໍ່ສາມາດໃຊ້ໄດ້)?** ຍ້າຍ 10 ຫາ 20 ຂອງ ເກົ່າທີ່ສຸດ .ready ຫຼືໄຟລ໌ທີ່ບໍ່ເຄື່ອນໄຫວອອກຈາກໄດເລກະທໍລີທີ່ບໍ່ແມ່ນ WAL, ຫຼືຍ້າຍໄຟລ໌ pg_wal ໄດເລກະທໍລີຊົ່ວຄາວໄປຫາພາທິຊັນອື່ນທີ່ມີພື້ນທີ່ຫວ່າງໂດຍໃຊ້ການເຊື່ອມຕໍ່ສັນຍາລັກ:

   # ONLY while PostgreSQL is completely stopped (verify with: ps aux | grep postgres)
   sudo mkdir -p /mnt/extra_space/pg_wal_rescue
   sudo chown -R postgres:postgres /mnt/extra_space/pg_wal_rescue
   sudo mv /var/lib/postgresql/16/main/pg_wal/* /mnt/extra_space/pg_wal_rescue/
   sudo rmdir /var/lib/postgresql/16/main/pg_wal
   sudo ln -s /mnt/extra_space/pg_wal_rescue /var/lib/postgresql/16/main/pg_wal
   sudo chown -h postgres:postgres /var/lib/postgresql/16/main/pg_wal
   

4. ** ຖ້າ archive_command ລົ້ມເຫລວ ແລະຂັດຂວາງການລີໄຊເຄີນ WAL, ຂ້າມມັນເຂົ້າໄປຊົ່ວຄາວ postgresql.conf**: ຖ້າ​ຫາກ​ວ່າ​ເປົ້າ​ຫມາຍ S3 / ການ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​ຂອງ​ທ່ານ​ແມ່ນ​ຫຼຸດ​ລົງ​ແລະ​ pg_wal/archive_status/ ບັນຈຸພັນ .ready ໄຟລ​໌​, ແກ້​ໄຂ​ postgresql.conf (archive_command = '/bin/true') ** ເປັນ​ພຽງ​ແຕ່​ເປັນ​ມາດ​ຕະ​ການ​ສຸກ​ເສີນ​ທີ່​ສຸດ​ທີ່​ພັກ​ເພື່ອ​ຢຸດ​ແຜ່ນ​ຈາກ​ການ​ເສຍ​ຊີ​ວິດ **​, ໂດຍ​ຮູ້​ວ່າ​ທ່ານ​ຈະ​ຕ້ອງ​ໃຊ້​ເວ​ລາ​ສົດ​. pg_basebackup ທັນທີຫຼັງຈາກການຟື້ນຕົວເນື່ອງຈາກວ່າລະບົບຕ່ອງໂສ້ການເກັບຮັກສາ WAL ຈະມີຊ່ອງຫວ່າງ.
5. ** ເລີ່ມ​ຕົ້ນ PostgreSQL ແລະ​ກວດ​ກາ​ໃນ​ທັນ​ທີ​ສະ​ລັອດ​ຕິງ replications **​: ເລີ່ມ PostgreSQL (sudo systemctl start postgresql) ແລະ​ເຊື່ອມ​ຕໍ່​ຜ່ານ​ sudo -u postgres psql:

   SELECT slot_name, plugin, slot_type, active,
          pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal
   FROM pg_replication_slots;
   

6. ** ວາງ​ຊ່ອງ​ການ​ທົດ​ລອງ​ທີ່​ຕາຍ​ແລ້ວ/ບໍ່​ມີ​ການ​ເຄື່ອນ​ໄຫວ​ທີ່​ເກັບ​ກຳ​ລັງ gigabytes ຂອງ WAL**: ຖ້າເຈົ້າເຫັນຊ່ອງທີ່ບໍ່ເຄື່ອນໄຫວ (active = f) ຖື 80 gigabytes ຂອງ retained_wal:

   SELECT pg_drop_replication_slot('name_of_dead_slot');
   

7. ** ບັງ​ຄັບ​ທັນ​ທີ​ CHECKPOINT ເພື່ອ recycle bloated ໄດ້ pg_wal ພາກສ່ວນ **:

   CHECKPOINT;
   

   ປັດຈຸບັນ CHECKPOINT; ສໍາ​ເລັດ​ຮູບ​ຫຼັງ​ຈາກ​ການ​ຫຼຸດ​ລົງ​ຊ່ອງ​ຕາຍ​, PostgreSQL ຈະ​ອັດ​ຕະ​ໂນ​ມັດ​ຖອນ​ການ​ເຊື່ອມ​ຕໍ່​ຫຼື recycle gigabytes ຂອງ​ໄຟລ​໌ 16 megabyte ເກົ່າ​ໃນ​ພາກ​ສ່ວນ pg_wal/, ກັບຄືນການນໍາໃຊ້ແຜ່ນຂອງທ່ານກັບປົກກະຕິ.
8. ** ປ້ອງ​ກັນ​ບໍ່​ໃຫ້​ການ​ເສຍ​ຊີ​ວິດ​ສະ​ລັອດ​ຕິ​ສ​ການ​ທົດ​ລອງ​ໃນ​ອະ​ນາ​ຄົດ **​: ກໍາ​ນົດ​ max_slot_wal_keep_size ໃນ postgresql.conf (ມີຢູ່ໃນ PostgreSQL 13+) ໄປຫາຫມວກທີ່ປອດໄພ (ເຊັ່ນ: max_slot_wal_keep_size = 20GB) ດັ່ງນັ້ນ PostgreSQL invalidates ຊ່ອງ replica ຂອງຕາຍແທນທີ່ຈະ crashing ຖານຂໍ້ມູນຕົ້ນຕໍຢູ່ທີ່ 0 bytes ຟຣີ.

ໄລຍະ 4: ການຟື້ນຕົວ MySQL / MariaDB (InnoDB) ທີ່ 0 bytes ຟຣີ¶

ເມື່ອ MySQL ຫຼື MariaDB ຕີ 100% ການ​ນໍາ​ໃຊ້​ແຜ່ນ (/var/lib/mysql), InnoDB stalls ທັງຫມົດຂຽນຫຼື crash ກັບ [ERROR] [MY-012640] [InnoDB] Error number 28 means 'No space left on device'.

ການກໍານົດສິ່ງທີ່ເຕັມໄປ /var/lib/mysql¶

ແລ່ນ sudo du -sh /var/lib/mysql/* | sort -hr | head -n 15 ເພື່ອເບິ່ງວ່າຜູ້ກະທຳຜິດທັງ 4 ຄົນນີ້ ບໍລິໂພກແຜ່ນໃດແດ່: 1. ** ບັນ​ທຶກ​ຖານ​ສອງ​ບໍ່​ມີ​ຂອບ​ເຂດ (binlog.000001, mysql-bin.000042): ໂດຍຄ່າເລີ່ມຕົ້ນໃນ MySQL 8.0+, ການບັນທຶກໄບນາຣີຖືກເປີດໃຊ້ດ້ວຍການຮັກສາໄວ້ 30 ມື້ (binlog_expire_logs_seconds = 2592000), ເຊິ່ງສາມາດສ້າງເຫດການແຖວຫຼາຍຮ້ອຍ gigabytes ໄດ້ຢ່າງງ່າຍດາຍໃນລະຫວ່າງການນໍາເຂົ້າຫຼາຍ. 2. ** ການ​ສອບ​ຖາມ runaway ຂຽນ​ຕາ​ຕະ​ລາງ​ຊົ່ວ​ຄາວ​ຂະ​ຫນາດ​ໃຫຍ່ (#sql* ຫຼື ibtmp1) : ໃຫຍ່ GROUP BY ຫຼື ORDER BY ຕື່ມການສອບຖາມ ibtmp1 ຫຼື /tmp/#sql_* ຈົນກ່ວາແຜ່ນມົນຕີ 0 bytes. 3. ** monolithic ibdata1 system tablespace bloat : ຖ້າ innodb_file_per_table ຖືກປິດໃຊ້ງານ ຫຼືການເຮັດທຸລະກໍາທີ່ຍາວນານໄດ້ຂັດຂວາງບັນຊີລາຍຊື່ປະຫວັດສາດ InnoDB (ຍົກເລີກການເຂົ້າສູ່ລະບົບພາຍໃນ ibdata1 ຫຼື undo_001) ຈາກ​ການ​ລົບ​ລ້າງ​. 4. ** ບັນ​ທຶກ​ການ​ສອບ​ຖາມ​ຊ້າ MySQL ຫຼື​ບັນ​ທຶກ​ຄວາມ​ຜິດ​ພາດ (/var/log/mysql/mysql-slow.log).

MySQL / MariaDB ເປັນການກູ້ຂໍ້ມູນແບບບໍ່ມີພື້ນທີ່ເທື່ອລະກ້າວ¶

1. ** ຢ່າ​ລົບ​ລ້າງ​ ibdata1, ib_logfile0, ib_logfile1, #innodb_redo/*, ຫຼື undo_001 ກັບ rm**: ການລຶບໃດໆຂອງໄຟລ໌ເຫຼົ່ານີ້ເຮັດໃຫ້ທຸກ .ibd ໄຟລ໌ຕາຕະລາງໃນຖານຂໍ້ມູນຂອງເຈົ້າບໍ່ສາມາດອ່ານໄດ້.
2. ພື້ນທີ່ເລີ່ມຕົ້ນເລີ່ມຕົ້ນຟຣີ (500 megabytes ຫາ 2 gigabyte):
3. ຕັດອອກ /var/log/mysql/error.log ແລະ mysql-slow.log ຜ່ານ sudo truncate -s 0 /var/log/mysql/*.log.
4. ສຸດ ext4, ແລ່ນ sudo tune2fs -m 1 /dev/<partition>.
5. ຖ້າ mysqld ປະຈຸບັນໄດ້ຢຸດເຊົາແລະ /var/lib/mysql/ibtmp1 (ພື້ນທີ່ຕາຕະລາງຊົ່ວຄາວທີ່ບໍ່ຖືກບີບອັດ) ແມ່ນໃຫຍ່ຫຼວງ, ibtmp1 ຖືກສ້າງຄືນໃຫມ່ໂດຍອັດຕະໂນມັດໃນເວລາເລີ່ມຕົ້ນ, ຫຼືທ່ານສາມາດຍ້າຍ ** ສອງຫຼືສາມ ** ບັນທຶກຄູ່ທີ່ເກົ່າແກ່ທີ່ສຸດ (binlog.000001, binlog.000002 - ບໍ່ເຄີຍເປັນ binlog ທີ່ມີການເຄື່ອນໄຫວສູງສຸດ) ກັບ /dev/shm ດັ່ງ​ນັ້ນ​ຊົ່ວ​ຄາວ mysqld ສາມາດ boot ໄດ້.
6. ເລີ່ມ MySQL ແລະລຶບບັນທຶກຖານສອງຢ່າງປອດໄພໂດຍໃຊ້ SQL (PURGE BINARY LOGS): ເປັນຫຍັງເຈົ້າຕ້ອງໃຊ້ SQL ແທນ rm /var/lib/mysql/binlog.*? ເນື່ອງຈາກວ່າ MySQL ຕິດຕາມທຸກຊື່ໄຟລ໌ບັນທຶກສອງໃນ binlog.index. ຖ້າທ່ານລຶບບັນທຶກຖານສອງດ້ວຍ rm ໂດຍບໍ່ມີການປັບປຸງ binlog.index, MySQL ຈະປະຕິເສດທີ່ຈະເລີ່ມຕົ້ນຫຼື replication ຈະແຕກ. ຄັ້ງດຽວ mysqld ເລີ່ມຕົ້ນ, ເຂົ້າສູ່ລະບົບ (sudo mysql) ແລະ​ດໍາ​ເນີນ​ການ​:

   SHOW BINARY LOGS;
   PURGE BINARY LOGS BEFORE NOW() - INTERVAL 1 DAY;
   

   (ຫຼືລຶບລ້າງທຸກຢ່າງຂຶ້ນກັບໄຟລ໌ບັນທຶກທີ່ເຄື່ອນໄຫວປະຈຸບັນທີ່ສະແດງຢູ່ລຸ່ມສຸດຂອງ SHOW BINARY LOGS; ການ​ນໍາ​ໃຊ້ PURGE BINARY LOGS TO 'binlog.000085';)
7. ** ຕັ້ງ​ຂະ​ຫນາດ​ຂອງ​ບັນ​ທຶກ​ຖານ​ສອງ​ຖາ​ວອນ​ແລະ​ຫລວງ​ການ​ເກັບ​ຮັກ​ສາ​ໄວ້​ໃນ​ /etc/mysql/mysql.conf.d/mysqld.cnf**:

   [mysqld]
   binlog_expire_logs_seconds = 259200   # Keep only 3 days (259,200 seconds)
   max_binlog_size = 256M
   innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:5G
   

   ຝາປິດ ibtmp1 ທີ່ max:5G ຮັບປະກັນວ່າ unindexed rogue JOIN ຫຼື ORDER BY ການສອບຖາມລົ້ມເຫລວກັບ a table is full ຄວາມຜິດພາດແທນທີ່ຈະຂະຫຍາຍ ibtmp1 ຈົນກ່ວາເຄື່ອງແມ່ຂ່າຍ Linux ທັງຫມົດເສຍຊີວິດຢູ່ທີ່ 0 bytes ຟຣີ.

ໄລຍະທີ 5: ກູ້ຄືນຖານຂໍ້ມູນ SQLite3 ທີ່ເສຍຫາຍ (database or disk is full / SQLITE_FULL / malformed)¶

ແອັບພລິເຄຊັນທີ່ຝັງໄວ້, Docker containers (Nextcloud, Vaultwarden, Home Assistant, Plex, Grafana, Gitea), ແລະການບໍລິການມືຖື / desktop ແມ່ນອີງໃສ່ SQLite3. ເມື່ອດິສກ໌ຕີ 0 ໄບຕ໌ຟຣີ ໃນຂະນະທີ່ SQLite ຢູ່ເຄິ່ງກາງຂອງບັນທຶກການກັບຄືນ ຫຼືບັນທຶກການຂຽນລ່ວງໜ້າ (-wal) ດ່ານກວດກາ, ທ່ານຈະພົບກັບຫນຶ່ງໃນສອງກໍລະນີສຸກເສີນ: 1. ** ຂະ​ຫນາດ​ໃຫຍ່​ .db-wal file bloat ** (ໄດ້ .db-wal ໄຟລ໌ໄດ້ເຕີບໂຕເຖິງ 10 gigabytes ໃນຂະນະທີ່ .db ໄຟລ໌ແມ່ນພຽງແຕ່ 200 megabytes, ເພາະວ່າຜູ້ອ່ານທີ່ໃຊ້ເວລາດົນນານໄດ້ປ້ອງກັນການກວດກາ WAL ແບບ passive, ແລະໃນປັດຈຸບັນ disk ແມ່ນເຕັມ 100 ເປີເຊັນ). 2. **RuntimeError: database disk image is malformed (SQLITE_CORRUPT) ** ເກີດ​ຈາກ​ຮາດ​ແວ​ແຕກ​ fsync(), ຕູ້ຄອນເທນເນີໄດ້ຂ້າ rollback ກາງຢູ່ທີ່ 0 bytes ຟຣີ, ຫຼືບາງຄົນທີ່ລຶບ -wal ຫຼື -journal ຍື່ນດ້ວຍມື.

ຂັ້ນ​ຕອນ​ທີ 1​: ຫຼຸດ​ລົງ bloated​ .db-wal ໄຟລ໌ແລະສູນຍາກາດ SQLite ເມື່ອພື້ນທີ່ດິດຢູ່ໃກ້ກັບສູນ¶

1. ຢຸດເຊົາການບັນຈຸຄໍາຮ້ອງສະຫມັກຫຼືບໍລິການທີ່ຖືຖານຂໍ້ມູນ SQLite ເປີດ (sudo systemctl stop app ຫຼື docker stop container_name).
2. ສຳເນົາ app.db, app.db-wal, ແລະ app.db-shm ກັບ partition ຫຼື drive ພາຍນອກທີ່ມີພື້ນທີ່ຫວ່າງຫຼາຍ (ຫຼື 2x ຂະຫນາດຂອງຟຣີ app.db ຢູ່ໃນແຜ່ນທ້ອງຖິ່ນກ່ອນ).
3. ເປີດຖານຂໍ້ມູນດ້ວຍ sqlite3 CLI ແລະບັງຄັບຈຸດກວດກາ WAL ທີ່ຖືກຕັດ, ເຊິ່ງພັບກອບທີ່ຫມັ້ນສັນຍາທັງຫມົດຈາກ app.db-wal ເຂົ້າໄປໃນ app.db ແລະຫົດຕົວລົງ app.db-wal ເຖິງ 0 bytes:

   sqlite3 /path/to/app.db "PRAGMA wal_checkpoint(TRUNCATE);"
   

4. ຢັ້ງຢືນ B-tree ແລະ freelist ຄວາມສົມບູນຂອງໂຄງສ້າງ:

   sqlite3 /path/to/app.db "PRAGMA integrity_check;"
   

   ຖ້າມັນພິມ ok, ຖານຂໍ້ມູນຂອງເຈົ້າມີສຸຂະພາບດີ 100 ເປີເຊັນ.
5. ** ວິ​ທີ​ການ​ VACUUM ຖານຂໍ້ມູນ SQLite ຂະໜາດໃຫຍ່ເມື່ອແຜ່ນທ້ອງຖິ່ນບໍ່ມີພື້ນທີ່ຫວ່າງພຽງພໍ**: ມາດຕະຖານ VACUUM; ຮຽກ​ຮ້ອງ​ໃຫ້​ສູງ​ເຖິງ 2x ຂະ​ຫນາດ​ຖານ​ຂໍ້​ມູນ ໃນ​ຊ່ອງ​ແຜ່ນ​ຟຣີ​ໃນ​ການ​ແບ່ງ​ປັນ​ດຽວ​ກັນ​ແລະ​ /var/tmp. ແທນທີ່ຈະ, ໃຊ້ VACUUM INTO (ແນະນໍາໃນ SQLite 3.27.0) ເພື່ອຂຽນສໍາເນົາທີ່ຫນາແຫນ້ນ, defragmented ສົດໆໂດຍກົງໃສ່ແຜ່ນທີ່ຕິດຕັ້ງແຍກຕ່າງຫາກຫຼືການແບ່ງປັນເຄືອຂ່າຍ:

   sqlite3 /path/to/app.db "VACUUM INTO '/mnt/external_usb/app_compacted.db';"
   

ຂັ້ນ​ຕອນ​ທີ 2​: ການ​ກູ້​ຄືນ​ຕົ້ນ​ໄມ້ B ທີ່​ເສຍ​ຫາຍ (database disk image is malformed) ກັບ .recover¶

ຖ້າ PRAGMA integrity_check; ບົດລາຍງານ row 412 missing from index, btreeInitPage() returns error code 11, ຫຼື database disk image is malformed:

1. ** ຄັ້ງ​ທໍາ​ອິດ​ພະ​ຍາ​ຍາມ​ສ້າງ​ດັດ​ຊະ​ນີ​ມັດ​ທະ​ຍົມ​ທີ່​ແຕກ​ຫັກ​ຄືນ​ໃຫມ່ (REINDEX)**: ເລື້ອຍໆຂໍ້ມູນຕາຕະລາງຕົວຈິງ (table B-trees) ແມ່ນ 100 ເປີເຊັນ intact ແລະພຽງແຕ່ດັດຊະນີ B-tree ທີສອງໄດ້ຖືກເສຍຫາຍໃນເວລາທີ່ແຜ່ນເຕັມໄປ. ແລ່ນ:

   sqlite3 /mnt/external_usb/copy_of_app.db "REINDEX;"
   sqlite3 /mnt/external_usb/copy_of_app.db "PRAGMA integrity_check;"
   

   ຖ້າ PRAGMA integrity_check; ດຽວນີ້ກັບຄືນມາ ok, ທ່ານໄດ້ຟື້ນຕົວ 100 ເປີເຊັນຂອງຖານຂໍ້ມູນຂອງທ່ານກັບສູນການສູນເສຍແຖວ.
2. ** ຖ້າ REINDEX ລົ້ມເຫລວ, ແລ່ນເຄື່ອງສະແກນ forensic B-tree (.recover)**: ແຕກຕ່າງຈາກເກົ່າ .dump ຄໍາສັ່ງ (ເຊິ່ງຢຸດການສົ່ງອອກຕາຕະລາງໃນຂະນະທີ່ມັນມົນຕີຕົວຊີ້ B-tree ທີ່ເສຍຫາຍ), .recover (ສ້າງຂຶ້ນໃນ sqlite3 ເວີຊັ່ນ 3.29.0+) ຂ້າມຕົວຊີ້ B-tree ພາຍໃນທີ່ເສຍຫາຍທັງໝົດ, ສະແກນທຸກໜ້າໃບດິບ 4 ກິໂລໄບຂອງໄຟລ໌ຕາມລຳດັບຈາກ byte 0 ຫາ EOF, ສ້າງທຸກແຖວທີ່ສາມາດອ່ານໄດ້, ແລະວາງບັນທຶກເດັກນ້ອຍກຳພ້າເຂົ້າໄປໃນ lost_and_found ຕາຕະລາງ:

   sqlite3 /mnt/external_usb/copy_of_app.db ".recover" | sqlite3 /mnt/external_usb/repaired_app.db
   

3. ກວດສອບຖານຂໍ້ມູນທີ່ສ້າງຂຶ້ນໃໝ່:

   sqlite3 /mnt/external_usb/repaired_app.db "PRAGMA integrity_check;"
   

   ກວດເບິ່ງວ່າ ກ lost_and_found ຕາ​ຕະ​ລາງ​ໄດ້​ຖືກ​ສ້າງ​ຕັ້ງ​ຂຶ້ນ (sqlite3 /mnt/external_usb/repaired_app.db ".tables") ເພື່ອກວດກາເບິ່ງແຖວເດັກກຳພ້າທີ່ກູ້ມາຈາກໜ້າໃບທີ່ບໍ່ໄດ້ເຊື່ອມຕໍ່. ສໍາລັບຖານຂໍ້ມູນ SQLCipher ທີ່ເຂົ້າລະຫັດໄວ້ (ເຊັ່ນ: Signal ຫຼື WhatsApp backup), ເບິ່ງຄູ່ມືສະເພາະຂອງພວກເຮົາກ່ຽວກັບ ການເຂົ້າລະຫັດ SQLite, Signal, ແລະ WhatsApp chat backup ສໍ້ລາດບັງຫຼວງແລະການສະກັດເອົາລະຫັດທ້ອງຖິ່ນ.

ໄລຍະທີ 6: ເຫດການສຸກເສີນ "Tripwire Ballast File" ແລະລາຍການກວດກາການປ້ອງກັນ¶

ເມື່ອເຄື່ອງແມ່ຂ່າຍແລະຖານຂໍ້ມູນຂອງທ່ານກັບມາອອນໄລນ໌, ປະຕິບັດການປົກປ້ອງສີ່ຢ່າງນີ້ທັນທີເພື່ອວ່າທ່ານຈະບໍ່ຕິດຢູ່ 0 bytes ຟຣີອີກເທື່ອຫນຶ່ງ:

• ** ສ້າງ 1 gigabyte (1,073,741,824 byte) Emergency Ballast File on every database partition**: Run sudo fallocate -l 1G /var/lib/EMERGENCY_DELETE_ME.ballast. ຖ້າເຄື່ອງແມ່ຂ່າຍເຄີຍ hits 100% disk ເຕັມ, ແລ່ນ sudo rm /var/lib/EMERGENCY_DELETE_ME.ballast ປົດປ່ອຍ 1 gigabyte ຂອງຕັນຕິດກັນໃນ 1 millisecond.
• ຫລວງ systemd-journald ແລະບັນທຶກ Docker container ຢ່າງຖາວອນ: ຕັ້ງ SystemMaxUse=200M ໃນ /etc/systemd/journald.conf ແລະ configure /etc/docker/daemon.json ກັບ "log-opts": {"max-size": "20m", "max-file": "3"}.
• ** ໂດດດ່ຽວ /var/log, /tmp, ແລະ /var/lib/postgresql ໃສ່ປະລິມານ LVM ແຍກຕ່າງຫາກ**: ການຮັກສາໄວ້ /var/log ແລະ /tmp ແຍກອອກຈາກປະລິມານຖານຂໍ້ມູນ ຮັບປະກັນວ່າບັນທຶກເວັບທີ່ໜີໄປບໍ່ເຄີຍຂັດຂ້ອງກັບຖານຂໍ້ມູນ ຫຼືປິດການເຂົ້າສູ່ລະບົບ SSH.
• ** ເຕືອນ​ກ່ຽວ​ກັບ​ທັງ​ສອງ​ df -h (> 80%) ແລະ df -i (> 80%) ບວກ pg_replication_slots lag**: ຕັ້ງຄ່າການຕິດຕາມ (node_filesystem_avail_bytes ແລະ node_filesystem_files_free) ເພື່ອເຕືອນກ່ອນທີ່ຈະນໍາໃຊ້ຂ້າມ 85 ເປີເຊັນ.

ໝາຍເລກສຸກເສີນລະດັບພາກພື້ນ ແລະພິທີການຂອງອົງການ¶

ໃນຂະນະທີ່ດິສເຊີບເວີເຕັມທີ່ປົກກະຕິແມ່ນເປັນການສຸກເສີນໃນການດໍາເນີນງານ IT ພາຍໃນ, ການ outage ຜົນກະທົບຕໍ່ສຸຂະພາບ Electronic Health Record (EHR) ຖານ​ຂໍ້​ມູນ​, ການ​ສົ່ງ​ສຸກ​ເສີນ (CAD), ການວັດແທກນ້ຳ/ພະລັງງານຂອງເທດສະບານ, ຫຼືການມີຂໍ້ມູນສ່ວນຕົວຕາມກົດໝາຍອາດຈະຮຽກຮ້ອງໃຫ້ມີການເລັ່ງສຸກເສີນຢ່າງເປັນທາງການ:

• ** ສະ​ຫະ​ລັດ​ແລະ​ກາ​ນາ​ດາ **​: ໂທ 911 ຖ້າ​ເຊີບ​ເວີ​ເກີດ​ອຸ​ບັດ​ເຫດ​ປິດ​ການ​ຕິດ​ຕາມ​ກວດ​ກາ​ທາງ​ຄລີ​ນິກ ຫຼື​ການ​ຈັດ​ສົ່ງ, ແລະ​ກະ​ຕຸ້ນ​ຂັ້ນ​ຕອນ​ການ​ຢຸດ​ເຊົາ​ງານ. ລາຍ​ງານ​ການ​ສູນ​ເສຍ​ຊັບ​ພະ​ຍາ​ກອນ​ພື້ນ​ຖານ​ໂຄງ​ລ່າງ​ທີ່​ສໍາ​ຄັນ​ຫຼື​ການ​ໂຈມ​ຕີ ransomware ກັບ CISA (1-844-Say-CISA / cisa.gov/report) ຫຼື ສູນ​ກາ​ນາ​ດາ​ສໍາ​ລັບ​ຄວາມ​ປອດ​ໄພ Cyber (1-833-CYBER-88).
• ** ສະຫະລາດຊະອານາຈັກ **: ໂທ 999 ສໍາລັບໄພຂົ່ມຂູ່ຕໍ່ຊີວິດຫຼືລະບົບ NHS ທີ່ສໍາຄັນ. ພາຍໃຕ້ກົດລະບຽບຂອງ GDPR ແລະ NIS ຂອງອັງກິດ, ປະເມີນວ່າການສູນເສຍຄວາມພ້ອມຂອງຖານຂໍ້ມູນແບບຖາວອນຕ້ອງການແຈ້ງການເຖິງ ICO (0303 123 1113) ພາຍ​ໃນ 72 ຊົ່ວ​ໂມງ​.
• ** ສະ​ຫະ​ພາບ​ເອີ​ຣົບ **​: ໂທ 112 ໃນ​ທົ່ວ​ປະ​ເທດ​ສະ​ມາ​ຊິກ EU ທັງ​ຫມົດ​. ໜ່ວຍງານທີ່ຈຳເປັນພາຍໃຕ້ NIS2 Directive ຈະຕ້ອງແຈ້ງ CSIRT ແຫ່ງຊາດຂອງເຂົາເຈົ້າພາຍໃນ 24 ຊົ່ວໂມງຫຼັງຈາກເກີດການຢຸດຢ່າງໃຫຍ່ຫຼວງ, ແລະການສູນເສຍຂໍ້ມູນສ່ວນຕົວແບບຖາວອນໂດຍບໍ່ມີການຟື້ນຟູຂໍ້ມູນສຳຮອງຈະເຮັດໃຫ້ເກີດ GDPR ມາດຕາ 33 ລາຍງານພາຍໃນ 72 ຊົ່ວໂມງ.
• ** ອົດ​ສະ​ຕາ​ລີ​ແລະ​ນິວ​ຊີ​ແລນ **: ໂທ 000 ໃນ​ອົດ​ສະ​ຕາ​ລີ​ຫຼື 111 ໃນນິວຊີແລນ; ຕິດ​ຕໍ່ ACSC (1300 CYBER1) ສໍາ​ລັບ​ເຫດ​ການ​ພື້ນ​ຖານ​ໂຄງ​ລ່າງ​.
• ** ອິນ​ເດຍ​ແລະ​ອາ​ຊີ​ປາ​ຊີ​ຟິກ **: ໂທ 112 ສໍາລັບການຕອບສະຫນອງສຸກເສີນ; ລາຍ​ງານ​ການ​ຢຸດ​ເຊົາ​ທີ່​ເກີດ​ຈາກ​ອິນ​ເຕີ​ເນັດ​ກັບ CERT-In (incident@cert-in.org.in) ພາຍ​ໃນ​ປ່ອງ​ຢ້ຽມ 6 ຊົ່ວ​ໂມງ​ບັງ​ຄັບ​.

ຄຳຖາມທີ່ມັກຖາມເລື້ອຍໆ¶

ເປັນຫຍັງ df -h ຢູ່​ທີ່ 100​% (0 Avail) ເຖິງແມ່ນວ່າຫຼັງຈາກຂ້າພະເຈົ້າລຶບໄຟລ໌ບັນທຶກ 50 GB ກັບ rm?¶

ໃນລະບົບໄຟລ໌ Linux, rm ໂທເທົ່ານັ້ນ ຍົກເລີກການເຊື່ອມຕໍ່(), ການຖອນຊື່ໄຟລ໌ອອກຈາກໄດເລກະທໍລີໃນຂະນະທີ່ kernel ຮັກສາການຈັດສັນແຜ່ນດິດຈົນກ່ວາທຸກຂະບວນການທີ່ຖືໄຟລ໌ນັ້ນເປີດປິດຕົວອະທິບາຍໄຟລ໌ຂອງມັນ (i_count == 0). ແລ່ນ sudo lsof +L1 ເພື່ອຊອກຫາ ID ຂະບວນການ (PID) ແລະຕົວອະທິບາຍໄຟລ໌ (FD) ຂອງ (ລຶບແລ້ວ) ໄຟລ໌, ຫຼັງຈາກນັ້ນດໍາເນີນການ sudo sh -c ': > /proc/PID/fd/FD' ໃຫ້ສູນຕັນຢູ່ໃນສະຖານທີ່ທັນທີໂດຍບໍ່ມີການ restart ການບໍລິການ.

ຈະເປັນແນວໃດຖ້າຂ້ອຍບໍ່ສາມາດ SSH ເຂົ້າໄປໃນເຄື່ອງແມ່ຂ່າຍເພາະວ່າ /tmp ຫຼື /var/run ແມ່ນ 100% ເຕັມແລະ sshd ປະຕິເສດການຈັດສັນເຊດຊັນບໍ?¶

ທໍາອິດໃຫ້ລອງປະຕິບັດຄໍາສັ່ງໂດຍກົງທີ່ບໍ່ແມ່ນ PTY ຜ່ານ SSH ໂດຍບໍ່ມີການຈັດສັນ pseudo-terminal ແບບໂຕ້ຕອບ: ssh -T root@server "sh -c ': > /var/log/syslog'". ຖ້າ ຮາກ ການເຂົ້າສູ່ລະບົບຖືກປິດໄວ້, ໃຊ້ console serial serial ຂອງຜູ້ໃຫ້ບໍລິການຄລາວຂອງທ່ານ (AWS EC2 Serial Console, DigitalOcean Console, Linode Lish, ຫຼື Proxmox/VMware VNC) ເພື່ອເຂົ້າສູ່ລະບົບໂດຍກົງໃນ ttyS0 ຫຼືບູດເຂົ້າໄປໃນຮູບແບບການຟື້ນຕົວຜູ້ໃຊ້ດຽວ.

ບາງຄົນໄດ້ລຶບໄຟລ໌ພາຍໃນ PostgreSQL ແລ້ວ pg_wal ໄດເລກະທໍລີກ່ອນທີ່ຈະອ່ານຄູ່ມືນີ້, ແລະໃນປັດຈຸບັນ PostgreSQL ປະຕິເສດທີ່ຈະເລີ່ມຕົ້ນດ້ວຍ PANIC: could not locate a valid checkpoint record. ຂໍ້ມູນທັງໝົດເສຍບໍ?¶

ບໍ່, ແຖວຕາຕະລາງສ່ວນຫຼາຍແມ່ນຍັງຢູ່ພາຍໃນ $PGDATA/ຖານ/, ເຖິງແມ່ນວ່າການເຮັດທຸລະກໍາໃນການບິນພາຍໃນໄຟລ໌ WAL ທີ່ຖືກລົບແມ່ນສູນເສຍແລະບາງຫນ້າອາດຈະຖືກຈີກ. ທໍາອິດເຮັດສໍາເນົາຄົບຖ້ວນສົມບູນ $PGDATA ໄດເລກະທໍລີ (cp -a /var/lib/postgresql/16/main /mnt/backup/pgdata_raw). ຈາກນັ້ນແລ່ນ sudo -u postgres /usr/lib/postgresql/16/bin/pg_resetwal -f /var/lib/postgresql/16/main, ເລີ່ມ PostgreSQL ໃນຮູບແບບຜູ້ໃຊ້ດຽວ, ແລະດໍາເນີນການທັນທີ pg_dumpall ເຂົ້າໄປໃນການເລີ່ມຕົ້ນໃຫມ່ (initdb) ກຸ່ມ; ຢ່າສືບຕໍ່ແລ່ນການຈະລາຈອນການຜະລິດຢູ່ໃນກຸ່ມຫຼັງຈາກ pg_resetwal.

ຂ້ອຍຈະລຶບລ້ານໄຟລ໌ຂະຫນາດນ້ອຍໄດ້ແນວໃດເມື່ອ rm -rf hangs ຫຼືລົ້ມເຫຼວໃນ inode-ຫມົດ (df -i 100%) ເຊີບເວີ?¶

ເມື່ອໄດເລກະທໍລີມີເຊດຊັນນ້ອຍໆຫຼາຍລ້ານຄັ້ງ ຫຼືໄຟລ໌ cache, ດັດຊະນີໄດເລກະທໍລີຂອງມັນ (ຮຕ) ການຂະຫຍາຍຕົວຂະຫນາດໃຫຍ່, ເຊິ່ງກໍ່ໃຫ້ເກີດ ls ແລະ rm -rf ເພື່ອຢຸດການຈັດຮຽງຊື່ໄຟລ໌ໃນ RAM. ແທນທີ່ຈະ, ແລ່ນ sudo ຊອກຫາ /path/to/million_files -mindepth 1 -delete, ຫຼືສ້າງໄດເລກະທໍລີ RAM ຫວ່າງເປົ່າ (mkdir /dev/shm/ເປົ່າ) ແລະ​ດໍາ​ເນີນ​ການ​ sudo rsync -a --delete /dev/shm/empty/ /path/to/million_files/ ເພື່ອຍົກເລີກການເຊື່ອມໂຍງ inodes ຢ່າງໄວວາ.

ເປັນຫຍັງ Docker ຈຶ່ງຕື່ມຂໍ້ມູນໃສ່ແຜ່ນເຊີບເວີທັງໝົດຂອງຂ້ອຍເມື່ອກ່ອງບັນຈຸຂອງຂ້ອຍນ້ອຍໆ, ແລະຂ້ອຍຈະເຮັດຄວາມສະອາດໄດ້ແນວໃດ /var/lib/docker ປອດໄພບໍ?¶

Docker ສະສົມພື້ນທີ່ດິສກ໌ຢູ່ໃນບັນທຶກ JSON stdout ທີ່ບໍ່ໄດ້ຫມຸນ (/var/lib/docker/containers/*/*-json.log), dangling ວາງຊ້ອນ2 ຊັ້ນຮູບພາບ, ແລະ cache buildkit. ບໍ່ເຄີຍດ້ວຍຕົນເອງ rm -rf ໂຟນເດີພາຍໃນ /var/lib/docker/overlay2/. ທໍາອິດຕັດບັນທຶກ JSON (sudo truncate -s 0 /var/lib/docker/containers/*/*-json.log) ດັ່ງນັ້ນ daemon ມີຫ້ອງຫາຍໃຈ, ຫຼັງຈາກນັ້ນແລ່ນ sudo docker ລະບົບ prune -a -f (ຍົກ​ເວັ້ນ --ປະລິມານ ດັ່ງນັ້ນປະລິມານຖານຂໍ້ມູນຍັງຄົງ untouched).

ຂ້ອຍສາມາດຂະຫຍາຍ cloud EBS / persistent disk volume ດໍາລົງຊີວິດໃນຂະນະທີ່ເຄື່ອງແມ່ຂ່າຍຢູ່ທີ່ 100% disk utilization?¶

ແມ່ນແລ້ວ, ການຂະຫຍາຍປະລິມານອອນໄລນ໌ເຮັດວຽກໂດຍບໍ່ມີການ rebooting, ມີຫນຶ່ງຈັບ: script ຜູ້ຊ່ວຍ growpart /dev/nvme0n1 1 ພະຍາຍາມສ້າງໄຟລ໌ຊົ່ວຄາວໃນ /tmp ການ​ນໍາ​ໃຊ້ mktemp ແລະລົ້ມເຫລວຢູ່ທີ່ 0 bytes ຟຣີ. ຂ້າມຄວາມລົ້ມເຫລວນັ້ນໂດຍການແລ່ນ sudo TMPDIR=/dev/shm growpart /dev/nvme0n1 1 (ໃຊ້ RAM-backed /dev/shm mount) ຕາມດ້ວຍ sudo resize2fs /dev/nvme0n1p1 (ext4) ຫຼື sudo xfs_growfs / (XFS).

ຄູ່ມືທີ່ກ່ຽວຂ້ອງ¶

• ອຸບັດຕິເຫດ rm -rf ຫຼື Shift+Delete ໃນ Linux, macOS, ຫຼື Windows: ເຊື່ອມຕໍ່ແບບອ່ານເທົ່ານັ້ນທັນທີ.
• ການເຂົ້າລະຫັດ SQLite, Signal, ແລະ WhatsApp chat backup ສໍ້ລາດບັງຫຼວງແລະການສະກັດເອົາລະຫັດທ້ອງຖິ່ນ
• ໄຟລ໌ Word, Excel, PDF ແລະຖານຂໍ້ມູນເສຍຫາຍແລະການຟື້ນຕົວເອກະສານທີ່ບໍ່ໄດ້ບັນທຶກໄວ້
• ໂໝດອ່ານເທົ່ານັ້ນແບບກະທັນຫັນ SSD ແລະ NVMe, 0% ບລັອກສຳຮອງ, ແລະ TRIM ປິດໃຊ້ງານການກູ້ຂໍ້ມູນ
• ວິກິດການໂຮດເວັບ, ການເຄື່ອນຍ້າຍ, ແລະການຟື້ນຟູການສໍາຮອງຂໍ້ມູນ
• ຕົວເລກສຸກເສີນຕາມປະເທດ

ແຫຼ່ງຂໍ້ມູນແລະຄໍາແນະນໍາຢ່າງເປັນທາງການ¶

• PostgreSQL Global Development Group: PostgreSQL 16 ເອກະສານທີ່ເປັນທາງການ - ບົດທີ 30: ຄວາມໜ້າເຊື່ອຖື ແລະບັນທຶກການຂຽນລ່ວງໜ້າ (WAL Configuration, Replication Slots, and Recovery from Disk Full Failures).
• ສະມາຄົມ SQLite (sqlite.org): ວິທີການເສຍຫາຍໄຟລ໌ຖານຂໍ້ມູນ SQLite (ການລັອກໄຟລ໌, ໄຟລ໌ວາລະສານທີ່ບໍ່ໄດ້ເຊື່ອມຕໍ່/ໄຟລ໌ WAL, ແລະ .recover ການຂະຫຍາຍ CLI).
• Oracle Corporation / MySQL Documentation & MariaDB Foundation: *InnoDB Crash Recovery, Binary Log Purge Procedures (PURGE BINARY LOGS), ແລະພື້ນທີ່ຕາຕະລາງຊົ່ວຄາວ (ibtmp1) ການ​ຄຸ້ມ​ຄອງ *.
• ອົງການ Linux Kernel (kernel.org): Ext4 ບໍລິຫານລະບົບໄຟລ໌ (tune2fs Reserved Blocks, Inode Tables, ແລະ /proc/<pid>/fd/ ການຕັດຕົວອະທິບາຍໄຟລ໌).
• ສະຖາບັນມາດຕະຖານ ແລະ ເຕັກໂນໂລຊີແຫ່ງຊາດ (NIST) (ສະຫະລັດ): ສິ່ງພິມພິເສດ 800-123: ຄູ່ມືກ່ຽວກັບຄວາມປອດໄພຂອງເຊີບເວີທົ່ວໄປ ແລະການຄຸ້ມຄອງການມີໃຫ້.