[pgsql-jp: 29444] Re: DBのバックアップとレストアについて

Naofumi Kondoh nkon @ shonan.ne.jp
2003年 3月 18日 (火) 02:42:06 JST


ソフト工房の近藤です。

雲@Unimedia Inc. wrote:

...略...

> 新サーバーにて
> 2:pg_dump 旧DB名 -Fc -v -b -h 旧HOST名 -u  | split -b 1m - ファイル名
> 3:create 新DB名
> 4:cat ファイル名* | psql 新DB名
> 
> そこで、2の作業をすると1Mのファイルが2462個出来ました。
> そして4の作業は、現在も処理中です。
> すでに12時間ほどかかっております。
... 略 ....

原因がわからないときの常套手段ですが、
psql に  -E オプションをつけて internal commands
も表示するようにすれば、何かヒントがつかめないでしょうか。

後は、find $PGDATA -ls 等で、どういうファイルができつつ
あるか確認するとか。

# UNIX ファイル名と表名の対応は作りかけのプログラム
# があります。SCEMA 対応にして近く公開します。
# もっと使いやすいのがあるのではと思いますが、参考までに。
http://www.softkoubou.co.jp/study/pgls/pgls.c

一般論ですが、

index を付けたままで pg_dump していると、index 作成に
時間がかかりますので、drop index してから、pg_dump ,
コピーして、最後に create index するのも時間短縮の
常套手段です。

データー移行期間中だけ、同期書き込みを外すとか、
WAL が独立した DISK DRIVE でない場合は、バッファーを
大きくして flushing 期間を大きくとると効果がある
かもしれません。ちゃんと試したことないので推測ですが。

後は、小さめのテーブル1つだけで同じ処理をしてみて
どうなるか確認してみるとか。

/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
 (株)ソフト工房   近藤直文        Email:  nkon @ shonan.ne.jp
http://www.SOFTKOUBOU.co.jp/      http://www.shonan.ne.jp/~nkon/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/





pgsql-jp メーリングリストの案内