TOP>企業情報>コラム>技術情報>はじめましてPostgreSQL! Vol.2

はじめましてPostgreSQL! Vol.2

はじめましてPostgreSQL!

前回はPostgreSQLのインストール手順を解説しました。第2回目となる今回はデータベースが使えるようになるまでの初期設定手順を解説します。

(全4回連載)

Vol.2 誰でも簡単!PostgreSQLのインストールと初期設定(初期設定編)

PostgreSQLに必要な初期設定


前回はGUIを使ってPostgreSQL 9.1のインストールを行いました。画面の指示に沿って進んでいけば良いので、簡単にインストールできたのではないでしょうか。

本稿では初期データベースの稼動確認やパラメータ設定、リモート接続設定など、PostgreSQLを利用する際に必要となる初期設定について整理します。

データベースの稼働確認


One Click Installerでインストールが正常終了すると、PostgreSQLの初期データベースが作成され、PostgreSQLインスタンスも起動されています。

まず、コマンドライン操作ツールであるpsqlおよび、PostgreSQL管理GUIツールのpgAdmin-IIIを利用してデータベースへの接続を確認してみましょう。

One Click Installerを利用したインストール手順の「ステップ4」にて、データベース管理者ユーザ postgresを作成しており、初期データベース名もpostgresとなっていますので、以下のように接続します。

・psqlでの接続確認

SQL


※-d データベース名
 -U ユーザ名

「postgres=#」のプロンプトが表示されていれば正常に接続されています。次に、データベース設定情報が格納されているpg_database カタログから、One Click Installerで設定した、ロケール設定を確認してみます。

・pg_databaseカタログの確認

SQL


※pg_databaseカタログ
  使用可能なデータベースの属性情報が格納されています。
 datname列
  データベース名
 datcollate列
  文字の並び順
 datctype列
  文字種

上記のように、One Click Installerを利用したインストール手順の「ステップ6」にて、指定したロケールの「ja_JP.UTF-8」に設定されていることがわかります。なお、「templateX」とは、データベースを作成する際のテンプレートとして機能するデータベースです。

次に、GUIのPostgreSQL管理ツールのpgAdmin-IIIを利用してデータベースに接続してみましょう。

「アプリケーション」→「PostgreSQL 9.1」→「pgAdmin III」を選択して、pgAdmin-IIIを起動します。

pgAdmin IIIの起動

pgAdmin IIIの起動

pgAdmin IIIの起動後の画面

pgAdmin IIIの起動後の画面

pgAdmin IIIのオブジェクトブラウザに表示されている「PostgreSQL 9.1(localhost:5432)」をダブルクリックすると、ユーザ postgres のパスワード入力画面が表示されますので、パスワードを入力してください。

ユーザ postgres のパスワード入力画面

ユーザ postgres のパスワード入力画面

正常に接続できれば、データベース、テーブル空間、グループロール、ログインロールなどのオブジェクトがオブジェクトブラウザに表示されます。

pgAdmin-IIIで対象データベースへ接続後の画面

pgAdmin-IIIで対象データベースへ接続後の画面

オブジェクトブラウザでは、対象となるオブジェクトをドリルダウンすることで属性情報を参照、変更したり、テーブルであれば格納されているデータを参照することができます。

pgAdmin-IIIのオブジェクトブラウザ

pgAdmin-IIIのオブジェクトブラウザ

以上のように、初期データベースに簡単に接続できることがわかりました。

One Click Installerで作成された初期データベースを、このまま利用することもできますが、次の項では、初期データベースを活用するためのカスタマイズ設定について簡単にご紹介します。

クライアントからの接続制限


まず、PostgreSQLに接続できるクライアントの制限方法について説明します。

データベースは企業の大切なデータを保持しているため、不特定のクライアントから接続を許可するのではなく、信頼されるクライアントからの接続のみ許可する設定が必要です。

・リモートからの接続可否

データベース・パラメータの「listen_addresses」でリモートからの接続を許可するかどうかを設定できます。One Click Installerで導入した場合、すべてのネットワークインターフェースからのリモート接続を許可する「*」という設定となっていますので、接続できるネットワークインターフェースを限定する場合、「listen_addresses」に、ホスト名やIPアドレスをカンマ区切りで指定します。

「listen_addresses」などの、データベース・パラメータを格納しているpostgresql.confファイルは、One Click Installerの「ステップ3」で指定した、データディレクトリに存在します。

例えば、「listen_addresses = '*'」 を 「listen_addresses = 'localhost,192.168.132.0'」 に変更することで、自ホスト(localhost)からのループバック接続と、192.168.132.0 のインターフェースからのリモート接続を許可する設定に変更できます。

・listen_addresses (string)の変更

SQL


※先頭に「#」が付いている行は、コメントです。

postgresql.conf ファイルのデータベース・パラメータ値の変更をデータベース・インスタンスに反映させるには、データベース・インスタンスを再起動する必要があります。pg_ctlコマンドを利用してデータベース・インスタンスを再起動し、設定したパラメータが有効になっているかどうかをpsqlのshowコマンドで確認してみましょう。

・データベース・インスタンスの再起動とデータベース・パラメータの確認

SQL


※pg_ctlコマンド
  restart
   データベース・インスタンスを再起動する
  停止オプション
   -m:
    データベース・インスタンスを停止するモードを選択できます。
   smart:
    データベースに接続しているセッションが終了するまで待機(デフォルト)
   fast:
    データベースに接続しているセッションを強制的にロールバックして停止
   immediate:
    データベースに接続しているセッションを強制終了して停止

※psql の showコマンド
 現在のデータベース・インスタンスのパラメータに設定されている値を表示
 show パラメータ名;

なお、テスト環境の場合やネットワークインターフェースが1つしか存在しない環境であれば、「listen_addresses」はOne Click Installerで設定される「 * 」でも構いません。

・クライアント認証

今度は、接続元ホスト、接続先データベース、接続ユーザを指定した接続可否設定です。どのクライアントから、どのデータベースへ、どのユーザとしての接続を許可する、もしくは拒否するという設定を行えます。設定ファイルは One Click Installerの「ステップ3」で指定した、データディレクトリに存在するpg_hba.confファイルです。

One Click Installerで導入した場合、以下のようにローカル接続(local)、ローカルループバック(127.0.0.1/32)のTCP/IP接続(host)の全てのユーザ(all)が、任意のデータベース(all)に任意のデータベースユーザ名(all)で接続することを許可されていますが、md5のパスワード暗号化が行われた認証が必要となっています。

・pg_hba.conf

SQL


TYPE
  接続のタイプを指定します。
   local:ローカル接続
   host:TCP/IPのリモート接続

DATABASE
  対象となるデータベースを指定します
   all:すべてのデータベースを意味します
   データベース名:制御対象となるデータベース名

USER
  対象となるPostgreSQLユーザを指定します
   all:すべてのユーザを意味します
   ユーザ名:制御対象となるユーザ名

ADDRESS
  対象となるホストおよびネットワークを指定します。
  IPアドレスの範囲指定は、「192.168.10.0/24」のようにIPアドレス/マスク長」の形式で記述します。

METHOD
  接続がこのレコードに一致する場合に使用する認証方式を指定します。
   trust
    接続を無条件で許可します。
   reject
    接続を無条件に拒否します。
   md5
    クライアントに対して認証時にMD5暗号化パスワードを要求します。

そのほかの、認証方式や設定についてはPostgreSQL日本語マニュアル「第19章クライアント認証 」を参照ください。

以下のように設定することで、IPアドレス「192.168.40.149」から、postgresデータベースにpos910ユーザでmd5暗号化パスワードでの接続を許可することになります。

・pg_hba.conf

SQL


なお、pg_hba.conf への変更内容は、pg_ctl reload により、設定値を再読込みさせれば有効になります。

・pg_hba.confの変更内容の反映

SQL


サーバログ設定


次はPostgreSQLのサーバログの設定について説明します。PostgreSQLが稼働している間に発生する警告やエラーメッセージをサーバログに出力させることで、障害が発生したときに迅速な調査を行うことができます。問題が発生してもサーバログに必要な情報が出力されない場合、再度、同様の問題が発生し、サーバログに警告やエラーメッセージが記録されるまで対策を打ちにくい状態となり、問題解決が長期化する可能性が高くなります。そのため、問題発生時の状態を確認できるサーバログ設定が最低限必要です。

ポイントは、警告やエラーメッセージを出力するプロセスを特定できる情報を追加すること、そしてパフォーマンスの分析に必要となるログ情報もあらかじめ出力する設定にすることです。

以下の主要なサーバログ関連のデータベース・パラメータの設定を参考にしてください。

サーバログ関連のデータベース・パラメータ設定


PostgreSQLのメモリ/リソース関連の設定


続いて、PostgreSQLのメモリ / リソース関連のデータベース・パラメータの設定について説明します。

データベースに登録されるデータはファイルとしてハードディスクに保存されているため、多数のユーザからの様々なSQLの要求のたびに、ハードディスクからデータの入出力を行うと、要求に応えるまでの待ち時間が長くなったり、同時に多数の要求を処理することが困難になります。そのため、何度もアクセスされるデータをコンピュータの主記憶装置(メインメモリ)に一時的に保持することで、ハードディスクへの入出力を抑える仕組みが実装されています。このメインメモリに確保されるデータを一時配置する領域をPostgreSQLでは「共有バッファ」と呼び、データベース・パラメータの「shared_buffers」でサイズを設定しています。そのほか、変更履歴であるWAL(Write Ahead Logging)を一時的に保持するWALバッファ「wal_buffers」や、SQLで指定されるソート処理を行う作業領域「work_mem」、メンテナンス処理で利用する作業領域の「maintenace_work_mem」などが存在します。

このようなメモリやリソース関連のパラメータを厳密に調整するには、本番環境のPostgreSQL稼働状況の診断と、その診断結果に応じたパラメータ・チューニングを繰り返す必要がありますが、8割程度のチューニング成果を求めるのであれば、メインメモリの範囲内で、ざっくりとしたガイドラインを利用して各種パラメータ設定値を検討した方が時間的にも工数的にも効率的です。

また、接続セッションの最大数 「max_connections」のように、設定値に達してしまうと上限を拡張しない限り、そのリソースを得ることはできないパラメータもありますので注意しましょう。

以下のメモリ/リソース関連の主要なデータベース・パラメータの設定を参考にしてください。

データベース・パラメータの設定


変更履歴のアーカイブ設定


最後にデータベースのデータを格納しているファイルに障害が発生した際に、データが消失しないための設定について説明します。

前項にて、ハードディスクへの入出力を抑えてパフォーマンスを向上させる仕組みとして、PostgreSQLでは「共有バッファ」が実装されていると説明しました。たしかにパフォーマンスの向上はできるのですが、メモリ中のデータ変更をすぐにディスクに反映させないことで、メモリとディスクのデータの状態にズレが生じることになります。また、メモリ中のデータはサーバ障害などでPostgreSQLが異常終了してしまうと消失します。このように、サーバ障害などが発生した場合には、トランザクションの変更を保証することができなくなってしまうため、PostgreSQLでは変更履歴ログであるWAL(Write Ahead Logging)によって変更内容を保証する仕組みが実装されています。WALは名前の通りトランザクションで変更されたデータよりも先に、変更履歴をディスクに書き込むことで、データベース・サーバがハードウェア障害により異常終了した場合でも、ディスクに書き込まれていた変更履歴からデータを復旧する仕組みです。

ただ、デフォルト設定では、WALセグメントファイルと呼ばれる変更履歴ファイルが循環利用により上書きされるため、ディスク障害などでデータを格納しているファイルに障害が発生した場合は、バックアップ・ファイルから障害発生直前までのデータに復旧することができません。そこで、WALセグメントファイルが上書きされる前にWALセグメントファイルをコピーするための設定として、データベース・パラメータの「wal_level」、「archive_mode」、「archive_command」を変更します。

「wal_level」のデフォルト値:minimalは、サーバの異常終了に伴うデータベース・インスタンスのクラッシュリカバリに必要な情報のみWALファイルに書き出す設定になっています。そのため、データを格納しているファイル障害からリカバリに必要となる情報を書き出す設定であるarchiveに変更します。

「archive_mode」は、WALセグメントファイルのアーカイブ設定を有効にするかどうか制御しており、アーカイブ設定を有効にするためには「on」を設定します。「archive_command」は、WALセグメントファイルをコピーする際のOSコマンド(cpコマンドなど)を指定します。循環利用されているWALセグメントファイルの書き込み先が切替るタイミングで「archive_command」に指定されたコマンドによって以前書き込み先であったWALセグメントファイルがコピーされます。

変更履歴(WAL)のアーカイブ設定

Ready to Install 画面

また、このような、WALセグメントファイルのアーカイブ設定を行っておけば、PostgreSQLデータベースを稼働させた状態でデータベース全体の物理ファイルのコピーであるオンライン・バックアップを取得できます。データベースのオンライン・バックアップとWALセグメントファイルのアーカイブを利用することで、オンライン・バックアップのリストアとWALアーカイブによるリカバリが可能となり、データを保持するファイルに障害が発生する直前の状態までデータベースを復旧することができます。

オンライン・バックアップの手順や、データベースのリカバリ方法については別途、詳細を説明する機会を設けたいと思います。

2回にわたってPostgreSQL 9.1のインストールと初期設定手順を解説してきましたが、大半がGUIの操作なので予想以上に簡単だったのではないでしょうか。

PostgreSQLは商用RDBMSと比べても遜色ない基本機能を有しているため、商用RDBMSを利用している方も違和感なく利用することができると思います。

次回は、PostgreSQLに、より使いやすいGUIツールやOracle Databaseからの互換機能が追加されたPostgres Plus Advanced Serverについて解説します。

※補足
PostgreSQLのデータベース・パラメータのデフォルト値と設定値の違いを確認するためには、pg_settingsカタログを参照してください。

・One Click Installerで作成された初期データベースの場合

SQL


  • Postgres Plus は、EDB Postgres の旧製品名です。


執筆者紹介

岸和田 隆

岸和田 隆(Takashi Kishiwada)

株式会社アシスト データベース技術本部

アシスト入社後、Oracle Database の研修講師、フィールド・ サポート、新バージョンの検証を経て、2007年 自社ブランド 「DODAI」の準アプライアンス製品の企画・開発、2009年 PostgreSQL、2011年 EDB Postgres、MySQL / MariaDB の事業立上を担当。 現在は「データベースのアシスト」を目指した活動を行っている。

岸和田の紹介記事はこちら



関 俊洋

関 俊洋(Toshihiro Seki)

株式会社アシスト データベース技術本部

2006年、株式会社アシスト入社。データベース・システムの構築や運用トラブルの解決といったフィールド・サポート業務を経験し、その後は新製品の検証やハードウェアとデータベースを組み合わせたソリューション(DODAI)の立ち上げに従事。現在はデータベースの価値や魅力を伝えるための執筆・講演活動を行っている。『SQL逆引き大全363の極意』共著。

関の紹介記事はこちら

連載記事一覧


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る