Bagaimana saya bisa meminta log transaksi postgresql flush?

Saya memiliki masalah berikut: distribusi Linux "vertikal" (Sophos UMT) hadir dengan PostgreSQL 9.2 untuk menyimpan konfigurasinya. Sayangnya, sejak pembaruan terakhir, tampaknya log transaksi (WAL) dari beberapa contoh tumbuh tanpa pernah memerah. Ini menyebabkan folder pg_xlog tumbuh beberapa urutan besarnya lebih besar dari folder dasar.

Saya sekarang dalam situasi sulit: karena pertumbuhan file WAL yang berlebihan, disk dari salah satu mesin ini (VM) akan penuh sebelum Senin. Saya sudah membuka kasing dukungan dengan vendor tetapi, sejauh ini, mereka tidak sangat membantu (mereka menyarankan kami membangun kembali VM dengan disk yang lebih besar).

Basis data ini tidak pernah didukung karena peranti lunak ini melakukan pencadangan dengan cara yang berbeda (ia memiliki prosedur pencadangan sendiri dan mengirimkan file pencadangan melalui email) dan saya kira inilah alasan mengapa WAF tumbuh sangat banyak.

Saya takut bahwa saya jauh dari menjadi ahli PostgreSQL sehingga sangat mungkin saya mengajukan pertanyaan yang konyol atau jelas tetapi, bagaimana prosedur untuk meminta file WAL untuk memerah?

Idealnya, saya sedang mencari prosedur yang akan memungkinkan saya untuk menyiram file-file WAL ini pada sistem yang bermasalah untuk membeli sendiri cukup waktu untuk membuat vendor mengeluarkan perbaikan yang lebih baik.

Sunting : Seperti yang diminta, ini adalah output dari SELECT version();kueri:

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

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

 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

Kami akhirnya menginstal ulang seluruh server (seperti yang diminta oleh dukungan Sophos) tetapi menggunakan versi sebelumnya dan disk yang lebih besar. Rupanya, versi lama menggunakan ruang yang jauh lebih sedikit untuk WAL daripada yang baru.

Karena penasaran, saya menjalankan pemeriksaan untuk parameter pgsql versi dan 7non-default dan saya mendapat hasil yang sangat berbeda:

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

dan

              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)

Sepertinya saya ada cukup banyak perubahan di antara kedua versi ini.

Kemungkinan besar apa yang Anda lihat adalah checkpoint_segmentsnilai yang sangat besar dan panjang checkpoint_timeout; secara bergantian, mereka mungkin telah menetapkan wal_keep_segmentsnilai yang sangat besar jika itu seharusnya mendukung replikasi streaming.

Anda dapat memaksa pos pemeriksaan dengan CHECKPOINTperintah. Ini dapat menunda database untuk beberapa waktu jika telah mengakumulasikan sejumlah besar WAL dan belum pernah menulisnya secara latar belakang. Jika checkpoint_completion_targetrendah (kurang dari 0,8 atau 0,9) maka kemungkinan akan ada banyak pekerjaan yang harus dilakukan pada waktu checkpoint. Bersiaplah untuk database menjadi lambat dan tidak responsif selama pos pemeriksaan. Anda tidak dapat membatalkan pos pemeriksaan setelah dimulai dengan cara normal; Anda dapat mem-crash database dan memulai kembali, tetapi itu hanya membuat Anda kembali ke tempat Anda sebelumnya.

Saya tidak yakin, tetapi saya merasa pos pemeriksaan juga dapat mengakibatkan pertumbuhan basis data utama - dan melakukannya sebelum ruang kosong di WAL, jika ada. Jadi pos pemeriksaan berpotensi memicu Anda kehabisan ruang, sesuatu yang sangat sulit untuk dipulihkan tanpa menambahkan lebih banyak penyimpanan setidaknya untuk sementara.

Sekarang akan menjadi waktu yang sangat baik untuk mendapatkan cadangan database yang tepat - gunakan pg_dump -Fc dbnameuntuk membuang setiap basis data, dan pg_dumpall --globals-onlyuntuk membuang definisi pengguna dll.

Jika Anda mampu downtime, berhenti database dan mengambil salinan tingkat file-sistem dari seluruh direktori data (folder yang berisi pg_xlog, pg_clog, global, base, dll). Jangan lakukan ini saat server sedang berjalan dan jangan hilangkan file atau folder, semuanya penting (well, kecuali pg_log, tapi tetap ide yang bagus tetap menyimpan log teks).

Jika Anda ingin komentar yang lebih spesifik tentang kemungkinan penyebab (dan jadi saya bisa lebih percaya diri dalam hipotesis saya), Anda dapat menjalankan kueri berikut dan menempelkan hasilnya ke jawaban Anda (dalam blok yang indentasi kode) kemudian berkomentar jadi saya saya diberitahu:

SELECT version();

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

Ada kemungkinan bahwa pengaturan checkpoint_completion_target = 1kemudian berhenti dan restart DB mungkin menyebabkannya mulai secara agresif menulis keluar antrian WAL. Ini tidak akan membebaskan apa pun sampai ia melakukan pemeriksaan, tetapi Anda bisa memaksa satu aktivitas tulis sekali melambat (seperti diukur dengan sar, iostat, dll). Saya belum diuji untuk melihat apakah checkpoint_completion_targetmempengaruhi WAL yang sudah ditulis ketika diubah di restart; pertimbangkan untuk menguji ini pada tes sekali pakai PostgreSQL Anda initdbdi komputer lain terlebih dahulu.

Cadangan tidak ada hubungannya dengan retensi dan pertumbuhan WAL; itu tidak terkait cadangan.

Lihat:

• Manual PostgreSQL di WAL
• Manual PostgreSQL tentang konfigurasi WAL
• depesz aktif checkpoint_completion_target
• depesz di WAL