次のルールを使用して、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番目の質問は:すでに、より高度なデータベース構成について学ぶ時期ではありませんか?データベースのバックアップが実行されていない場合、システムは正常に動作しますが、おそらくデータベースダンプの問題が着信問題の最初の症状ですか?
pg_dump
100%CPUで問題があり、gzipからのものでした。pg_dump --compress=0
Ubuntu 16.04で指定すると解決されます。その後もバックアップは超高速でした。コンテナーでのgzip圧縮に注意してください。あなたが期待することをしないかもしれません。