pg_dumpのリソースを貪欲にする方法

Question

次のルールを使用して、毎日pg_dumpを呼び出すようにcronを構成しました。

# xyz database backups: 00 01 * * * root umask 077 && pg_dump --user=xyz_system xyz | gzip > /var/xyz/backup/db/xyz/`date -u +\%Y\%m\%dT\%H\%M\%S`.gz

基本的には動作します。データベースは比較的速く、指数関数的に成長します（ただし、指数はそれほど大きくありません）。現在、gzipされたダンプには約160MB必要です。データベースがダンプされると、システムはクロールを開始します。 topコマンドを使用して見た負荷平均は、約200, 200, 180でした。基本的に、サーバーはほとんど応答しません。

最初の質問は、ボトルネックがどこにあるかを判別する方法です。パフォーマンスの低下は重いI/O操作が原因ですか？テーブルロックの問題が原因ですか？多分それはメモリの問題ですか？ pg_dumpコマンドの出力は、gzipコマンドにパイプされます。それは順次ですか、つまり、ダンプ全体がメモリに配置され（スワッピングの問題ですか？）、次に圧縮されますか、それとも並行ですか（つまり、gzipは取得したものを圧縮し、それ以上待機します）？他の原因が考えられますか？

2番目の質問は、ダンプ操作をシステムの主な機能の邪魔にならないようにする方法です。私が理解している限り、データベースの整合性のため、ダンプに時間がかかることはありません。テーブル書き込みロックなどがあります。問題を制限する（またはデータベースの成長を考慮して遅延させる）にはどうすればよいですか。

番目の質問：より高度なデータベース構成について学習する時がきましたか？データベースのバックアップが実行されていない場合、システムは正常に動作しますが、DBダンプの問題が着信問題の最初の症状ですか？

filiprem · Accepted Answer

ワオ。驚くべき数の質問。いくつか取り上げたいと思いますが、この答えはまだ完全ではありません。

ボトルネックの場所を特定する方法。

最初にtopを使用して、ダンプ中に何が起こっているかを確認します。プロセスのCPU使用率、プロセスのステータスを調べます。 Dは「I/O待ち」を意味します。

パフォーマンスの低下は重いI/O操作が原因ですか？

はい、たぶん。

テーブルロックの問題が原因ですか？

多分。 pg_stat_activityシステムビューで、ダンプ中にpostgresで何が行われているかを確認します。

多分それはメモリの問題ですか？

ありそうもない。

Pg_dumpコマンドの出力は、gzipコマンドにパイプされます。順次ですか、つまり、ダンプ全体がメモリに配置されますか（スワップの問題？）

いいえ。gzipはストリームモードで動作するブロックコンプレッサーであり、すべての入力をメモリに保持するわけではありません。

そして、それとも圧縮されているのか、それとも同時に実行されているのか（つまり、gzipは取得したものを圧縮し、それ以上待つ）

はい、ブロックごとに圧縮し、出力し、さらに待ちます。

他の原因が考えられますか？

はい。

私が理解している限り、データベースの整合性のため、ダンプに時間がかかることはありません。テーブル書き込みロックなどがあります。問題を制限する（またはデータベースの成長を考慮して遅延させる）にはどうすればよいですか。

ダンプ期間は、ダンプの整合性には影響しません。整合性は、すべてのpg_dumpプロセスで繰り返し可能な読み取り分離レベルの1つのトランザクションを使用することによって保証されます。テーブル書き込みロックはありません。

より高度なデータベース構成について学ぶ時間はもうありますか？データベースのバックアップが実行されていない場合、システムは正常に動作しますが、DBダンプの問題が着信問題の最初の症状ですか？

遅すぎることはありません。 http://wiki.postgresql.org/wiki/Performance_Optimization から始めます。

Khaled · Answer

Postgresqlの継続的アーカイブを参照することをお勧めします。 pg_dumpを使用するよりも優れている点は次のとおりです。

毎回完全バックアップを行う必要はありません。最初は1回のフルバックアップで十分ですが、たとえば数日ごとにフルバックアップすることをお勧めします。
DBのサイズが大きくなったときの復元が非常に速くなります。
他のポイントに復元する機能（ポイントインタイムリカバリ）。
1時間ごと（30分程度）に増分バックアップを実行します。これは設定可能であり、更新アクティビティにも依存します。

ただし、いくつかの欠点があります（ほとんどの場合問題にはなりません）。

これらはバイナリバックアップであるため、通常はより多くの領域が必要です。 DBフォルダーは圧縮できます。
それらを別のアーキテクチャー（バイナリー・データ）で復元することはできません。