standby側での作業

su - postgres
mkdir /usr/local/pgsql/basebackup
pg_basebackup -x -h primary.server.ip -D /usr/local/pgsql/basebackup
chmod 700 basebackup
cp -a ./data/recovery.conf ./basebackup
mv ./basebackup/postgresql.conf ./basebackup/postgresql.conf.master
cp -a ./data/postgresql.conf ./basebackup/
diff ./basebackup/postgresql.conf ./basebackup/postgresql.conf.master
mv ./basebackup/pg_hba.conf ./basebackup/pg_hba.conf.master
cp -a ./data/pg_hba.conf ./basebackup/pg_hba.conf
diff ./basebackup/pg_hba.conf ./basebackup/pg_hba.conf.master

#下記の4つのコマンドはrootにて
/etc/init.d/postgresql stop
mv /usr/local/pgsql/data /usr/local/pgsql/data20160623
mv /usr/local/pgsql/basebackup /usr/local/pgsql/data
/etc/init.d/postgresql start

su - postgres
psql -p 5432 -c "SELECT pg_last_xact_replay_timestamp()"
 pg_last_xact_replay_timestamp
-------------------------------
 2016-06-23 16:27:45.726323+09
(1 row)

基本的には
作業フォルダを作成
プライマリーのホストから、スタンバイの指定のフォルダにデータをコピー
basebackupのパーミッションを変更しておかないと起動時にエラーになるのでDBのユーザ(postgres等)のみのパーミッションへ変更
masterとの差分ファイル、pg_hba.conf, postgresql.conf, recovery.conf を元フォルダからコピー
もし、*.pid ファイルとかあれば削除しておく。pg_log のフォルダの中のログもマスタのログなので必要に応じて削除
PostgreSQLを停止
ディレクトリをリネーム
PostgreSQLを起動
起動が成功したら、コマンドから動作を確認
といったながれです。
ちなみに、起動が失敗したときは

#切り戻し
mv /usr/local/pgsql/data /usr/local/pgsql/basebackup
mv /usr/local/pgsql/data20160623 /usr/local/pgsql/data
/etc/init.d/postgresql start

とかで、切り戻して、起動ログを確認して対応します。
 

コミュニティのリポジトリを使う初期の導入については、
http://lets.postgresql.jp/documents/tutorial/yum/
を参考にしてください。

ここでは、上記の導入を終了していざ、initdb を行う時の注意点として、
9.1 以上から、引数で、localeを指定出来る様になったので、

service postgresql-9.2 initdb C
といったかたちで、ロケールを C (なぜCなのかは、適当にググってください)
としておくと、環境変数の $LANG あたりに影響されずに幸せになります。

あと、一緒に default の encoding を設定したいのですが、これは引数では対応してないので
(対応自体は難しくなさそうでしたが)基本一回しかinitdbしないので、

$SU -l postgres -c "$PGENGINE/initdb --pgdata='$PGDATA' --auth='ident' $LOCALESTRING" >> "$PGLOG" 2>&1 < /dev/null
の行に
$SU -l postgres -c "$PGENGINE/initdb --pgdata='$PGDATA' --encoding=UTF8 --auth='ident' $LOCALESTRING" >> "$PGLOG" 2>&1 < /dev/null
と「--encoding=UTF8」あたりを直接書き込んでしまいます。


ここは、createdb するときにencodingを指定してあげれば回避もできるのですが、初期設定文字コード
とDBで利用したい文字コードが違うとtemplate0が使えなり、都度都度、template1等を指定してあげる
必要があるので、最初に合わせておきます。

以上の2点を忘れずに設定しておくこと。俺。

ざっくり書いてるので、詳しい人からみるとおかしい点もあるかと思いますが、気になった点はより詳しい記事が
あると思うので、調べてみてください。

明らかな間違え等々は、修正加筆したいので、コメントか twitterの @itm_kiyoまで、御願いします。
 

• Q. なんて読むの？書くの？
• A. PostgreSQL(ぽすとぐれすきゅーえる)、PとSQLは大文字。ちなみにMySQL(y以外は大文字)なんで、小文字と大文字の区別をきちんとするとその界隈の人がよろこびます。
  でも、「postgres」 とか 、「Postgres」や「ポスグレ」とか書かれてることも多いです。

• Q. どのバージョンを使うのが良いの？
• A. 最新版。とりあえず、最新版。基本的に最新版が一番機能が豊富で速い。
  ただ、その版で取り込まれた新機能については、当然バグも多くあると思うので、マイナーバージョンがすこし上がるのを待つのが良いかと思う。

• Q. 最新版が、早いといいますがベンチマークとっても早くなってなさそうなんですが。
• A. 単純なSQLだと見た目に差が出づらいです。内部のオプティマイザが苦悶するようなSQLだと差が出やすいと思います。

• Q. どのぐらいのサイクルでリリースしてるの
• A. 大体、1年か1年半ぐらいでバージョンアップしてる。2桁目までは、メジャーバージョンで、3桁目がマイナーバージョン(セキュリティパッチ等)にあたるので。
  9.1.3 は、version9.1 の3番目のバージョンという事になる。

• Q. もっと具体的におしえて
• A. 1997/01 6.0
  1998/03 6.3
  1998/01 6.4
  1999/11 6.5
  2000/05 7.0
  2001/04 7.1
  2002/02 7.2
  2002/11 7.3
  2003/11 7.4
  2005/01 8.0
  2005/11 8.1
  2006/12 8.2
  2008/02 8.3
  2009/07 8.4
  2010/09 9.0
  2011/09 9.1
  2012/09 9.2
  って感じらしいよ。

• Q. サポートあるの？
• A. サポート事業をしてる企業様があるので、そちらでお願いします。バグ報告とかは、本家の方に直接だしてもいいのだけどJPUGのMLへ投稿しても良い感じになるかも。
  あと、4世代前までしかメンテしない方針なので、今回9.2がでたので8.2のメンテナンスは打ち切られると思います。
  そう言う意味でも、できるだけ新しいのを使う方が吉。

• Q. JPUGってなによ？
• A. 日本PostgreSQLユーザ会(ユーザーと伸ばさない)。僕も所属してるけど、PostgreSQLの普及・促進を目指すNPO法人です。
  各支部とかもあるので、参加してくれると嬉しいです。

• Q. バージョンはどうやってきまるの？
• A. たぶん気分。8.xになったときは、Windows対応したので、9.xになったときは、レプリケーション対応したので、という理由だったはず。これは、1桁目のメジャーバージョンをかえるインパクトがある機能追加があった場合に変わるみたいだ。
  一説によれば、PostgreSQLは、4までしか数字を数えられないので、x.4 のあとは1桁目が上がるという説もある。この説がただしければ9.4の次は10.0という事になります。

• Q. Windows版がないんじゃ？？
• A. 8.0で、windowsも対応しました。9.0からは、64bit Windowsも対応。

• Q.ライセンスはどうなってるの？
• A. The PostgreSQL Licence (PostgreSQL) になるのですが、BSDタイプ(準拠した)のライセンスです。簡単に書くと、元のライセンス条件の記述さえ消さなければ好きに使って大丈夫ってやつ。
  もっと簡単に書くと、好きに使って問題無い！

• Q. FDWってなによ？
• A. FDW(Foreign Data Wrappe),外部データラッパっていうやつで、SQL/MED(Management of External Data)の規格の一つで簡単にいうと、PostgreSQLにQUERYを発行したら、あら不思議、外部の(たとえばMySQLとかCSV)データが取得できるという変態機能。
  twitterAPIに変更あるらしいから今後はわからにけど、twitterのデータを取ってくるとかもできる。というかラッパーが用意されてる。(ちなみに使ってみたら楽しかったｗ)

• Q. なぜその様な機能を実装したの。
• A. はい、ここ大切。標準SQLに規格の記載があったから。PostgreSQLは標準SQLに準拠する事に重きをおいてます。なんで実装されました。

• Q. 使って見ようとおもって9.1をいれたら、エスケープでwaningだでるのですが。
• A. postgresql.confの、standard_conforming_strings が on になっているとおもわれます。今すぐ、offにしてreloadするか、おそらく、「where name = 'i\'tm_kiyo'」 とかなっている所を「where name = E'i''tm_kiyo'」か、「where name = E'\'tm_kiyo'」とかに書き直してください。
  この動作は、標準SQLで規程されてるので採用されました。PostgreSQLが標準SQLに準拠する姿勢の本気度が見えました・・・

• Q. 日本語のソートがおかしいのですが。
• A. ロケール(locale)をみなおす、 「psql -l」とかで、localeをチェック。
  「C」となっていたら、あなたのプログラムがおかしいです。「ja_JP.UTF-8」とかなってたら仕様です。今すぐPostgreSQLが、8.3より古ければ「initdb --no-locale」8.4以降であれば「createdb dbname --locale=C」とかしてください。
  詳しくは、http://lets.postgresql.jp/documents/technical/text-processing/2

• Q. 昔つかってたけど、vacuumするのが面倒だよね？
• A. autovacuum を使ってください。自動でやっくれます。仕組み的には、8.1から組み込まれてるのですが、8.3からデフォルトでONになりました。
  これは、開発者達の「自動でさせても性能が劣化しないからデフォルトONにしたよ」というメッセージだとおもって、素直に使ってください。
  ちなみに、8.4からは、vaccumに関係する設置値の max_fsm_pages も自動になったので、特になにかをする事はありません。

• Q. でも、PostgreSQLって追記型なんで速度的に遅いんでしょ？
• A. MySQLは、UPDATEが行われた時に、元のデータがあった場所へデータを上書きする。
  PostgreSQLは、UPDATEが行われた時に、元のデータに削除フラグを立てて、データの最後に追記する。
  簡単に書くとこういうイメージだと思われますが、PostgreSQLの中の人たちがこの部分にメスを入れないハズはなく。
  8.2に、FILLFACTORと言う機能。(データを追加するときに、すこし空き領域をもたせる事によって、更新されたときに元のデータの近くに配置する事ができ、余計なディスクスキャンをへらす)
  8.3で、Hot(Heap Only Tuple)と言う機能(データが更新されると、必ずインデックスも更新されてた、それをスキップしちゃう)
  などの機能で、更新処理が早くなってたりします。
  
  おまけですが追記型故にDBサイズが肥大化しがちだったのですが、Hotの機能の副産物で、ガベージ(ゴミデータ)を回収(再利用)するのはVACUUMの役割だったのですが、VACUUMが動かなくても回収出来る様になりDBサイズが大きく肥大する事などがなくなりました。
  つまりは、DBの肥大化という問題も同時に解消されていっていると言うこと。
  これは、 8.4で、Visibility map(ゴミデータの監視)の機能追加とかもあるのですがVisibility mapは、9.2で実装された、「index only scan」に繋がってきてるというのは話が大きくそれるのでまた今度。

• Q. わかったけど、じゃあ、どのぐらいスケーラビリティする？
• A. 8.1で、CPUの8コア。8.2で、16コア。今度の9.2で、64コアまでスケーラビリティ。
  サーバ1台で足りなければ、9.0からはレプリケーションもあるし、pgpool-II ,Slony-I とか他にも色々あるので用途によって使い分けてください。
  (09/13:17:40 追記:CPUのスケールは、TPC-Wの様な、ほぼreadなら望めるけど、TPC-Cの様なもでるだと9.1でも8コア程度という事をご指摘頂きました、ということは9.2の64コアもread中心って事かもしれませんね。要調査。)

• Q. レプリケーションってどこまできるの？
• A. 9.0で非同期、9.1で同期、9.2でカスケーディングができます。PostgreSQLの非同期と同期は、
  スタンバイにデータを送りつけるだけが非同期。
  スタンバイにデータが送られた事を確認までできたのが同期。(MySQLでいう準同期にあたるらしい)
  なので、どちらもスタンバイ側のPostgreSQLにきちんとデータが登録されたという点までは確認してませんのでお間違えの無いように。
  ちなみに、PostgreSQLのレプリケーションはWALファイルの転送で実装しています。
  あと、業務でレプリケーションを使うなら9.1以降がお奨めです。9.1で実装された管理コマンド等があるためです。

• Q. 可用性を高めるために、2台構成で1台をウォームスタンバイしておきたけどお奨めある？
• A. 大規模なのは、やったことないのでわかりませんが、最小限のスタンバイあわせて2台構成とかなら9.1以降を利用して、同期レプリケーションをとりつつ、HAクラスタはPacemakerを使うのを個人的にお奨め。
  Pacemakerには、PostgreSQL用の設定ファイルがあるはずなんで、それを利用します。Heartbeat+DRBDでもいいのですけどね。
  
  付属の利点として、Pacemakerの萌えキャラ「かなちゃん」「かよちゃんは」を見て、（*´∀｀*）萌え～としてても業務だと言い張れます。
  一応JPUGにも「かめさん」というマスコットがいるので応援してあげてください。。(改めてみたら、名前が無い様だったので記載通り「かめさん」が名称だと勝手に解釈しています)

• Q. GUIのツールとかないの？
• A. pgadmin,phpPgAdmin とかがあります。

• Q.情報はどこからしいれるの？
• A. とりあえず、JPUGのセミナーを聞いてもらうとか、仕組み分科会の勉強会でコアな話をするとか、let's.postgres とか、postgres でググるとか、本(PostgreSQL徹底入門 第3版 あたりか？)買うとか

• Q. おいら英語が苦手でさー。
• A. PostgreSQLのドキュメントは全て日本語化されてます。これはJPUGの文書・書籍関連分科会がボランティアで行っています。
  9.2のドキュメントも2週間もあれば日本語化されると思いますが、その裏には分科会の方々のがんばりがある事を頭の片隅においておいて頂けると嬉しいです。
  分科会はMLを中心に活動してるので、可能な方は参加して頂けるともっと嬉しいです。(僕も参加してるぉ！幽霊部員だけどな！！)

• Q. どのような方々が開発してるの？
• A. PostgreSQL Global Development Group が開発しています。というと偉そうですが、世界各地の技術者がそれぞれの機能を開発して、コアメンバが取り込むかどうかを決定(先に開発の指針も)を行っています。
  マルチバイト対応をおこなった石井さんを初め、レプリケーションを実装した藤井さん等々多くの日本の開発者も開発に携わっています。

• Q. 本体に入ってない機能を使いたいのですが？
• A. 追加モジュールのcontribの事だと思います。ソースからインストールした場合は、「cd ./contrib | make | make install 」とかで組み込めるのですが9.1からは EXTENSION という管理単位が導入されたので、「CREATE EXTENSION hogehoge」とかでも組み込めます。(というかできるならこっちで)

• Q. はやりのNoSQL(Not Only SQL)の方がいいんじゃね？
• A. ひとえに、databaseといってもその目指す方向性で大きく利用形態等々が異なってきます、多くのNoSQLのアプリが、Partition Tolerance（ネットワーク分断への耐性）とAvailability（可用性）に重きを置いているのに対して、PostgreSQLをはじめとする、RDBMSは Consistency（一貫性、整合性）とAvailability（可用性）に重きを置いてます。
  誰かのツイートは、少々表示の時差があっても困りませんが、振込をして、銀行口座の残金が減ってるはずなのに、表示が変わらなかったら困りますよね(それはそれで嬉しいかもしれませんが)
  どちらが優れてるというのではなく、プロジェクト每にどのDBが最適か？で選んだ方が幸せになれると思います。
  
  とはいえ、PostgreSQLにも、XML型、JSON型等あり、それぞれの構造自体を保存して、XMLならXPath経由で必要な情報を取得できたり、contrib(追加モジュール)になりますが、hstoreという(キー、値)の組み合わせの集合を単一のPostgreSQLデータフィールドに格納するためのhstoreデータ型、つまりは 「Key Value Store」を実装していたりするので、NoSQLの側面ももっているという手前味噌な自慢をさせてくださいませ。

• Q. 良いことばかり行ってるけど弱点も教えてよ
• A. なんでしょうね。組込にむいてなとか？ 不得手はあるとは思いますが、致命的な弱点というのはあまりないんじゃないかなー？ちょっと書くの(考えるの)に疲れてきました。。。

• Q. てか機能面を教えてよ、どのような事ができるとか。
• A. 色々できるので、またこんどで。というか書いてたらきりがない。PostGISとか特徴的なことはあるけど。なんか色々できます。だいぶ書くの(考えるの)に疲れてきました。。。。。。

• Q. よし、今○○使ってるけど、乗り換えてみるか！マイグレーションは簡単？
• A. 簡単でないと思うけど事例はあります、JPUGのセミナーでマイグレーションの話とかもやってます。当然、マイグレーションのサービスをしてくれる企業様もあるので興味がある方は調べてみるといいと思います。

ということで、なんかツッコミとかされたた、加筆修正します。

--
なんかたったこれだけ書くのに4時間かかったぉ(>_<)