100% Puno (0 Byte nga Libre): Pagbawi sa Nahulog nga Database Han . rm ngan . apt Pakyas tungod han Kakulang hin mga Inode / Espasyo¶

Pagdiskobre nga an usa nga produksyon nga server han Linux in naigo . 100% paggamit han disk (0 bytes free) o . 100% paggamit han inode (df -i) samtang nagpapadalagan hin usa ka aktibo nga PostgreSQL, MySQL/InnoDB, MariaDB, o SQLite nga database in usa han mga pinakadelikado nga kapakyasan nga paagi ha pagdumara han mga sistema. Sa zero byte o zero libre nga inodes, ang krisis nag-cascade sa dagmit: ang operating sistema kernel dili na makahimo sa Unix domain sockets sa 2010. /tmp o /var/run, bash napapakyas ha pagtapos han tab tungod kay diri ini makakagsurat hin temporaryo nga mga tubo han shell, . apt o dnf diri makakadalagan ha paglimpyo han mga pakete tungod kay an mga tagdumara han pakete nagkikinahanglan hin temporaryo nga mga file han kandado, ngan an imo makina han database nabungkag ha butnga han usa nga Write-Ahead Log (WAL) checkpoint o nagdudumiri pagsara hin malimpyo tungod kay diri ini makakag-alutaga hin bisan usa nga 4 kilobyte (0.004 megabyte) nga bloke para han iya .pid o kandado nga file. Mas maraot pa gud, an nahahadlok nga mga administrador agsob dumalagan . rm -rf /var/log/*.log ha damu-ka-gigabyte nga mga file han troso ngan magkinita nga may kahadlok sugad han . df -h nagsusumat la gihap . 100% Use% (0 Avail), o ira makamaratay nga ginpapara . pg_wal (pg_xlog) o . ib_logfile0 ha paglibre hin espasyo, permanente nga pagdaot han database nga labaw pa han pagbawi han transaksyon. Kon aksidente mo nga ginpara an mga kritikal nga file han database durante han pagsari ha paglimpyo, undang dayon ngan balhin ha . aksidente nga rm -rf o Pagbalhin-Para an pagbasa-la nga pagbutang utro ngan inode nga pag-ukit .; kon an imo ilarom nga hardware han pagtipig naglalabog hin mga sayop han I/O o nag-lock ha iya kalugaringon kontra ha mga pagsurat, konsultaha . SSD ug NVMe tigda nga pagbasa-la nga paagi ug TRIM pag-abangdo sa pagluwas . o nadaot nga Word, Excel, PDF, ngan pagbawi han file han database .. Kon ini nga pagparong nakakaapekto ha mga sistema han katalwasan ha kinabuhi han ospital, pagpadara ha emerhensya, o kritikal nga mga pampubliko nga mga pagamit, tawagi ha iyo lokal nga numero han emerhensya (911 ha Estados Unidos ngan Canada, . 112 ha bug-os nga Unyon han Europa, . 999 ha Reino Unido) o kitaa an amon pankalibutan nga direktoryo han . mga numero han emerhensya.

Buhata ini yana .¶

1. AYAW pag-delete pg_wal/, pg_xlog/, pg_multixact/, ib_logfile*, undo_*, o -wal / -shm mga file para makahimo hin espasyo: An pagpara han mga file han log nga Write-Ahead Log o InnoDB pag-utro/pag-undo han mga file han log samtang an usa nga database in nabunggo o waray pag-tsek nga nagbubungkag han amo la nga rekord han mga pahina nga waray komiter ngan ha paglupad. An database nga may-ada bug-os nga disk 100 porsyento nga mababawi kon mahigawas na an espasyo; usa ka datos nga an mga file han WAL mano-mano nga ginpara gamit an . rm mag-aantos hin diri mababalik nga B-tree ngan tambak nga korapsyon.
2. Pag-eksamin ha sulod hin 5 ka segundo kon waray ka na mga bloke han disk (df -h), tikang ha mga inode han sistema han salin (df -i), o pagkapot hin abrido nga mga file nga waray sumpay ( ).lsof +L1):
3. Dalagan . df -h ha pag-usisa han kapasidad han bloke ngan . df -i ha pag-usisa han kapasidad han inode. An usa nga server nga may-ada 50 ka gigabyte (53.6 ka bilyon nga byte) han libre nga espasyo ha disk maglalabog pa gihapon . No space left on device (ENOSPC) kon df -i nagpapakita IUse% = 100% (kasagaran tungod han minilyon nga gudtiay nga mga file han sesyon, cache, o spool han koreo).
4. Kun . df -h nagpapakita 100% ginamit (0 Avail) bisan katapos mo dumalagan . rm ha dagko nga mga file han troso, dalagan . sudo lsof +L1. Bisan ano nga file nga ginpara nga may . rm samtang nginx, rsyslog, docker, postgres, o mysqld nagkakapot pa gihapon hin abrido nga file nga naghuhulagway nagpapadayon nga nag-uubos hin 100 porsyento han iya mga bloke han disk tubtob nga an proseso magtikang utro o imo direkta nga gin-uutod an naghuhulagway.
5. Libre nga mga gigabyte nga espasyo ha 1 ka segundo nga waray pagtikang utro han mga demonyo pinaagi han pag-utod han mga abrido nga mga file ha lugar (: > /path/to/logfile o : > /proc/<pid>/fd/<n>):
6. Imbes nga . rm /var/log/syslog (nga nagbibilin hin mga bloke nga nakatrangka han nagdadalagan nga logger), sero an file ha lugar gamit an shell null nga pagbalhin: sudo sh -c ': > /var/log/syslog' o sudo truncate -s 0 /var/log/syslog.
7. Kun nagdalagan ka na . rm ha daku nga file han troso ngan . df -h waray mahulog, bilnga an ID han proseso hini (PID) ngan paghulagway han salin ( ).FD) ha . sudo lsof +L1 ngan utdon ini hin diretso pinaagi han interfang han procfs han kernel: sudo sh -c ': > /proc/<PID>/fd/<FD>'. Mabalik an espasyo ha . df -h ha kadagmitan.
8. Abrihi an kadagmitan nga emerhensya nga kwarto han pagginhawa ha ext4 / ext3 pinaagi han pagpaubos han ginreserba nga porsyento han bloke han ugat ( ).tune2fs -m 1: Ha kasagaran, . ext4 nagrereserba hin 5 porsyento han bug-os nga partisyon (25 gigabytes ha usa nga 500 gigabyte disk) nga eksklusibo para ha . UID 0 (root), kahulogan nga diri-ugat nga mga serbisyo sugad han . postgres (UID 109), mysql, ngan . www-data maigo No space left on device ha 95 porsyento nga paggamit. Bawi an 80 porsyento hito nga reserba ha Internet ha sulod hin 1 ka segundo nga waray pag-undang pinaagi han pagdalagan . sudo tune2fs -m 1 /dev/sda1 (o an imo gamot nga bloke nga aparato tikang findmnt /).
9. **Bante systemd-journald binary nga mga troso ngan daan nga mga cache han pakete nga talwas **: Pagdalagan . sudo journalctl --vacuum-size=50M (nga talwas nga naglilibot ngan nagpupurga hin binary . /var/log/journal mga archive tubtob ha 50 nga megabyte) ngan . sudo apt-get clean (o sudo dnf clean all), nga nagpapara han mga gin-download . .deb / .rpm mga arkibo ha . /var/cache/apt/archives/ nga diri kinahanglan magsurat ha dpkg nga database.
10. **Kon diri maubos hin 1 ka gigabyte ngadto ha 5 ka gigabyte (1.07 bilyon ngadto ha 5.36 bilyon nga byte) nga espasyo in libre, dad-a an database ha igbaw ha single-user o recovery mode agud matapos an iya WAL checkpoint ugsa tugutan an trapiko han kliyente **: Pabay-i an PostgreSQL, MySQL/InnoDB, o SQLtehead nga mag-play utroWAL), i-flush an mahugaw nga mga pahina ngadto ha nangunguna nga mga file han datos, ngan utrohon hin malimpyo an mga nahubag nga mga bahin hito nga WAL antes abrihan utro an imo aplikasyon nga firewall o web server.

Puno hin desisyon: waray-espasyo nga server ngan nahulog nga pagpili han datos¶

Gamita ini nga puno han desisyon basi hibaroan kon kay ano nga an sistema han operasyon nagsusumat . ENOSPC (No space left on device) ngan pilia an eksakto nga diri nakakabungkag nga dalan han pagbawi:

flowchart TD
    Start["Server o Database nga Paglabog: Waray nahibilin nga espasyo ha aparato (ENOSPC)"] --> CheckDF["Pagdalagan: df -h NGAN df -i"]

    CheckDF --> DiagType{"Ano an Ginsusumat han df?"}

    DiagType -->|"df -h Nagpakita sa 100% Paggamit (0 Paggamit) NGAN df -i <95%"| BlockFull["Bloke nga Kapoy: Susiha kon du -shx / Katugbang df -h ."]
    DiagType -->|"df -h Nagpapakita hin Libre nga mga GB PERO df -i Nagpapakita hin 100% nga Paggamit"| InodeFull["Kapoy han Inode: Mga Minilyon nga Gudti nga 0-ngadto ha-4KB nga mga Pail"]
    DiagType -->|"Pareho nga df -h ngan df -i Ipakita < 90% Gingamit ."| RamOrQuota["Natago nga limitasyon: Susiha an df -h / tmp (tmpfs RAM nga puno), Docker Overlay2, o XFS / ext4 Disk Quota"]

    BlockFull --> GhostCheck{"Ginpadalagan mo na ba an rm ha Dagko nga mga File nga Waray df Paghulog?"}
    GhostCheck -->|"Oo: du Mas Gutiay Kaysa ha df"| UnlinkedFD["Pagdalagan: sudo lsof +L1 -> Pagputol han File han Aswang pinaagi ha :> / proc / PID / fd / FD"]
    GhostCheck -->|"Diri: An Tinuod nga mga File Nagpupuno han Disk ."| EmergencySpace["Paghimo hin Dayon nga Pagginhawa nga Kwarto (1 GB ngadto ha 5 GB)"]

    EmergencySpace --> Ext4Check{"Ext4 / ext3 ba an sistema han salin?"}
    Ext4Check -->|"Oo"| Tune2fs["Run: sudo tune2fs -m 1 / dev / root_dev (Dayon nga Naglibre 4% sa Disk alang sa Non-Root DB User)"]
    Ext4Check -->|"Waray (XFS / Btrfs / ZFS)"| TruncLogs["Pag-utod hin mga troso ha lugar (: > / var / troso / syslog) ngan Pagdalagan journalctl - bakante-kadako = 50M"]

    InodeFull --> InodeClean["Pagbiling hin Direktoryo nga mayda Milyon-milyon nga mga File Gamit hin find / -xdev -printf '%h\n' | pagklase | unik -c | pag-urusa -k 1 -r | ulo -20 -> Tangtangon nga may pagbiling -tangtangon ."]

    UnlinkedFD --> DBRecover["Padayon ha Database nga Makina WAL & B-Kahoy nga Pagbawi ."]
    Tune2fs --> DBRecover
    TruncLogs --> DBRecover
    InodeClean --> DBRecover
    RamOrQuota --> DBRecover

    DBRecover --> WhichDB{"Hain nga Makina han Database an Naaksidente?"}
    WhichDB -->|"Pag-uyon"| PGFlow["Tipigi an pg_wal nga diri maruba -> Tikangi an Postgres ha pag-utro han WAL -> Pagdalagan han CHECKPOINT; -> Ihulog nga Daan nga mga Slot han Pagkopya ."]
    WhichDB -->|"MySQL / MariaDB (InnoDB)"| MyFlow["Tipigi an ib_logfile * nga waray maruba -> Tikangi an mysqld -> Paglimpyo han Mga Binary nga Mga LOG pinaagi han Paglimpyo han Mga LOG han MGA BINARY -> Pag-optimize han mga Lamesa"]
    WhichDB -->|"SQLite3."| SqFlow["Back Up .db + .db-wal + .db-shm -> Pagdalagan PRAGMA wal_checkpoint (TRUNCATE) o sqlite3 broken.db '.pagbawi'"]

Hugna 1: Kay ano nga mga sumbanan nga mga sugo (rm, apt, tab-completion) mapakyas ha 0 nga mga byte nga libre .¶

Kon an usa nga partisyon han Linux umabot ha 100 porsyento nga pag-ulang o pag-ubos han inode, an mga sumbanan nga mga sugo ha pag-ayad napapakyas ha diri ginlalaoman nga mga paagi: - Pagpindot Tab ha bash naglalabog cannot create temp file for here-document: No space left on device: Moderno bash-completion mga iskrip maghimo hin temporaryo nga mga file ha . /tmp. Kun . /tmp naukoy ha gamot . / partisyon imbes nga usa nga . tmpfs RAM nga bukid, shell pagtapos ug . heredocs (<<EOF) kapakyasan. Ayuha dayon ini pinaagi hin pagtudlok . TMPDIR ngadto sa ginpaangbit nga panumduman RAM:

export TMPDIR=/dev/shm

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

An 5 nga magkalainlain nga hinungdan han . No space left on device (ENOSPC)¶

Antes kaptan an bisan ano nga mga file han database, itanding ini nga lima nga senaryo basi kumpirmahon kon ano nga rekurso an aktuwal nga naubos:

Hugna 2: Pagbawi hin espasyo ha disk nga talwas ha ubos hin 60 ka segundo¶

Sunda ini nga eksakto nga mga pitad agud mabawi an butnga han 500 ka megabyte ngan 50 ka gigabyte (0.53 bilyon ngadto ha 53.6 bilyon nga byte) hin espasyo nga diri nakakadaot han aktibo nga mga proseso:

Lakang 1: Pag-utod han bukas nga ginpara ("aswang") nga mga file pinaagi han . /proc/<pid>/fd/¶

Kun ikaw o in usa nga awtomatiko nga logrotate nga script in nagpara na hin dagko nga mga file pero waray mahibalik an espasyo han disk, kitaa an waray sumpay nga abrido nga file han 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'

Lakang 2: Pagbawi ext4 ginreserba nga mga bloke online nga may . tune2fs¶

Ha bisan ano nga . ext4 o ext3 filesystem, susiha an yana nga ginreserba nga bloke nga ihap:

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

sudo tune2fs -m 1 /dev/nvme0n1p1

Lakang 3: Pag-utod han aktibo nga mga troso han teksto ha lugar ngan pag-vacuum . journald¶

Bilnga an mga gidako-i nga mga salin ha ugat nga sistema han salin (pagpabilin ha pareho nga salin nga may . -xdev para diri ka mag-usik hin oras ha pag-scan . /proc o mga gawas nga mga bungtod):

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

Hugna 3: Pagbawi han PostgreSQL katapos han 100% nga puno nga disk (pg_wal paghubag)¶

Kun an usa nga PostgreSQL nga serbidor maubos hin espasyo ha disk, ini in nag-log . PANIC: could not write to file "pg_wal/xlogtemp.1234": No space left on device, ginpapaundang dayon an mga proseso han bata han koreo, ngan nadiri pagtikang.

Kay ano . pg_wal (pg_xlog sa PostgreSQL 9.6 ug mas daan) nagpupuno sa tibuok disk .¶

Sa normal nga operasyon, PostgreSQL nagsusurat sa matag pagbag-o ngadto sa 16 megabyte (16.7 milyones byte) nga bahin nga mga file sa sulod $PGDATA/pg_wal/ ngan gin-uutro ito katapos han kada . CHECKPOINT ha oras nga an sobra na . max_wal_size. Bisan pa man, an PostgreSQL gindidire ha pagpara o pag-utro han daan nga . pg_wal mga file ilarom han tulo nga kondisyon: 1. Usa nga ilo o naulangan nga Pisikal / Lohikal nga Slot han Pagkopya: Usa nga replika nga server (standby), konektor nga Debezium / Kafka, o . pg_receivewal kliyente nga naputol mga adlaw na an nakalabay, pero an iya pagkopya nga slot (pg_replication_slots) amo la gihapon an . active = false ha panguna, nga nagsusugo han PostgreSQL nga tipigan an kada usa nga WAL nga bahin nga nahimo tikang han pag-utod. 2. Usa nga kapakyasan archive_command: archive_mode = on gin-aktibo ha . postgresql.conf, ngan an backup nga iskrip ( ).pgBackRest, WAL-G, Barman, o aws s3 cp) in nagbabalik hin diri-sero nga kodigo hin paggawas (pananglitan, usa nga natapos nga S3 nga yawi o diri-maabot nga backup nga tagbalay). Gintitipigan han PostgreSQL an kada waray archibo nga WAL nga bahin ha 2019. pg_wal/ tubtob . archive_command mga balik 0. 3. ** Usa nga disk nga puno hin patay nga kandado **: pg_wal nagtubo tubtob han . 0 bytes nagpabilin ha . /var/lib/postgresql, ngan yana an PostgreSQL diri ngani makakagtikang ha paghulog han replikasyon nga slot o matapos an usa nga checkpoint tungod kay an pagtikang nga pagbawi mismo nagkikinahanglan hin pipira nga megabyte nga libre nga espasyo ha disk ha pagsurat hin temporaryo nga mga file han estado.

Lakang-ha-lakang PostgreSQL nga walay-lupas nga pagluwas (Waray nga Pagkawala sa Datos)¶

1. Paghimo hin 1 gigabyte ngadto ha 5 ka gigabyte (1.07 bilyon ngadto ha 5.36 bilyon nga byte) hin temporaryo nga espasyo ha gawas pg_wal/:
2. Una nga paggamit . sudo tune2fs -m 0 /dev/<partition> ug pagputol nga mga talaan hin teksto nga sistema / PostgreSQL (sudo truncate -s 0 /var/lib/postgresql/*/main/log/*.log o /var/log/postgresql/*.log).
3. Ano man kon an datos may-ada kalugaringon nga dedikado nga partisyon nga may zero nga mga talaan han teksto ngan XFS (salit tune2fs waray)? Ibalhin an 10 ngadto ha 20 han pinakadaan .ready o diri aktibo nga mga file tikang hin diri-WAL nga direktoryo, o ibalhin an . pg_wal direktoryo temporaryo ngadto ha lain nga partisyon nga may libre nga espasyo gamit an simboliko nga sumpay:

   # 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. Kun archive_command an napapakyas ngan nakakaulang ha pag-recycle han WAL, temporaryo nga lakyan ini ha 2019. postgresql.conf: Kun an imo S3/backup nga target in ubos ngan . pg_wal/archive_status/ may-ada yinukot nga . .ready mga file, pagliwat postgresql.conf (archive_command = '/bin/true') sugad la nga urhi nga emerhensya nga pitad basi diri mamatay an disk, nga maaram nga kinahanglan mo magkuha hin presko nga . pg_basebackup dayon katapos han pagbawi tungod kay an kadena han archive han WAL magkakaada gap.
5. ** Tikangi an PostgreSQL ngan susiha dayon an mga slot han pagkopya **: Tikangi an PostgreSQL (sudo systemctl start postgresql) ngan magsumpay pinaagi han . 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. Ihulog an bisan ano nga patay/diri aktibo nga slot han pagkopya nga nagtitirok hin mga gigabyte nga WAL: Kun mayda ka makita nga diri aktibo nga slot (active = f) nga nagkakapot hin 80 ka gigabyte nga . retained_wal:

   SELECT pg_drop_replication_slot('name_of_dead_slot');
   

7. Pwersa an kadagmitan . CHECKPOINT ha pag-recycle han nahubag . pg_wal mga bahin:

   CHECKPOINT;
   

   An takna . CHECKPOINT; natapos human ihulog sa patay nga slot, awtomatiko nga mag-unlink o mag-recycle ang gigabyte sa daan nga 16 megabyte nga bahin nga mga file sa 2019. pg_wal/, nga nagbabalik han imo paggamit han disk ha normal.
8. ** Pugngi an tidaraon nga pagkopya han slot nga disk nga kamatayon **: Ibutang max_slot_wal_keep_size ha postgresql.conf (magamit sa PostgreSQL 13+) ngadto sa talwas nga takup (sugad sa max_slot_wal_keep_size = 20GB) salit an PostgreSQL nagbabag-o han slot han usa nga patay nga replika imbes nga mag-crash han panguna nga database ha 0 nga mga byte nga libre.

Hugna 4: Pagbawi sa MySQL / MariaDB (InnoDB) ha 0 nga mga byte nga libre .¶

Kun an MySQL o MariaDB naigo . 100% paggamit han disk (/var/lib/mysql), An InnoDB nag-uundang han ngatanan nga pagsurat o pag-crash nga may . [ERROR] [MY-012640] [InnoDB] Error number 28 means 'No space left on device'.

Pagkilala kon ano an napuno . /var/lib/mysql¶

Dalagan . sudo du -sh /var/lib/mysql/* | sort -hr | head -n 15 basi makita kon hin-o hinin upat nga salaan an nag-ubos han disk: 1. ** Waray Tubtuban nga Binary nga mga Log (binlog.000001, mysql-bin.000042**: Ha kasagaran ha MySQL 8.0+, an duha nga pag-log in gin-aktibo nga may 30-ka-adlaw nga pagtipig (binlog_expire_logs_seconds = 2592000), nga madali makahimo hin ginatos nga mga gigabyte nga mga panhitabo ha laray durante han kadamo nga pag-import. 2. Usa nga pinalagiw nga pakiana nga nagsusurat hin higante nga temporaryo nga mga lamesa (#sql* o ibtmp1): Usa nga dako nga GROUP BY o ORDER BY ginpuno an pakiana ibtmp1 o /tmp/#sql_* tubtob nga an disk umabot ha 0 nga byte. 3. **Usa nga bato ibdata1 sistema nga espasyo han lamesa paghubag **: Kun . innodb_file_per_table nabaldado o maiha na nga mga transaksyon nagpugong han listahan han kasaysayan han InnoDB (ibalik an mga talaan ha sulod ibdata1 o undo_001) tikang ha pagpurga. 4. MySQL hinay nga pakiana nga talan o sayop nga talan (/var/log/mysql/mysql-slow.log).

Lakang-lakang MySQL / MariaDB zero-espasyo pagluwas .¶

1. AYAW GUD pagpara ibdata1, ib_logfile0, ib_logfile1, #innodb_redo/*, o undo_001 nga may rm: An pagpara han bisan hain hini nga mga file nakakahimo han kada . .ibd file han lamesa ha imo database nga diri mababasa.
2. Libre nga inisyal nga pagtikang nga espasyo (500 megabyte ngadto ha 2 gigabyte):
3. Pag-utod /var/log/mysql/error.log ngan . mysql-slow.log pinaagi sudo truncate -s 0 /var/log/mysql/*.log.
4. On ext4, pagdalagan . sudo tune2fs -m 1 /dev/<partition>.
5. Kun . mysqld ha pagkayana in gin-undang ngan . /var/lib/mysql/ibtmp1 (an diri-ginpipirit nga temporaryo nga espasyo han lamesa) daku, . ibtmp1 awtomatiko nga ginhihimo utro ha pagtikang, o mahimo mo ibalhin an pinakadaan nga duha o tulo nga binary nga mga troso (binlog.000001, binlog.000002 - waray gud an pinakahitaas nga numero nga aktibo nga binlog) ngadto ha . /dev/shm temporaryo nga sugad . mysqld pwede boot.
6. ** Tikangi an MySQL ngan limpyohi an binary nga mga troso hin talwas gamit an SQL (PURGE BINARY LOGS)**: Kay ano nga kinahanglan mo gamiton an SQL imbes nga . rm /var/lib/mysql/binlog.*? Tungod kay an MySQL nagsusubay han kada ngaran han salin han binary nga log ha . binlog.index. Kon imo papason an mga binary nga mga troso nga may . rm nga waray pag-update . binlog.index, An MySQL magdudumiri pagtikang o an pagkopya in mabubungkag. Makausa . mysqld nagtitikang, pagsulod (sudo mysql) ngan pagdalagan:

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

   (O limpyohi an ngatanan tubtob ha yana nga aktibo nga log file nga iginpapakita ha ubos han . SHOW BINARY LOGS; gamit an PURGE BINARY LOGS TO 'binlog.000085';)
7. Ibutang an permanente nga binary nga kadako han troso ngan pagtipig nga takup ha . /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
   

   Pagtakop ibtmp1 ha max:5G nagsisiguro nga an usa nga paralimbong waray indeks . JOIN o ORDER BY an pakiana napapakyas ha usa nga . table is full sayop imbes nga magpahaluag . ibtmp1 tubtob nga an bug-os nga Linux nga server mamatay ha 0 nga byte nga libre.

Hugna 5: Pagbawi sa nadaot nga SQLite3 nga datos (database or disk is full / SQLITE_FULL / malformed)¶

Mga nakasulod nga aplikasyon, mga surudlan han Docker (Nextcloud, Vaultwarden, Home Assistant, Plex, Grafana, Gitea), ug mga serbisyo sa mobile / desktop nasalig sa SQLite3. Kon an usa nga disk naigo hin 0 nga mga byte nga libre samtang an SQLite aada ha butnga han usa nga pag-ibalik han journal o usa nga Pagsurat-Unahan nga Log (-wal) checkpoint, makakatapo ka hin usa han duha nga emerhensya: 1. **Dako .db-wal file paghubag ** (ang .db-wal file nga nagtubo ngadto ha 10 ka gigabyte samtang an . .db file in 200 megabytes lamang, tungod kay an maiha na nga mga magbarasa nagpugong hin diri aktibo nga WAL checkpoint, ngan yana an disk 100 porsyento na nga puno). 2. RuntimeError: database disk image is malformed (SQLITE_CORRUPT) dara han guba nga higamit . fsync(), usa nga surudlan nga ginpatay ha butnga han pagbalik ha 0 nga byte nga libre, o usa nga tawo nga nagpapara han . -wal o -journal file pinaagi han kamot.

Lakang 1: Pag-ubos han usa nga hubag . .db-wal file ngan pag-vacuum han SQLite kon an espasyo ha disk harani na ha zero .¶

1. Hunong sa surudlan sa aplikasyon o serbisyo nga nagpupugong sa SQLite nga datos nga abrido ( ).sudo systemctl stop app o docker stop container_name).
2. Kopyaha app.db, app.db-wal, ngan . app.db-shm ngadto ha usa nga partisyon o gawas nga drive nga may-ada damu nga libre nga espasyo (o libre nga 2x an kadaku han 100). app.db ha lokal nga disk una).
3. Abrihi an database gamit an . sqlite3 CLI ngan piriton an pag-utod han WAL nga pag-usisa, nga nagpipilo han ngatanan nga ginkomiter nga mga bayanan tikang ha . app.db-wal ngadto ha app.db ngan nagtitikaguti . app.db-wal ngadto ha 0 nga mga byte:

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

4. Pag-usisa han B-puno ngan libre nga listahan han integridad han istraktura:

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

   Kun mag-iimprinta . ok, an imo database 100 porsyento nga mahimsog.
5. **Paonan-o VACUUM usa ka dako nga SQLite nga datos kon ang lokal nga disk walay igo nga libre nga espasyo **: Sumbanan VACUUM; nagkikinahanglan hin tubtob 2x an kadako han datos ha libre nga espasyo ha disk ha pareho nga partisyon ngan . /var/tmp. Lugod, gamita an . VACUUM INTO (ginpakilala ha SQLite 3.27.0) ha pagsurat hin bag-o nga gin-ipit, gin-utod nga kopya direkta ngadto hin bulag nga ginbutang nga disk o pag-angbit hin network:

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

Lakang 2: Pagluwas hin nadaot nga B-nga puno (database disk image is malformed) nga may . .recover¶

Kun . PRAGMA integrity_check; mga taho row 412 missing from index, btreeInitPage() returns error code 11, o database disk image is malformed:

1. Una nga sarihi an pagtukod utro han mga naruba nga ikaduha nga mga indeks (REINDEX): Agsob nga an aktuwal nga datos han lamesa (table B-trees) 100 porsyento nga waray maruba ngan usa la nga ikaduha nga indeks B-nga puno an nadaot han napuno an disk. Pagdalagan:

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

   Kun . PRAGMA integrity_check; yana nabalik ok, nabawi mo an 100 porsyento han imo database nga waray nawara nga mga laray.
2. Kun REINDEX napapakyas, padalagan ang forensiko nga B-kahoy nga scanner (.recover): Diri sugad han mas edaran . .dump sugo (nga naundang ha pag-eksport hin lamesa ha takna nga naigo ini hin nadaot nga B-nga puno nga tudlo), . .recover (gintukod ha sqlite3 bersyon 3.29.0+) nalabay hin bug-os an mga nadaot nga sulod nga B-tree pointers, gin-i-scan an kada hilaw nga 4 kilobyte nga pakli han dahon han file hin sunod-sunod tikang ha byte 0 ngadto ha EOF, gintutukod utro an kada mababasa nga laray, ngan ginbubutang an bisan ano nga mga ilo nga mga rekord ngadto hin usa nga . lost_and_found lamesa:

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

3. Pag-verify han bag-o nga ginhimo utro nga datos:

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

   Susiha kon an usa nga . lost_and_found ginhimo an lamesa (sqlite3 /mnt/external_usb/repaired_app.db ".tables") ha pag-usisa han bisan ano nga mga ilo nga laray nga narekober tikang ha waray sumpay nga mga pahina han dahon. Alang sa encrypted SQLCipher nga mga databases (sugad sa Signal o WhatsApp backups), tan-awa ang among dedicated guide sa encrypted SQLite, Signal, ug WhatsApp chat backup korapsyon ug lokal nga pagkuha sa yawi ..

Hugna 6: Emerhensya nga "Tripwire Ballast File" & pagbantay paglikay nga listahan¶

Kun an imo server ngan database in balik na ha online, ipatuman dayon ini nga upat nga panalipod basi diri ka na gud ma-trap ha 0 bytes nga libre utro:

• **Paghimo hin 1 nga gigabyte (1,073,741,824 byte) Emerhensya nga Balast nga File sa matag partisyon sa datos **: Pagdalagan . sudo fallocate -l 1G /var/lib/EMERGENCY_DELETE_ME.ballast. Kun an server in maigo gud . 100% disk nga puno, nagdadalagan . sudo rm /var/lib/EMERGENCY_DELETE_ME.ballast naglilibre hin 1 ka gigabyte nga magkasumpay nga mga bloke ha 1 ka milisegundo.
• **Kalo systemd-journald ngan mga talaan han Docker nga surudlan hin permanente **: Ibutang . SystemMaxUse=200M ha /etc/systemd/journald.conf ngan pag-configure . /etc/docker/daemon.json nga may "log-opts": {"max-size": "20m", "max-file": "3"}.
• **Ibulag /var/log, /tmp, ngan . /var/lib/postgresql ngadto ha bulag nga mga tomo han LVM **: Pagtipig . /var/log ngan . /tmp bulag tikang ha mga kadamo han datos nga datos nagsisiguro nga an usa nga pinalagiw nga web log diri gud nabungkag han datos nga datos o nagtratrangka han mga login han SSH.
• **Pahimatngon ha PAREHO df -h (> 80%) NGAN . df -i (> 80%) dugang pg_replication_slots lag **: Pag-andam han pagbantay (node_filesystem_avail_bytes ngan . node_filesystem_files_free) nga mag-alerto antes umabot ha 85 porsyento an paggamit.

Mga numero han emerhensya ha rehiyon ngan mga patakaran han ahensya¶

Samtang an bug-os nga disk han server kasagaran nga usa nga emerhensya ha mga operasyon han IT ha sulod, an usa nga pag-undang nga nakakaapekto ha pag-ataman han kahimsog Elektroniko nga Rekord han Kahimsog (EHR) mga datos, emerhensya nga pagpadara (CAD), telemetry han tubig/kuryente han munisipyo, o pagkaada hin personal nga datos han balaud mahimo magkinahanglan hin pormal nga pag-uswag han emerhensya:

• Estados Unidos ug Kanada: Pagtawag 911 kun an usa nga pag-crash han server in nagpapa-aktibo han klinikal nga pagbantay o pagpadara, ngan nagpapa-aktibo han mga pamaagi han pag-undang. Igreport an kritikal nga imprastraktura nga rekurso-kaubos o mga pag-atake ha ransomware ngadto ha CISA (1-844-Say-CISA / cisa.gov/report) o an Sentro han Kanada para han Seguridad ha Internet (1-833-CYBER-88).
• Nagkaurosa nga Ginhadian: Pagtawag 999 para han mga tarhug ha kinabuhi o kritikal nga mga sistema han NHS. Ubos sa UK GDPR ug Mga Balaod sa NIS, pag-usisa kon ang permanente nga pagkawara sa pagkaada sa database nagkikinahanglan og pagpahibalo ngadto sa ICO (0303 123 1113) ha sulod hin 72 ka oras.
• Unyon han Europa: Pagtawag 112 ha bug-os nga ngatanan nga mga estado nga miyembro han EU. An mga importante nga mga entidad ilarum han NIS2 Directive in kinahanglan magpahibaro han ira nasyunal nga CSIRT ha sakob han 24 ka oras han mahinungdanon nga pagparong, ngan an permanente nga pagkawara han personal nga datos nga waray backup recovery nag-aaghat han GDPR Artikulo 33 nga pagreport ha sakob han 72 ka oras.
• Australia ug New Zealand: Dial 000 ha Australia o 111 ha Nueva Zelanda; pakigsumpayan ha ACSC (1300 CYBER1) para han mga insidente ha imprastraktura.
• Indya ug Asya-Pasipiko: Dial 112 para han emerhensya nga pagbaton; igreport an mga pagparong tungod han cyber ngadto ha CERT-In (incident@cert-in.org.in) ha sakob han obligado nga 6-oras nga bintana.

Agsob igpakiana .¶

Kay ano nga . df -h magpabilin ha 100% (0 Avail) bisan katapos ko paraon an 50 GB nga log file nga may . rm?¶

Ha mga sistema hin file han Linux, . rm mga tawag la kuhaa an sumpay (), pagkuha han ngaran han salin tikang han direktoryo samtang an kernel nagtitipig han mga bloke han disk nga igin-alutaga tubtob nga an tagsa nga proseso nga nagpupugong hito nga salin nga abrido magsara han iya paghulagway han salin (ako_pag-ihap == 0). Dalagan . sudo lsof +L1. para mabilngan an ID han Proseso (PID) ngan Paghulagway han Sail ( ).FD) han . (ginpara) file, katapos padalagana . sudo sh -c ': > / proc / PID / fd / FD''. para ma-zero dayon an mga bloke ha lugar nga diri na utro nga gintitikangan an serbisyo.

Ano man kun diri ngani ako makakag-SSH ha server tungod kay . /tmp o /var/run amo an 100% nga puno ngan . sshd nadiri pag-alutaga hin sesyon?¶

Una sarihi an pagpatuman hin diri-PTY direkta nga sugo ha SSH nga waray pag-alutaga hin interaktibo nga peke nga terminal: ssh -T root@server "sh -c ': > /var/log/syslog'". Kun . gamot login in disabled, gamiton ang imong cloud provider's out-of-band serial console (AWS EC2 Serial Console, DigitalOcean Console, Linode Lish, o Proxmox / VMware VNC) sa pag-log in direkta sa ttyS0. o mag-boot ngadto ha usa nga gumaramit nga pagbawi nga paagi.

Mayda na nagpara hin mga file ha sulod han PostgreSQL pg_wal direktoryo ugsa basahon ini nga giya, ngan yana nagdudumiri an PostgreSQL nga magtikang ha . PANIC: could not locate a valid checkpoint record. Nawara ba an ngatanan nga datos?¶

Diri, kadam-an han mga laray han lamesa aada pa ha sulod . $ PGDATA / base /, bisan kon an mga transaksyon ha paglupad ha sulod han ginpara nga mga file han WAL nawawara ngan an pipira nga mga pahina bangin maggisi. Paghimo anay hin bug-os nga kopya han bug-os nga . $ PGDATOS direktoryo (cp -a / var / lib / postgresql / 16 / panguna / mnt / backup / pgdata_law). Katapos dumalagan . sudo -u postgres / usr / lib / postgresql / 16 / bin / pg_resetwal -f / var / lib / postgresql / 16 / panguna, tikangi an PostgreSQL ha uusa nga gumaramit nga paagi, ngan dayon dalagan . pg_bayaan ngadto hin bag-o nga gintikangan (pagtikang) kumpol; ayaw gud pagpadayon ha pagdalagan han trapiko han produksyon ha usa nga grupo katapos han . pg_pagbalik.

Paonan-o ko papason an minilyon nga gudtiay nga file kon . rm -rf nabitay o napapakyas ha usa nga inode-naubos (df -i 100%) nga serbidor?¶

Kon an usa nga direktoryo may-ada minilyon nga gudtiay nga mga file han sesyon o cache, an indeks han direktoryo hito (hpuno) nagtutubo nga daku, nga nagigin hinungdan han . ls ngan . rm -rf ha pag-undang han pag-urusa han mga ngaran han file ha RAM. Lugod, dumalagan . sudo pagbiling / dalan / ngadto / milyon_nga mga file -hunahuna nga kahilarom 1 -pabura, o paghimo hin waray sulod nga direktoryo han RAM ( ).mkdir / dev / shm / waray sulod) ngan dumalagan . sudo rsync -a --para / dev / shm / waray sulod / / dalan / ngadto / milyon_nga mga file / ha pag-unlink hin mga inode hin madagmit.

Kay ano nga ginpuno han Docker an akon bug-os nga disk han server samtang an akon mga surudlan mismo gutiay, ngan paonan-o ko malilimpyohan . /var/lib/docker talwas?¶

An Docker nagtitirok hin espasyo ha disk ha waray pagtuyok nga JSON stdout nga mga talaan (/var/lib/docker/mga surudlan/*/*-json.log), nga nagbibitay . pagtabon2. mga sapaw han imahe, ngan cache han pagtukod. Ayaw gud mano-mano . rm -rf mga folder ha sulod . / var / lib / doktor / pagtabon2 /. Una pag-utod han mga JSON nga mga talaan (sudo truncate -s 0 / var / lib / docker / containers / * / * -json.log) salit an demonyo may-ada kwarto ha pagginhawa, katapos dumalagan . sudo docker sistema prune -a -f (pagkuha --mga tomo salit an mga tomo han datos nagpapabilin nga waray kaptan).

Mahimo ko ba pagpahaluag hin dampog nga EBS / nagpapadayon nga disk nga kadamo nga buhi samtang an server aada ha 100% nga paggamit han disk?¶

Oo, an online nga pagpahaluag han kadamu nagtrabaho nga waray pag-utro, nga may usa nga dakop: an kabulig nga iskrip . pagtubo nga bahin / dev / nvme0n1 1 naniningkamot paghimo hin temporaryo nga fayl ha . /tmp gamit an pagsari ngan napapakyas ha 0 nga byte nga libre. Labay ito nga kapakyasan pinaagi han pagdalagan . sudo TMPDIR = / dev / shm growpart / dev / nvme0n1 1 (gamit an RAM-nga ginsusuportahan / dev / shm bukid) nga ginsundan han . sudo pagbag-o han kadako2fs / dev / nvme0n1p1 (ext4.) o . sudo xfs_mga tumubo / (XFS).

Mga may kalabutan nga giya .¶

• Aksidente nga rm -rf o Bilhin+Para ha Linux, macOS, o Windows: kadagmitan nga pagbasa-la nga pagbutang utro
• Encrypted SQLite, Sinyales, ug WhatsApp chat backup korapsyon ug lokal nga pagkuha sa yawi .
• Nadaot nga Word, Excel, PDF, ngan database nga file ngan waray nakatalwas nga pagbawi han dokumento
• SSD ug NVMe tigda nga pagbasa-la nga paagi, 0% nga ekstra nga mga bloke, ug TRIM nga pagluwas .
• Krisis han pag-abiabi han web, pagbalhin, ngan pagpahiuli han backup
• Mga numero han emerhensya pinaagi han nasud

Mga surok ngan opisyal nga giya .¶

• Opisyal nga Dokumento - Kapitulo 30: Pagkasaligan ug ang Pagsurat-Unahan nga Log (WAL nga Pag-andam, Mga Slot sa Pagkopya, ug Pagbawi Tikang sa Disk nga Bug-os nga mga Kapakyasan) *.
• SQLite nga Katig-uban (sqlite.org): *Paonan-o Madadaot an Usa nga Pail han Datos han SQLite (Pagtrangka han Pail, Mga Pail nga Waray Sumpay nga Journal / WAL, ngan an .recover CLI nga Pagpahilawig) *.
• Oracle Corporation / MySQL Dokumentasyon & MariaDB Pundasyon: * InnoDB Crash Recovery, Binary Log Purge Mga Pamaagi (PURGE BINARY LOGS), ngan Temporaryo nga Lamesa ( ).ibtmp1) Pagdumala*.
• An Linux nga Organisasyon (kernel.org): * Pagdumara han Sistema han Salin han Ext4 (tune2fs Mga Reserbado nga Bloke, mga Lamesa han Inode, ngan . /proc/<pid>/fd/ Pagputol han Paghulagway han File) *.
• Nasodnon nga Instituto sa mga Sumbanan ug Teknolohiya (NIST) (Estados Unidos): Espesyal nga Publikasyon 800-123: Giya ha Kabug-osan nga Seguridad ngan Pagdumara han Pagkaada han Server.