සේවාදායක තැටිය 100% පිරී ඇත (බයිට් 0 ක් නොමිලේ): බිඳවැටුණු දත්ත සමුදායක් ප්‍රතිසාධනය කරන විට rm සහ apt Inodes/Space නොමැතිකම නිසා අසාර්ථකයි¶

නිෂ්පාදන Linux සේවාදායකයක් වැදී ඇති බව සොයා ගැනීම 100% තැටි භාවිතය (0 bytes free) හෝ 100% ඉනෝඩ භාවිතය (df -i) ක්‍රියාකාරී PostgreSQL, MySQL/InnoDB, MariaDB, හෝ SQLite දත්ත සමුදායක් ක්‍රියාත්මක කිරීමේදී පද්ධති පරිපාලනයේ ඇති භයානකම අසාර්ථක ක්‍රමවලින් එකකි. ශුන්‍ය බයිට් හෝ ශුන්‍ය නිදහස් ඉනෝඩ වලදී, අර්බුදය වේගයෙන් ගලා යයි: මෙහෙයුම් පද්ධති කර්නලයට තවදුරටත් යුනික්ස් වසම් සොකට් සෑදිය නොහැක. /tmp හෝ /var/run, bash තාවකාලික ෂෙල් පයිප්ප ලිවිය නොහැකි නිසා ටැබ්-සම්පූර්ණ කිරීමට අසමත් වේ, apt හෝ dnf පැකේජ කළමණාකරුවන්ට තාවකාලික අගුළු ගොනු අවශ්‍ය වන නිසා පැකේජ පිරිසිදු කිරීමට ක්‍රියා කළ නොහැක, සහ ඔබේ දත්ත සමුදාය එන්ජිම ලියන්න-ඉදිරි ලොගයක් මැද කඩා වැටේ (WAL) මුරපොලක් හෝ එය සඳහා තනි කිලෝබයිට් 4 (මෙගාබයිට් 0.004) කුට්ටියක් වෙන් කළ නොහැකි නිසා පිරිසිදුව වසා දැමීම ප්‍රතික්ෂේප කරයි. .pid හෝ ගොනුව අගුළු දමන්න. නරකම දෙය නම්, කලබලයට පත් පරිපාලකයින් බොහෝ විට ධාවනය කිරීමයි rm -rf /var/log/*.log බහු-ගිගාබයිට් ලොග් ගොනු මත සහ භීතියෙන් නරඹන්න 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 ලොග් ගොනු මකාදැමීම හෝ පියාසර පිටු වල එකම වාර්තාව විනාශ කරයි. සම්පූර්ණ තැටියක් සහිත දත්ත සමුදායක් අවකාශය නිදහස් කළ පසු සියයට 100ක් නැවත ලබාගත හැක; WAL ගොනු අතින් මකා දැමූ දත්ත සමුදායක් rm ආපසු හැරවිය නොහැකි බී-ගස් සහ ගොඩවල් දූෂණයට ලක් වනු ඇත.
2. ** ඔබ තැටි කුට්ටි වලින් ඉවත් වී ඇත්දැයි තත්පර 5 කින් හඳුනා ගන්න (df -h), ගොනු පද්ධතියෙන් පිටත ඉනෝඩ (df -i), හෝ විවෘත නොබැඳි ගොනු අල්ලාගෙන සිටීම (lsof +L1)**:
3. දුවන්න df -h වාරණ ධාරිතාව පරීක්ෂා කිරීමට සහ df -i inode ධාරිතාව පරීක්ෂා කිරීමට. ගිගාබයිට් 50ක් (බයිට් බිලියන 53.6ක්) නිදහස් තැටි ඉඩක් සහිත සේවාදායකයක් තවමත් විසි කරයි No space left on device (ENOSPC) නම් df -i පෙන්වයි IUse% = 100% (සාමාන්‍යයෙන් කුඩා සැසි, හැඹිලි හෝ තැපැල් ස්පූල් ගොනු මිලියන ගණනක් නිසා ඇතිවේ).
4. නම් df -h පෙන්වයි 100% භාවිතා කරන ලදී (0 Avail) ඔබ දිව ගිය පසු පවා rm විශාල ලොග් ගොනු මත, ධාවනය කරන්න sudo lsof +L1. සමඟ මකා දැමූ ඕනෑම ගොනුවක් rm අතර nginx, rsyslog, docker, postgres, හෝ mysqld ක්‍රියාවලිය නැවත ආරම්භ වන තෙක් හෝ ඔබ කෙලින්ම විස්තරය කප්පාදු කරන තෙක් විවෘත ගොනු විස්තරයක් එහි තැටි කුට්ටි වලින් සියයට 100ක් පරිභෝජනය කරයි.
5. (: > /path/to/logfile හෝ : > /proc/<pid>/fd/<n>)**:
6. වෙනුවට rm /var/log/syslog (එමගින් ක්‍රියාත්මක වන ලොගරය මඟින් අවහිර කිරීම් අගුළු දමා ඇත), shell null යළි-යොමුවීම් භාවිතයෙන් ගොනුව ශුන්‍ය කරන්න: sudo sh -c ': > /var/log/syslog' හෝ sudo truncate -s 0 /var/log/syslog.
7. ඔබ දැනටමත් දිව ගොස් ඇත්නම් rm දැවැන්ත ලොග් ගොනුවක් මත සහ df -h වැටුනේ නැත, එහි ක්‍රියාවලි ID සොයා ගන්න (PID) සහ ගොනු විස්තරය (FD) තුළ sudo lsof +L1 කර්නල් procfs අතුරුමුහුණත හරහා එය කෙලින්ම කපා දමන්න: sudo sh -c ': > /proc/<PID>/fd/<FD>'. අවකාශය වෙත නැවත පැමිණෙනු ඇත df -h ක්ෂණිකව.
8. ** ක්ෂණික හදිසි හුස්ම ගැනීමේ කාමරය විවෘත කරන්න ext4 / ext3 වෙන් කර ඇති මූල වාරණ ප්‍රතිශතය අඩු කිරීමෙන් (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 ක භාවිතයකින්. ධාවනය කිරීමෙන් බිංදු අක්‍රිය කාලය සමඟ තත්පර 1 කින් එම සංචිතයෙන් සියයට 80 ක් සබැඳිව ලබා ගන්න sudo tune2fs -m 1 /dev/sda1 (හෝ ඔබගේ root block උපාංගය වෙතින් findmnt /)
9. ** රික්තය systemd-journald ද්විමය ලඝු-සටහන් සහ පැරණි පැකේජ හැඹිලි ආරක්ෂිතව**: ධාවනය කරන්න sudo journalctl --vacuum-size=50M (එය ආරක්ෂිතව භ්‍රමණය වන අතර ද්විමය පිරිසිදු කරයි /var/log/journal ලේඛනාගාරය මෙගාබයිට් 50 දක්වා) සහ sudo apt-get clean (හෝ sudo dnf clean all), බාගත කළ ඒවා මකා දමයි .deb / .rpm ලේඛනාගාර තුළ /var/cache/apt/archives/ dpkg දත්ත ගබඩාවට ලිවීමට අවශ්‍ය නොවී.
10. අවම වශයෙන් ගිගාබයිට් 1 සිට ගිගාබයිට් 5 දක්වා (බයිට් බිලියන 1.07 සිට 5.36 දක්වා) ඉඩ නිදහස් වූ පසු, සේවාලාභී ගමනාගමනයට ඉඩ දීමට පෙර එහි WAL මුරපොල සම්පූර්ණ කිරීමට දත්ත සමුදාය තනි පරිශීලක හෝ ප්‍රතිසාධන ප්‍රකාරයට ගෙන එන්න: PostgreSQL, MySQL/InnoDB, හෝ SQLite එහි ලොගය නැවත ධාවනය කිරීමට ඉඩ දෙන්න.WAL), අපිරිසිදු පිටු ප්‍රධාන දත්ත ගොනු වෙත ෆ්ලෂ් කරන්න, සහ ඔබේ යෙදුම් ෆයර්වෝල් හෝ වෙබ් සේවාදායකය නැවත විවෘත කිරීමට පෙර එහි පිම්බුණු WAL කොටස් පිරිසිදුව ප්‍රතිචක්‍රීකරණය කරන්න.

තීරණ ගස: ශුන්‍ය-අවකාශ සේවාදායකය සහ බිඳ වැටුණු දත්ත සමුදා ත්‍රිත්වය¶

මෙහෙයුම් පද්ධතිය වාර්තා කරන්නේ මන්දැයි හඳුනා ගැනීමට මෙම තීරණ ගස භාවිතා කරන්න ENOSPC (No space left on device) සහ නිශ්චිත විනාශකාරී නොවන ප්‍රතිසාධන මාර්ගය තෝරන්න:

flowchart TD
    Start["සේවාදායකය හෝ දත්ත සමුදාය විසි කිරීම: උපාංගයේ ඉඩක් ඉතිරි නොවේ (ENOSPC)"] --> CheckDF["ධාවනය: df -h සහ df -i"]

    CheckDF --> DiagType{"df වාර්තා කරන්නේ කුමක්ද?"}

    DiagType -->|"df -h 100% භාවිතය පෙන්වයි (0 ලබා ගත හැක) සහ df -i < 95%"| BlockFull["විඩාව අවහිර කරන්න: du -shx / df -h ගැලපේදැයි පරීක්ෂා කරන්න"]
    DiagType -->|"df -h නොමිලේ GBs පෙන්වයි නමුත් df -i 100% IUse පෙන්වයි"| InodeFull["Inode Exhaustion: කුඩා 0-4KB ගොනු මිලියන ගණනක්"]
    DiagType -->|"df -h සහ df -i පෙන්වන්න <90% භාවිතා කර ඇත"| RamOrQuota["සැඟවුණු සීමාව: df -h /tmp (tmpfs RAM පිරී ඇත), Docker Overlay2, හෝ XFS/ext4 තැටි කෝටා පරීක්ෂා කරන්න"]

    BlockFull --> GhostCheck{"ඔබ දැනටමත් විශාල ගොනු මත df අතහැරීමකින් තොරව rm ධාවනය කර තිබේද?"}
    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 (Root නොවන DB පරිශීලකයා සඳහා තැටියෙන් 4% ක් ක්ෂණිකව නිදහස් කරයි)"]
    Ext4Check -->|"නැත (XFS / Btrfs / ZFS)"| TruncLogs["Logs In-Place (: > /var/log/syslog) කපා දමා journalctl --vacuum-size=50M ධාවනය කරන්න"]

    InodeFull --> InodeClean["Find / -xdev -printf '%h\n' භාවිතා කරමින් ගොනු මිලියන ගණනක් සහිත නාමාවලිය සොයන්න | වර්ග කිරීම | uniq -c | වර්ග කිරීම -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{"කුමන Database Engine එක කඩා වැටුනේද?"}
    WhichDB -->|"PostgreSQL"| PGFlow["pg_wal නොවෙනස්ව තබා ගන්න -> WAL නැවත ධාවනය කිරීමට Postgres ආරම්භ කරන්න -> CHECKPOINT ධාවනය කරන්න; -> පරණ ප්‍රතිනිර්මාණ කට්ට අතහරින්න"]
    WhichDB -->|"MySQL / MariaDB (InnoDB)"| MyFlow["ib_logfile* නොවෙනස්ව තබා ගන්න -> Mysqld ආරම්භ කරන්න -> PURGE BINARY LOGS හරහා ද්විමය ලොග් පිරිසිදු කරන්න -> වගු ප්‍රශස්ත කරන්න"]
    WhichDB -->|"SQLite3"| SqFlow["උපස්ථ කරන්න .db + .db-wal + .db-shm -> PRAGMA wal_checkpoint(TRUNCATE) ධාවනය කරන්න හෝ sqlite3break.db '.recover'"]

අදියර 1: ඇයි සම්මත විධාන (rm, apt, tab-completion) නොමිලේ බයිට් 0 කින් අසමත් වේ¶

Linux කොටසකට සියයට 100 ක අවහිරයක් හෝ ඉනෝඩයක් වෙහෙසට පත් වූ විට, සම්මත ප්‍රතිකර්ම විධාන අනපේක්ෂිත ආකාරයෙන් අසාර්ථක වේ: - ** එබීම Tab තුළ bash විසි කරයි cannot create temp file for here-document: No space left on device**: නවීන bash-completion ස්ක්‍රිප්ට් තාවකාලික ගොනු නිර්මාණය කරයි /tmp. නම් /tmp මූලයේ වාසය කරයි / a වෙනුවට partition 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 සහ ගිගාබයිට් 50 (බයිට බිලියන 0.53 සිට බයිට් බිලියන 53.6) අතර ප්‍රමාණයක් නැවත ලබා ගැනීමට මෙම නිශ්චිත පියවර අනුගමනය කරන්න:

පියවර 1: හරහා විවෘත මකා දැමූ ("අවතාරය") ගොනු කප්පාදු කරන්න /proc/<pid>/fd/¶

ඔබ හෝ ස්වයංක්‍රීය ලොග්‍රෝටේට් ස්ක්‍රිප්ට් එකක් දැනටමත් විශාල ගොනු මකා දමා ඇති නමුත් තැටි ඉඩ නැවත ලබා නොදුන්නේ නම්, කර්නලයේ නොබැඳි විවෘත ගොනු වගුව පරීක්ෂා කරන්න:

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¶

root ගොනු පද්ධතියේ විශාලතම ගොනු සොයන්න (එකම ගොනු පද්ධතියේ රැඳී සිටීම -xdev එබැවින් ඔබ ස්කෑන් කිරීමට කාලය නාස්ති නොකරන්න /proc හෝ බාහිර සවිකිරීම්):

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: 100% තැටිය සම්පූර්ණ බිඳවැටීමකින් පසු PostgreSQL ප්‍රතිසාධනය කිරීම (pg_wal ඉදිමීම)¶

PostgreSQL සේවාදායකයක් තැටි ඉඩ අවසන් වූ විට, එය ලොග් වේ PANIC: could not write to file "pg_wal/xlogtemp.1234": No space left on device, වහාම තැපැල් ස්ථානාධිපති ළමා ක්රියාවලීන් ගබ්සා කරයි, සහ ආරම්භ කිරීම ප්රතික්ෂේප කරයි.

ඇයි pg_wal (pg_xlog PostgreSQL 9.6 සහ ඊට වැඩි) මුළු තැටියම පුරවයි¶

සාමාන්‍ය ක්‍රියාකාරිත්වයේ දී, PostgreSQL සෑම වෙනස්කමක්ම මෙගාබයිට් 16 (බයිට් මිලියන 16.7) දක්වා කොටස් ගොනු තුළ ලියයි. $PGDATA/pg_wal/ සහ එක් එක් පසු ඒවා ප්රතිචක්රීකරණය කරයි CHECKPOINT ඉක්මවා ගිය පසු max_wal_size. කෙසේ වෙතත්, PostgreSQL ** පැරණි මකා දැමීම හෝ ප්‍රතිචක්‍රීකරණය කිරීම තහනම් කර ඇත pg_wal ගොනු ** කොන්දේසි තුනක් යටතේ: 1. අනාථ හෝ පසුගාමී භෞතික/තාර්කික අනුකරණ ස්ලට්: අනුරූ සේවාදායකය (standby), Debezium/Kafka සම්බන්ධකය, හෝ pg_receivewal සේවාලාභියා දින කිහිපයකට පෙර විසන්ධි විය, නමුත් එහි අනුකරණ ස්ලට් (pg_replication_slots) තවමත් පවතී active = false ප්‍රාථමිකයේ, විසන්ධි වූ දා සිට ජනනය වන සෑම WAL කොටසක්ම රඳවා ගැනීමට PostgreSQL වෙත උපදෙස් දෙයි. 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 හට ප්‍රතිනිර්මාණ ස්ලට් එක අතහැරීමට හෝ මුරපොලක් සම්පූර්ණ කිරීමට පවා නොහැක, මන්ද ආරම්භක ප්‍රතිසාධනයටම තාවකාලික රාජ්‍ය ගොනු ලිවීමට මෙගාබයිට් කිහිපයක් නිදහස් තැටි ඉඩ අවශ්‍ය වේ.

පියවරෙන් පියවර PostgreSQL ශුන්‍ය-අවකාශ ගැලවීම (ශුන්‍ය දත්ත නැතිවීම)¶

1. ** ගිගාබයිට් 1 සිට ගිගාබයිට් 5 දක්වා (බයිට් බිලියන 1.07 සිට බිලියන 5.36 දක්වා) පිටත තාවකාලික ඉඩක් සාදන්න 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 ආරම්භ කර වහාම අනුවර්තන කොටස් පරීක්ෂා කරන්න: 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. WAL ගිගාබයිට් ප්‍රමාණයක් රැස් කරන ඕනෑම මිය ගිය/අක්‍රිය ප්‍රතිනිර්මාණ තව් අතහරින්න: ඔබ අක්‍රිය තව් එකක් දුටුවහොත් (active = f) ගිගාබයිට් 80 ක් රඳවා තබා ගැනීම retained_wal:

   SELECT pg_drop_replication_slot('name_of_dead_slot');
   

7. ** වහාම බල කරන්න CHECKPOINT ඉදිමුණු දේ ප්‍රතිචක්‍රීකරණය කිරීමට pg_wal කොටස්**:

   CHECKPOINT;
   

   මොහොත CHECKPOINT; Dead slot අතහැරීමෙන් පසු අවසන් වේ, PostgreSQL විසින් පැරණි මෙගාබයිට් 16 ඛණ්ඩ ගොනු වල ගිගාබයිට් ස්වයංක්‍රීයව විසන්ධි කිරීම හෝ ප්‍රතිචක්‍රීකරණය කරයි. pg_wal/, ඔබේ තැටි භාවිතය සාමාන්‍ය තත්ත්වයට ගෙන ඒම.
8. අනාගත ප්‍රතිනිර්මාණ තව් තැටි මරණය වළක්වන්න: සකසන්න max_slot_wal_keep_size තුළ postgresql.conf (PostgreSQL 13+ හි ඇත) ආරක්ෂිත තොප්පියකට (උදා max_slot_wal_keep_size = 20GB) එබැවින් PostgreSQL විසින් ප්‍රාථමික දත්ත සමුදාය බයිට් 0කින් නොමිලයේ බිඳ වැටීමට වඩා මිය ගිය අනුරුවක ස්ලට් අවලංගු කරයි.

අදියර 4: MySQL / MariaDB ප්‍රතිසාධනය කිරීම (InnoDB) බයිට් 0 කින් නොමිලේ¶

MySQL හෝ MariaDB පහර දෙන විට 100% තැටි භාවිතය (/var/lib/mysql), InnoDB සියලු ලිවීම් හෝ බිඳ වැටීම් නතර කරයි [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 මෙම වැරදිකරුවන් හතර දෙනාගෙන් තැටිය පරිභෝජනය කළේ කවුරුන්ද යන්න බැලීමට: 1. ** සීමා නොකළ ද්විමය ලොග (binlog.000001, mysql-bin.000042): MySQL 8.0+ හි පෙරනිමියෙන්, ද්විමය ලොග් කිරීම දින 30ක රඳවා ගැනීමක් සමඟ සක්‍රීය කර ඇත (binlog_expire_logs_seconds = 2592000), තොග ආනයනයේදී පහසුවෙන් ගිගාබයිට් සිය ගණනක් පේළි සිදුවීම් ජනනය කළ හැක. 2. ** යෝධ තාවකාලික වගු ලියන පලායන විමසුමක් (#sql* හෝ ibtmp1): දැවැන්ත එකක් GROUP BY හෝ ORDER BY විමසුම පුරවා ඇත ibtmp1 හෝ /tmp/#sql_* තැටිය බයිට් 0 ක් ලබා ගන්නා තුරු. 3. ** මොනොලිතික් ibdata1 system tablespace bloat**: if innodb_file_per_table අබල කර ඇත හෝ දිගුකාලීන ගනුදෙනු InnoDB ඉතිහාස ලැයිස්තුව වැළැක්වීය (ඇතුළත ලොග් ඉවත් කරන්න ibdata1 හෝ undo_001) පිරිසිදු කිරීමෙන්. 4. MySQL මන්දගාමී විමසුම් ලොගය හෝ දෝෂ ලොගය (/var/log/mysql/mysql-slow.log).

පියවරෙන් පියවර MySQL / MariaDB zero-space ගලවා ගැනීම¶

1. කවදාවත් මකන්න එපා ibdata1, ib_logfile0, ib_logfile1, #innodb_redo/*, හෝ undo_001 සමඟ rm: මෙම ගොනු වලින් ඕනෑම එකක් මකා දැමීම සෑම එකක්ම කරයි .ibd ඔබගේ දත්ත ගබඩාවේ ඇති වගු ගොනුව කියවිය නොහැක.
2. ** නොමිලේ ආරම්භක ආරම්භක ඉඩ (මෙගාබයිට් 500 සිට ගිගාබයිට් 2 දක්වා)**:
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 - කිසිවිටෙක ඉහළම සංඛ්‍යා සහිත සක්‍රීය බින්ලොග්) වෙත /dev/shm තාවකාලිකව එසේ mysqld boot කරන්න පුළුවන්.
6. ** MySQL අරඹන්න සහ SQL භාවිතයෙන් ආරක්ෂිතව ද්විමය ලොග් පිරිසිදු කරන්න (PURGE BINARY LOGS)**: ඔබ වෙනුවට SQL භාවිතා කළ යුත්තේ ඇයි? rm /var/lib/mysql/binlog.*? MySQL සෑම ද්විමය ලොග් ගොනු නාමයක්ම නිරීක්ෂණය කරන බැවිනි binlog.index. සමඟ ද්විමය ලොග මකා දැමුවහොත් rm යාවත්කාලීන කිරීමකින් තොරව binlog.index, MySQL ආරම්භ කිරීම ප්‍රතික්ෂේප කරයි හෝ අනුකරණය කැඩී යයි. වරක් 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 තක්කඩියෙකු සුචිගත නොකළ බව සහතික කරයි JOIN හෝ ORDER BY a සමඟ විමසුම අසාර්ථක වේ table is full පුළුල් කිරීම වෙනුවට දෝෂයකි ibtmp1 සම්පූර්ණ ලිනක්ස් සේවාදායකයම බයිට් 0 කින් මිය යන තුරු නොමිලේ.

අදියර 5: දූෂිත SQLite3 දත්ත සමුදායක් ප්‍රතිසාධනය කිරීම (database or disk is full / SQLITE_FULL / malformed)¶

කාවැද්දූ යෙදුම්, ඩොකර් බහාලුම් (Nextcloud, Vaultwarden, Home Assistant, Plex, Grafana, Gitea), සහ ජංගම/ඩෙස්ක්ටොප් සේවා SQLite3 මත රඳා පවතී. SQLite ජර්නල පෙරළීමක මැද හෝ Write-Ahead ලොගයක ඇති විට තැටියක් බයිට් 0ක් නොමිලේ ලබා ගන්නා විට (-wal) මුරපොල, ඔබට හදිසි අවස්ථා දෙකෙන් එකක් හමුවනු ඇත: 1. ** දැවැන්ත .db-wal ගොනු ඉදිමීම** (ද .db-wal ගොනුව ගිගාබයිට් 10 දක්වා වර්ධනය වී ඇත .db ගොනුව මෙගාබයිට් 200 ක් පමණි, මන්ද දිගුකාලීන පාඨකයන් අක්‍රිය WAL මුරපොලක් වැළැක්වූ අතර දැන් තැටිය සියයට 100 ක් පිරී ඇත). 2. RuntimeError: database disk image is malformed (SQLITE_CORRUPT) බිඳුණු දෘඪාංගයක් නිසා ඇති විය fsync(), කන්ටේනරයක් බයිට් 0 ක් නොමිලයේ මැද පෙරළීම, හෝ යමෙකු මකා දැමීම -wal හෝ -journal අතින් ගොනු.

පියවර 1: පුම්බා හැකිලීම .db-wal තැටියේ ඉඩ ශුන්‍යයට ආසන්න වන විට ගොනු කර SQLite රික්ත කිරීම¶

1. SQLite දත්ත ගබඩාව විවෘතව තබාගෙන සිටින යෙදුම් බහාලුම් හෝ සේවාව නවත්වන්න (sudo systemctl stop app හෝ docker stop container_name)
2. පිටපත් කරන්න app.db, app.db-wal, සහ app.db-shm විශාල ඉඩ ප්‍රමාණයක් සහිත කොටසකට හෝ බාහිර ධාවකයකට (හෝ නොමිලේ 2x විශාලත්වය app.db මුලින්ම දේශීය තැටියේ).
3. සමඟ දත්ත සමුදාය විවෘත කරන්න sqlite3 CLI සහ සියලු කැපවූ රාමු නැමෙන, කප්පාදු කරන WAL මුරපොලක් බල කරන්න app.db-wal බවට app.db සහ හැකිලෙනවා app.db-wal 0 බයිට් දක්වා:

   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ක් නොවෙනස්ව පවතින අතර තැටිය පුරවන විට දූෂිත වී ඇත්තේ ද්විතියික දර්ශක B-ගසක් පමණි. ධාවනය:

   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 අසමත්, අධිකරණ B-tree ස්කෑනරය ධාවනය කරන්න (.recover)**: පැරණි මෙන් නොව .dump විධානය (එය දූෂිත B-tree pointer එකකට පහර දුන් මොහොතේම මේසයක් අපනයනය කිරීම නතර කරයි) .recover (සාදන ලද sqlite3 අනුවාදය 3.29.0+) දූෂිත අභ්‍යන්තර B-tree දර්ශක සම්පූර්ණයෙන් මග හරියි, ගොනුවේ සෑම අමු 4 kgbyte කොළ පිටුවක්ම byte 0 සිට EOF දක්වා අනුපිළිවෙලින් පරිලෝකනය කරයි, කියවිය හැකි සෑම පේළියක්ම ප්‍රතිනිර්මාණය කරයි, සහ ඕනෑම අනාථ වාර්තාවක් a තුළට තබයි. 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 දත්ත සමුදායන් සඳහා (සංඥා හෝ WhatsApp උපස්ථ වැනි), අපගේ කැපවූ මාර්ගෝපදේශය බලන්න සංකේතනය කරන ලද SQLite, සංඥා සහ WhatsApp චැට් උපස්ථ දූෂණය සහ දේශීය යතුරු නිස්සාරණය.

අදියර 6: හදිසි "Tripwire Ballast File" සහ අධීක්ෂණ වැළැක්වීමේ පිරික්සුම් ලැයිස්තුව¶

ඔබගේ සේවාදායකය සහ දත්ත සමුදාය නැවත සබැඳි වූ පසු, මෙම ආරක්‍ෂක ක්‍රම හතර වහාම ක්‍රියාත්මක කරන්න එවිට ඔබ නැවත කිසිදාක නොමිලේ බයිට් 0කට කොටුවෙන්නේ නැත.

• ගිගාබයිට් 1ක් සාදන්න (1,073,741,824 byte) සෑම දත්ත සමුදා කොටසකම හදිසි බැලස්ට් ගොනුව: ධාවනය කරන්න sudo fallocate -l 1G /var/lib/EMERGENCY_DELETE_ME.ballast. සර්වර් එක කවදා හරි වැදුනොත් 100% තැටිය පිරී ඇත, ධාවනය වේ sudo rm /var/lib/EMERGENCY_DELETE_ME.ballast මිලි තත්පර 1 කින් ගිගාබයිට් 1 ක අඛණ්ඩ කුට්ටි නිදහස් කරයි.
• ** කැප් systemd-journald සහ ඩොකර් කන්ටේනර් ලොග් ස්ථිරව**: සකසන්න SystemMaxUse=200M තුළ /etc/systemd/journald.conf සහ වින්යාස කරන්න /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 ප්‍රමාදය: අධීක්ෂණය වින්‍යාස කරන්න (node_filesystem_avail_bytes සහ node_filesystem_files_free) භාවිතය සියයට 85 ඉක්මවීමට පෙර අනතුරු ඇඟවීමට.

කලාපීය හදිසි අංක සහ නියෝජිත ආයතන ප්‍රොටෝකෝල¶

සම්පූර්ණ සේවාදායක තැටියක් සාමාන්‍යයෙන් අභ්‍යන්තර තොරතුරු තාක්ෂණ මෙහෙයුම් හදිසි අවස්ථාවක් වන අතර, සෞඛ්‍ය ආරක්ෂණ ඉලෙක්ට්‍රොනික සෞඛ්‍ය වාර්තාවට බලපාන ඇනහිටීමක් (EHR) දත්ත සමුදායන්, හදිසි යැවීම (CAD), නාගරික ජලය/බලය දුරස්ථමානය, හෝ ව්‍යවස්ථාපිත පුද්ගලික දත්ත ලබා ගැනීම සඳහා විධිමත් හදිසි උත්සන්න කිරීමක් අවශ්‍ය විය හැක:

• එක්සත් ජනපදය සහ කැනඩාව: Dial 911 සේවාදායක බිඳවැටීමක් සායනික අධීක්ෂණය හෝ යැවීම අක්‍රිය කරන්නේ නම්, සහ අක්‍රීය කාල ක්‍රියා පටිපාටි සක්‍රිය කරන්න. තීරනාත්මක යටිතල පහසුකම් සම්පත් අවසන් වීම හෝ ransomware ප්‍රහාර CISA වෙත වාර්තා කරන්න (1-844-Say-CISA / cisa.gov/report) හෝ ** සයිබර් ආරක්ෂාව සඳහා කැනේඩියානු මධ්‍යස්ථානය (1-833-CYBER-88)**.
• එක්සත් රාජධානිය: Dial 999 ජීවිතයට තර්ජන හෝ තීරණාත්මක NHS පද්ධති සඳහා. UK GDPR සහ NIS රෙගුලාසි යටතේ, ස්ථිර දත්ත සමුදාය ලබා ගැනීමේ පාඩුව ICO වෙත දැනුම් දීම අවශ්‍ය දැයි තක්සේරු කරන්න (0303 123 1113) පැය 72ක් ඇතුළත.
• යුරෝපීය සංගමය: අමතන්න 112 සියලුම EU සාමාජික රටවල් හරහා. NIS2 විධානය යටතේ ඇති අත්‍යවශ්‍ය ආයතන සැලකිය යුතු ඇනහිටීමකින් පැය 24ක් ඇතුළත ඔවුන්ගේ ජාතික CSIRT වෙත දැනුම් දිය යුතු අතර, උපස්ථ ප්‍රතිසාධනයකින් තොරව ස්ථිර පුද්ගලික දත්ත අහිමි වීම GDPR 33 වගන්තිය පැය 72ක් තුළ වාර්තා කිරීම අවුලුවයි.
• ඕස්ට්‍රේලියාව සහ නවසීලන්තය: Dial 000 ඕස්ට්‍රේලියාවේ හෝ 111 නවසීලන්තයේ; ** ACSC අමතන්න (1300 CYBER1)** යටිතල පහසුකම් සිදුවීම් සඳහා.
• ඉන්දියාව සහ ආසියා-පැසිෆික්: Dial 112 හදිසි ප්රතිචාර සඳහා; සයිබර් ප්‍රේරිත ඇනහිටීම් CERT-In වෙත වාර්තා කරන්න (incident@cert-in.org.in) අනිවාර්ය 6-පැය කවුළුව තුළ.

නිතර අසන ප්රශ්න¶

ඇයි කළේ df -h 100% රැඳී සිටින්න (0 Avail) මම 50 GB ලොග් ගොනුවක් මකා දැමූ පසුවත් rm?¶

Linux ගොනු පද්ධති තුළ, rm ඇමතුම් පමණි විසන්ධි කරන්න (), එම ගොනුව විවෘතව තබාගෙන සිටින සෑම ක්‍රියාවලියක්ම එහි ගොනු විස්තරය වැසෙන තෙක් කර්නලය තැටි කුට්ටි වෙන්කර තබා ගන්නා අතරම නාමාවලියෙන් ගොනු නාමය ඉවත් කරයි (i_count == 0) දුවන්න sudo lsof +L1 ක්‍රියාවලි ID සොයා ගැනීමට (PID) සහ ගොනු විස්තරය (FD) හි (මකන ලද) ගොනුව, පසුව ධාවනය කරන්න sudo sh -c ': > /proc/PID/fd/FD' සේවාව නැවත ආරම්භ නොකර වහාම එහි ඇති කුට්ටි ශුන්‍ය කිරීමට.

මට සේවාදායකයට SSH වත් කළ නොහැකි නම් කුමක් කළ යුතුද? /tmp හෝ /var/run 100% පිරී ඇත සහ sshd සැසියක් වෙන් කිරීම ප්රතික්ෂේප කරයිද?¶

අන්තර්ක්‍රියාකාරී ව්‍යාජ පර්යන්තයක් වෙන් නොකර SSH හරහා PTY නොවන සෘජු විධානයක් ක්‍රියාත්මක කිරීමට පළමුව උත්සාහ කරන්න: ssh -T root@server "sh -c ': > /var/log/syslog'". නම් මූල පුරනය වීම අක්‍රිය කර ඇත, සෘජුවම ලොග් වීමට ඔබගේ ක්ලවුඩ් සපයන්නාගේ පිටත-බෑන්ඩ් අනුක්‍රමික කොන්සෝලය (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/base/, මකා දැමූ 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 ඉනෝඩය අවසන් වූ (ඉනෝඩය) මත එල්ලීම හෝ අසාර්ථක වීම (df -i 100%) සේවාදායකය?¶

නාමාවලියක කුඩා සැසියක් හෝ හැඹිලි ගොනු මිලියන ගණනක් අඩංගු වන විට, එහි නාමාවලි දර්ශකය (htree) විශාල ලෙස වර්ධනය වේ, ඇති කරයි ls සහ rm -rf RAM හි ගොනු නාම වර්ග කිරීම නතර කිරීමට. ඒ වෙනුවට, දුවන්න sudo find /path/to/million_files -mindepth 1 -delete, හෝ හිස් RAM නාමාවලියක් සාදන්න (mkdir /dev/shm/හිස්) සහ ධාවනය කරන්න sudo rsync -a --delete /dev/shm/empty/ /path/to/million_files/ iodes ඉක්මනින් විසන්ධි කිරීමට.

මගේ බහාලුම් කුඩා වූ විට ඩොකර් මගේ සම්පූර්ණ සේවාදායක තැටිය පුරවන්නේ ඇයි සහ මම පිරිසිදු කරන්නේ කෙසේද? /var/lib/docker ආරක්ෂිතව?¶

ඩොකර් නොකැඩූ JSON stdout ලොග වල තැටි ඉඩ රැස් කරයි (/var/lib/docker/containers/*/*-json.log), එල්ලීම උඩ තට්ටුව2 රූප ස්ථර, සහ buildkit හැඹිලි. කවදාවත් අතින් rm -rf ඇතුළත ෆෝල්ඩර /var/lib/docker/overlay2/. මුලින්ම JSON ලඝු-සටහන් කපා දමන්න (sudo trincate -s 0 /var/lib/docker/containers/*/*-json.log) එබැවින් ඩීමන් හට හුස්ම ගැනීමේ කාමරයක් ඇත, ඉන්පසු දුවන්න sudo docker system prune -a -f (නොහැරීම --වෙළුම් එබැවින් දත්ත සමුදා පරිමාවන් නොසැලී පවතී).

සේවාදායකය 100% තැටි භාවිතයේ පවතින අතරතුර මට වලාකුළු EBS / ස්ථීර තැටි පරිමාවක් සජීවීව පුළුල් කළ හැකිද?¶

ඔව්, සබැඳි වෙළුම් ප්‍රසාරණය නැවත පණගැන්වීමකින් තොරව ක්‍රියා කරයි, එක් අල්ලා ගැනීමක් සමඟ: උපකාරක පිටපත වර්ධනය /dev/nvme0n1 1 තුළ තාවකාලික ගොනුවක් සෑදීමට උත්සාහ කරයි /tmp භාවිතා කරමින් mktemp සහ නොමිලේ බයිට් 0 කින් අසමත් වේ. ධාවනය කිරීමෙන් එම අසාර්ථකත්වය මඟහරින්න sudo TMPDIR=/dev/shm growthpart /dev/nvme0n1 1 (RAM පිටුබලය භාවිතා කරමින් /dev/shm කන්ද) අනුගමනය කරයි sudo resize2fs /dev/nvme0n1p1 (ext4) හෝ sudo xfs_growfs / (XFS)

අදාළ මාර්ගෝපදේශ¶

• Linux, macOS, හෝ Windows මත අහඹු rm -rf හෝ Shift+Delete: වහාම කියවීමට පමණක් නැවත සවිකිරීම
• සංකේතනය කරන ලද SQLite, සංඥා සහ WhatsApp චැට් උපස්ථ දූෂණය සහ දේශීය යතුරු නිස්සාරණය
• දූෂිත Word, Excel, PDF, සහ දත්ත සමුදා ගොනුව සහ සුරකින ලද ලේඛන ප්රතිසාධනය
• SSD සහ NVMe හදිසි කියවීමට පමණක් ප්‍රකාරය, 0% අමතර කොටස්, සහ TRIM ගලවා ගැනීමේ අක්‍රිය
• වෙබ් සත්කාරක අර්බුදය, සංක්‍රමණය සහ උපස්ථ ප්‍රතිසාධනය
• රට අනුව හදිසි අංක

මූලාශ්ර සහ නිල මාර්ගෝපදේශ¶

• PostgreSQL ගෝලීය සංවර්ධන සමූහය: PostgreSQL 16 නිල ලේඛනගත කිරීම - 30 පරිච්ඡේදය: විශ්වසනීයත්වය සහ ලිවීමේ-ඉදිරි ලොගය (WAL වින්‍යාස කිරීම, අනුවර්තනය කිරීමේ කට්ට, සහ තැටි සම්පූර්ණ අසමත්වීම් වලින් ප්‍රතිසාධනය).
• SQLite Consortium (sqlite.org): SQLite දත්ත සමුදා ගොනුවක් දූෂිත කරන්නේ කෙසේද (ගොනු අගුලු දැමීම, සම්බන්ධ නොකළ ජර්නලය/WAL ගොනු, සහ .recover CLI දිගුව).
• Oracle Corporation / MySQL Documentation & MariaDB පදනම: *InnoDB බිඳ වැටීම් ප්‍රතිසාධනය, ද්විමය ලොග් පිරිසිදු කිරීමේ ක්‍රියා පටිපාටි (PURGE BINARY LOGS), සහ තාවකාලික මේස අවකාශය (ibtmp1) කළමනාකරණය *.
• ලිනක්ස් කර්නල් සංවිධානය (kernel.org): * Ext4 ගොනු පද්ධති පරිපාලනය (tune2fs වෙන් කළ කුට්ටි, ඉනෝඩ් වගු, සහ /proc/<pid>/fd/ ගොනු විස්තරය කප්පාදු කිරීම)*.
• ජාතික ප්‍රමිති සහ තාක්ෂණ ආයතනය (NIST) (එක්සත් ජනපදය): විශේෂ ප්‍රකාශනය 800-123: සාමාන්‍ය සේවාදායක ආරක්ෂාව සහ ලබා ගත හැකි කළමනාකරණය සඳහා මාර්ගෝපදේශය.