postgresqlトランザクションログのフラッシュをリクエストするにはどうすればよいですか?


11

次の問題があります。「垂直」Linuxディストリビューション(Sophos UMT)には、PostgreSQL 9.2の設定を保存するためのものが付属しています。残念ながら、前回の更新以降、一部のインスタンスのトランザクションログ(WAL)がフラッシュされずに増大しているようです。これにより、pg_xlogフォルダーがベースフォルダーよりも数桁大きくなります。

私は現在、デリケートな状況にあります。WALファイルの過度の増大により、これらのマシンの1つ(VM)のディスクが月曜日の前に満杯になります。私は既にベンダーとのサポートケースを開いていますが、これまでのところ、あまり役に立ちません(より大きなディスクでVMを再構築することをお勧めします)。

ソフトウェアが別の方法でバックアップを実行しているため(このデータベースには独自のバックアップ手順があり、バックアップファイルを電子メールで送信するため)、このデータベースはバックアップされません。これが、WAFが非常に大きくなる理由だと思います。

私はPostgreSQLのエキスパートではないため、ばかげた質問や明らかな質問をしている可能性が高いですが、WALファイルのフラッシュを要求する手順は何ですか?

理想的には、問題のあるシステムでこれらのWALファイルをフラッシュして、ベンダーがより適切な修正を発行するのに十分な時間を確保するための手順を探しています。

編集:要求どおり、SELECT version();クエリの出力は次のとおりです。

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

そしてSELECT name, current_setting(name), source FROM pg_settings WHERE source NOT IN ('default', 'override');クエリ

 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)

編集2

最後にサーバー全体を再インストールしましたが(ソフォスのサポートからの要求に応じて)、以前のバージョンとより大きなディスクを使用しました。明らかに、古いバージョンは新しいバージョンよりもWALに使用するスペースがはるかに少ないです。

好奇心から、バージョンとデフォルト以外のpgsqlパラメータのチェックを実行したところ、まったく異なる結果が得られました。

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

そして

              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)

これらの2つのバージョン間で多くの変更があったように見えます。

回答:


9

おそらくあなたが見ているものは巨大なcheckpoint_segments価値と長いものcheckpoint_timeoutです。または、wal_keep_segmentsストリーミングレプリケーションをサポートすることになっている場合は、非常に大きな値に設定されている可能性があります。

CHECKPOINTコマンドを使用してチェックポイントを強制できます。データベースが大量のWALを蓄積し、バックグラウンドで作成していない場合、データベースがしばらく停止する可能性があります。checkpoint_completion_targetが低い場合(0.8または0.9未満)、チェックポイント時に実行する作業のバックログが大きくなる可能性があります。チェックポイント中にデータベースが遅くなり、応答しなくなる準備をしてください。通常の方法で開始したチェックポイントは中止できません。データベースをクラッシュして再起動することはできますが、それによって元の状態に戻るだけです。

確かではありませんが、チェックポイントによってメインデータベースのサイズが大きくなる可能性があると感じています。WAL内のスペースが解放される前に、そのスペースが解放される前にそうする必要があります。したがって、チェックポイントによって潜在的に領域が不足する可能性があります。これは、少なくとも一時的にストレージを追加せずに回復するのが非常に難しいことです。

データベースの適切なバックアップを取得するには、今が非常に良いタイミングです。pg_dump -Fc dbname各データベースpg_dumpall --globals-onlyをダンプしたり、ユーザー定義をダンプしたりするために使用します。

あなたは、ダウンタイムに余裕があれば、(含むフォルダデータベースを停止し、全体のデータディレクトリのファイルシステムレベルのコピーを取りpg_xlogpg_clogglobalbase、など)。サーバーの稼働中にこれを行わないでください。ファイルやフォルダは省略しないでください。これらはすべて重要です(を除いてpg_log、ただしテキストログを保持することをお勧めします)。

可能性のある原因についてより具体的なコメントが必要な場合(そして、私の仮説に自信がある場合)、次のクエリを実行して、その出力を(コードインデントされたブロック内の)回答に貼り付けてからコメントすることができます通知されました:

SELECT version();

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

checkpoint_completion_target = 1DB を設定してから停止して再起動すると、キューに入れられたWALの書き込みが積極的に開始される可能性があります。チェックポイントを実行するまで解放されませんが、(sar、iostatなどで測定されるように)書き込みアクティビティが遅くなると強制的に実行できます。checkpoint_completion_target再起動で変更されたときに、すでに作成されたWALに影響するかどうかを確認するためのテストは行っていません。initdb最初に別のマシンで使い捨てのPostgreSQLでこれをテストすることを検討してください。

バックアップは、WALの保持と増加とは関係ありません。バックアップ関連ではありません。

見る:


詳しい回答ありがとうございます。ご質問いただいた2つのクエリの結果を更新しました。チェックポイントに関連するものは何も表示されません。それまでの間、弾丸をかましてシステム全体を大容量のディスクで再インストールすることにしました。これにより、ソフォスからサポートされている修正プログラムを入手するのに十分な時間が得られます。
ステファン

@Stephane 再インストールする必要はありません。古いマシンをより大きなディスクにディスクイメージし、PostgreSQLを新しく作成されたより大きなパーティションに移動できます。そうは言っても、低レベルのLinuxシステム管理者の経験によっては、再インストールする方が簡単な場合があります。
クレイグリンガー2013年

@Stephane Your wal_keep_segmentsがに設定されている100ため、マスターサーバーで不要になったストリーミングレプリカで使用できるように、最大​​1.6 GBのWALアーカイブを保持する必要があります。(マスターサーバーとして)ストリーミングレプリケーションを使用しない場合はwal_keep_segments、ゼロに設定してそのスペースを取り戻すことができます。あなたはcheckpoint_segmentsそれがあなたのためではなかった場合は、以上の3 * 16 = WALの48メガバイトは何もしてはならないので、デフォルトのようですwal_keep_segmentshot_standby電源を入れたのもおかしいです-これはレプリカですか?
クレイグリンガー2013年

再度、感謝します。システムはレプリカの一部ではありませんが、システムを使用するソフトウェア(Sopho UTMファイアウォール)をアクティブ/パッシブフェイルオーバーモードで使用できるため、デフォルトで設定されている可能性があります。
ステファン2013年

@Stephaneそうだね。私は自分でPostgreSQLを起動wal_keep_segments0て再起動します。不要なWALが削除されることを確認していませんが、削除されると思います。手動で削除することはお勧めしません。間違ったWALアーカイブファイルを削除すると、データベースの動作が完全に停止します。
クレイグリンガー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.