ホーム   »  スポンサー広告  »  スポンサーサイト  »  Linux   »  pgpool  »  pgpoolを導入する上での注意点

スポンサーサイト

広告
  
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


Yahoo!ブックマーク Googleブックマーク はてなブックマーク livedoorClip del.icio.us newsing FC2 Technorati ニフティクリップ iza Choix Flog Buzzurl 
ランキングはこちらをクリック!
▲ Page Top     

pgpoolを導入する上での注意点

広告
  

pgpoolの注意点



レプリケーションについて


同じ問い合わせを送っても異なる結果を返すようなデータ,たとえば乱数やト ランザクションID,OID,SERIAL,シーケンス,CURRENT_TIMETSTAMPのような ものに関する問い合わせをレプリケーションすることはできません(正確に は,同じ値でレプリケーションされる保証がありません). SERIALやシーケンスに関しては,関連テーブルをロックすることによって回避 することもできます.
※insert_lockを有効にしておけばテーブルロックを利用して同期が取られます。

# vi /opt/db/pgpool/etc/pgpool.conf
insert_lock = true





オーバヘッドがあります


PostgreSQLに対するアクセスはすべていったんpgpoolを経由するため, その分のオーバヘッドがあります.




すべてのlibpqプロトコルがサポートされていません


現時点では,以下の機能がサポートされていません.

trust, clear text password以外の認証方式(レプリケーションモード時)
trust, clear text password, crypt, md5以外の認証方式(非レプリケーションモード時)
pgpoolに対して,pg_hba.confによるアクセス制御はサポートされて いません
pgpool自体にpg_hba.confによるアクセス制限はかかりません
TCP/IPコネクションを許可している場合(後述の allow_inet_domain_socketが1の場合),pgpool自体にはどのホストか らでも接続できてしまいます.必要ならばiptablesなどを使ってアク セス制限をかけて下さい. (pgpool-IIにはアクセス制限機能があります)



template1, regressionという名前のデータベースについて


template1, regressionという名前のデータベースはコネクションプールの対象になりません




一時テーブルについて


CREATE TEMP TABLEで作成されたテーブルはフロントエンドがセッションを終 了しても削除されません.これは,コネクションプールの効果でバックエンド から見るとセッションが継続しているように見えるからです.セッションの終 了時に明示的にDROP TABLEするか,トランザクションブロックの中でCREATE TEMP TABLE ... ON COMMIT DROPをお使い下さい.reset_query_listを活用す ることもできます.PostgreSQL 8.3以降では,reset_query_listに"DISCARD ALL"と書くことによって この問題が解決できます.




PREPAREについて


同じ理由でPREPAREで作成されたプランはセッションが終わっても削除されま せん.DEALLOCATEで明示的に削除してください.PostgreSQL 8.3以降では,reset_query_listに"DISCARD ALL"と書くことによって この問題が解決できます.


デッドロック対策


(1) セカンダリはマスタの問い合わせ処理が終了後、問い合わせを処理をさせる。

# vi pgpool.conf
==========================
replication_strict = true
==========================



※masterとsecondaryの並列処理ができません。


(2)特定問い合わせのみ、セカンダリはマスタの問い合わせ処理が終了後、問い合わせを処理をさせる。
replication_strictをfalseにした上で,デッドロックが発生する可能性のある問い合わせの先頭に特別なキーワード「/*STRICT*/」を入れる
「/*STRICT*/」をSQLコメントとして挿入すると,この問い合わせだけはmasterとsecondaryが並列処理しなくなるので,デッドロックが起きない。必要な個所だけ/*STRICT*/を記入すればパフォーマンスの低下を最小限に押さえられる。

/*STRICT*/ LOCK TABLE t1;




バックアップ


pgpool経由でのバックアップは、load_balance_modeやreplicate_selectなどの設定によりバックアップが失敗することがあります。
よって、PITRや論理バックアップ(pg_dump, pg_dumpall)は、直接PostgreSQLからバックアップした方が無難です。




ホスティング・レンタルサーバの紹介
ジュース1本分でレンタルサーバ

★月額105円~/容量最大30GB/機能満載! ロリポップ!レンタルサーバー ★

■超オススメのWADAXレンタルサーバー












関連記事
スポンサーサイト


Yahoo!ブックマーク Googleブックマーク はてなブックマーク livedoorClip del.icio.us newsing FC2 Technorati ニフティクリップ iza Choix Flog Buzzurl 
ランキングはこちらをクリック!
▲ Page Top     

Comment
Trackback
Trackback URL
Comment Form
管理者にだけ表示を許可する
サイト紹介

仕事で遭遇したトラブル対応をまとめたサイト。インフラエンジニア、サーバエンジニアとしてスキルアップするための情報(IT講座、Linux、Postfix、PostgreSQL、MySQL、Apache、Java、セキュリティ対策、おすすめ書籍)提供します。
全記事表示リンク
カテゴリ
スポンサーリンク

サーバエンジニアのための書籍
プロフィール

hotally

Author:hotally
仕事:インフラエンジニア
取得資格:第2種基本情報処理
     情報セキュリティスペシャリスト
     ネットワークスペシャリスト
     PostgreSQLCE シルバー

アクセスランキング
[ジャンルランキング]
コンピュータ
618位
アクセスランキングを見る>>

[サブジャンルランキング]
Webサービス
27位
アクセスランキングを見る>>
ブログ
最新記事
カテゴリークラウド
スポンサーリンク


RSSリンクの表示
リンク
ブロとも申請フォーム
QRコード
QR
Lc.ツリータグリスト
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。