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


8

次のルールを使用して、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番目の質問は、システムの主な機能のためのダンプ操作は控えめにする方法です。私が理解している限りでは、データベースの整合性のため、ダンプに時間がかかることはありません。テーブル書き込みロックなどがあります。問題を制限する(またはデータベースの成長を考慮して遅延させる)にはどうすればよいですか。

3番目の質問は:すでに、より高度なデータベース構成について学ぶ時期ではありませんか?データベースのバックアップが実行されていない場合、システムは正常に動作しますが、おそらくデータベースダンプの問題が着信問題の最初の症状ですか?

回答:


13

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

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

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

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

はい、たぶん。

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

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

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

ありそうもない。

pg_dumpコマンドの出力は、gzipコマンドにパイプされます。それはシーケンシャルですか、つまり、ダンプ全体がメモリに配置されます(スワッピング問題?)

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

そして、それとも圧縮されますか、それとも並行しますか(つまり、gzipは取得したものを圧縮し、さらに待ちます)?

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

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

はい。

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

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

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

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


FWIW、pg_dump100%CPUで問題があり、gzipからのものでした。pg_dump --compress=0Ubuntu 16.04で指定すると解決されます。その後もバックアップは超高速でした。コンテナーでのgzip圧縮に注意してください。あなたが期待することをしないかもしれません。
リゲマー

5

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

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

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

  1. これらはバイナリバックアップであるため、通常はより多くの領域が必要です。DBフォルダーは圧縮できます。
  2. 別のアーキテクチャ(バイナリデータ)でそれらを復元することはできません。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.