本作品はCC-BYライセンスによって許諾されています。通じてお寄せいただきますようお願いいたします。Incの米国、およびその他の国における商標もしくは登録商標です。Corporationの商標です。その子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。氏の日本およびその他の国における登録商標または商標です。Hat,Inc.の商標または登録商標です。Corporationの米国及びその他の国における登録商標または商標です。その子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。その子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。Canadaのカナダにおける登録商標およびその他の国における商標です。米国およびその他の国における登録商標です。Councilの商標です。商標または登録商標として使用している場合があります。PGECons)は、PostgreSQL本体および各種ツールの情報収集と提供、整備などの活動を通じて、ミッションクリティカル性の高いエンタープライズ領域へのPostgreSQLの普及を推進することを目的として設立された団体です。技術部会ではPostgreSQLの普及に資する課題を活動テーマとし、3つのワーキンググループで具体的な活動を行っています。年度まではそれぞれ、「性能ワーキンググループ」、「設計運用ワーキンググループ」という名称で活動してきました。2016年度は、従来の活動領域を広げる意図のもとでそれらを再定義し、上記のような名称に改めました。これに伴い、WG3ではPostgreSQLの設計運用を中心としたさまざまな課題の解決のための調査検証を行い、PostgreSQLが広く活用される事を推進していくこととしました。本資料はWG3の2017年度の活動として、WindowsにおけるPostgreSQLについて、インストレーション、ユーティリティコマンド、HAの切り口で調査、検証した結果をまとめたものです。8.0.0のリリースからWindowsをサポートするようになりました。高可用性を想定した構成を組むための情報があまり整理されていない状況にありました。今年度はWindows上でのPostgreSQLに関して、実際にWindows環境での検証と机上調査を通して情報を整備することを目的として活動しました。本資料の読者は以下のような知識を有していることを想定しています。インストレーションを実施した環境とLinux版PostgreSQLとの差異について説明します。インストール方法について検証します。検証した環境は以下の通りです。環境構築¶ソースからのインストレーションの検証には、以下の環境を利用しました。記載に沿った内容として、Perlのランタイムに以下を使用した検証も実施しました。制限がある場合があります。使用する目的に応じたエディションを選択ください。Express」を選択してダウンロードします。インストーラの手順に従ってインストールします。SDK」を選択してダウンロードします。インストーラの手順に従ってインストールします。インストーラの手順に従ってインストールします。2017を起動します。配下に移動し、ビルドコマンドを実行します。build.bat以下のようなメッセージが表示されていれば、ビルドは成功しています(警告の件数、経過時間は環境により増減することがあります)。build.bat(省略)ビルドに成功しました。[インストール先ディレクトリ]以下のようなメッセージが表示されていれば、インストールは成功しています。動作確認¶インストールしたバイナリが動作するか簡単にテストします。インストール方法について検証します。使用したインストーラのバージョンは以下の通りです。環境構築¶Windows環境でのソースからのインストレーションと同一の環境を利用しました。PostgreSQLのバージョンとインストール先のOSが選択できます。インストール¶ダウンロードしたインストーラを起動します。インストール先のディレクトリを選択します。今回は「C:\PostgreSQL_Install」とします。インストールするコンポーネントを選択します。DBクラスタの作成先を選択します。データベースのスーパーユーザのパスワードを入力します。DBの待ち受けポート番号を選択します。本検証ではindows環境でのソースからのインストレーションと同一環境を利用したため、ポート番号を「5433」に変更しています。使用するDBのロケールを選択します。これまで選択したインストール条件を確認します。インストールを実施します。以下の画面が表示されれば、インストールは完了です。動作確認¶インストールしたバイナリが動作するか簡単にテストします。[サービス]の順にクリックし、「postgresql-10」サービスに対して[サービスの開始]を実行します。c:\PostgreSQL_Install\dataデータベースシステム内のファイルの所有者は"[コマンドを実行したユーザ名]"ユーザでした。このユーザがサーバプロセスを所有しなければなりません。データベースクラスタはロケール"Japanese_Japan.932"で初期化されます。ロケールにより暗示される符号化方式"SJIS"はサーバ側の符号化方式として使用できません。デフォルトのデータベース符号化方式は代わりに"UTF8"に設定されます。ロケール"Japanese_Japan.932"用の適切なテキスト検索設定が見つかりませんデフォルトのテキスト検索設定はsimpleに設定されました。データベージのチェックサムは無効です。ローカル接続向けに"trust"認証が有効です。pg_hba.confを編集する、もしくは、次回initdbを実行する時に-Aオプション、または、--auth-localおよび--auth-hostを使用することで変更することができます。本章では、以下の環境に対して比較を実施しました。それぞれの環境でのpg_configコマンドの実行結果を以下に示します。実行ファイルやDLLファイルが生成されます。配下に実行ファイル(pgbench.exe)が生成されています。配下にDLLファイル(pg_stat_statements.dll)が生成されています。postgresql.confのshared_preload_librariesに「pg_stat_statements」を設定することで利用可能になります。以下の条件を満たす場合に、「Windows対応状況」列を「○」としています。Windows対応状況を一覧にしています。「Windows対応状況」列の凡例は、リリースノート等の公式文書内の記述を元にしており、以下の基準で記載しています。今年度の検証でのまとめを以下に記述します。ソースからのインストレーション、インストーラからのインストレーションの2種類の方法について動作検証を実施しました。Expressを使用したWindowsネイティブな環境を使用しました。PostgreSQLのコマンドを利用するサードパーティのソフトウェアの動作に影響を与える可能性があります。可能な限り、避けることをお勧めします。今年度の検証でのまとめを以下に記述します。インストーラからのインストールによって構築できる内容を示しました。ソリューションや業務パッケージへの組み込み用途など、インストレーションをカスタマイズしたい場合には、ソースからのインストレーションを検討ください。UNIX環境でのインストレーションと同様のカスタマイズはできない場合があることにご注意ください。contribモジュールについてはWindows環境でも利用可能なように、インストレーション実行時に必要なモジュールがインストールされます。PostgreSQL本体に含まれない周辺ツールについては、Windowsで使用可能なものは限定的です。そのため、データベースの構築先としてWindowsの要件がある場合には、要件を満たす代替手段の検討画必要になる場合があります。Windows環境で正しく動作するか、また差異がないかといった観点で確認を行いました。確認した項目は下記の4項目です。信頼性や性能の向上を目的にWALの書き出し先を変更することがあります。本節では、Windows環境において変更する場合の手順を確認しまとめます。事前準備¶インストーラでインストールした場合、デフォルトでデータベースクラスタが作成され、自動起動するようになっています。起動しているPostgreSQLを停止し、自動起動しないように設定変更を行います。WindowsのサービスからPostgreSQLサービスの設定を開きます。status:」にある「Stop」ボタンを押すと、起動しているPostgreSQLが停止します。type:」で「Disabled」を選択することで自動起動をオフにします。事前準備が整ったら、initdbコマンドでデータベースクラスタを初期化します。検証で用いた環境は以下の構成になっています。E:\pgwal(*)インストーラからのインストレーションで指定したディレクトリです。Linux環境同様、initdbコマンドの-XオプションでWAL書き出し先のディレクトリを指定することでWAL書き出し先を変更できます。初期化後、データベースクラスタ配下のファイル・フォルダを確認すると、次のようになっています。Linux環境では、pg_walがシンボリックリンクとして作成されますが、Windows環境では「JUNCTION」として作成されます。Explorerから確認すると、次のようにフォルダに矢印がついた形で見えます。実現方式の違いはありますが、Windows環境でもinitdbコマンドでWALの書き出し先を変更できることが確認できました。本節ではpg_ctlコマンドを用いたPostgreSQLの起動・停止を確認します。start」で起動できます。stop」で停止できます。status」での状態確認も問題なく行えます。上記の通り、pg_ctlコマンドを用いてPostgreSQLの起動・停止が行えることを確認しました。本節では、Windows環境固有のログ出力であるイベントログへの出力について確認します。ログの出力先はpostgresql.confのlog_destinationパラメータで変更できます。'syslog'」と設定することでシステムログにPostgreSQLサーバのログを出力し、一元管理できます。'syslog'」を指定するとどのような挙動をとるのか確認しました。上記のようにlog_destinationにsyslogを含めた場合、PostgreSQL起動時に次のようなエラーが起こり、PostgreSQLの起動に失敗します。"syslog".」とあるように、Windows環境ではキーワードとしても"syslog"は受け付けないようです。'eventlog'」に設定することでイベントログへの出力がなされるようになります。イベントログの確認¶PostgreSQLをインストーラからインストールした場合、デフォルトのイベントソースとして"PostgreSQL"というエントリが登録されます。"PostgreSQL"という値はevent_sourceパラメータのデフォルト値でもあるため、インストール後にlog_destinationの設定を変えるだけで、次のようにイベントビューアでイベントログを確認できます。event_sourceパラメータはpostgresql.confで変更可能です(もしくは起動時のオプションで変更可能)。変更後の値(上記例では"PGECons")が、イベントソースのエントリとして登録されていないためこれだけではイベントログは出力されません。イベントログを出力するためには、次のようにregsvr32コマンドを用いてイベントソースのエントリを登録します。することで、イベントビューアに"PGECons"というイベントソースを持つイベントログが出力されるようになります。上記の通り、Windows環境固有のイベントログ出力の設定方法および動作確認を行いました。本節では、PostgreSQLのバックアップ、リストアについて「論理バックアップとリストア」、「物理バックアップとリカバリ」の2つを確認しました。論理バックアップとリストア¶まずは、pg_dumpコマンドを用いた論理バックアップとpg_restoreコマンドを用いたリストアについて確認します。事前準備としてtestdbデータベースを作成し、tblテーブルに1000件のデータを挿入しています。その後、pg_dumpコマンドを-Fc(カスタム形式)をつけて実行します。pg_restoreコマンドでカスタム形式のバックアップファイルを確認するとLinux環境同様にSQL文が列挙されていました。新たにデータベースを作成し、バックアップファイルをpg_restoreコマンドでリストアすることで問題なくバックアップ取得時の状態を再現できました。Recovery)の動作を確認します。Cドライブ直下にアーカイブWALを格納するディレクトリを作成します。postgresql.confでWALアーカイブの設定を行います。具体的には、archive_modeをonにし、archive_commandを設定します。archive_commandではcopyコマンドを用いてWALファイルをアーカイブWAL領域へとコピーするように設定しています。archive_commandで「"%p"」などのようにパスの部分をダブルクォテーションでくくらないと正しくarchive_commandが実行されませんでした。設定が終わったら、PostgreSQLを再起動します。再起動が完了したら、すべての準備が整いましたので、ベースバックアップの取得を行います。次の例では、pg_basebackupコマンドを用いてベースバックアップを取得しています。PITRの挙動確認のため、追加で1000件のデータを挿入します。この時のトランザクションIDを記憶しておき、後ほどこの時点まで復旧するようにします。次の例では手順ミスを想定してtblテーブルのデータをすべて削除しています。以降の手順を簡単にするため、この時までのWALがすべてアーカイブされるようpg_switch_wal関数を利用しました。ここからPITRを行っていきます。PostgreSQLを停止し、現行のデータベースクラスタを退避させています。その後、次のようにxcopyコマンドを用いて取得したベースバックアップをデータベースクラスタとしてリストアします。これだけではWindows環境で権限が不足していたため、別途Explorerから所有者のフルアクセス権限を付与し直しました。引き続き、recovery.confの設定を行います。recovery.confのサンプルファイルであるrecovery.conf.sampleは「<インストール先>\share」配下にあります。次の例ではrecovery.conf.sampleをデータベースクラスタ配下にrecovery.confという名前でコピーしています。recovery.confに、アーカイブWALのリストア設定およびリカバリ完了時点を設定します。リストア設定はarchive_commandの設定同様にcopyコマンドを用いて、アーカイブWAL領域からWAL領域へとコピーするようにしています。リカバリ完了時点の設定は、先ほどの手順ミス前に確認したトランザクションID(590)をrecovery_target_xidに設定しています。最後にWAL領域を削除し、E:\pg_walへのジャンクションを作成します。ジャンクションはmklinkコマンドに"/J"オプションを付けることで作成できます。PostgreSQLの再起動です。アーカイブWALのリストアおよびリカバリが行われます。リカバリ完了時点に到達すると、PostgreSQLは一時停止モードになります。この状態はPostgreSQLへの接続および参照クエリのみが実行できる状態です。tblテーブルの内容を確認し、想定する時点(例では2000件のデータが存在する時点)までのリカバリが行えてるか確認します。問題がないようであれば、pg_wal_replay_resume関数を実行してリカバリを完了させます。論理バックアップからのリストア、物理バックアップからのリカバリともにLinux環境と同様の挙動となることを確認しました。本章では、Linux環境とWindows環境でのPostgreSQLの運用手順の差異について確認しました。本章で確認した範囲でいえば、細かい違いはあるものの、大筋の流れは差異なく実施できると言えます。環境におけるPostgreSQLのHigh-Availability(以下HA)構成について説明します。等を導入する事が一般的かと思います。WSFCを利用する場合は、共有ディスクが必要になります。WSFCを用いずPgpool-IIをクラスタソフトウェアとして利用することで、Windowsに構築したストリーミングレプリケーション構成のPostgreSQLを管理でき、HA構成を実現できます。Pgpool-II自体はWindows未対応のため、Linux環境の構築が必要となります。説明し、本構成でできる事・できない事を明らかにします。Pgpool-IIのフェイルオーバー等Linux環境に閉じた部分は、本章では紹介しません。検証環境の概略図は以下になります。検証環境構成図アプリケーションからのトランザクションは、全てLinuxサーバ(pgpool1)に構築されたPgpool-IIに投入されます。Pgpool-IIは3台のWindowsサーバ上に構築されたPostgreSQLを管理します。実施可能か検証するため、PostgreSQLは3台設定します。0))に投入され、ストリーミングレプリケーションによって他の2台のDBサーバへ反映されます。参照処理はPgpool-IIのロードバランス機能によって、3台のDBサーバに割り振られます。各サーバの詳細は下表の通りです。2)また、各サーバにインストールするソフトウェアと設定概要は下表の通りです。構築準備¶HA構成の構築を始める前にシステムの基礎的な環境を整える必要があります。ここでは下記3点について説明します。実施時にPgpool-IIが起動するシェルの中で、ホスト名で名前解決できるようにするため、hostsファイルを設定します。Pgpool-IIが起動するシェルの中でssh通信を行う際に、パスワードが要求される事により処理が停止する事態を回避するため、pgpass.confを設定します。Pgpool-IIと各DBサーバ間で通信するため、Windows環境にSSHを設定します。各サーバのホスト名を登録します。"C:\Users\Administrator\AppData\Roaming\postgresql\pgpass.conf"*:*:*:postgres:postgres*:*:replication:postgres:postgresPgpool-IIでPostgreSQLを制御するにはssh経由で行いますが、デフォルトでsshはインストールされていません。sshはマイクロソフトがプレリリース版を出しているので、そちらを利用するため設定を行いたいと思います。Windowsのsshは下記サイトよりダウンロードします。ready)」との表記がありますので、利用するにあたってはご注意ください。ダウンロードファイルはzip形式になっています。起動して、上記zipファイルの展開によって生成されたOpenSSH-Win64フォルダに移動します。移動した先で下記のようにコマンドを実行し、SSHをインストールします。下記の実行例は、Cドライブ直下に展開したフォルダを配置した場合の例になります。installed」が表示されれば、sshd及びssh-agentのインストールは完了です。次に、FirewallがSSHの通信を許可するように設定を変更します。引き続きPowerShellで以下のコマンドを実行します。規則は、ストアから正常に解析されました。規則は、ストアから正常に解析されました。」が確認できたら、firewall設定は完了です。念のため設定状況を確認します。規則は、ストアから正常に解析されました。OK」となっていれば、SSHの通信が許可されている事になります。次にホストの認証キーを生成するため、下記のコマンドを実行します。ED25519このコマンドを実行した結果、下記のファイルが作成されます。コメントアウトを外します。yes次にSSHクライアントとしての秘密鍵と公開鍵のペアを作成するために、ssh-keygenコマンドを実行します。このコマンドでは、下記実行例の「※※」で示す通り、3か所で入力を求められます。1回目の入力では、ファイルの出力先の指定を求められます。デフォルトの場合は、何も入力せずにEnterのみ入力します。2回目の入力では、生成する鍵のパスフレーズの入力を求められます。本環境では公開鍵認証によりパスフレーズなしでログインできるようにするため、ここでも何も入力せずにEnterのみ入力します。3回目にもう一度同じパスフレーズ(何も入力しない)を入力します。