[pgsql-jp: 36082] Re: ramdisk上のtablespaceの効果

[Morita Kazuro]

森田です。
谷田様。さっそくお答えくださりありがとうございます。

リカバリの問題は、再立ち上げ後に root で実行するスクリプトと、
DBの実行ユーザーで実行する２つのスクリプトをつくりました。

root で実行する方では mke2fs と mount をしてさらに postgres ユーザーのための
パーミッションを設定するなどしています。
DBの実行ユーザー動かすスクリプトでは、一旦古いテーブルを一旦、drop table し、
テーブルスペースを drop tablespace してから create tablespace し、create table
するようになっています。

ようするに、古いテーブルスペースの実体がなくなっていても、drop table や drop tablespace は
WARNING:  could not remove relation 41179150/45677313/45677519: No such file or directory
などと警告はでますが、エラーにはならないようなのです。このあと、create tablespace、create table
をすれば、一見したところでは復活しているようなのです。
本番サーバーのクローンのテストサーバーでは動くことは確認しました。


----- Original Message ----- 
From: "TANIDA Yutaka" <tanida ＠ sraoss.co.jp>
To: "PostgreSQL Japanese Mailing List" <pgsql-jp ＠ ml.postgresql.jp>
Sent: Monday, October 03, 2005 2:10 PM
Subject: [pgsql-jp: 36078] Re: ramdisk上のtablespaceの効果


> 谷田です。
> 
> On Mon, 3 Oct 2005 13:21:54 +0900
> "Morita Kazuro" <morita ＠ yuki.ad.jp> wrote:
> 
> > WEBを使ったロールプレイングゲームという性格上、URLを直にたたかれるとまずいので、
> > 直前にアクセスしたURLとそこからリンクしているURLを常にテーブルに保持しております。
> > このテーブルはユーザーのアクセスごとに必ず参照、更新が行われ、１日あたり数百万回の
> > update があります。このテーブルへの参照、更新がデーターベース全体の数割をしめています。
> > 
> > で、このテーブルへのアクセスの高速化ができればと思い、この部分をramdiskからmountした
> > 所を使ったtablespaceにすることを検討しております。もし、電源ダウンが起こればこのテーブル
> > は消滅しますが、この場合はシステムの再立ち上げであり、ユーザーにはトップページからアクセス
> > してもらうことになり、いずれにしろこのテーブルは初期化されるからです。
> > 
> > で、質問ですが、ramdisk を使うのと、その領域を shared_buffers にするのでは、どちらが
> > 高速化を期待できるのでしょうか？
> 
> ramdisk上にtablespaceを置くと、クラッシュ後、再起動してしまったときにファ
> イルがなくなっているのがリカバリ時の妨げになるので、復旧処理が大変なので
> はないでしょうか。
> 
> 私的には、上記のような事象なら、専用に別のオンメモリDBを用意するのが筋か
> なと思います。もちろん、それに相当する機能をPostgreSQLで用意できていれば
> 理想だったのでしょうが・・・
> 
> -- 
> TANIDA Yutaka <tanida at sraoss.co.jp>
> 
>