☰

PostgreSQL 8.1 se quedó sin espacio y se detuvo, el directorio de datos está vacío

tag-icon • tag-icon linux postgresql disk-space-utilization gentoo data-recovery
PostgreSQL 8.1 se quedó sin espacio y se detuvo, el directorio de datos está vacío

Utilicé PostgreSQL 8.1 en Gentoo/Linux 2.6.14r5. El espacio en disco de mi servidor de base de datos se ve a continuación:

db postgresql # df -l
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda3              9775248   2018528   7756720  21% /
udev                   1557872        88   1557784   1% /dev
shm                    1557872         0   1557872   0% /dev/shm
/dev/sda4            281096760 244270836  36825924  87% /var/lib/postgresql
/dev/sdb1            961402192 244780080 667785712  27% /mnt/sdb1

No puedo reiniciar ./etc/init.d/postgresql porque los datos del subdirectorio en /var/lib/postgresql están vacíos. PostgreSQL8.1 se actualizó desde 8.0, por lo que hay un archivo data.old en /var/lib/postgresql. Cuando ejecuto 'du -b', el resultado es el siguiente:

     postgresql # du -b
471     ./.ssh
580     ./data
7697    ./paul/Fifthwindow-RogersBuck
19673   ./paul/Fifthwindow-Tattoo/Output
20633   ./paul/Fifthwindow-Tattoo
13762   ./paul/Fifthwindow-Beard/Output
14493   ./paul/Fifthwindow-Beard
3036    ./paul/Fifthwindow-Touch1/Output
10789   ./paul/Fifthwindow-Touch1
56931   ./paul
3624120 ./data.old/base/1
3624120 ./data.old/base/10792
3624120 ./data.old/base/10793
48      ./data.old/base/16394/pgsql_tmp
248802448893    ./data.old/base/16394
48      ./data.old/base/backup
248813321469    ./data.old/base
11370   ./data.old/paul/output_files
14332   ./data.old/paul
122952  ./data.old/pg_subtrans
48      ./data.old/pg_twophase
57416   ./data.old/pg_multixact/members
49224   ./data.old/pg_multixact/offsets
106736  ./data.old/pg_multixact
4880603 ./data.old/global
316494192       ./data.old/pg_clog
48      ./data.old/pg_xlog/archive_status
536872320       ./data.old/pg_xlog
48      ./data.old/pg_tblspc
249678076379    ./data.old
27023   ./scripts/cron/daily
917     ./scripts/cron/weekly
28036   ./scripts/cron
861     ./scripts/runOnce
599794  ./scripts/manual
628811  ./scripts
171463723       ./output
249850258001    .

Cuando ejecuto 'pg_dump -h my.host.ip.0 -p 5432 -U postgres -F t -b -v -f "/some/directory/backup.file" mydb', el mensaje aparece a continuación:

pg_dump: dumping contents of table _selections_by_content_last30days
pg_dump: dumping contents of table _selections_by_content_last365days
pg_dump: dumping contents of table actionlog
pg_dump: ERROR:  could not count blocks of relation 1663/16394/17943: No such file or directory
pg_dump: SQL command to dump the contents of table "actionlog" failed: PQendcopy() failed.
pg_dump: Error message from server: ERROR:  could not count blocks of relation 1663/16394/17943: No such file or directory
pg_dump: The command was: COPY public.actionlog (eventdetail, eventdatetime, eventtypeid, consoleid, albumid, trackid, sequenceid, sessionid, contentid, actionlogid, fileid) TO stdout;
pg_dump: *** aborted because of error

¡por favor, ayúdame! ¡Cualquier idea será apreciada!

¡Gracias!

Respuesta1

Finalmente, lo descubrí. Esto se debe a que la carpeta de partición del disco 1663/16394/17943estaba en otro controlador físico. Así que primero tuve que montarlo y luego hice el siguiente paso.

Ese era un sistema muy antiguo. Afortunadamente ya no tuve que cuidarlo.

Respuesta2

¿Se podía acceder a su servidor Postgres desde Internet? Recientemente se publicó una vulnerabilidad de Postgres, pero la versión 8.1 no es compatible desde 2010, por lo que no recibió actualizaciones de seguridad. Usar esta versión no es razonable si el proveedor de su sistema operativo no proporciona actualizaciones respaldadas, como por ejemplo lo hacen RHEL5 o CentOS5. El kernel de su sistema operativo es de aproximadamente 2006. ¿Su sistema operativo todavía recibe actualizaciones de seguridad?

Parece que su sistema se vio comprometido y todos sus datos simplemente se eliminaron. Si no tiene copias de seguridad, supongo que es irrecuperable (es decir, para simples mortales). Si su servidor de base de datos todavía está ejecutándose, puede intentar volcar datos de tablas individuales; parece que _selections_by_content_last30daysse _selections_by_content_last30daysvolcó exitosamente, pero actionlogla tabla no. Si su base de datos aún se está ejecutando, es posible que tenga algunos archivos abiertos que se eliminaron pero que en realidad no se liberarán hasta que se detenga; es posible que haya algunos datos recuperables allí.

Los datos de la versión anterior 8.0 aún se pueden recuperar, pero es una operación complicada, ya que necesitarás compilar e instalar la versión anterior o postgres para acceder a ellos. Es mejor hacer esto en otro servidor: ¡cópielo en un lugar seguro lo antes posible!

información relacionada