Postgresql işlem günlüklerinin temizlenmesini nasıl isteyebilirim?

Aşağıdaki sorun var: bir "dikey" Linux dağıtım (Sophos UMT) yapılandırmasını depolamak için PostgreSQL 9.2 ile birlikte gelir. Ne yazık ki, son güncellemeden bu yana, bazı örneklerin işlem günlükleri (WAL) hiç temizlenmeden büyümektedir. Bu, pg_xlog klasörünün, temel klasörden birkaç büyüklük büyüklüğünde büyümesine neden olur.

Şimdi hassas bir durumdayım: WAL dosyalarının aşırı büyümesi nedeniyle, bu makinelerden birinin diski (VM) Pazartesi gününden önce dolar. Zaten satıcıyla bir destek vakası açtım, ancak şimdiye kadar çok yardımcı olmuyorlar (VM'yi daha büyük disklerle yeniden oluşturmamızı öneriyorlar).

Bu veritabanı asla yedeklenmez çünkü yazılım farklı bir şekilde yedekleme yapar (kendi yedekleme prosedürüne sahiptir ve yedekleme dosyalarını e-posta ile gönderir) ve WAF'lerin bu kadar büyümesinin nedeni budur.

Korkarım ki bir PostgreSQL uzmanı olmaktan çok uzakım, bu yüzden aptalca veya açık bir soru soruyorum ama WAL dosyalarının temizlenmesini istemek için prosedür nedir?

İdeal olarak, satıcıya daha iyi bir düzeltme yayınlamak için kendime yeterince zaman almak için bu WAL dosyalarını sorunlu sistemde yıkamamı sağlayacak bir prosedür arıyorum.

Düzenleme : İstendiği gibi, SELECT version();sorgunun çıktısı aşağıdadır:

 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 satır)

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

 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

Sonunda tüm sunucuyu (Sophos desteğinin istediği gibi), ancak önceki sürümü ve daha büyük bir diski kullanarak yeniden kurduk. Görünüşe göre, eski sürüm WAL için yenisinden çok daha az yer kullanıyor.

Meraktan, sürüm ve 7non-default pgsql parametrelerini kontrol ettim ve oldukça farklı sonuçlar aldım:

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

ve

              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)

Bana öyle geliyor ki, bu iki versiyon arasında oldukça fazla değişiklik var.

Büyük olasılıkla gördüğünüz şey büyük bir checkpoint_segmentsdeğer ve uzun checkpoint_timeout; alternatif olarak, wal_keep_segmentsakış çoğaltmayı desteklemesi gerekiyorsa çok büyük bir değere ayarlanmış olabilirler .

Bir denetim noktasını CHECKPOINTkomutla zorlayabilirsiniz . Bu, büyük miktarda WAL biriktirmişse ve arka planı yazmamışsa, veritabanını bir süre durdurabilir. Eğer checkpoint_completion_target(az 0.8 veya 0.9) düşük olduğu daha sonra olma olasılığı var büyük denetim noktası anda yapılacak işin birikim. Denetim noktası sırasında veritabanının yavaş ve yanıt vermemesine hazırlıklı olun. Bir kontrol noktasını normal yollarla başladıktan sonra iptal edemezsiniz; veritabanını kilitleyebilir ve yeniden başlatabilirsiniz, ancak bu sizi bulunduğunuz yere geri götürür.

Emin değilim, ama bir kontrol noktasının da ana veritabanının büyümesine neden olabileceği hissine sahibim - ve eğer varsa, WAL'de herhangi bir alan serbest bırakılmadan önce bunu yapabilirim. Bu nedenle, bir kontrol noktası potansiyel olarak alanınızın bitmesini tetikleyebilir, en azından geçici olarak daha fazla depolama alanı eklemeden kurtarılması çok zor bir şey.

Şimdi veritabanının düzgün bir yedeğini almak için çok iyi bir zaman olacaktır - pg_dump -Fc dbnameher veritabanını pg_dumpall --globals-onlyboşaltmak ve kullanıcı tanımlarını boşaltmak için kullanın.

Eğer kesinti gelemez, veritabanını durdurmak ve tüm veri dizinin bir dosya sistem düzeyi kopyasını (içeren klasörü almak pg_xlog, pg_clog, global, base, vs). Sunucu çalışırken bunu yapmayın ve herhangi bir dosya veya klasörü atlamayın, hepsi önemlidir (hariç pg_log, ancak metin günlüklerini yine de tutmak iyi bir fikirdir).

Olası neden hakkında daha spesifik bir yorum istiyorsanız (ve benim hipotezimde daha emin olabileceğim) aşağıdaki sorguları çalıştırabilir ve çıktılarını cevabınıza (kod girintili blokta) yapıştırabilirsiniz. haberdar oldum:

SELECT version();

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

Ayarın checkpoint_completion_target = 1ardından DB'nin durdurulması ve yeniden başlatılması, sıraya alınmış WAL'ı agresif bir şekilde yazmaya başlamasına neden olabilir . Bir kontrol noktası yapana kadar serbest kalmaz, ancak yazma etkinliği yavaşladığında (sar, iostat, vb. İle ölçüldüğü gibi) birini zorlayabilirsiniz. Ben checkpoint_completion_targetbir yeniden başlatma değiştiğinde zaten yazılmış WAL etkiler olup olmadığını görmek için test etmedi ; PostgreSQL'i bir initdbbaşka testte önce bir test üzerinde test etmeyi düşünün .

Yedeklemelerin WAL alıkoyma ve büyüme ile hiçbir ilgisi yoktur; yedekleme ile ilgili değildir.

Görmek:

• WAL üzerindeki PostgreSQL kılavuzu
• WAL yapılandırması hakkında PostgreSQL kılavuzu
• depesz checkpoint_completion_target
• WAL'da depesz