Comment puis-je demander un vidage des journaux de transactions postgresql?

J'ai le problème suivant: une distribution Linux "verticale" (Sophos UMT) est livrée avec PostgreSQL 9.2 pour stocker sa configuration. Malheureusement, depuis la dernière mise à jour, il semble que les journaux de transactions (WAL) de certaines instances augmentent sans jamais être vidés. Cela entraîne une augmentation du dossier pg_xlog de plusieurs ordres de grandeur par rapport au dossier de base.

Je suis maintenant dans une situation délicate: en raison de la croissance excessive des fichiers WAL, le disque d'une de ces machines (une VM) sera plein avant lundi. J'ai déjà ouvert un dossier de support avec le fournisseur mais, jusqu'à présent, ils ne sont pas très utiles (ils suggèrent de reconstruire la machine virtuelle avec des disques plus gros).

Cette base de données n'est jamais sauvegardée car le logiciel effectue des sauvegardes d'une manière différente (il a sa propre procédure de sauvegarde et envoie des fichiers de sauvegarde par e-mail) et je suppose que c'est la raison pour laquelle les WAF se développent autant.

Je crains d'être loin d'être un expert PostgreSQL, il est donc très probable que je pose une question idiote ou évidente, mais quelle est la procédure pour demander le vidage des fichiers WAL?

Idéalement, je suis à la recherche d'une procédure qui me permettra de vider ces fichiers WAL sur le système problématique afin de m'acheter suffisamment de temps pour que le fournisseur émette une meilleure solution.

Edit : Comme demandé, voici le résultat de la SELECT version();requête:

 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 rangée)

Et la SELECT name, current_setting(name), source FROM pg_settings WHERE source NOT IN ('default', 'override');requête

 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)

Modifier2

Nous avons finalement réinstallé l'ensemble du serveur (comme demandé par le support Sophos) mais en utilisant la version précédente et un disque plus grand. Apparemment, l'ancienne version utilise beaucoup moins d'espace pour le WAL que la nouvelle.

Par curiosité, j'ai exécuté la vérification de la version et des paramètres pgsql 7 par défaut et j'ai obtenu des résultats assez différents:

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

et

              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)

Il me semble qu'il y a eu pas mal de changements entre ces deux versions.

Ce que vous voyez est probablement une checkpoint_segmentsvaleur énorme et longue checkpoint_timeout; alternativement, ils peuvent avoir défini wal_keep_segmentsune valeur très élevée s'il est censé prendre en charge la réplication en streaming.

Vous pouvez forcer un point de contrôle avec la CHECKPOINTcommande. Cela peut bloquer la base de données pendant un certain temps si elle a accumulé une énorme quantité de WAL et ne l'a pas écrite en arrière-plan. S'il checkpoint_completion_targetest faible (moins de 0,8 ou 0,9), il y aura probablement un gros arriéré de travail à faire au moment du point de contrôle. Soyez prêt à ce que la base de données devienne lente et ne réponde pas pendant le point de contrôle. Vous ne pouvez pas abandonner un point de contrôle une fois qu'il a commencé par des moyens normaux; vous pouvez planter la base de données et la redémarrer, mais cela vous ramène là où vous étiez.

Je ne suis pas certain, mais j'ai le sentiment qu'un point de contrôle pourrait également entraîner la croissance de la base de données principale - et le faire avant que tout espace ne soit libéré dans le WAL, le cas échéant. Un point de contrôle peut donc potentiellement vous faire manquer d'espace, ce qui est très difficile à récupérer sans ajouter plus de stockage au moins temporairement.

Ce serait maintenant un très bon moment pour obtenir une sauvegarde correcte de la base de données - utiliser pg_dump -Fc dbnamepour vider chaque base de données, et pg_dumpall --globals-onlyvider les définitions d'utilisateurs, etc.

Si vous pouvez vous permettre le temps d' arrêt, arrêtez la base de données et de prendre une copie de niveau du système de fichiers de l'intégralité du répertoire de données (le dossier contenant pg_xlog, pg_clog, global, base, etc.). Ne faites pas cela lorsque le serveur est en cours d'exécution et n'omettez aucun fichier ou dossier, ils sont tous importants (enfin, sauf pg_log, mais c'est une bonne idée de conserver les journaux de texte de toute façon).

Si vous souhaitez un commentaire plus spécifique sur la cause probable (et je peux donc être plus confiant dans mon hypothèse), vous pouvez exécuter les requêtes suivantes et coller leur sortie dans votre réponse (dans un bloc en retrait de code), puis commenter afin que je suis averti:

SELECT version();

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

Il est possible que la mise en checkpoint_completion_target = 1puis arrêter et redémarrer le DB pourrait l' amener à commencer à écrire de manière agressive sur faisaient la queue WAL. Il n'en libérera aucun jusqu'à ce qu'il fasse un point de contrôle, mais vous pouvez en forcer un une fois que l'activité d'écriture ralentit (mesurée avec sar, iostat, etc.). Je n'ai pas testé pour voir si checkpoint_completion_targetaffecte le WAL déjà écrit lorsqu'il est modifié lors d'un redémarrage; pensez à tester ceci sur un test jetable PostgreSQL vous initdbsur une autre machine d'abord.

Les sauvegardes n'ont rien à voir avec la rétention et la croissance de WAL; ce n'est pas lié à la sauvegarde.

Voir:

• Le manuel PostgreSQL sur WAL
• Le manuel PostgreSQL sur la configuration WAL
• depesz sur checkpoint_completion_target
• depesz sur WAL