PostgresでのWALセグメントのゼロ化

比較的少量のPostgresデータベースがあり、各WALセグメントを圧縮してS3に送信するために継続的なアーカイブがセットアップされています。これはボリュームの少ないシステムであるarchive_timeoutため、10分ごとにヒットし、ほとんど使用されていないWALセグメントをアーカイブします。これは、ほとんどがゼロであったため、非常によく圧縮されていました。

ただし、PostgresはWALセグメントをリサイクルして、各WALスイッチで新しいファイルを割り当てるコストを回避します。これは、高負荷の状況で役立ちますが、通常よりも重いアクティビティのバーストの後、WALセグメントファイルがいっぱいになることを意味します以前のセグメントからのジャンクであり、まったくうまく圧縮されません。私たちはこのジャンクのすべてのコピーをたくさん保存しています。

WALアーカイブを保持するために使用しているスペースの量を減らす方法はありますか？いくつかの次善の可能性：

1. Postgresが何らかの方法でWALセグメントをリサイクルしないようにして、毎回ゼロのファイルから開始します。ドキュメントはこれを行うためのオプションがあることを示していませんが、私はそれを逃したかもしれません。

2. Postgresが使用を開始/終了するときに、WALセグメントファイルをゼロにするようにします。再び、ドキュメントはこれが可能であることを示唆していないようです。

3. 一部のWALセグメントファイルを使用していない間に外部的にゼロにするか削除します。これがどのファイルかを判別する安全な方法はありますか？

4. からの出力を使用してセグメントをアーカイブする前に、セグメントの未使用部分をゼロにしてpg_xlogdump、ジャンクの開始位置を見つけます。可能ですが、好きではありません。少なくとも、archiveコマンドでこれを行うことにより、Postgresがファイルを再利用しないことを確認できます。

5. セグメントファイルの使用された部分のみをアーカイブします。これも、pg_xlogdump何らかの方法で出力を解釈し、復元中にゼロで埋めます。あまり好きではありませんが、可能だと思います。

バージョン9.4から、WALファイルの末尾を自動的にゼロにするようになりました。（実際にはほとんどゼロですが、ゼロにならないブロックヘッダーがいくつかありますが、結果は非常に圧縮可能です）。

バージョン9.2には、というプログラムpg_clearxlogtailがあります。圧縮ステップの前に、archive_commandに追加できます。

9.3を使用している場合は、運が悪いです。

チェックポイントは本質的にログファイルの切り替えを引き起こさないことに注意してください。切り替えを引き起こしているのは、おそらくarchive_timeoutです。