データベースのバックアップ
いつもお世話になっております。
Zabbixのデータベースのバックアップについてアドバイスを頂きたい事があります。
サービスサーバの監視をzabbixで行っているのですが、データベースのサイズが肥大化しています。
運用自体は充分なハードディスク容量を積んでいるのでまだ余裕は有るのですが、定時バックアップで
ダンプを行った際に、Zabbixの監視が実質停止している状況を確認しました。
具体的にはダンプを始めてから終わるまでに以下の現象が起きています。
・障害を検知してもアラートが飛ばない(逆に飛び続ける事もありました)
・障害を検知した時間からかなり遅れてアラートが飛んでくる
・ダンプが終わった後に概要から最新の値等を見た時に値が欠けている(酷い時はダンプ期間中の全ての値が有りませんでした)
現在データベースの容量は70GBあります。
基本的に過去の監視データを削除するというポリシーは無いため、ヒストリやトレンドは3650(10年分)で設定しています。
基本的にダンプを行ってもデータベースの動作に影響は無い筈なので、少なくとも監視データの更新等に影響は無いと思っていたのですが、現状だとそうもいかない模様です。
またrsyncを使った同期バックアップも、ダンプ程では無いものの、断続的に監視が停止していました。
大規模なデータベースのバックアップでZabbixの監視を停止する事なく行う方法は有りますでしょうか？
<導入情報>
OS：Gentoo
Postgresql 5.4.5
zabbix 1.8.3
kodai - 投稿数: 1341
どのようなコマンドでダンプを取得されたのでしょうか？
PostgreSQLはあまり使っていないのでダンプ取得についても知識がないのですが、少なくともMySQL InnoDBではダンプコマンドに適切なオプションを指定しないとダンプ中はデータベースにロックがかかります。
MySQL InnoDBと同様、PostgreSQLでもトランザクション機能が働いていると思うのですが、一貫性のあるデータを取得するためにダンプ時はロックがかかっているということはないでしょうか？
MINTIA - 投稿数: 40
お返事有難うございます。
ダンプコマンドは
pg_dumpall を引数無しで実行しています。
pg_dumpはロックをかけないので、データベースに対する他の作業を妨げません。
なので、理論上はZabbixの更新作業に影響は無いと思っています。
実際にダンプ中のZabbix関連のプロセスは特に問題なく立っていますが、DBへ更新がされていないみたいです。
KAZ - 投稿数: 1085
MINTIAさん
念の為に「ACCESS EXCLUSIVE」になってないか確認して貰えますか？
PostgreSQL/ロック確認方法
http://u-16.sakura.ne.jp/u16wiki/?PostgreSQL%2F%A5%ED%A5%C3%A5%AF%B3%CE%C7%A7%CA%FD%CB%A1
上記でロックがかかってない事が確認できれば、それ以外の原因と切り分けできますので…
宜しくお願い致します。m(__)m
fripper - 投稿数: 495
＞pg_dumpはロックをかけないので、データベースに対する他の作業を妨げません。
＞なので、理論上はZabbixの更新作業に影響は無いと思っています。
確かにそのとおりなのですが‥
pg_dump 実行中は、他のソフトからロックを取得することができなくなります。
zabbix 内部での db 更新は、その大半がトランザクションになっているため、
ロック→更新→コミット
の繰り返しとなっています。
結果、pg_dump でのダンプ中は、zabbix からのほとんどの更新がされなくなります
正確には、ロックが取得できなくなる‥というか、取得を待たされるだけなのですが、
結果的にはタイムアウトしてしまい、エラーになる、ということです。
kodai - 投稿数: 1341
私も少し調べてみました。
たしかに日本語のマニュアル翻訳サイトには「pg_dumpはデータベースに対する他の作業を妨げません」とあるのですが、flipperさんの回答と同じく英語のサイトでは例外として以下のことが書かれていました。
PostgreSQL 8.4.5 Documentation: Chapter 24. Backup and Restore:
「Exceptions are those operations that need to operate with an exclusive lock, such as most forms of ALTER TABLE.」
http://www.postgresql.org/docs/8.4/static/backup-dump.html
少し古いですがpg_dumpとlockが競合するという情報もありました。
pg_dump中に更新処理が出来ない
http://blogs.yahoo.co.jp/clay_design/11457955.html
Zabbix側の動きは確認していませんが、KAZさんの通りpg_dumpを取得している間のロック待ちの状態を確認してみるのが早いと思います。それから、Zabbixサーバのログにデータベースに接続できなかったエラーログは出ていないでしょうか？
原因がpg_dump中のロック待ちということであれば、容量が70GBとなるとダンプ処理にもかなり時間がかかると思うので、その間ロック待ちを続けるのは難しいと思います。(Zabbixサーバはデータベースへの接続が失われても、プロセス自体は落ちないようになっています。)
他のバックアップ方法として思いつくのは、以下の方法でしょうか。postgresqlで実現できるのかは知らないのですが...
- mysqlのバイナリログに相当するもので発行されたSQLそのものをバックアップしておく
- レプリケーションを組んでスレーブ側でバックアップを取る
それから、データベース稼働中にrsyncでバックアップを取るのは危険です。おそらくデータの整合性が取れなくなってしまいますし、最悪データが破損する可能性があります。
MINTIA - 投稿数: 40
>KAZさん
ロック方法の確認が手動で出来るのは知らなかったです。
ダンプ中はロックはかからないと思っていましたが、例外が有るみたいですね・・・
既にpg_dumpによるバックアップは停止していますが、更新処理がされない時の確認に活用させて頂きます。
>fripperさん
なるほど・・・
ダンプ中はロックをかけないという単純な認識でいましたが、ロック情報の取得に関しては例外なのですね。
確かにZabbixの更新が出来ない事も頷けます。
となると、サイズの大小に限らずpg_dumpは単機構成のZabbixのデータベースのバックアップには向かないですね。
>kodaiさん
postgresqlにもPITRというバックアップ機構が有るので、そちらでバックアップを検討してみます。
元々postgresqlのバックアップにpg_dumpを使うのが習慣になっていたので、Zabbixも同様にして
いたのですが、そうもいかないですね。
実際に何度かテストでrsyncを行ってみたら、rsync終了後にデータベースがエラーを吐き続けて監視が停止する事態が発生しました。
rsyncしたデータを持ってきて、pg_xlogを無理矢理resetしたりしてpostgresqlを立て直しましたが同様でした。
確かに危険ですね・・・
とりあえずpg_dumpとrsyncによるバックアップを停止し、PITRによるバックアップに切り替えてみます。
貴重なアドバイス有難うございました。大変参考になりました。
KAZ - 投稿数: 1085
MINTIAさん
参考になるか分かりませんが…
NPO法人 日本PostgreSQLユーザー会
[url=http://www.postgresql.jp/branch/nagoya/npug2007/backup_pitr.pdf/download]バックアップとPITR[/url]
MINTIA - 投稿数: 40
>KAZさん
資料有難うございます。
PITRが有る事自体は知っていましたが、運用するのは始めてなので充分に調査・テストして取り入れようと思います。
実質、PITR以外に選択肢が無い状況だと、かえってどの方法でバックアップを取るか悩む必要が無いのでシンプルでよいですね。