¿Cómo puedo solicitar una descarga de los registros de transacciones postgresql?

Tengo el siguiente problema: una distribución Linux "vertical" (Sophos UMT) viene con PostgreSQL 9.2 para almacenar su configuración. Desafortunadamente, desde la última actualización, parece que los registros de transacciones (WAL) de algunas instancias están creciendo sin ser vaciados. Esto hace que la carpeta pg_xlog crezca en un orden de magnitud mayor que la carpeta base.

Ahora estoy en una situación delicada: debido al crecimiento excesivo de los archivos WAL, el disco de una de estas máquinas (una VM) se llenará antes del lunes. Ya he abierto un caso de soporte con el proveedor pero, hasta ahora, no son muy útiles (sugieren que reconstruyamos la VM con discos más grandes).

Esta base de datos nunca se realiza una copia de seguridad porque el software realiza copias de seguridad de una manera diferente (tiene su propio procedimiento de copia de seguridad y envía archivos de copia de seguridad por correo electrónico) y supongo que esta es la razón por la cual los WAF están creciendo tanto.

Me temo que estoy lejos de ser un experto en PostgreSQL, por lo que es muy probable que esté haciendo una pregunta tonta u obvia, pero ¿cuál es el procedimiento para solicitar que se vacíen los archivos WAL?

Idealmente, estoy buscando un procedimiento que me permita vaciar estos archivos WAL en el sistema problemático para ganarme el tiempo suficiente para que el proveedor emita una solución mejor.

Editar : según lo solicitado, aquí está el resultado de la SELECT version();consulta:

 PostgreSQL 9.2.4 on i686-pc-linux-gnu, compiled by gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973], 32-bit

(1 fila)

Y la SELECT name, current_setting(name), source FROM pg_settings WHERE source NOT IN ('default', 'override');consulta

 hot_standby                      | on                  | configuration file
 listen_addresses                 | *                   | configuration file
 log_destination                  | syslog              | configuration file
 log_min_duration_statement       | -1                  | configuration file
 log_min_error_statement          | error               | configuration file
 log_min_messages                 | notice              | configuration file
 maintenance_work_mem             | 512MB               | configuration file
 max_connections                  | 300                 | configuration file
 max_files_per_process            | 1000                | configuration file
 max_prepared_transactions        | 0                   | configuration file
 max_stack_depth                  | 2MB                 | configuration file
 max_standby_streaming_delay      | 10s                 | configuration file
 max_wal_senders                  | 10                  | configuration file
 password_encryption              | on                  | configuration file
 pg_stat_statements.max           | 1000                | configuration file
 pg_stat_statements.save          | on                  | configuration file
 pg_stat_statements.track         | all                 | configuration file
 pg_stat_statements.track_utility | off                 | configuration file
 port                             | 5432                | configuration file
 random_page_cost                 | 2                   | configuration file
 replication_timeout              | 1min                | configuration file
 seq_page_cost                    | 1                   | configuration file
 shared_buffers                   | 512MB               | configuration file
 shared_preload_libraries         | pg_stat_statements  | configuration file
 ssl                              | off                 | configuration file
 stats_temp_directory             | pg_stat_tmp         | configuration file
 superuser_reserved_connections   | 20                  | configuration file
 synchronous_commit               | local               | configuration file
 syslog_facility                  | local0              | configuration file
 syslog_ident                     | postgres            | configuration file
 temp_buffers                     | 256MB               | configuration file
 temp_file_limit                  | -1                  | configuration file
 TimeZone                         | GMT                 | configuration file
 timezone_abbreviations           | AlmostAll           | configuration file
 track_activities                 | on                  | configuration file
 track_activity_query_size        | 4096                | configuration file
 track_counts                     | on                  | configuration file
 track_functions                  | none                | configuration file
 track_io_timing                  | on                  | configuration file
 unix_socket_directory            | /var/run/postgresql | configuration file
 unix_socket_group                | postgres            | configuration file
 unix_socket_permissions          | 0777                | configuration file
 update_process_title             | on                  | configuration file
 vacuum_defer_cleanup_age         | 0                   | configuration file
 wal_buffers                      | 16MB                | configuration file
 wal_keep_segments                | 100                 | configuration file
 wal_level                        | hot_standby         | configuration file
 wal_receiver_status_interval     | 5s                  | configuration file
 work_mem                         | 512MB               | configuration file
(69 rows)

Edit2

Finalmente reinstalamos todo el servidor (como lo solicitó el soporte de Sophos) pero usando la versión anterior y un disco más grande. Aparentemente, la versión anterior usa mucho menos espacio para el WAL que la nueva.

Por curiosidad, ejecuté la comprobación de la versión y los parámetros pgsql no predeterminados y obtuve resultados bastante diferentes:

PostgreSQL 8.4.14 on i686-pc-linux-gnu, compiled by GCC gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973], 32-bit

              name               | current_setting |        source
---------------------------------+-----------------+----------------------
 autovacuum_analyze_scale_factor | 0.0005          | configuration file
 checkpoint_segments             | 12              | configuration file
 checkpoint_warning              | 0               | configuration file
 escape_string_warning           | off             | configuration file
 fsync                           | on              | configuration file
 listen_addresses                | *               | configuration file
 log_destination                 | syslog          | configuration file
 log_timezone                    | Europe/Zurich   | command line
 maintenance_work_mem            | 1GB             | configuration file
 max_connections                 | 300             | configuration file
 max_stack_depth                 | 2MB             | environment variable
 port                            | 5432            | configuration file
 shared_buffers                  | 32MB            | configuration file
 standard_conforming_strings     | off             | configuration file
 syslog_facility                 | local0          | configuration file
 syslog_ident                    | postgres        | configuration file
 temp_buffers                    | 1024            | configuration file
 TimeZone                        | UTC             | configuration file
 timezone_abbreviations          | AlmostAll       | configuration file
 work_mem                        | 512MB           | configuration file
(20 rows)

Me parece que hubo muchos cambios entre estas dos versiones.

postgresql

— Stephane
fuente

Lo más probable es que lo que está viendo es un gran checkpoint_segmentsvalor y largo checkpoint_timeout; alternativamente, podrían haber establecido wal_keep_segmentsun valor muy grande si se supone que admite la replicación de transmisión.

Puede forzar un punto de control con el CHECKPOINTcomando. Esto puede detener la base de datos durante algún tiempo si ha acumulado una gran cantidad de WAL y no ha estado escribiendo en segundo plano. Si checkpoint_completion_targetes bajo (menos de 0,8 o 0,9), es probable que haya una gran cantidad de trabajo pendiente en el momento del punto de control. Esté preparado para que la base de datos se vuelva lenta y no responda durante el punto de control. No puede abortar un punto de control una vez que comienza por medios normales; puedes bloquear la base de datos y reiniciarla, pero eso solo te devuelve a donde estabas.

No estoy seguro, pero tengo la sensación de que un punto de control también podría provocar el crecimiento de la base de datos principal, y hacerlo antes de que se libere espacio en el WAL, si es que lo hay. Por lo tanto, un punto de control podría provocar que se quede sin espacio, algo de lo que es muy difícil recuperarse sin agregar más almacenamiento al menos temporalmente.

Ahora sería un muy buen momento para obtener una copia de seguridad adecuada de la base de datos: utilícela pg_dump -Fc dbnamepara volcar cada base de datos y pg_dumpall --globals-onlypara volcar definiciones de usuario, etc.

Si usted puede permitirse el tiempo de inactividad, detener la base de datos y tener una copia de nivel de sistema de archivos del directorio de datos entera (la carpeta que contiene pg_xlog, pg_clog, global, base, etc). No haga esto mientras el servidor se está ejecutando y no omita ningún archivo o carpeta, todos son importantes (bueno, excepto pg_log, pero es una buena idea mantener los registros de texto de todos modos).

Si desea un comentario más específico sobre la causa probable (y puedo estar más seguro de mi hipótesis), puede ejecutar las siguientes consultas y pegar su resultado en su respuesta (en un bloque con sangría de código) y luego comentar para que yo Estoy notificado:

SELECT version();

SELECT name, current_setting(name), source
  FROM pg_settings
  WHERE source NOT IN ('default', 'override');

Es posible que la configuración, checkpoint_completion_target = 1luego detener y reiniciar la base de datos , haga que comience a escribir agresivamente WAL en cola. No liberará ninguno hasta que haga un punto de control, pero podría forzar uno una vez que la actividad de escritura se ralentice (medida con sar, iostat, etc.). No he probado para ver si checkpoint_completion_targetafecta a WAL ya escrito cuando se cambia en un reinicio; considere probar esto en una prueba desechable PostgreSQL initdbprimero en otra máquina.

Las copias de seguridad no tienen nada que ver con la retención y el crecimiento de WAL; No está relacionado con la copia de seguridad.

Ver:

— Craig Ringer
fuente

Muchas gracias por la respuesta detallada. He actualizado por pregunta con el resultado de las dos consultas que proporcionó. Sin embargo, no puedo ver nada relacionado con los puntos de control. Mientras tanto, hemos decidido morder la bala y reinstalar todo el sistema con un disco más grande: eso nos dará tiempo suficiente para obtener una solución compatible de Sophos.

— Stephane

@Stephane No debería necesitar reinstalarlo : puede simplemente crear una imagen de disco de la máquina anterior en un disco más grande y luego mover PostgreSQL a una partición más grande recién creada. Dicho esto, dependiendo de su experiencia con el administrador de sistemas Linux de bajo nivel, podría ser más fácil de reinstalar.

— Craig Ringer

@Stephane Your wal_keep_segmentsestá configurado en 100, por lo que eso significa que debería tener hasta 1,6 GB de archivos WAL retenidos para su uso por una réplica de transmisión una vez que el servidor maestro ya no los necesite. Si no utiliza la replicación de transmisión (como servidor maestro), puede establecerlo wal_keep_segmentsen cero y recuperar ese espacio. Su checkpoint_segmentsparece ser el valor por defecto, por lo que no debería tener nada más que 3 * 16 = 48 MB de WAL si no fuera por su wal_keep_segments. También es extraño que hayas hot_standbyactivado, ¿es esta una réplica?

— Craig Ringer

Gracias de nuevo. El sistema no forma parte de ninguna réplica, pero el software que lo utiliza (cortafuegos Sopho UTM) se puede usar en modo de conmutación por error activo / pasivo, por lo que es posible que esté configurado de forma predeterminada.

— Stephane

@Stephane Sí, eso sería todo. Me vuelvo wal_keep_segmentsa 0y reiniciar PostgreSQL personalmente. No he verificado que eliminará el WAL no deseado, pero espero que lo haga. No recomiendo eliminarlo manualmente; eliminar los archivos WAL incorrectos detendrá por completo el funcionamiento de su base de datos.

— Craig Ringer