[pgsql-jp: 38543] Re: DB

[Hisakazu Nakai]

中井です。

最終的には、企業の価値観によると思うので、自分ならこうする
だろうということを挙げます。

このままの場合
　vaccumeは行っていらっしゃるのでしょうか。オンライン中に
　vaccumeできますし、やって損をすることはないと思います。
　どれくらいの頻度が適切かは、更新がどれくらいかによります。
　放っておいてレスポンスが低下しても、業務上問題なければ、
　データが増えたからといってDBは壊れることはないので、
　構わないでしょう。
　それより、4時間毎のバックアップだけでいいのかと心配に
　なります。バックアップを取りさえすればいいわけではなく、
　実際に復旧にどれくらい掛かるかを考慮すべきだと思います。
　復旧までの間、機会損失による減収がどれくらいかを一つの
　判断基準にされた方がいいと思います。

少し費用を掛けてもいい場合
　DBを一つにまとめた方が、レスポンス、メモリ消費、
　トランザクションの点で良くなります。
　バックアップが問題ならば、もう一台ハードを用意して、
　ポイントインタイムリカバリを使ってウォーアップ
　スタンバイにするか、pgpoolを使ってリプリケーションを
　行います。4時間毎のバックアップはBtoBにおいては
　気休めにもならないと思います。予備のハードがなければ、
　確実に数時間は停止しますし、故障の原因によっては、
　最悪数日間も停止します。
　私のところでは社内向けの情報サービスを提供しています。
　わずか数十Mbyteのデータベースですが、二台のサーバで
　pgpoolを使って、ほぼリアルタイムのスタンバイ構成に
　しています。

Keisuke YAMAMOTO wrote:
> このたび、BtoBサイトを企画運営する会社に転職しました。
> 転職した先では、DBは1台のマシンで社内のすべてのサービスを
> まかなっています。
> 現状で、DBが20個以上動いています。
> その理由は、DBが大きくなるとバックアップのハンドリングが
> 悪いため、1つの大きさが数Gに抑えられるようにしてきた
> とのことです。
> DBを跨ぐ仕組みは、APサーバ(PHP)で別々に読み込んで行って
> います。
> 4時間に1回ダンプを取っています。
> DBはそれぞれ、EUC、SJIS、UTF-8、と文字コードもそろって
> ない状態です。
> マシンには物理メモリーが2Gで、shared_buffers は
> 大きくするとスワップしてしまうようで、64M 割り当て
> ています。
> パフォーマンスがかなり悪くなってきているのですが、
> ダンプを取っている時間やメモリーの大きさに問題があると
> 予想しています。
> しかし、相当な変更コストがかかり、客観的に見て余程の
> 危険と、変更後のメリットがないのであれば、進言できる
> 状態ではありません。
> そこで、私はPostgreSQLで大きなDBを運用した経験がない
> ため、PostgreSQLでは、どのぐらい危険性があるのか、
> このままで運用するなら、どのようにすれば良いか、
> ご意見を賜れば幸いです。

-- 
-=-=-=-=  SHINKO ELECTRIC INDUSTRIES CO., LTD.           =-=-=-=-
=-=-=-=-    Research & Development Div.                  -=-=-=-=
-=-=-=-=      Infomation Technology Research Dept.       =-=-=-=-
=-=-=-=-  Name:Hisakazu Nakai          TEL:026-263-3922  -=-=-=-=
-=-=-=-=  Mail:nakai ＠ shinko.co.jp      FAX:026-263-4562  =-=-=-=-