El espacio en disco es un recurso exigente hoy en día. Por lo general, deseará almacenar datos el mayor tiempo posible, pero esto podría ser un problema si no toma las medidas necesarias para evitar un posible problema de "falta de espacio en disco".
En este blog, veremos cómo podemos detectar este problema para PostgreSQL, prevenirlo y, si es demasiado tarde, algunas opciones que probablemente lo ayuden a solucionarlo.
Cómo identificar problemas de espacio en disco de PostgreSQL
Si, lamentablemente, se encuentra en esta situación de falta de espacio en disco, podrá ver algunos errores en los registros de la base de datos de PostgreSQL:
2020-02-20 19:18:18.131 UTC [4400] LOG: could not close temporary statistics file "pg_stat_tmp/global.tmp": No space left on deviceo incluso en el registro de su sistema:
Feb 20 19:29:26 blog-pg1 rsyslogd: imjournal: fclose() failed for path: '/var/lib/rsyslog/imjournal.state.tmp': No space left on device [v8.24.0-41.el7_7.2 try http://www.rsyslog.com/e/2027 ]PostgreSQL puede continuar funcionando durante un tiempo ejecutando consultas de solo lectura, pero eventualmente fallará al intentar escribir en el disco, luego verá algo como esto en la sesión de su cliente:
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and repeat your command.
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.Entonces, si observa el espacio en disco, tendrá esta salida no deseada...
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/pve-vm--125--disk--0 30G 30G 0 100% /Cómo prevenir problemas de espacio en disco de PostgreSQL
La forma principal de prevenir este tipo de problema es monitorear el uso del espacio en disco y el crecimiento del uso de la base de datos o del disco. Para esto, un gráfico debería ser una forma amigable de monitorear el incremento de espacio en disco:
Y lo mismo para el crecimiento de la base de datos:
Otra cosa importante para monitorear es el estado de replicación. Si tiene una réplica y, por alguna razón, esta deja de funcionar, dependiendo de la configuración, es posible que PostgreSQL almacene todos los archivos WAL para restaurar la réplica cuando vuelva.
Todo este sistema de monitoreo no tiene sentido sin un sistema de alerta para saber cuando necesita tomar medidas:
Cómo solucionar problemas de espacio en disco de PostgreSQL
Bueno, si se enfrenta a este problema de falta de espacio en disco incluso con el sistema de vigilancia y alerta implementado (o no), hay muchas opciones para tratar de solucionar este problema sin pérdida de datos (o al menos como sea posible).
¿Qué está consumiendo su espacio en disco?
El primer paso debe ser determinar dónde está mi espacio en disco. Una mejor práctica es tener particiones separadas, al menos una partición separada para el almacenamiento de su base de datos, para que pueda confirmar fácilmente si su base de datos o su sistema está usando demasiado espacio en disco. Otra ventaja de esto es minimizar el daño. Si su partición raíz está llena, su base de datos aún puede escribir en su propia partición sin problemas.
Uso del espacio de la base de datos
Veamos ahora algunos comandos útiles para comprobar el uso del espacio en disco de la base de datos.
Una forma básica de verificar el uso del espacio de la base de datos es verificar el directorio de datos en el sistema de archivos:
$ du -sh /var/lib/pgsql/11/data/
819M /var/lib/pgsql/11/data/O si tiene una partición separada para su directorio de datos, puede usar df -h directamente.
El comando PostgreSQL “\l+” enumera las bases de datos agregando la información de tamaño:
$ postgres=# \l+
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges | Size | Tablespace
| Description
-----------+----------+-----------+---------+-------+-----------------------+---------+------------
+--------------------------------------------
postgres | postgres | SQL_ASCII | C | C | | 7965 kB | pg_default
| default administrative connection database
template0 | postgres | SQL_ASCII | C | C | =c/postgres +| 7817 kB | pg_default
| unmodifiable empty database
| | | | | postgres=CTc/postgres | |
|
template1 | postgres | SQL_ASCII | C | C | =c/postgres +| 7817 kB | pg_default
| default template for new databases
| | | | | postgres=CTc/postgres | |
|
world | postgres | SQL_ASCII | C | C | | 8629 kB | pg_default
|
(4 rows)Usando pg_database_size y el nombre de la base de datos, puede ver el tamaño de la base de datos:
postgres=# SELECT pg_database_size('world');
pg_database_size
------------------
8835743
(1 row)Y usar pg_size_pretty para ver este valor de una manera legible por humanos podría ser aún mejor:
postgres=# SELECT pg_size_pretty(pg_database_size('world'));
pg_size_pretty
----------------
8629 kB
(1 row)Cuando sepa dónde está el espacio, puede tomar las medidas correspondientes para solucionarlo. Tenga en cuenta que solo eliminar filas no es suficiente para recuperar el espacio en disco, deberá ejecutar VACUUM o VACUUM FULL para finalizar la tarea.
Archivos de registro
La forma más sencilla de recuperar espacio en disco es eliminando los archivos de registro. Puede consultar el directorio de registro de PostgreSQL o incluso los registros del sistema para verificar si puede ganar algo de espacio desde allí. Si tienes algo como esto:
$ du -sh /var/lib/pgsql/11/data/log/
18G /var/lib/pgsql/11/data/log/Debe verificar el contenido del directorio para ver si hay un problema de rotación/retención de registros o algo está sucediendo en su base de datos y escribirlo en los registros.
$ ls -lah /var/lib/pgsql/11/data/log/
total 18G
drwx------ 2 postgres postgres 4.0K Feb 21 00:00 .
drwx------ 21 postgres postgres 4.0K Feb 21 00:00 ..
-rw------- 1 postgres postgres 18G Feb 21 14:46 postgresql-Fri.log
-rw------- 1 postgres postgres 9.3K Feb 20 22:52 postgresql-Thu.log
-rw------- 1 postgres postgres 3.3K Feb 19 22:36 postgresql-Wed.logAntes de eliminar los registros, si tiene uno enorme, una buena práctica es conservar las últimas 100 líneas y luego eliminarlo. Por lo tanto, puede verificar qué sucede después de generar espacio libre.
$ tail -100 postgresql-Fri.log > /tmp/log_temp.logY luego:
$ cat /dev/null > /var/lib/pgsql/11/data/log/postgresql-Fri.logSi simplemente lo elimina con "rm" y el archivo de registro está siendo utilizado por el servidor PostgreSQL (u otro servicio), el espacio no se liberará, por lo que debe truncar este archivo usando este cat / comando dev/null en su lugar.
Esta acción es solo para PostgreSQL y archivos de registro del sistema. No elimine el contenido de pg_wal u otro archivo de PostgreSQL, ya que podría generar un daño crítico a su base de datos.
Inflar
En una operación normal de PostgreSQL, las tuplas eliminadas u obsoletas por una actualización no se eliminan físicamente de la tabla; están presentes hasta que se realiza un VACÍO. Por lo tanto, es necesario hacer el VACUUM periódicamente (AUTOVACUUM), especialmente en las tablas que se actualizan con frecuencia.
El problema aquí es que el espacio no se devuelve al sistema operativo usando solo VACUUM, solo está disponible para usar en la misma tabla.
VACUUM FULL reescribe la tabla en un nuevo archivo de disco, devolviendo el espacio no utilizado al sistema operativo. Desafortunadamente, requiere un bloqueo exclusivo en cada mesa mientras se ejecuta.
Debe consultar las tablas para ver si se requiere un proceso VACÍO (COMPLETO).
Ranuras de replicación
Si está utilizando espacios de replicación y no está activo por algún motivo:
postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;
slot_name | slot_type | active
-----------+-----------+--------
slot1 | physical | f
(1 row)Podría ser un problema para su espacio en disco porque almacenará los archivos WAL hasta que todos los nodos en espera los hayan recibido.
La forma de solucionarlo es recuperando la réplica (si es posible), o borrando el slot:
postgres=# SELECT pg_drop_replication_slot('slot1');
pg_drop_replication_slot
--------------------------
(1 row)Por lo tanto, se liberará el espacio utilizado por los archivos WAL.
Conclusión
Como mencionamos, los sistemas de monitoreo y alerta son las claves para evitar este tipo de problemas. De esta manera, ClusterControl puede ayudarlo a tener sus sistemas en funcionamiento, enviándole alarmas cuando sea necesario o incluso tomando medidas de recuperación para mantener su clúster de base de datos en funcionamiento. También puede implementar/importar diferentes tecnologías de bases de datos y escalarlas si es necesario.
