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

Iwao Watanabe iwao3 @ DSL.gr.jp
2003年 3月 18日 (火) 08:53:18 JST


こんにちは

----- Original Message ----- 
From: "Naofumi Kondoh" <nkon @ shonan.ne.jp>
To: <pgsql-jp @ ml.postgresql.jp>
Sent: Tuesday, March 18, 2003 2:42 AM
Subject: [pgsql-jp: 29444] Re: DBのバックアップとレストアについて


> > 新サーバーにて
> > 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時間ほどかかっております。
(snip)
> 原因がわからないときの常套手段ですが、
> psql に  -E オプションをつけて internal commands
> も表示するようにすれば、何かヒントがつかめないでしょうか。

最近の事情は知らないのですが、少なくとも 7.1.2 については
pg_dump が出力するSQLはスペックの低いマシンへの配慮が足りないもので、
大きめなDBを扱う業務には、そのまま使うには向いていないと考えています。

いくらautocomitで登録するとはいえ、
10万件を超えるデータを copy 一発で
登録しようとするコードを生成するのは感心しません。
メモリが少ないマシンだとそれだけで固まってしまいます。
1000件くらいで分割して出力してくれればいいのに。

私はDB丸ごと別バージョンに移行するというとき以外は
-t オプション無しで起動することはしません。
インクリメンタルバックアップをシステムが提供してくれない都合上、
スキーマ定義時にバックアップすべきテーブルを洗い出して
アプリケーションレベルでバックアップ専用テーブル
(元テーブルの内容を適当な件数に分割したもの、
あるいは日付を埋め込んでいるものなら指定した日付以後を抽出したもの)
を作り出して、テーブル単位でバックアップしています。
もちろん復元するアプリケーションも
スクリプトレベルの単純なものですが 別途開発します。

本番DBのデータを開発機に移すときにも使えますよ。






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