Come posso richiedere un flush dei log delle transazioni postgresql?

Ho il seguente problema: una distribuzione Linux "verticale" (Sophos UMT) viene fornita con PostgreSQL 9.2 per memorizzare la sua configurazione. Sfortunatamente, dall'ultimo aggiornamento, sembra che i registri delle transazioni (WAL) di alcune istanze stiano crescendo senza mai essere scaricati. Questo fa sì che la cartella pg_xlog cresca di un ordine di grandezza maggiore della cartella di base.

Ora sono in una situazione delicata: a causa dell'eccessiva crescita dei file WAL, il disco di una di queste macchine (una VM) si riempirà prima di lunedì. Ho già aperto un caso di supporto con il fornitore, ma finora non sono stati molto utili (suggeriscono di ricostruire la VM con dischi più grandi).

Non viene mai eseguito il backup di questo database perché il software sta eseguendo i backup in modo diverso (ha una propria procedura di backup e invia file di backup via e-mail) e suppongo che questo sia il motivo per cui i WAF stanno crescendo così tanto.

Temo di essere ben lungi dall'essere un esperto PostgreSQL, quindi è molto probabile che stia facendo una domanda sciocca o ovvia, ma qual è la procedura per richiedere lo svuotamento dei file WAL?

Idealmente, sto cercando una procedura che mi permetta di svuotare questi file WAL sul sistema problematico al fine di farmi guadagnare abbastanza tempo per convincere il fornitore a fornire una soluzione migliore.

Modifica : come richiesto, ecco l'output della SELECT version();query:

 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 riga)

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

 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

Alla fine abbiamo reinstallato l'intero server (come richiesto dal supporto Sophos) ma utilizzando la versione precedente e un disco più grande. Apparentemente, la versione precedente utilizza molto meno spazio per la WAL rispetto a quella nuova.

Per curiosità, ho eseguito il controllo della versione e dei parametri 7non-default pgsql e ho ottenuto risultati abbastanza diversi:

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

e

              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)

Mi sembra che ci siano stati molti cambiamenti tra queste due versioni.

Molto probabilmente quello che stai vedendo è un checkpoint_segmentsvalore enorme e lungo checkpoint_timeout; in alternativa, potrebbero aver impostato wal_keep_segmentsun valore molto elevato se si suppone che supporti la replica di streaming.

È possibile forzare un checkpoint con il CHECKPOINTcomando. Questo potrebbe arrestare il database per qualche tempo se ha accumulato un'enorme quantità di WAL e non lo ha scritto in background. Se checkpoint_completion_targetè basso (meno di 0,8 o 0,9), è probabile che ci sia un grosso arretrato di lavoro da fare al momento del checkpoint. Prepararsi al rallentamento e alla mancata risposta del database durante il checkpoint. Non è possibile interrompere un checkpoint una volta che inizia con mezzi normali; puoi bloccare il database e riavviarlo, ma questo ti riporta semplicemente dove eri.

Non ne sono certo, ma ho la sensazione che un checkpoint possa comportare anche la crescita del database principale, e farlo prima che qualsiasi spazio venga liberato nel WAL, se lo è. Quindi un checkpoint potrebbe potenzialmente farti rimanere a corto di spazio, qualcosa da cui è molto difficile recuperare senza aggiungere ulteriore spazio di archiviazione almeno temporaneamente.

Ora sarebbe un ottimo momento per ottenere un backup corretto del database: utilizzare pg_dump -Fc dbnameper scaricare ciascun database e pg_dumpall --globals-onlyper scaricare definizioni utente ecc.

Se potete permettervi il tempo di inattività, arrestare il database e prendere una copia a livello di file-system di tutta la directory dei dati (la cartella che contiene pg_xlog, pg_clog, global, base, ecc). Non farlo mentre il server è in esecuzione e non omettere alcun file o cartella, sono tutti importanti (bene, tranne pg_log, ma è una buona idea mantenere comunque i registri di testo).

Se desideri un commento più specifico sulla probabile causa (e quindi posso essere più fiducioso nella mia ipotesi è) puoi eseguire le seguenti query e incollare il loro output nella tua risposta (in un blocco con rientro del codice) quindi commentare così io sono avvisato:

SELECT version();

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

È possibile che l'impostazione, l' checkpoint_completion_target = 1arresto e il riavvio del DB, possano causare l'avvio aggressivo della scrittura in coda WAL. Non si libererà fino a quando non farà un checkpoint, ma potresti forzarne uno una volta che l'attività di scrittura rallenta (misurata con sar, iostat, ecc.). Non ho testato per vedere se checkpoint_completion_targetinfluisce su WAL già scritto quando viene modificato in un riavvio; considera di provare questo su un test usa e getta PostgreSQL initdbprima su un altro computer.

I backup non hanno nulla a che fare con la conservazione e la crescita di WAL; non è correlato al backup.

Vedere:

• Il manuale PostgreSQL su WAL
• Il manuale PostgreSQL sulla configurazione WAL
• dipende da checkpoint_completion_target
• dipende da WAL