□PostgreSQL9.2のレプリケーションを試してみた□PostgreSQL9.2のレプリケーションを試してみた□PostgreSQLのレプリケーションを試してみたhttp://lets.postgresql.jp/documents/technical/replication/1http://www.interdb.jp/techinfo/pg_sr/sr_sync01.htmlhttp://d.hatena.ne.jp/hiroe_orz17/20111113/1321180635PostgreSQLは9.0から非同期レプリケーション(データ複製とか冗長化とか)に対応している。9.1からは同期レプリケーションにも対応している。『レプリケーションだけなら』pgpool-IIとかは要らず、基本的にはマスターとスレーブ双方でちょこっと設定するだけでOKとなっている。コレをCentOSのKVM上に設定して、レプリケーションの実際をテストしながら試してみる。マスターサーバーをmaster00として、レプリケーション先サーバーをsub01とsub02とする。・開発ツールをとりあえずインストールする。1.el6_2と、古いのでレプリケーションテストが出来ない。別途PostgreSQLのリポジトリから最新版を取って来る。/usr/src/package/PostgreSQL9.2とかを取ってこれるリポジトリを落として来てインストール。postgresqlとして、postgresql92シリーズがリストにある事を確認してから、インストール。postgresql92-contribで、入ったらデータベースの準備とかしましょう。onあとは、実際のレプリケーションテストに入ること。sub02として追加する。md5そしたらマスターサーバーのレプリケーション設定をする。この段階ではまだレプリケーションはOFFにしておいた方がいいらしい。restart)はあとでonにする。これらのパラメータをいじったらrestartしろと書いてあるのでする。restartそしたらテスト用のデータを入れてバキュームしてきれいにしておく。–analyzeここまで準備が出来たらマスターサーバーのレプリケーションをONにする。今回はDBサーバーが別々になるのでNFSも面倒だし、ということでしないことにする。実際にはデータベースの用途(信頼性その他)で決定すること。allmax_wal_sendersはレプリケーション先サーバーを二機としているので2+1で3としている。synchronous_standby_namesには、このあとで設定するレプリケーション先サーバー名(別にHOSTNAMEと同じでなくてもいいけど)を列記する。したらマスターサーバーのPostgreSQLを再起動。restart■マスターサーバーからレプリケーション先サーバーにレプリケーションまずは一括コピー。試しに、本来とは違うディレクトリにバックアップコピーしてみる。tablespaceこんな感じでコピーできたら、本来のデータディレクトリにコピーする。–progress続いてレプリケーション先サーバーの設定。application_name=sub01’のようにして、マスターサーバーへの接続設定と、非同期レプリケーションの時にはなかった「application_name=sub01」という、自身のサーバー名を設定する。設定を追加したら、レプリケーション先サーバーsub01のPostgreSQLをとりあえず手動で起動。ストリーミングレプリケーションがプライマリに無事接続できましたという感じになる。同期スタンバイが設定されていますと言うようにsub01が繋がったというメッセージが出る。syncというように確認できる。potentialのように増える。ver9.1の同期レプリケーションはスレーブ1台のみ有効なのでslave2はslave1が停止するまで”非同期レプリケーション”で稼働する」ということらしい。■レプリケーションの確認マスターサーバーで、以下の二行をコピペする。asyncとなるが、この時「sent_location」と「replay_location」の差が同期の差。asyncというように、差がなくなって同期も取れたことが判る。pg_last_xact_replay_timestamp()”とすると、いつまでのデータをマスターサーバーからレプリケーションしたかという日時を見ることが出来る。13:16:23.2158+09レプリケーション処理が発生しないと、コレは空っぽのまま。参考URLにも書いてあるが、PostgreSQLはそれ自体がトラブって落ちたとしても、何か便利に自動的に切り替わってサービスが継続できると言うわけではない。Pacemakerやpgpool-IIの管理機能などを組み合わせることで、上位アプリが(比較的)意識しなくてもデータベースが切り替わるように仕組みを作らないといけない。自分たちでサービスを継続する仕組みそのものを作ったほうがいいと未だに思う。上記のようなツールを使っても、トラブルがそれらの想定を超えた場合には、何も出来なくなるようなことは避けたほうがよい。トラぶった時のデータの整合性を確認しなければならないのだから、いかに迅速にサービスを復旧できるかだろう。レプリケーションのメリットは、このいわばほぼリアルタイムバックアップができるということと、参照に限った負荷分散と言うことになるんだろうかなー。一度はやってみると、レプリケーションと言うのは何処まで、どのようにやってくれるのか判るので、何処から自分たちでフォローしなければいけないかも見えてくるんじゃないかと思う。コメントをキャンセルメールアドレスが公開されることはありません。*サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。