システム カタログ › データベース アプライアンス › PGSQL64 - PostgreSQL データベース アプライアンス

PGSQL64 - PostgreSQL データベース アプライアンス

機能の概要

重要： CA 3Tera AppLogic 2.8+ では PGSQL を使用できません。代わりに PGSQL64 を使用してください。

PGSQL64 は、PostgreSQL データベース エンジン（http://www.postgresql.org）に基づいたデータベース アプライアンスです。 任意のアプリケーションにデータベースを簡単に追加できる方法を提供します。 PGSQL64 は、MYSQLx アプライアンスによって現在サポートされていない多くの機能をサポートするエンタープライズ スタイルのデータベース アプライアンスです。 これらの機能の一部として、ストアド プロシージャ、トリガ、ビューおよびユーザ定義データ型が含まれます。

PGSQL64 は、各 PGSQ64L インスタンス上で設定できるアプリケーション定義ボリューム上にデータベースを格納します。 空のボリューム上で起動されると、PGSQL64 はオプションで空のデータベースを作成します。 PGSQL64 データベース ボリュームは複数の PGSQL インスタンス間で共有できません（PGSQL インスタンス当たり 1 つのデータベース ボリューム）。

PGSQL64 クライアントは、in 端子を通じて設定されたデータベースにアクセスします。 データベース リクエストは、同じ端子で処理されて完了し、元に戻ります。 PGSQL64 では、有効な Postgres ユーザが in 端子を通じてデータベースにアクセスできます（アプライアンスには 1 つの設定済みスーパーユーザの役割があります： 標準の「postgres」）。 PGSQL64 は、in 端子を通じてサポートされる同時接続の最大数で設定できます。

PGSQL64 では、log 端子を通じてアクセスできるデータベース ログの管理も行えます。 ログはデータベース情報およびエラー ログ記録を追跡するのに役立ちます。 ログ パス、名前、有効期間および内容を設定できます。 また、さまざまなデータベース統計とデバッグ情報を有効にして、データベース アクセス パターンのプロファイリングおよび問題/エラーの診断を促進することもできます。

一般に、GSQL64 は、汎用 Web データベース アプリケーション（単純なクエリを実行する多くのユーザが存在する小規模データベース）または判断サポート データベース（複雑なクエリを実行する少数のユーザが存在する大規模データベース）のいずれかに使用されます。

境界

リソース

注： 同時ユーザ数とデータベース サイズという 2 つの主要要因に基づいて、メモリを増やす必要があります。 通常、PGSQL は、メモリ 128MB 当たり約 80 人の同時ユーザをサポートできます。 データベースが大きいほど、PGSQL は処理用のメモリ要求が増大します。 たとえば、PGSQL は少なくとも 1G の 10G データベース用メモリで設定する必要があります。パフォーマンスを向上させるには、1G を超えるメモリが推奨されます。

端子

デフォルト インターフェースは有効です。 （SSH 経由の）診断およびトラブルシューティング用です。 このアプライアンスの今後のバージョンで SSH アクセスを無効にする可能性があります。

ユーザ ボリューム

重要： データ ボリュームは PGSQL インスタンスに排他的に使用する必要があります（他のアプライアンスと共有できない）。

プロパティ

注： PGSQL プロパティはどれもファイル名とパス以外は大文字と小文字を区別しません。

ロギング プロパティ

重要： ログ記録が有効で、log 端子が接続されていない場合、PGSQL アプライアンスは起動に失敗します。

カスタム カウンタ

log_cmd_stats プロパティが「yes」に設定されている場合、PGSQL アプライアンスは mon 端子を介して以下のカスタム カウンタをレポートします。 これらのカウンタは PostgreSQL カウンタ グループに属します。

エラー メッセージ

アプリケーションの起動に失敗した場合、以下の内容のエラーがシステム ログにログ記録される場合があります。

ダッシュボード メッセージ

ユーザに注意を呼びかける必要がある重大エラーが検出された場合、PGSQL は、以下のようにグリッドのダッシュボードにメッセージをログ記録します。

ディスク空き容量がしきい値を下回ると、これらのメッセージは、1 回のみログ記録されます。

パフォーマンス

PGSQL のパフォーマンスは、sync_on_write、log_filename および log_cmd_stats プロパティ値の著しい影響を受けます。 fsync、ログ記録および統計をすべて無効にすると（sync_on_write=no、log_filename=""、log_cmd_stats=no）、最良のパフォーマンス結果が得られます。 以下の表は、これらの機能を有効および無効にしたときに実行されるサンプル pgbench テスト結果を示しています（秒当たりのトランザクション数を示す tps 単位で指定）。 pgbench はデータベースのパフォーマンスを測定するために PostgreSQL に含まれているユーティリティです。

典型的な使用状況

シンプルな 2 層アプリケーション（Web データベース アプリケーション）

以下の図は、単純なクエリを実行する多くのユーザ向けの 2 層 Web アプリケーションでの PGSQL アプライアンスの標準的な使い方を示しています。

使用するアプライアンス：

• usr - 入力ゲートウェイ
• srv - アクティブなコンテンツ（たとえば CGI スクリプト）を備えた Web サーバ
• dbase - PostgreSQL データベース アプライアンス

クライアント リクエストは usr ゲートウェイ上に着信します。 ゲートウェイが Web サーバにリクエストを転送し、この Web サーバがリクエストを提供します。 srv 上のスクリプト（たとえば Perl または PHP）は、永続データにアクセスする必要があるときに、db 端子を介して dbase アプライアンスを使用します。

この例では、dbase とともに使用されるデータベースは読み取り専用ではなく、多くのユーザが srv を通じてアクセスして、単純なクエリを実行できます。 そのため、dbase は 256MB のメモリを使用するように設定されています。 また、データベースはデータベース エラー ログ ファイル（ログ端子は接続されていません）を維持しません。

プロパティ設定の例：

注： dbase 上にデータ ボリュームも設定する必要があり、web 上にコンテンツ ボリュームを設定する必要があります。 ここで使用できるアプリケーション ボリュームを作成するには、「グリッド ユーザ ガイド」を参照してください。

拡張性のある 2 層アプリケーション（Web データベース アプリケーション）

以下の図は、データベースを使用して、複数の負荷分散サーバ間で状態とデータが共有される 2 層 Web アプリケーション内の PGSQL アプライアンスの典型的な使用状況を示しています（単純なクエリを実行する多くのユーザ向け）。 さらに、この例には、管理者がデータベースにログインしてメンテナンスできるメンテナンス用の個別の入力および管理者が PostgreSQL エラー ログにログインして表示することができる入力があります。

使用するアプライアンス：

• usr - ユーザ リクエスト用の入力ゲートウェイ
• webs - ユーザ リクエスト用の web ロード バランサ
• srv1、srv2 - アクティブなコンテンツ（CGI スクリプトなど）を備えた Web サーバ
• 設定 - Web サーバ コンテンツ ストレージ
• dbase - PostgreSQL データベース アプライアンス
• logs - データベースと Web エラー ログ ファイル用のストレージ
• maint - メンテナンス アクセス用の入力ゲートウェイ
• admin - 管理者によって使用される汎用 Linux サーバ
• gway - 管理者のインターネットへのアクセス用のネットワーク ゲートウェイ
• log - データベース エラー ログへのアクセス用の入力ゲートウェイ

クライアント リクエストは usr ゲートウェイ上に着信します。 ゲートウェイは Web ロード バランサにリクエストを転送し、Web ロード バランサはいずれかの Web サーバ（srv1 または srv2）にリクエストを方向付けます。 Web サーバ上のスクリプト（Perl や PHP など）が永続データにアクセスする必要がある場合、db 端子を介して、dbase アプライアンスを使用します。

dbase データベースは log 端子を介して logs アプライアンスにそのエラー ログを書き込みます。 さらに、管理者はログ ゲートウェイを介して logs アプライアンスにログインして、データベース エラー ログ ファイル（および Web サーバ ログ ファイル）を表示できます。

また、管理者は SSH 経由で maint ゲートウェイを介して、admin サーバにログインできます。 admin サーバから、管理者は、統計またはデータベース スキーマの変更のために dbase データベースにアクセスできます。 admin サーバは、たとえば、より新しいバージョンのライブラリやデータベース スキーマをダウンロードするために、gway ゲートウェイを介してインターネットにアクセスできます。

この例では、dbase とともに使用されるデータベースは読み取り専用ではなく、多くのユーザが Web サーバを通じてアクセスして単純なクエリを実行できます。 そのため、dbase は 256MB のメモリを使用するように設定されています。 また、データベースは 1 週間分のログ ファイル（1 日 1 ファイル）を保持するように設定されています（それぞれの週が終わると、ログ ファイルは上書きされます）。

プロパティ設定の例：

注：

• dbase アプライアンス上にデータ ボリュームも設定する必要があり、logs アプライアンス上にコンテンツ ボリュームも設定する必要があります。

maint、admin、gway および log アプライアンスは 2 層アプリケーションの操作に必要ありません。 admin サーバが存在する場合、admin サーバにデータベースのスクラブ、電子メールの送信などのためのクローン ジョブがある場合があります。

シンプルな 2 層アプリケーション（判断サポート システム）

以下の図は、サイズが数 GB の大規模データベース上で複雑なクエリを実行する一部のユーザ向けの判断サポート システムを実装する2 層 Web アプリケーション内の PGSQL アプライアンスの典型的な使用状況を示しています。

使用するアプライアンス：

• usr - 入力ゲートウェイ
• srv - アクティブなコンテンツ（たとえば CGI スクリプト）がある Web サーバ
• config - Web サーバ コンテンツ ストレージ
• dbase - PostgreSQL データベース アプライアンス
• logs - データベースと Web エラー ログ ファイル用のストレージ
• admin - ログ ファイルを表示するための入力ゲートウェイ

クライアント リクエストは usr ゲートウェイ上に着信します。 ゲートウェイが srv サーバにリクエストを転送し、この srv サーバがリクエストを提供します。 srv 上のスクリプト（たとえば Perl または PHP）は、永続データにアクセスする必要があるときに、db 端子を介して dbase アプライアンスを使用します。 dbase アプライアンスはログによってエクスポーズされた共有のルート ディレクトリ内にログ ファイルを格納するように設定されています。

ブラウザを使用して、管理者は admin ゲートウェイに接続して、PostgreSQL ログ ファイルを表示します。 admin ゲートウェイは logs NAS アプライアンスにリクエストを転送します。

この例では、dbase で使用されるデータベースは読み取り専用ではなく、多くのユーザが複雑なクエリ（何百万もの行にアクセスする大規模なクエリ）を実行する srv 経由でこのデータベースにアクセスする場合があります。 そのため、dbase は 1536MB のメモリを使用するように構成されます。 また、データベースは 1 週間分のログ ファイル（1 日 1 ファイル）を保持するように設定されています（それぞれの週が終わると、ログ ファイルは上書きされます）。

プロパティ設定の例：

注： dbase アプライアンス上にデータ ボリュームも設定する必要があり、logs アプライアンス上にコンテンツ ボリュームも設定する必要があります。

シンプルな 2 層アプリケーション（Web 読み取り専用データベース アプリケーション）

PGSQL アプライアンスの一般的でない使用状況として、読み取り専用データベースを使用する 2 層 Web アプリケーションが考えられます。 これはデータベースが読み取り専用（変更不可）であることを除いて、前の単純なアプリケーション例と同じです。 読み取り専用データベースに必要とされないさまざまな PostgreSQL 機能をオフにするため、読み取り専用データベースを使用するように、PGSQL をパラメータ化することが重要です。その結果、パフォーマンス（データベース自動バキューム、データベース変更統計など）が向上します。

プロパティ設定の例：

データベース アプリケーションのデバッグ

PGSQL は、パラメータ化されたログ ファイル（log_filename）を使用してデータベースをデバッグできるようにプロパティをエクスポーズします。 たとえば、これは、ユーザが SQL ステートメントをトラッキングしたり、SQL ステートメントの実行にかかる時間を見たり、SQL ステートメントが失敗する理由を見たりする場合に便利です。 デバッグ情報には次のものが含まれます。

• PostgreSQL によってエクスポーズされた標準的なデバッグ情報
• SQL ステートメント処理および実行統計（クエリに便利）
• SQL コマンド、データベース行レベル アクセスなどに関する PostgreSQL 統計。
• ユーザ接続/切断

通常、データベースをデバッグするために、以下のプロパティが設定されます。

デバッグ情報は log 端子を介してアクセスされたエラー ログ内に格納されるか、または PostgreSQL 統計ビュー（http://www.postgresql.org/docs/8.3/static/monitoring-stats.html）の 1 つによって利用可能です。

注

以下の点に留意してください。

• PGSQL は、複雑度が比較的低いデータベース用途（マスタ/ スレーブ、レプリケーションなしなど）を想定して設計されています。 より高度な機能を備えたデータベースを必要とする場合は、お問い合わせください。
• PGSQL では、有効な Postgres ユーザがデータベースにアクセスできます（スーパーユーザとして postgres とルートの役割が新たに設定済み）。in 端子を通じてアクセスする場合、ユーザ パスワードは無視されます。 データベースには、in 端子を通じて、または PGSQL アプライアンス自体でローカルにアクセスできます。
• ボリューム要件
  • データ ボリュームが ext3 ファイルシステムで作成されていることを確認してください。それ以外の場合は、PostgreSQL の起動に失敗します。
  • auto_create が yes に設定されている場合は、ボリュームを空のまま（作成直後の状態）にできます。 起動されると、PGSQL は空のデータベースをボリューム上に作成します。
  • ボリュームにはデータベース データのみが含まれます。 データは、新しい（たとえば、より大きい）ボリュームにファイルをすべてコピーすることによって移動させることができます。
  • データ ボリューム上の PostgreSQL 設定ファイルは /appliance/conf ディレクトリからコピーされます。
  • 既存のデータベースの場合、PGSQL は、PostgreSQL PG_VERSION ファイルがボリュームのルート ディレクトリに存在することを想定します。 このファイルが見つからない場合、PGSQL はデータベースが無効であると想定し、auto_create が yes に設定されていると上書きします。
• 読み取り/書き込みデータベース（read_only は no）の場合、PGSQL はデータベースの自動バキュームを実行します。 これにより、データ ボリューム上のディスク領域を節減できます。 これは PostgreSQL のビルトイン機能です。 自動バキュームを行わないと、データ ボリュームが満杯になる可能性があります。 自動バキュームを有効にするには、log_cmd_stats 設定を yes にする必要があります。
• PGSQL に接続されたアプライアンスには、専用のデータベースとテーブルが存在しない場合に作成する役割があります。 または、手動でデータ ボリュームに初期データベースをコピーできます。
• PGSQL の in 端子に接続されたアプライアンスまたはサーバで PostgreSQL サーバにアクセスしてリクエストをサブミットするには、PostgreSQL クライアント ライブラリが必要です。 このライブラリはここでダウンロードできます。
• 参照情報：
  • http://www.postgresql.org -- PostgreSQL の Web サイト

http://www.postgresql.org/docs/8.3/interactive/index.html --PostgreSQL 8.3 ドキュメント

このアプライアンス上で使用されるオープン ソースおよびサードパーティ ソフトウェア

アプライアンス ベース クラス上にあるソフトウェア（LUX64 は PGSQL64 のベース クラスです）に加えて、以下のオープン ソース サードパーティ ソフトウェアが使用されます。