Wie kann ich eine Leerung der postgresql-Transaktionsprotokolle anfordern?

Ich habe das folgende Problem: Eine "vertikale" Linux-Distribution (Sophos UMT) wird mit PostgreSQL 9.2 geliefert, um die Konfiguration zu speichern. Leider scheinen die Transaktionsprotokolle (WAL) einiger Instanzen seit dem letzten Update zu wachsen, ohne jemals gelöscht zu werden. Dies führt dazu, dass der Ordner pg_xlog mehrere Größenordnungen größer als der Basisordner wird.

Ich bin jetzt in einer heiklen Situation: Aufgrund des übermäßigen Wachstums der WAL-Dateien wird die Festplatte eines dieser Computer (einer VM) vor Montag voll. Ich habe bereits einen Support-Fall mit dem Anbieter eröffnet, aber bisher sind sie nicht sehr hilfreich (sie schlagen vor, die VM mit größeren Festplatten neu zu erstellen).

Diese Datenbank wird niemals gesichert, da die Software Sicherungen auf andere Weise durchführt (sie verfügt über ein eigenes Sicherungsverfahren und sendet Sicherungsdateien per E-Mail), und ich nehme an, dass dies der Grund ist, warum die WAFs so stark wachsen.

Ich befürchte, dass ich weit davon entfernt bin, ein PostgreSQL-Experte zu sein, daher stelle ich sehr wahrscheinlich eine dumme oder offensichtliche Frage, aber wie wird angefordert, dass die WAL-Dateien gelöscht werden?

Im Idealfall suche ich nach einem Verfahren, mit dem ich diese WAL-Dateien auf dem problematischen System leeren kann, um mir genügend Zeit zu verschaffen, damit der Anbieter eine bessere Lösung herausgibt.

Bearbeiten : Wie angefordert, ist hier die Ausgabe der SELECT version();Abfrage:

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

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

 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

Wir haben schließlich den gesamten Server neu installiert (wie vom Sophos-Support angefordert), aber die vorherige Version und eine größere Festplatte verwendet. Anscheinend verbraucht die ältere Version viel weniger Platz für die WAL als die neue.

Aus Neugier führte ich die Überprüfung auf Versions- und 7non-Standard-pgsql-Parameter durch und erhielt ganz andere Ergebnisse:

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

und

              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)

Es sieht für mich so aus, als ob sich zwischen diesen beiden Versionen ziemlich viele Änderungen ergeben haben.

Höchstwahrscheinlich ist das, was Sie sehen, ein großer checkpoint_segmentsWert und lang checkpoint_timeout; Alternativ haben sie möglicherweise wal_keep_segmentseinen sehr großen Wert festgelegt, wenn die Streaming-Replikation unterstützt werden soll.

Sie können einen Prüfpunkt mit dem CHECKPOINTBefehl erzwingen . Dies kann die Datenbank für einige Zeit blockieren, wenn sie eine große Menge an WAL angesammelt hat und sie nicht im Hintergrund geschrieben hat. Wenn der checkpoint_completion_targetWert niedrig ist (weniger als 0,8 oder 0,9), besteht wahrscheinlich ein großer Arbeitsstau zum Zeitpunkt des Checkpoints. Seien Sie darauf vorbereitet, dass die Datenbank während des Prüfpunkts langsam und nicht mehr reagiert. Sie können einen Checkpoint nicht mehr abbrechen, wenn er auf normale Weise beginnt. Sie können die Datenbank zum Absturz bringen und neu starten, aber das bringt Sie einfach dorthin zurück, wo Sie waren.

Ich bin mir nicht sicher, aber ich habe das Gefühl, dass ein Checkpoint auch zum Wachstum der Hauptdatenbank führen könnte - und dies, bevor überhaupt Speicherplatz in der WAL freigegeben wird, wenn überhaupt. Ein Checkpoint kann also möglicherweise dazu führen, dass Ihnen der Speicherplatz ausgeht. Dies ist sehr schwer zu beheben, ohne zumindest vorübergehend mehr Speicher hinzuzufügen.

Jetzt wäre ein sehr guter Zeitpunkt, um eine ordnungsgemäße Sicherung der Datenbank zu erhalten. Verwenden Sie pg_dump -Fc dbnamediese Option, um jede Datenbank zu sichern und pg_dumpall --globals-onlyBenutzerdefinitionen usw. zu sichern .

Wenn Sie die Ausfallzeiten leisten können, um die Datenbank stoppen und eine Dateisystemebene Kopie des gesamten Datenverzeichnisses übernehmen (den Ordner mit pg_xlog, pg_clog, global, base, etc.). Tun Sie dies nicht, während der Server läuft, und lassen Sie keine Dateien oder Ordner aus, sie sind alle wichtig (außer pg_log, aber es ist eine gute Idee, die Textprotokolle trotzdem aufzubewahren).

Wenn Sie einen genaueren Kommentar zur wahrscheinlichen Ursache wünschen (und ich kann meiner Hypothese sicherer sein), können Sie die folgenden Abfragen ausführen und ihre Ausgabe in Ihre Antwort einfügen (in einem Code-eingerückten Block), und dann einen Kommentar abgeben bin benachrichtigt:

SELECT version();

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

Es ist möglich, dass das Einstellen und checkpoint_completion_target = 1anschließende Stoppen und Neustarten der Datenbank dazu führt, dass die WAL in der Warteschlange aggressiv ausgeschrieben wird. Es wird keine freigegeben, bis ein Checkpoint ausgeführt wird, aber Sie können eine erzwingen, sobald die Schreibaktivität langsamer wird (gemessen mit sar, iostat usw.). Ich habe nicht getestet, ob checkpoint_completion_targetsich bereits geschriebene WAL auf Änderungen bei einem Neustart auswirkt. Erwägen Sie, dies auf einem Wegwerftest zu testen. PostgreSQL Sie zuerst initdbauf einem anderen Computer.

Backups haben nichts mit der Beibehaltung und dem Wachstum von WAL zu tun. Es ist nicht Backup-bezogen.

Sehen:

• Das PostgreSQL-Handbuch zu WAL
• Das PostgreSQL-Handbuch zur WAL-Konfiguration
• depesz auf checkpoint_completion_target
• depesz auf WAL