PostgreSQLエンタープライズ・コンソーシアム 技術部会 WG#3

2017年度WG3活動報告書
Windows環境調査編

PostgreSQL Enterprise Consortium

目次
目次
1. ライセンス2. はじめに2.1. PostgreSQLエンタープライズコンソーシアムとWG3について
2.2. 本資料の概要と目的
2.3. 本資料の構成
2.4. 想定読者
3. PostgreSQLのインストレーション
3.1. Windows環境でのソースからのインストレーション
3.1.1. 前提条件
3.1.2. 環境構築
3.1.2.1. Microsoft Visual Studio Express 2017 for Windows Desktopのインストール
3.1.2.2. Microsoft Windows SDKのインストール
3.1.2.3. Strawberry Perlのインストール
3.1.3. ビルド
3.1.4. インストール
3.1.5. 動作確認
3.2. Windows環境でのインストーラからのインストレーション
3.2.1. 前提条件
3.2.2. 環境構築
3.2.3. インストーラの入手先
3.2.4. インストール
3.2.5. 動作確認
3.3. インストレーションのカスタマイズ可否および各種ツールのWindowsでの対応状況
3.3.1. 前提条件
3.3.2. インストレーション時のカスタマイズ可否の差異
3.3.3. contribのWindows対応状況
3.3.3.1. Windowsでのcontirbモジュールの使用方法
3.3.3.2. 対応状況の一覧表
3.3.4. 周辺ツールのWindows対応状況
3.4. まとめ
3.4.1. インストレーションについて
3.4.1.1. インストレーションでの留意点
3.4.2. インストレーションのカスタマイズ可否および各種ツールのWindowsでの対応状況
4. PostgreSQLの運用手順確認
4.1. WAL書き出し先を変更したデータベースクラスタの初期化
4.1.1. 事前準備
4.1.2. initdbの実行
4.2. PostgreSQLの起動と停止
4.2.1. PostgreSQLの起動
4.2.2. PostgreSQLの停止
4.3. PostgreSQLのイベントログ出力
4.3.1. syslog出力時の挙動
4.3.2. イベントログの確認
4.4. PostgreSQLのバックアップ・リストア
4.4.1. 論理バックアップとリストア
4.4.2. 物理バックアップとリカバリ
4.5. まとめ
4.5.1. PostgreSQLとしての差異
4.5.2. OSの違いによる差異
5. High-Availability
5.1. 調査、検証の目的
5.2. 環境構築手順
5.2.1. 本章における検証環境の構成

Page 2 of 50

2
5
6
6
6
6
6
7
7
7
7
7
7
7
7
8
8
10
10
10
10
10
13
15
15
15
16
16
17
17
17
17
17
17
18
18
18
18
20
20
20
20
20
21
22
22
22
24
24
25
26
26
26
26

PostgreSQL Enterprise Consortium

5.2.2. 構築準備
5.2.3. 構築手順（全体像）
5.2.4. Windows版 PostgreSQLのインストール
5.2.5. Pgpool-II環境構築
5.2.6. Windows版 PostgreSQLのレプリケーション環境構築
5.2.7. Pgpool-IIへの登録
5.2.8. failover, follow master, 設定
5.3. Pgpool-II運用におけるPCPコマンドの動作確認
5.3.1. pcp_node_count
5.3.2. pcp_node_info
5.3.3. pcp_proc_count
5.3.4. pcp_proc_info
5.3.5. pcp_pool_status
5.3.6. pcp_detach_node
5.3.7. pcp_attach_node
5.3.8. pcp_promote_node
5.3.9. pcp_stop_pgpool
5.4. 障害での動作検証
5.4.1. スレーブ DBがダウンした場合の障害検証
5.4.2. 3台中1台目のマスタDBがダウンした場合の障害検証
5.4.3. 3台中2台目のマスタDBがダウンした場合の障害検証
5.5. まとめ
6. 著者

Page 3 of 50

27
31
31
31
31
33
34
36
37
37
37
38
38
39
39
40
40
40
41
44
47
49
50

PostgreSQL Enterprise Consortium

Page 4 of 50

PostgreSQL Enterprise Consortium

1. ライセンス
本作品はCC-B Yライセンスによって許諾されています。 ライセンスの内容を知りたい方は こちら でご確認ください。 文書の内容、表記に関する誤り、ご要望、感想等につきましては、PG ECo n s のサイト を通じてお寄せいただきますようお願いいたします。

Eclip se は、Eclip se Fo u n datio n In c の米国、およびその他の国における商標もしくは登録商標です。
IB M およびDB 2 は、世界の多くの国で登録された In tern atio n al B u sin ess Mach in es Co rp o ratio n の商標です。
In tel 、インテルおよびXeo n は、米国およびその他の国における In tel Co rp o ratio n の商標です。
Java は、O racle Co rp o ratio n 及びその子会社、関連会社の米国及びその他の国における登録商標です。 文中の社名、商品名等は各社の商標または登録商標である場合があります。
Lin u x は、Lin u s To rvalds 氏の日本およびその他の国における登録商標または商標です。
Red Hat およびSh ado w man lo go は、米国およびその他の国におけるRed Hat,In c. の商標または登録商標です。
Micro so ft 、W in do w s Server 、SQ L Server 、米国 Micro so ft Co rp o ratio n の米国及びその他の国における登録商標または商標です。
MySQ L は、O racle Co rp o ratio n 及びその子会社、関連会社の米国及びその他の国における登録商標です。 文中の社名、商品名等は各社の商標または登録商標である場合があります。
O racle は、O racle Co rp o ratio n 及びその子会社、関連会社の米国及びその他の国における登録商標です。 文中の社名、商品名等は各社の商標または登録商標である場合があります。
Po stgreSQ L は、Po stgreSQ L Co mmu n ity Asso ciatio n o f Can ada のカナダにおける登録商標およびその他の国における商標です。
W in do w s は米国 Micro so ft Co rp o ratio n の米国およびその他の国における登録商標です。
TPC, TPC B en ch mark, TPC-B , TPC-C, TPC-E, tp mC, TPC-H, TPC-DS, Q p h H は米国Tran sactio n Pro cessin g Perfo rman ce Co u n cil の商標です。
その他、本資料に記載されている社名及び商品名はそれぞれ各社が 商標または登録商標として使用している場合があります 。

Page 5 of 50

PostgreSQL Enterprise Consortium

2. はじめに2.1. PostgreSQLエンタープライズコンソーシアムとWG3について
Po stgreSQ L エンタープライズコンソーシアム(略称 PG ECo n s)は、Po stgreSQ L 本体および各種ツールの情報収集と提供、整備などの活動を通じて、ミッションクリティカル性の高いエンタープライズ領域へのPo stgreSQ L の普及を推進することを目的として設立された団体です。
PG ECo n s 技術部会ではPo stgreSQ L の普及に資する課題を活動テーマとし、3 つのワーキンググループで具体的な活動を行っています。
W G 1 （新技術検証ワーキンググループ）
W G 2 （移行ワーキンググループ）
W G 3 （課題検討ワーキンググループ）
これら 3 つのワーキンググループのうち、W G 1 、W G 3 については 2015 年度まではそれぞれ、「性能ワーキンググループ」、「設計運用ワーキンググループ」という名称で活動してきました。2016 年度は、従来の活動領域を広げる意図のもとでそれらを再定義し、上記のような名称に改めました。
これに伴い、W G 3 ではPo stgreSQ L の設計運用を中心としたさまざまな課題の解決のための調査検証を行い、Po stgreSQ L が広く活用される事を推進していくこととしました。

2.2. 本資料の概要と目的
本資料はW G 3 の2017 年度の活動として、W in do w s におけるPo stgreSQ L について、インストレーション、ユーティリティコマンド、HA の切り口で調査、検証した結果をまとめたものです。

Po stgreSQ L は2005 年、Po stgreSQ L 8.0.0 のリリースから W in do w s をサポートするようになりました。 一方で、Po stgreSQ L は長らく Lin u x 環境を中心に開発・利用されていたこともあり、 W in do w s での環境構築、周辺ツールの対応状況、ユーティリティコマンドのLin u x 環境との比較や、 高可用性を想定した構成を組むための情報があまり整理されていない状況にありました。
今年度はW in do w s 上でのPo stgreSQ L に関して、実際に W in do w s 環境での検証と机上調査を通して情報を整備することを目的として活動しました。

2.3. 本資料の構成
はじめに

Po stgreSQ L のインストレーション
W in do w s 環境でのソースからのインストレーション
W in do w s 環境でのインストーラからのインストレーション
インストレーションのカスタマイズ可否および各種ツールのW in do w s での対応状況
まとめ

Po stgreSQ L の運用手順確認
W AL 書き出し先を変更したデータベースクラスタの初期化
Po stgreSQ L の起動と停止
Po stgreSQ L のイベントログ出力
Po stgreSQ L のバックアップ・リストア
まとめHigh -Availab lity
調査、検証の目的
環境構築手順p gp o o l-II 運用におけるPCP コマンドの動作確認
障害での動作検証
まとめ
著者

2.4. 想定読者
本資料の読者は以下のような知識を有していることを想定しています。

DB MS を操作してデータベースの構築、保守、運用を行う DB A の知識
Po stgreSQ L を利用する上での基礎的な知識

Page 6 of 50

PostgreSQL Enterprise Consortium

3. PostgreSQLのインストレーション
本章では、W in do w s 環境におけるPo stgreSQ L のインストレーション、 インストレーションを実施した環境とLin u x 版Po stgreSQ L との差異について説明します。

3.1. Windows環境でのソースからのインストレーション
本節では、Po stgreSQ L のW in do w s 環境におけるソースからのビルドおよび インストール方法について検証します。

3.1.1. 前提条件
検証した環境は以下の通りです。

O S:W in do w s 7 Pro fessio n al 32b it
CPU :Co re2Du o 6300 1.86G Hz
Memo ry:2G B

3.1.2. 環境構築
ソースからのインストレーションの検証には、以下の環境を利用しました。

Micro so ft Visu al Stu dio Exp ress 2017 fo r W in do w s Deskto p
Micro so ft W in do w s SDK 8.1
Straw b erry Perl 5.26.1
Po stgreSQ L 10.1(ソース)
また本検証では、Po stgreSQ L Do cu men t 「 Ch ap ter 17. In stallatio n fro m So u rce Co de o n W in do w s 」の 記載に沿った内容として、Perl のランタイムに以下を使用した検証も実施しました。

ActiveState Perl 5.24.2 Co mmu n ity Editio n
ただし、ActiveState Perl は、利用目的によりはライセンス上、もしくはエディション上 制限がある場合があります。使用する目的に応じたエディションを選択ください。

3.1.2.1. M icrosoft Visual Studio Express 2017 for Windows Desktop のイ ンスト ール
1. Micro so ft のVisu al Stu dio のW eb ページ から「 Visu al Stu dio Exp ress 」を選択してダウンロードします。
2. インストーラの手順に従ってインストールします。
3.1.2.2. M icrosoft Windows SDK のイ ンスト ール
1. Micro so ft のW in do w s SDKのW eb ページ から「 W in do w s Stan dalo n e SDK」を選択してダウンロードします。
2. インストーラの手順に従ってインストールします。
3.1.2.3. Strawberry Perlのイ ンスト ール
1. Straw b erry Perl のW eb ページ からダウンロードします。
2. インストーラの手順に従ってインストールします。

3.1.3. ビル ド
1. 開発者コマンドプロンプト fo r VS 2017 を起動します。
2. [ソースの配置先]\src\to o ls\msvc 配下に移動し、ビルドコマンドを実行します。

> cd postgresql-10.0\src\tools\msvc> build.bat

3. 以下のようなメッセージが表示されていれば、ビルドは成功しています(警告の件数、経過時間は環境により増減することがあります)。

Page 7 of 50

PostgreSQL Enterprise Consortium> build.bat(省略)
ビルドに成功しました。

(省略、警告がある場合に、ここに出力される)
7 個の警告0 エラー
経過時間 00:18:52.43

3.1.4. イン ストー ル
1. 以下を実行します。

> install.bat [インストール先ディレクトリ]

2. 以下のようなメッセージが表示されていれば、インストールは成功しています。

> install.bat c:\PostgreSQL
Installing version 10 for release in c:\PostgreSQL(省略)
Installation complete.

3.1.5. 動作確認
インストールしたバイナリが動作するか簡単にテストします。
環境変数の設定# 現在の設定内容を確認> echo %PATH%(省略)# PATHの末尾に PostgreSQLの> set PATH=%PATH%;c:\PostgreSQL\bin> echo %PATH%(省略)...;c:\PostgreSQL\bin# データベースクラスタの設定(後の手順でデータベースクラスタを作成)> set PGDATA=c:\PostgreSQL\data

データベースクラスタの作成(in itdb )Page 8 of 50

PostgreSQL Enterprise Consortium> cd C:\PostgreSQL\bin> initdb c:\PostgreSQL\data
The files belonging to this database system will be owned by user "[コマンドを実行したユーザ名]".
This user must also own the server process.
The database cluster will be initialized with locale "Japanese_Japan.932".
Encoding "SJIS" implied by locale is not allowed as a server-side encoding.
The default database encoding will be set to "UTF8" instead.
initdb: could not find suitable text search configuration for locale "Japanese_Japan.932"
The default text search configuration will be set to "simple".
Data page checksums are disabled.
creating directory c:/PostgreSQL/data ... okcreating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... windows
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or--auth-local and --auth-host, the next time you run initdb.
Success. You can now start the database server using:
pg_ctl -D ^"c^:^\PostgreSQL^\data^" -l logfile start

DB クラスタの起動> pg_ctl -l c:\PostgreSQL\log.txt start
waiting for server to start.... done
server started

DB 作成、テーブル作成とデータ参照

Page 9 of 50

PostgreSQL Enterprise Consortium> createdb testdb> echo %ERRORLEVEL%0> psql -U [ユーザ名] testdb
psql (10.1)
Type "help" for help.
testdb=# create table testtable(id int, name text);
CREATE TABLE
testdb=# insert into testtable values (1,'MyName');INSERT 0 1
testdb=# select * from testtable;
id | name----+-------1 | MyName(1 row)

3.2. Windows環境でのインストーラからのインストレーション
本節では、Po stgreSQ L のW in do w s 環境におけるインストーラによる インストール方法について検証します。

3.2.1. 前提条件
使用したインストーラのバージョンは以下の通りです。

p o stgresql-10.1-3-w in do w s.exe

3.2.2. 環境構築
W in do w s 環境でのソースからのインストレーションと同一の環境を利用しました。

3.2.3. イン ストー ラの 入手先
W in do w s 用のPo stgreSQ L のインストーラは、En terp riseDB 社のW eb ページ からダウンロードします。 Po stgreSQ L のバージョンとインストール先のO S が選択できます。

3.2.4. イン ストー ル
Page 10 of 50

PostgreSQL Enterprise Consortium

1. ダウンロードしたインストーラを起動します。
2. インストール先のディレクトリを選択します。今回は「 C:\Po stgreSQ L_In stall 」とします。

3. インストールするコンポーネントを選択します。

4. DB クラスタの作成先を選択します。

5. データベースのスーパーユーザのパスワードを入力します。

Page 11 of 50

PostgreSQL Enterprise Consortium

6. DB の待ち受けポート番号を選択します。本検証ではin do w s 環境でのソースからのインストレーションと同一環境を利用したため、ポート番号を「 5433 」に変更
しています。

7. 使用するDB のロケールを選択します。

8. これまで選択したインストール条件を確認します。

Page 12 of 50

PostgreSQL Enterprise Consortium

9. インストールを実施します。以下の画面が表示されれば、インストールは完了です。

3.2.5. 動作確認
インストールしたバイナリが動作するか簡単にテストします。
サービスの起動[コントロール パネル] → [管理ツール] → [サービス]の順にクリックし、「 p o stgresql-10 」サービスに対して [サービスの開始]を実行します。

環境変数の設定

Page 13 of 50

PostgreSQL Enterprise Consortium# 現在の設定内容を確認> echo %PATH%(省略)# PATHの末尾に PostgreSQLの> set PATH=%PATH%;c:\PostgreSQL_Install\bin> echo %PATH%(省略)...;c:\PostgreSQL_Install\bin# データベースクラスタの設定(後の手順でデータベースクラスタを作成)> set PGDATA=c:\PostgreSQL_Install\dataDB クラスタの作成(in itdb )> initdb c:\PostgreSQL_Install\data
データベースシステム内のファイルの所有者は"[コマンドを実行したユーザ名]"ユーザでした。
このユーザがサーバプロセスを所有しなければなりません。
データベースクラスタはロケール"Japanese_Japan.932"で初期化されます。
ロケールにより暗示される符号化方式"SJIS"はサーバ側の符号化方式として使用できません。
デフォルトのデータベース符号化方式は代わりに "UTF8"に設定されます。
initdb: ロケール"Japanese_Japan.932"用の適切なテキスト検索設定が見つかりません
デフォルトのテキスト検索設定はsimpleに設定されました。
データベージのチェックサムは無効です。
ディレクトリc:/PostgreSQL_Install/dataを作成しています ... ok
サブディレクトリを作成しています ... ok
デフォルトのmax_connectionsを選択しています ... 100
デフォルトの shared_buffers を選択しています ... 128MB

selecting dynamic shared memory implementation ... windows
設定ファイルを作成しています ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
データをディスクに同期しています...ok
警告: ローカル接続向けに "trust"認証が有効です。
pg_hba.confを編集する、もしくは、次回initdbを実行する時に -Aオプション、
または、--auth-localおよび--auth-hostを使用することで変更することができます。

Success. You can now start the database server using:
pg_ctl -D ^"c^:^\PostgreSQL^_Install^\data^" -l logfile start

DB クラスタの起動> pg_ctl -l c:\PostgreSQL_install\log.txt start
サーバの起動完了を待っています....完了
サーバ起動完了

DB 作成、テーブル作成とデータ参照

Page 14 of 50

PostgreSQL Enterprise Consortium> createdb testdb> echo %ERRORLEVEL%0> psql -U [ユーザ名] testdb
psql (10.1)
Type "help" for help.
testdb=# create table testtable(id int, name text);
CREATE TABLE
testdb=# insert into testtable values (1,'MyName');INSERT 0 1
testdb=# select * from testtable;
id | name----+-------1 | MyName(1 row)

3.3. インストレーションのカスタマイズ可否および各種ツールのWindowsでの対応状況
3.3.1. 前提条件
本章では、以下の環境に対して比較を実施しました。
インストレーションのカスタマイズ可否(Lin u x の場合とW in do w s の場合、W in do w s の場合はインストーラによるインストール時の設定値との比較)
co n trib のW in do w s での対応状況
周辺ツールのW in do w s での対応状況

3.3.2. イン ストレー シ ョ ン 時の カスタマイズ 可否の 差異
ソースからのインストレーションを実施した場合、インストーラからのインストレーションを実施した場合 それぞれの環境でのp g_co n fig コマンドの実行結果を以下に示します。
ソースからのインストレーションを実施した場合(C:\Po stgreSQ L にインストール)

Page 15 of 50

PostgreSQL Enterprise Consortium> pg_config
BINDIR = C:/POSTGR~1/bin
DOCDIR = C:/POSTGR~1/doc
HTMLDIR = C:/POSTGR~1/doc
INCLUDEDIR = C:/POSTGR~1/include
PKGINCLUDEDIR = C:/POSTGR~1/include
INCLUDEDIR-SERVER = C:/POSTGR~1/include/server
LIBDIR = C:/POSTGR~1/lib
PKGLIBDIR = C:/POSTGR~1/lib
LOCALEDIR = C:/PostgreSQL/share/locale
MANDIR = C:/PostgreSQL/man
SHAREDIR = C:/POSTGR~1/share
SYSCONFDIR = C:/PostgreSQL/etc
PGXS = C:/PostgreSQL/lib/pgxs/src/makefiles/pgxs.mk
CONFIGURE = --enable-thread-safety --with-ldap --without-zlib
CC = not recorded
CPPFLAGS = not recorded
CFLAGS = not recorded
CFLAGS_SL = not recorded
LDFLAGS = not recorded
LDFLAGS_EX = not recorded
LDFLAGS_SL = not recorded
LIBS = not recorded
VERSION = PostgreSQL 10.1

インストーラからのインストレーションを実施した場合(C:\Po stgreSQ L_In stall にインストール)> pg_config
BINDIR = C:/POSTGR~2/bin
DOCDIR = C:/POSTGR~2/doc
HTMLDIR = C:/POSTGR~2/doc
INCLUDEDIR = C:/POSTGR~2/include
PKGINCLUDEDIR = C:/POSTGR~2/include
INCLUDEDIR-SERVER = C:/POSTGR~2/include/server
LIBDIR = C:/POSTGR~2/lib
PKGLIBDIR = C:/POSTGR~2/lib
LOCALEDIR = C:/POSTGR~2/share/locale
MANDIR = C:/PostgreSQL_Install/man
SHAREDIR = C:/POSTGR~2/share
SYSCONFDIR = C:/PostgreSQL_Install/etc
PGXS = C:/PostgreSQL_Install/lib/pgxs/src/makefiles/pgxs.mk
CONFIGURE = --enable-thread-safety --enable-nls --with-ldap --with-openssl --with-ossp-uuid -with-libxml --with-libxslt --with-icu --with-tcl --with-perl --with-python
CC = not recorded
CPPFLAGS = not recorded
CFLAGS = not recorded
CFLAGS_SL = not recorded
LDFLAGS = not recorded
LDFLAGS_EX = not recorded
LDFLAGS_SL = not recorded
LIBS = not recorded
VERSION = PostgreSQL 10.1

インストレーション時のカスタマイズ可否の差異(pdf形式)

3.3.3. contribの Windows対応状況
3.3.3.1. Windows での contirb モジュールの使用方法
ソースからのインストレーションを実施した場合には、In stall コマンド実行時に指定したインストール先ディレクトリ配下に、 インストーラからインストレーションを実施した場合

Page 16 of 50

PostgreSQL Enterprise Consortiumには、インストーラ内で指定したインストール先ディレクトリ配下に 実行ファイルやDLL ファイルが生成されます。
実行ファイル形式のco n trib モジュールの場合
例えば、p gb en ch の場合は、[インストール先ディレクトリ]\b in 配下に実行ファイル(p gb en ch .exe)が生成されています。
ライブラリ形式のco n trib モジュールの場合
例えば、p g_stat_statemen ts の場合は[インストール先ディレクトリ]\lib 配下に DLL ファイル(p g_stat_statemen ts.dll)が生成されています。p o stgresql.co n f のsh ared_p relo ad_lib raries に「 p g_stat_statemen ts 」を設定することで利用可能になります。

3.3.3.2. 対応状況の一覧表
以下の条件を満たす場合に、「 W in do w s 対応状況」列を「 ○ 」としています。
ビルド時に vcxp ro j ファイルが生成され、[インストール先ディレクトリ]\lib 配下に配置される場合

contribのWindows対応状況(pdf形式)

3.3.4. 周辺ツ ー ル の Windows対応状況
2015 年の成果物「 2015 年度 W G 3 活動報告書 データベースツール編」より選定したツールの W in do w s 対応状況を一覧にしています。 「 W in do w s 対応状況」列の凡例は、リリースノート等の公式文書内の記述を元にしており、以下の基準で記載しています。

○ ：動作すること、動作のさせ方が明記されている場合△：動作可否の明確な記述はないが、ツールの性格(実装されている言語など)から動作する可能性がある場合
× ：動作しないことが明記されている場合
周辺ツールのWindows対応状況(pdf形式)

3.4. まとめ
3.4.1. イン ストレー シ ョ ン につい て
今年度の検証でのまとめを以下に記述します。
ソースからのインストレーション、インストーラからのインストレーションの2 種類の方法について動作検証を実施しました。
ソースからのインストレーションには、Po stgreSQ L をビルドするための環境として、U NIXライクな環境ではなく Visu al Stu dio 2017 Exp ress を使用した
W in do w s ネイティブな環境を使用しました。

3.4.1.1. イ ンスト レーショ ンでの留意点
ソースからのインストレーション、インストーラからのインストレーション共に、 インストール先のディレクトリとして「 Pro gram Files 」等の、スペースの含まれたパスを指定すると、Po stgreSQ L のコマンドを利用するサードパーティのソフトウェアの動作に影響を与える可能性があります。 可能な限り、避けることをお勧めします。

3.4.2. イン ストレー シ ョ ン の カスタマイズ 可否お よび各種ツ ー ル の Windowsで の 対応状況
今年度の検証でのまとめを以下に記述します。
インストーラからのインストールによって構築できる内容を示しました。
ソリューションや業務パッケージへの組み込み用途など、インストレーションをカスタマイズしたい場合には、ソースからのインストレーションを検討ください。
ただし、U NIX環境でのインストレーションと同様のカスタマイズはできない場合があることにご注意ください。

co n trib モジュールについてはW in do w s 環境でも利用可能なように、インストレーション実行時に必要なモジュールがインストールされます。
Po stgreSQ L 本体に含まれない周辺ツールについては、W in do w s で使用可能なものは限定的です。そのため、データベースの構築先として W in do w s の要件がある場合には、要件を満たす代替手段の検討画必要になる場合があります。

Page 17 of 50

PostgreSQL Enterprise Consortium

4. PostgreSQLの運用手順確認
本章では、Lin u x 環境で一般的に実施するPo stgreSQ L のユーティリティコマンドが W in do w s 環境で正しく動作するか、また差異がないかといった観点で確認を行いました。 確認した項目は下記の4 項目です。

W AL 書き出し先を変更してデータベースクラスタを初期化する
Po stgreSQ L を起動・停止する
Po stgreSQ L サーバのログ書き出しをEven tLo g にする
Po stgreSQ L をバックアップ・リストアする

4.1. WAL書き出し先を変更したデータベースクラスタの初期化
信頼性や性能の向上を目的に W AL の書き出し先を変更することがあります。 本節では、W in do w s 環境において変更する場合の手順を確認しまとめます。

4.1.1. 事前準備
インストーラでインストールした場合、デフォルトでデータベースクラスタが作成され、自動起動するようになっています。 まずは、起動しているPo stgreSQ L を停止し、自動起動しないように設定変更を行います。

W in do w s のサービスから Po stgreSQ L サービスの設定を開きます。

「 Service statu s: 」にある「 Sto p 」ボタンを押すと、起動しているPo stgreSQ L が停止します。
また、「 Startu p typ e: 」で「 Disab led 」を選択することで自動起動をオフにします。

4.1.2. initdbの 実行
事前準備が整ったら、in itdb コマンドでデータベースクラスタを初期化します。
なお、検証で用いた環境は以下の構成になっています。
ド ラ イ ブ名C ドライブ用途

ディレク ト リ

Po stgreSQ L のバイナ

C:\Pro gram Files\Po stgreSQ L\10 (*)

リ
アーカイブW AL 領域

C:\arcD ドライブ

データベースクラスタ

D:\data

E ドライブW AL 領域

E:\p gw al(*)インストーラからのインストレーションで指定したディレクトリです。

Page 18 of 50

PostgreSQL Enterprise Consortium

Lin u x 環境同様、in itdb コマンドの-XオプションでW AL 書き出し先のディレクトリを指定することでW AL 書き出し先を変更できます。

初期化後、データベースクラスタ配下のファイル・フォルダを確認すると、次のようになっています。

Lin u x 環境では、p g_w al がシンボリックリンクとして作成されますが、W in do w s 環境では「 JU NCTIO N 」として作成されます。
Exp lo rer から確認すると、次のようにフォルダに矢印がついた形で見えます。

Page 19 of 50

PostgreSQL Enterprise Consortium実現方式の違いはありますが、W in do w s 環境でもin itdb コマンドでW AL の書き出し先を変更できることが確認できました。

4.2. PostgreSQLの起動と停止
本節ではp g_ctl コマンドを用いた Po stgreSQ L の起動・停止を確認します。

4.2.1. PostgreSQL の 起動
「 3.2.4 動作確認」で示したように、必要な環境変数を設定していればLin u x 環境同様に「 p g_ctl start 」で起動できます。

4.2.2. PostgreSQL の 停止
Po stgreSQ L の停止についても、必要な環境変数を設定していれば「 p g_ctl sto p 」で停止できます。

また、「 p g_ctl statu s 」での状態確認も問題なく行えます。
上記の通り、p g_ctl コマンドを用いて Po stgreSQ L の起動・停止が行えることを確認しました。

4.3. PostgreSQLのイベントログ出力
本節では、W in do w s 環境固有のログ出力であるイベントログへの出力について確認します。
ログの出力先はp o stgresql.co n f のlo g_destin atio n パラメータで変更できます。

4.3.1. syslog出力時の 挙動
Lin u x 環境では「 lo g_destin atio n = 'syslo g' 」と設定することでシステムログに Po stgreSQ L サーバのログを出力し、一元管理できます。
W in do w s 環境で「 lo g_destin atio n = 'syslo g' 」を指定するとどのような挙動をとるのか確認しました。

Page 20 of 50

PostgreSQL Enterprise Consortium

上記のように lo g_destin atio n に syslo g を含めた場合、Po stgreSQ L 起動時に次のようなエラーが起こり、Po stgreSQ L の起動に失敗します。

「 U n reco gn ized key w o rd: "syslo g". 」とあるように、W in do w s 環境ではキーワードとしても"syslo g"は受け付けないようです。
代わりに「 lo g_destin atio n = 'even tlo g' 」に設定することでイベントログへの出力がなされるようになります。

4.3.2. イベ ン トログの 確認
Po stgreSQ L をインストーラからインストールした場合、デフォルトのイベントソースとして "Po stgreSQ L"というエントリが登録されます。
"Po stgreSQ L"という値はeven t_so u rce パラメータのデフォルト値でもあるため、インストール後に lo g_destin atio n の設定を変えるだけで、次のようにイベントビューアでイ
ベントログを確認できます。

even t_so u rce パラメータはp o stgresql.co n f で変更可能です(もしくは起動時のオプションで変更可能)。

しかし、変更後の値(上記例では"PG ECo n s")が、イベントソースのエントリとして登録されていないためこれだけではイベントログは出力されません。
イベントログを出力するためには、次のように regsvr32 コマンドを用いてイベントソースのエントリを登録します。

こうすることで、イベントビューアに "PG ECo n s"というイベントソースを持つイベントログが出力されるようになります。

Page 21 of 50

PostgreSQL Enterprise Consortium
上記の通り、W in do w s 環境固有のイベントログ出力の設定方法および動作確認を行いました。

4.4. PostgreSQLのバックアップ・リストア
本節では、Po stgreSQ L のバックアップ、リストアについて「論理バックアップとリストア」、「物理バックアップとリカバリ」の2 つを確認しました。

4.4.1. 論理バッ クアッ プとリ ストア
まずは、p g_du mp コマンドを用いた論理バックアップとp g_resto re コマンドを用いたリストアについて確認します。
事前準備として testdb データベースを作成し、tb l テーブルに 1000 件のデータを挿入しています。その後、p g_du mp コマンドを-Fc(カスタム形式)をつけて実行します。

p g_resto re コマンドでカスタム形式のバックアップファイルを確認するとLin u x 環境同様に SQ L 文が列挙されていました。

新たにデータベースを作成し、バックアップファイルをp g_resto re コマンドでリストアすることで問題なくバックアップ取得時の状態を再現できました。

4.4.2. 物理バッ クアッ プとリ カバリ
次に、オンライン物理バックアップとPITR(Po in t In Time Reco very)の動作を確認します。
まずはC ドライブ直下にアーカイブW AL を格納するディレクトリを作成します。

Page 22 of 50

PostgreSQL Enterprise Consortiump o stgresql.co n f でW AL アーカイブの設定を行います。具体的には、arch ive_mo de をo n にし、arch ive_co mman d を設定します。arch ive_co mman d ではco p yコマ
ンドを用いて W AL ファイルをアーカイブW AL 領域へとコピーするように設定しています。
なお、arch ive_co mman d で「 "%p "」などのようにパスの部分をダブルクォテーションでくくらないと正しく arch ive_co mman d が実行されませんでした。

設定が終わったら、Po stgreSQ L を再起動します。

再起動が完了したら、すべての準備が整いましたので、ベースバックアップの取得を行います。次の例では、p g_b aseb acku p コマンドを用いてベースバックアップを取得しています。

PITR の挙動確認のため、追加で1000 件のデータを挿入します。また、この時のトランザクションID を記憶しておき、後ほどこの時点まで復旧するようにします。次の例では手順ミスを想定して tb l テーブルのデータをすべて削除しています。また、以降の手順を簡単にするため、この時までのW AL がすべてアーカイブされるよう p g_sw itch _w al 関数を利用しました。

ここから PITR を行っていきます。
まずはPo stgreSQ L を停止し、現行のデータベースクラスタを退避させています。その後、次のように xco p yコマンドを用いて取得したベースバックアップをデータベースクラスタ
としてリストアします。
ただし、これだけではW in do w s 環境で権限が不足していたため、別途Exp lo rer から所有者のフルアクセス権限を付与し直しました。

引き続き、reco very.co n f の設定を行います。

reco very.co n f のサンプルファイルであるreco very.co n f.samp le は「 < インストール先> \sh are 」配下にあります。次の例ではreco very.co n f.samp le をデータベースクラス
タ配下に reco very.co n f という名前でコピーしています。

reco very.co n f に、アーカイブW AL のリストア設定およびリカバリ完了時点を設定します。リストア設定はarch ive_co mman d の設定同様に co p yコマンドを用いて、アーカイ
ブW AL 領域から W AL 領域へとコピーするようにしています。

Page 23 of 50

PostgreSQL Enterprise Consortium

リカバリ完了時点の設定は、先ほどの手順ミス前に確認したトランザクションID(590)をreco very_target_xid に設定しています。

最後に W AL 領域を削除し、E:\p g_w al へのジャンクションを作成します。ジャンクションはmklin k コマンドに "/J"オプションを付けることで作成できます。

いよいよPo stgreSQ L の再起動です。アーカイブW AL のリストアおよびリカバリが行われます。リカバリ完了時点に到達すると、Po stgreSQ L は一時停止モードになります。この状態はPo stgreSQ L への接続および参照クエリのみが実行できる状態です。

tb l テーブルの内容を確認し、想定する時点(例では2000 件のデータが存在する時点)までのリカバリが行えてるか確認します。

問題がないようであれば、p g_w al_rep lay_resu me 関数を実行してリカバリを完了させます。

論理バックアップからのリストア、物理バックアップからのリカバリともに Lin u x 環境と同様の挙動となることを確認しました。

4.5. まとめ
本章では、Lin u x 環境とW in do w s 環境でのPo stgreSQ L の運用手順の差異について確認しました。
本章で確認した範囲でいえば、細かい違いはあるものの、大筋の流れは差異なく実施できると言えます。

4.5.1. PostgreSQL としての 差異

Page 24 of 50

PostgreSQL Enterprise Consortium
・パラメータでパスを指定する際、バックスラッシュを多用するため、値の設定方法の差異（エスケープが必要など）には注意が必要です

4.5.2. OSの 違い による差異
・イベントログへの出力を行う場合は、regsvr32 コマンドを利用するなど手順が異なります
・物理的なファイルを扱う際は、当然ながら W in do w s 環境固有のコマンドを利用する必要があります

Page 25 of 50

PostgreSQL Enterprise Consortium

5. High-Availability
本章ではPgp o o l-II を利用した W in do w s 環境におけるPo stgreSQ L のHigh -Availab ility(以下HA)構成について説明します。

5.1. 調査、検証の目的
W in do w s 環境でHA 構成を組む場合、W in do w s Server Failo ver Clu sterin g (W SFC) 等を導入する事が一般的かと思います。 しかし、W SFC を利用する場合
は、共有ディスクが必要になります。

W SFC を用いずPgp o o l-II をクラスタソフトウェアとして利用することで、W in do w s に構築したストリーミングレプリケーション構成のPo stgreSQ L を管理でき、HA 構成を実現できます。 ただし、Pgp o o l-II 自体はW in do w s 未対応のため、Lin u x 環境の構築が必要となります。
本章ではPgp o o l-II を利用した HA 構成の環境構築・運用手順を説明し、本構成でできる事・できない事を明らかにします。 なお、Pgp o o l-II のフェイルオーバー等Lin u x
環境に閉じた部分は、本章では紹介しません。

5.2. 環境構築手順
5.2.1. 本章にお け る検証環境の 構成
検証環境の概略図は以下になります。

図 5.1 検証環境構成図
アプリケーションからのトランザクションは、全て Lin u x サーバ(p gp o o l1)に構築された Pgp o o l-II に投入されます。Pgp o o l-II は3 台のW in do w s サーバ上に構築された
Po stgreSQ L を管理します。

W in do w s 環境で fo llo w master が実施可能か検証するため、Po stgreSQ L は3 台設定します。
更新処理はマスタ DB (上図の場合はp o stgres1(n o de 0))に投入され、ストリーミングレプリケーションによって他の2 台のDB サーバへ反映されます。
参照処理はPgp o o l-II のロードバランス機能によって、3 台のDB サーバに割り振られます。
各サーバの詳細は下表の通りです。

項番

表 5.1 サーバ詳細
OS バージョ ン

サーバ名

IP アド レス1

p gp o o l1

192.168.1.231

Cen tO S 7.2 (x64)

Pgp o o l-II 実行環境

2

p o stgres1

192.168.1.228

W in do w s Server 2016 stan dard (x64)

Po stgreSQ L マスタ (Pgp o o l-II におけるn o de 0)

3

p o stgres2

192.168.1.229

W in do w s Server 2016 stan dard (x64)

Po stgreSQ L スレーブ１ (Pgp o o l-II におけるn o de 1)

4

p o stgres3

192.168.1.230

W in do w s Server 2016 stan dard (x64)

Po stgreSQ L スレーブ２ (Pgp o o l-II におけるn o de 2)

Page 26 of 50

用途PostgreSQL Enterprise Consortium
また、各サーバにインストールするソフトウェアと設定概要は下表の通りです。
表 5.2 インストールするソフトウェアと設定概要項番

ソフト ウェ ア
名1

Pgp o o l-II

2

Po stgreSQ L p o stgres1,p o stgres2,p o stgres3 10.1 (64 ビット版
W in do w s)

イ ンスト ール先サーバ名

p gp o o l1

ソフト ウェ アバー
ジョ ン

3.7.0

イ ンスト ール先

実行環境等

/u sr/p gp o o l-10

設定ファイル配置先： /etc/p gp o o l-II-10

C:\Po stgreSQ L\10

DB クラスタ配置先：
C:\Po stgreSQ L\10\data5.2.2. 構築準備
HA 構成の構築を始める前にシステムの基礎的な環境を整える必要があります。 ここでは下記3 点について説明します。
1. failo ver やfo llo w master 実施時に Pgp o o l-II が起動するシェルの中で、ホスト名で名前解決できるようにするため、h o sts ファイルを設定します。
2. Pgp o o l-II が起動するシェルの中でssh 通信を行う際に、パスワードが要求される事により処理が停止する事態を回避するため、p gp ass.co n f を設定します。
3. Pgp o o l-II と各DB サーバ間で通信するため、W in do w s 環境に SSH を設定します。
各サーバのホスト名を登録します。

Lin u x 環境

[root@pgpool1 ~]# cat /etc/hosts
192.168.1.231 pgpool1
192.168.1.230 postgres3
192.168.1.229 postgres2
192.168.1.228 postgres1

W in do w s 環境

C:\PostgreSQL\10\data>type C:\Windows\System32\drivers\etc\hosts
192.168.1.231 pgpool1
192.168.1.230 postgres3
192.168.1.229 postgres2
192.168.1.228 postgres1
fo llo w master の処理等でPo stgreSQ L のパスワード入力を避けるため W in do w s 環境に p gp ass.co n f を設定します。

C:\PostgreSQL\10\data>type "C:\Users\Administrator\AppData\Roaming\postgresql\pgpass.conf"*:*:*:postgres:postgres*:*:replication:postgres:postgres
Pgp o o l-II でPo stgreSQ L を制御するにはssh 経由で行いますが、デフォルトでssh はインストールされていません。 ssh はマイクロソフトがプレリリース版を出しているので、そちらを利用するため設定を行いたいと思います。

W in do w s のssh は下記サイトよりダウンロードします。
h ttp s://gith u b .co m/Po w erSh ell/W in 32-O p en SSH/releases※上記サイトのリリースノートに「 Th is is a p re-release (n o n -p ro du ctio n ready)」との表記がありますので、利用するにあたってはご注意ください。
ダウンロードファイルはzip 形式になっています。このzip ファイルを展開したら、 Po w erSh ell を 管理者モード で起動して、上記zip ファイルの展開によって生成された
O p en SSH-W in 64 フォルダに移動します。
移動した先で下記のようにコマンドを実行し、SSH をインストールします。 下記の実行例は、C ドライブ直下に展開したフォルダを配置した場合の例になります。

PS C:\OpenSSH-Win64> powershell -ExecutionPolicy Bypass -File install-sshd.ps1[SC] SetServiceObjectSecurity SUCCESS[SC] ChangeServiceConfig SUCCESS[SC] ChangeServiceConfig2 SUCCESS
sshd and ssh-agent services successfully installed

Page 27 of 50

PostgreSQL Enterprise Consortium
上記のように「 ssh d an d ssh -agen t services su ccessfu lly in stalled 」が表示されれば、ssh d 及びssh -agen t のインストールは完了です。 次に、Firew all がSSH の通信を許可するように設定を変更します。引き続きPo w erSh ell で以下のコマンドを実行します。

PS C:\OpenSSH-Win64> New-NetFirewallRule -Protocol TCP -LocalPort 22 -Direction Inbound -Action
Allow -DisplayName OpenSSH -Program C:\OpenSSH-Win64\sshed.exe
Name: {9f880921-f3a0-41d4-973c-4ac0c4b081db}(中略)PrimaryStatus: OK
Status: 規則は、ストアから正常に解析されました。 (65536)
EnforcementStatus: NotApplicable
PolicyStoreSource: PersistentStore
PolicyStoreSourceType : Local
上記のように「 Statu s : 規則は、ストアから正常に解析されました。」が確認できたら、firew all 設定は完了です。 念のため設定状況を確認します。

PS C:\Users\Administrator> Get-NetFirewallRule -DisplayName OpenSSH

Name: {9f880921-f3a0-41d4-973c-4ac0c4b081db}
DisplayName: OpenSSH
Description:
DisplayGroup
:
Group
:
Enabled: TrueProfile: Any
Platform: {}Direction: Inbound
Action: Allow
EdgeTraversalPolicy : Block
LooseSourceMapping: False
LocalOnlyMapping: FalseOwner:
PrimaryStatus: OK
Status: 規則は、ストアから正常に解析されました。 (65536)
EnforcementStatus: NotApplicable
PolicyStoreSource: PersistentStore
PolicyStoreSourceType : Local
上記のように 「 Disp layName : O p en SSH 」の「 Actio n : Allo w 」であり、「 PrimaryStatu s : O K 」となっていれば、SSH の通信が許可されている事になります。
次にホストの認証キーを生成するため、下記のコマンドを実行します。

PS C:\OpenSSH-Win64> .\ssh-keygen.exe -A
C:\OpenSSH-Win64\ssh-keygen.exe: generating new host keys: RSA DSA ECDSA ED25519
このコマンドを実行した結果、下記のファイルが作成されます。

Page 28 of 50

PostgreSQL Enterprise Consortium

PS C:\OpenSSH-Win64> dir ssh_host_*
ディレクトリ: C:\OpenSSH-Win64

Mode----a----a----a----a----a----a----a----a----LastWriteTime------------2018/01/31
2018/01/31
2018/01/31
2018/01/31
2018/01/31
2018/01/31
2018/01/31
2018/01/31

14:59
14:59
14:59
14:59
14:59
14:59
14:59
14:59

Length Name------ ---672 ssh_host_dsa_key
624 ssh_host_dsa_key.pub
227 ssh_host_ecdsa_key
196 ssh_host_ecdsa_key.pub
432 ssh_host_ed25519_key
116 ssh_host_ed25519_key.pub
1679 ssh_host_rsa_key
416 ssh_host_rsa_key.pub

公開鍵認証を有効化するため C:\O p en SSH-W in 64\ssh d_co n fig に記載されている Pu b keyAu th en ticatio n のコメントアウトを外します。

#PubkeyAuthentication yes↓
PubkeyAuthentication yes
次に SSH クライアントとしての秘密鍵と公開鍵のペアを作成するために、ssh -keygen コマンドを実行します。 このコマンドでは、下記実行例の「※※」で示す通り、3 か所で入力を求められます。

1 回目の入力では、ファイルの出力先の指定を求められます。デフォルトの場合は、何も入力せずに En ter のみ入力します。
2 回目の入力では、生成する鍵のパスフレーズの入力を求められます。本環境では公開鍵認証によりパスフレーズなしでログインできるようにするため、ここでも何も入力せずに En ter のみ入力します。
3 回目にもう一度同じパスフレーズ（何も入力しない）を入力します。

PS C:\OpenSSH-Win64> .\ssh-keygen.exe -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (C:\Users\Administrator/.ssh/id_rsa): ※※ 空Enterを投入
Created directory 'C:\Users\Administrator/.ssh'.
Enter passphrase (empty for no passphrase):※※ 空Enterを投入
Enter same passphrase again:※※ 空Enterを投入
Your identification has been saved in C:\Users\Administrator/.ssh/id_rsa.
Your public key has been saved in C:\Users\Administrator/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:2kCQtvTYgLHfZgFHFl62UBSJf+fVQEVIRgJkltOdv0k administrator@postgres1@postgres1
The key's randomart image is:+---[RSA 2048]----+| .ooo*=*+=+.===o|| ..=*.+.+o .o= || .o *+.. . + || .ooo.. . . .Eo||
. = S. o .. o|
|
o +
. o |
|
. .
|
|
|
|
|
+----[SHA256]-----+
このコマンドによって、C:\U sers\Admin istrato r\.ssh \id_rsa フォルダに id_rsa と id_rsa.p u b が作成されます。
上記で生成された鍵のファイルパーミッションを設定するために FixU serFilePermissio n s.p s1 を実行します。

Page 29 of 50

PostgreSQL Enterprise Consortium

PS C:\OpenSSH-Win64> cd C:\Users\Administrator\.ssh
PS C:\Users\Administrator\.ssh> Powershell -executionpolicy bypass -File C:\OpensshWin64\FixUserFilePermissions.ps1[*] C:\Users\Administrator\.ssh\id_rsa
looks good[*] C:\Users\Administrator\.ssh\id_rsa.pub'Everyone' has the following access to 'C:\Users\Administrator\.ssh\id_rsa.pub': 'ReadAndExecute,Synchronize'.
Shall I make it Read only?
[Y] はい(Y) [A] すべて続行(A) [N] いいえ (N) [L] すべて無視(L) [S] 中断(S) [?] ヘルプ (既定値は "Y"): ※※ 空Enterを投入'Everyone' now has Read access to 'C:\Users\Administrator\.ssh\id_rsa.pub'.
Repaired permissions
Done.
ここでも入力を求められる場合がありますが、これらのファイルはRead o n ly であるため、空En ter や 「 Y」で応答します。
クライアントの鍵を au th o rized_keys に登録します。ここまでの状況ではまだ au th o rized_keys が存在していないので、id_rsa.p u b を コピーして作成します。

PS C:\Users\Administrator\.ssh> copy id_rsa.pub authorized_keys
PS C:\Users\Administrator\.ssh>
他のサーバの公開鍵を登録する際は、上記のau th o rized_keys に id_rsa.p u b の内容を追記します。各マシンのau th o rized_keys には4 台のサーバの公開鍵の情報が登録されるようにします。
最後に au th o rized_keys のアクセス権を設定するため、FixHo stFilePermissio n s.p s1 を実行しますが、その前に Po w erSh ell の実行ポリシーを変更します。 プロンプ
トの入力要求には「 Y」を入力します。

PS C:\Users\Administrator\.ssh> Set-ExecutionPolicy bypass
実行ポリシーの変更
実行ポリシーは、信頼されていないスクリプトからの保護に役立ちます。実行ポリシーを変更すると、about_Execution_Policiesのヘルプ トピック (http://go.microsoft.com/fwlink/?LinkID=135170)
で説明されているセキュリティ上の危険にさらされる可能性があります。実行ポリシーを変更しますか?
[Y] はい(Y) [A] すべて続行(A) [N] いいえ (N) [L] すべて無視(L) [S] 中断(S) [?] ヘルプ (既定値は "N"): Y ※※ Yで応答する。

Po w erSh ell の実行ポリシーを変更したら FixHo stFilePermissio n s.p s1 を実行します。

PS C:\Users\Administrator\.ssh> C:\OpenSSH-Win64\FixHostFilePermissions.ps1 -Confirm:$false[*] C:\OpenSSH-Win64\sshd_config
looks good[*] C:\OpenSSH-Win64\ssh_host_dsa_key'postgres1\Administrator' has no more access to 'C:\OpenSSH-Win64\ssh_host_dsa_key'.
'NT SERVICE\sshd' now has Read access to 'C:\OpenSSH-Win64\ssh_host_dsa_key'.
Repaired permissions(中略)[*] C:\Users\Administrator\.ssh\authorized_keys'NT SERVICE\sshd' now has Read access to 'C:\Users\Administrator\.ssh\authorized_keys'.
Repaired permissions
Done.
ssh d を起動して、接続確認を行います。

Page 30 of 50

PostgreSQL Enterprise Consortium

PS C:\Users\Administrator> Restart-Service sshd
PS C:\Users\Administrator>
ssh d 起動したサーバとは別のサーバから ssh 接続を試みます。 以下の例はLin u x サーバ(p gp o o l1)から W in do w s サーバ(p o stgres1)への接続例です。

[root@pgpool1 ~]# ssh Administrator@192.168.1.228
Microsoft Windows [Version 10.0.14393](c) 2016 Microsoft Corporation. All rights reserved.
administrator@postgres1 C:\Users\Administrator>hostname
postgres1
公開鍵認証により、パスワードなしでログインができ、コマンド実行できれば完了です。

5.2.3. 構築手順（ 全体像）
HA 構成構築は以下のような流れで実施します。
1. W in do w s 版 Po stgreSQ L のインストール
2. Pgp o o l-II 環境構築
3. W in do w s 版 Po stgreSQ L のレプリケーション環境構築
4. 上記のPo stgreSQ L をPgp o o l-II へ登録
5. failo ver, fo llo w master 設定
なおオンラ イ ンリカ バリは、 Pgpool-IIの pgpool-recovery を Windows 環境に イ ンスト ールする術が現時点（ 2018 年 4 月時点） でないた め、今回は検証対象外と し まし た 。

5.2.4. Windows版 PostgreSQL の イン ストー ル
インストール手順は3 章の「 W in do w s 環境でのインストーラからのインストレーション」をご参照ください。

5.2.5. Pgpool-II環境構築
Pgp o o l-II の構築手順は下記サイトを参照してください。
h ttp s://lets.p o stgresql.jp /do cu men ts/tech n ical/p gp o o l/2
今回の検証でp gp o o l.co n f に設定した Po stgreSQ L のノード関連情報は以下のようになります。

[root@pgpool1 pgpool-II-10]# grep -e backend_hostname -e backend_port \>-e backend_weight -e backend_data_directory \>-e backend_data_directory pgpool.conf
backend_hostname0 = '192.168.1.228'
backend_port0 = 5432
backend_weight0 = 0.3
backend_data_directory0 = 'C:/PostgreSQL/10/data'
backend_hostname1 = '192.168.1.229'
backend_port1 = 5432
backend_weight1 = 0.4
backend_data_directory1 = 'C:/PostgreSQL/10/data'
backend_hostname2 = '192.168.1.230'
backend_port2 = 5432
backend_weight2 = 0.3
backend_data_directory2 = 'C:/PostgreSQL/10/data'

5.2.6. Windows版 PostgreSQL の レプリ ケー シ ョ ン 環境構築
W in do w s 版 Po stgreSQ L のレプリカ環境作成します。
下表に、ホットスタンバイを利用したレプリカ環境を構築するために確認・設定したパラメータを記載します。

Page 31 of 50

PostgreSQL Enterprise Consortium
表 5.3 p o stgresql.co n f のデフォルトからの変更点
項番

パラ メ ータ

設定値

パラ メ ータ の意味

1listen _addresses'*'

通信で使用するインターフェースを指定する。IP インターフェースを利用するので '*' とする。

2

w al_level

rep lica

W AL に出力する情報。ホットスタンバイを利用するためにはrep lica でなければならない。

3

max_w al_sen ders

10

W AL 送信プロセスの数。設定値はノード数に依存する。

4

h o t_stan db yon

ホットスタンバイを有効にするかどうか。利用するのでo n とする。

5

lo ggin g_co llecto ron

ログ収集機構を有効にするかどうか。ログを取得するのでo n とする。

6

arch ive_mo de

on

完了した W AL セグメントはアーカイブ格納領域に送信するかどうか。送信するのでo n とするが、回復要件に従って設定を判断する。

7

arch ive_co mman d'co p y "%p ""D:/Po stgreSQ L/arch ive/%f"'

完了した W AL セグメントのアーカイブを実行するローカルのシェルコマン
ド。アーカイブ先のパスは環境に応じて適宜設定する。

次に、マスタ DB サーバ p o stgres1(192.168.1.228) のp g_h b a.co n f に下記の設定を追加します。(追記箇所は※の所)

C:\PostgreSQL\10\data>type pg_hba.conf# PostgreSQL Client Authentication Configuration File
(中略)
# TYPE DATABASEUSER
ADDRESSMETHOD# IPv4 local connections:
host
all
all
127.0.0.1/32
md5
host
all
all
192.168.1.0/24
md5 ※# IPv6 local connections:
host
all
all
::1/128
md5# Allow replication connections from localhost, by a user with the# replication privilege.
hostreplicationall
127.0.0.1/32
md5
host
replication
all
192.168.1.0/24
md5 ※
host
replicationall::1/128
md5
C:\PostgreSQL\10\data>
p g_h b a.co n f の編集が完了したら、マスタ DB サーバ p o stgres1(192.168.1.228) のみ起動します。 DB の起動はサービス画面から「 p o stgresql-x64-10 」をを選択して、サービスの開始をクリックします。

図 5.2 サービス開始のイメージ
マスタ DB サーバの起動確認はp sql で接続する等で確認できます。

Page 32 of 50

PostgreSQL Enterprise Consortium

C:\PostgreSQL\10\data>psql -U postgres
psql (10.1)
Type "help" for help.
postgres=#
マスタ DB サーバが起動したら、2 台のスレーブDB サーバでp g_b aseb acku p を実行し、環境のコピーを行います。 p o stgres2(192.168.1.229)、
p o stgres3(192.168.1.230)でそれぞれ、以下のコマンドを実行します。

C:\PostgreSQL\10>pg_basebackup -h 192.168.1.228 -D ./data --verbose --progress -U postgres
pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 0/D3000028 on timeline 3
pg_basebackup: starting background WAL receiver
3094044/3094044 kB (100%), 1/1 tablespace
pg_basebackup: write-ahead log end point: 0/D3000130
pg_basebackup: waiting for background process to finish streaming ...
pg_basebackup: base backup completed
C:\PostgreSQL\10>
2 台のスレーブでp g_b aseb acku p が完了したら、マスタからコピーした DB クラスタ (C:\Po stgreSQ L\10\data)に、下記のように記述された reco very.co n f を配置します。
p rimary_co n n in fo にはマスタへの接続情報を記述するので、環境に合わせて変更してください。

standby_mode = 'on'
primary_conninfo = 'user=postgres password=postgres host=192.168.1.228 port=5432'
reco very.co n f の配置が完了したら、2 台のスレーブDB サーバも起動します。起動方法は、マスタ DB サーバの時と同様にサービスから起動します。 スレーブDB サーバの起動が確認できたら、マスタ DB サーバのコマンドプロンプトから p sql 経由で下記SQ L を実行し、レプリケーションが正しく行われている事を確認します。

postgres=# select * from pg_stat_replication;pid | usesysid | usename | application_name | client_addr | client_hostname | client_port |backend_start| backend_xmin | state | sent_lsn | write_lsn | flush_lsn |replay_lsn | write_lag | flush_lag | replay_lag | sync_priority | sync_state------+----------+----------+------------------+----------------+-----------------+-------------+------------------------------+--------------+-----------+------------+------------+------------+-----------+-----------+-----------+------------+---------------+-----------1456 |
10 | postgres | walreceiver| 192.168.1.230 ||
50328 |
2018-02-19 17:06:58.904175+09 || streaming | 0/D6000140 | 0/D6000140 | 0/D6000140 |
0/D6000140 ||||0 | async
3240 |
10 | postgres | walreceiver| 192.168.1.229 ||
50482 |
2018-02-19 16:51:28.101627+09 || streaming | 0/D6000140 | 0/D6000140 | 0/D6000140 |
0/D6000140 ||||0 | async(2 rows)
上記SQ L の結果より、clien t_addr が期待した IP アドレス(n o de 1 及びn o de 2)になっている事、state が streamin g である事、syn c_state が asyn c である事を確認します。 上記の例では、2 台のスレーブDB サーバが設定されているので、p g_stat_rep licatio n の検索結果も2 行表示されています。

5.2.7. Pgpool-IIへ の 登録
上記のPo stgreSQ L をPgp o o l-II への登録します。5.2.5 のp gp o o l.co n f の設定により、監視対象のサーバ情報は定義されているので、Pgp o o l-II を起動するだけで認識されます。下記のコマンド例では、Pgp o o l-II のログは /var/lo g/p gp o o l/p gp o o l.lo g へ出力します。

Page 33 of 50

PostgreSQL Enterprise Consortium[root@pgpool1 pgpool-II-10]# pgpool -n -d > /var/log/pgpool/pgpool.log 2>&1 &[1] 22238[root@pgpool1 pgpool-II-10]# psql -p9999 -Upostgres
Password for user postgres:psql (10.1)
Type "help" for help.
postgres=# show pool_nodes;
node_id |hostname| port | status | lb_weight | role | select_cnt | load_balance_node |replication_delay---------+----------------+------+--------+-----------+---------+------------+-------------------+-----------------0| 192.168.1.228 | 5432 | up
| 0.300000 | primary | 0| true| 0
1| 192.168.1.229 | 5432 | up
| 0.400000 | standby | 0| false| 0
2| 192.168.1.230 | 5432 | up
| 0.300000 | standby | 0| false| 0(3 rows)
Pgp o o l-II の認識結果は sh o w p o o l_n o des で確認できます。 statu s が全て u p になっている事、ro le は マスタ DB サーバ(192.168.1.228)のみp rimaryとなっていて、他2 台は stan db y となっている事を確認します。

5.2.8. failover, follow master, 設定
本項ではfailo ver, fo llo w master の設定方法を説明します。
最初に Lin u x 環境のp gp o o l.co n f に failo ver 及びfo llo w master 処理を記述するスクリプトの場所を定義します。 p gp o o l.co n f には以下のように記述します。

failover_command = '/etc/pgpool-II-10/failover.sh %d %P %m %H %R'
follow_master_command = '/etc/pgpool-II-10/follow_master.sh %h %d %H %M %P'
次に、上記のパラメータで指定したシェルスクリプト本体をPgp o o l-II サーバに配置します。

/etc/p gp o o l-II-10/failo ver.sh では下記のような処理を行います。
p ro mo te するノードの判定
p ro mo te するノードでの「 p g_ctl p ro mo te 」実行
下記にシェルの具体的な記述例を記載します。

[root@pgpool1 pgpool-II-10]# cat /etc/pgpool-II-10/failover.sh#! /bin/sh
log=/var/log/pgpool/failover.log
failed_node_id=$1
old_primary_node_id=$2
new_master_id=$3
new_master_host=$4
new_master_dir=$5# Do promote only when the primary node failes
if [ $failed_node_id = $old_primary_node_id ]; thenecho "The primary node (node $failed_node_id) dies." >> $log
echo "Node $new_master_id takes over the primary." >> $log
ssh Administrator@$new_master_host -T '"C:/PostgreSQL/10/bin/pg_ctl" -D "C:/PostgreSQL/10/data"
promote' >> $log
# source config_for_script.$new_master_id# ssh $PG_USER@$new_master_host -T '$PG_CTL -D $PG_DATA promote' >> $log
else
echo "Node $failed_node_id which is not the primary dies. This script doesnt't anything." >> $log
fiPage 34 of 50

PostgreSQL Enterprise Consortium/etc/p gp o o l-II-10/fo llo w _master.sh では下記のような処理を行います。
fo llo w master 実行ノードの判定
fo llo w master 実行ノードに対して、fo llo w master 用バッチの実行
fo llo w master 用バッチの実行後の Po stgreSQ L 起動確認
fo llo w master 実行ノードを Pgp o o l-II へ attach
下記にシェルの具体的な記述例を記載します。

[root@pgpool1 ~]# cat /etc/pgpool-II-10/follow_master.sh#!/bin/sh
log=/var/log/pgpool/follow_master.log
attach_node_host=$1
hostnode=$2
new_master_node_host=$3
if [ $hostnode != 2 ]; thenexit 0fi
TimeoutCount=10
CurrentCount=0
ssh Administrator@$attach_node_host -T "C:/PostgreSQL/10/do_followmaster.bat" $new_master_node_host>> $logssh Administrator@$attach_node_host -T 'pg_ctl status -D "C:\PostgreSQL\10\data"' > /dev/null
while [ $? -ne 0 ]doCurrentCount=`expr $CurrentCount + 1`
sleep 30
if [ $CurrentCount -gt $TimeoutCount ];thenecho "$0 exit due to TimeoutCount exceeded." >> $log
exit 0fi
ssh Administrator@$attach_node_host -T 'pg_ctl status -D "C:\PostgreSQL\10\data"' >/dev/nulldone
pcp_attach_node $hostnode -U postgres
echo "$0 exit due to PostgreSQL@$attach_node_host started." >> $log
exit 0
続いて、/etc/p gp o o l-II-10/fo llo w _master.sh で指定したバッチファイルを2 台目のスレーブDB サーバ p o stgres3(192.168.1.230) に配置します。 配置場所は
fo llo w _master.sh に記載した通り、C:/Po stgreSQ L/10 になります。
このバッチファイルでの処理概要は以下のようになります。

p g_b aseb acku p 取得前の Po stgreSQ L 関係プロセスの停止
新マスターから p g_b aseb acku p でDB クラスタをコピー
fo llo w master 後のスレーブとして動作するための設定ファイル配置
DB クラスタを格納したフォルダのパーミッション変更
Po stgreSQ L を起動
下記にバッチファイルの具体的な記述例を記載します。

Page 35 of 50

PostgreSQL Enterprise Consortium

C:\PostgreSQL\10>type "C:/PostgreSQL/10/do_followmaster.bat"@ECHO OFFREM The script sets environment variables helpful for PostgreSQL@SET PATH="C:\PostgreSQL\10\bin";%PATH%@SET PGDATA="C:\PostgreSQL\10\data"@SET PGDATABASE=postgres@SET PGUSER=postgres@SET PGPORT=5432@SET PGLOCALEDIR=C:\PostgreSQL\10\share\locale
set PGBASEBACKUP="C:\PostgreSQL\10\bin\pg_basebackup.exe"
set PGCTL="C:\PostgreSQL\10\bin\pg_ctl.exe"
set COPYFROM="C:\PostgreSQL\10\taihi_files"
set LOG="C:/PostgreSQL/10/do_dollowmaster.log"
set newmaster=%1
taskkill /IM pg_basebackup.exe /F /T%PGCTL% -D %PGDATA% -m immediate stop
rmdir /S /Q %PGDATA%%PGBASEBACKUP% -h %newmaster% -D %PGDATA% -X stream -U postgres -w
copy %COPYFROM%\postgresql.conf %PGDATA%
copy %COPYFROM%\pg_hba.conf %PGDATA%
copy %COPYFROM%\follow_master_recovery.conf %PGDATA%\recovery.conf
icacls %PGDATA% /grant "NETWORK SERVICE:F" /T
net start postgresql-x64-10 >> %LOG%
failo ver 及び fo llo w master の設定は以上になります。

5.3. Pgpool-II運用におけるPCPコマンドの動作確認
本節ではW in do w s 上に構築した Po stgreSQ L に対して、PCP コマンドが利用可能かどうかを検証します。

Pgp o o l-II でサポートしているPCP コマンド及び、検証結果の概要は下表の通りになります。 この内、p cp _w atch do g_in fo とp cp _reco very_n o de は今回の検証環境
では実行できないため、検証の対象外とします。
表 5.4 PCP コマンド一覧
項番

1

コ マンド 名p cp _n o de_co u n t

機能説明

利用可否 ( 〇 : 可能 ,×: 不可能 )Pgp o o l-II の p gp o o l.co n f で定義されたノードの総数を表示す 〇る

2

p cp _n o de_in fo

指定されたノードの情報を表示する〇

3

p cp _w atch do g_in fo

Pgp o o l-II の w atch do g ステータスを表示します

対象外(w atch do g を利用しないため)

4

p cp _p ro c_co u n t

Pgp o o l-II の子プロセスのプロセス ID を一覧表示する〇

5

p cp _p ro c_in fo

Pgp o o l-II の子プロセス情報を表示する〇

6

p cp _p o o l_statu s

p gp o o l.co n f のパラメータ設定値を取得する〇

7

p cp _detach _n o de

Pgp o o l-II からノードを切り離す〇

8

p cp _attach _n o de

Pgp o o l-II にノードを復帰させる〇

9

p cp _p ro mo te_n o de

Pgp o o l-II のノードをマスタに昇格させる〇

10

p cp _sto p _p gp o o l

Pgp o o l-II を指定されたモードでシャットダウンする〇

11

p cp _reco very_n o de

Pgp o o l-II のノードのデータを再同期させた上で復帰させる

× (前提である p gp o o l-reco veryが2018 年4 月
時点では W in do w s に対応していないため)

以下に具体的な実施例を示します。

Page 36 of 50

PostgreSQL Enterprise Consortium

5.3.1. pcp_node_count
本検証環境ではPgp o o l-II に 3 ノード認識させているので、コマンドの実行結果は「 3 」と表示されます。

[root@pgpool1 ~]# pcp_node_count -Upostgres
Password:3[root@pgpool1 ~]#5.3.2. pcp_node_info
p cp _n o de_in fo は各ノード毎に実施します。

[root@pgpool1 ~]# pcp_node_info 0 -Upostgres
Password:
192.168.1.228 5432 2 0.300000 up primary[root@pgpool1 ~]# pcp_node_info 1 -Upostgres
Password:
192.168.1.229 5432 2 0.400000 up standby[root@pgpool1 ~]# pcp_node_info 2 -Upostgres
Password:
192.168.1.230 5432 2 0.300000 up standby[root@pgpool1 ~]#5.3.3. pcp_proc_countPgp o o l-II のプロセスが表示されます。このコマンドによる表示結果はp s コマンドで表示されるPgp o o l-II のプロセスID と同じになります。

Page 37 of 50

PostgreSQL Enterprise Consortium[root@pgpool1 pgpool-II-10]# pcp_proc_count -Upostgres
Password:
29818 29819 29820 29821 29822 29823 29824 29825 29826 29827 29828 29829 29830 29831 29832 29833
29834 29835 29836 29837 29838 29839 29881 29841 29842 29843 29844 29845 29846 29847 29848 29849[root@pgpool1 pgpool-II-10]# ps -ef | grep pgpoolroot
2896 2722 0 14:30 pts/0
00:00:00 grep --color=auto pgpool
root
29817
1 0 3月06 ?
00:00:07 pgpool -n -d -Droot
29818 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29819 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29820 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29821 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29822 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29823 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29824 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29825 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29826 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29827 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29828 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29829 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29830 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29831 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29832 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29833 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29834 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29835 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29836 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29837 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29838 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29839 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29841 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29842 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29843 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29844 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29845 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29846 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29847 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29848 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29849 29817 0 3月06 ?
00:00:00 pgpool: wait for connection requestroot
29850 29817 0 3月06 ?
00:00:00 pgpool: PCP: wait for connection requestroot
29851 29817 0 3月06 ?
00:02:17 pgpool: worker processroot
29852 29817 0 3月06 ?
00:00:43 pgpool: health check process(0)root29853 29817 0 3月06 ?
00:00:43 pgpool: health check process(1)root29854 29817 0 3月06 ?
00:00:43 pgpool: health check process(2)root
29881 29817 0 3月06 ?
00:00:00 pgpool: postgres postgres idle

5.3.4. pcp_proc_info
接続中のPgp o o l-II プロセスの情報を表示します。

[root@pgpool1 pgpool-II-10]# pcp_proc_info -Upostgres -P 29881
Password:
postgres postgres 2018-03-06 12:05:36 2018-03-14 14:29:56 3 0 1 7828 1
postgres postgres 2018-03-06 12:05:36 2018-03-14 14:29:56 3 0 1 7020 1
postgres postgres 2018-03-06 12:05:36 2018-03-14 14:29:56 3 0 1 4772 1

5.3.5. pcp_pool_statusPgp o o l-II 実行時パラメータの現在の設定を n ame,valu e,descrip tio n の順に表示します。

Page 38 of 50

PostgreSQL Enterprise Consortium[root@pgpool1 ~]# pcp_pool_status -Upostgres
Password:name : listen_addresses
value: *desc : host name(s) or IP address(es) to listen on(以下略)

5.3.6. pcp_detach_node
Pgp o o l-II からノードを切り離します。

[root@pgpool1 ~]# psql -U postgres -p 9999 -c "show pool_nodes;"node_id |hostname| port | status | lb_weight | role | select_cnt | load_balance_node |replication_delay---------+----------------+------+--------+-----------+---------+------------+-------------------+-----------------0| 192.168.1.228 | 5432 | up
| 0.300000 | primary | 8| false| 0
1| 192.168.1.229 | 5432 | up
| 0.400000 | standby | 0| true| 0
2| 192.168.1.230 | 5432 | up
| 0.300000 | standby | 0| false| 0(3 rows)[root@pgpool1 ~]# pcp_detach_node -n 2 -Upostgres
Password:
pcp_detach_node -- Command Successful[root@pgpool1 ~]# psql -U postgres -p 9999 -c "show pool_nodes;"node_id |hostname| port | status | lb_weight | role | select_cnt | load_balance_node |replication_delay---------+----------------+------+--------+-----------+---------+------------+-------------------+-----------------0| 192.168.1.228 | 5432 | up
| 0.300000 | primary | 8| true| 0
1| 192.168.1.229 | 5432 | up
| 0.400000 | standby | 0| false| 0
2| 192.168.1.230 | 5432 | down | 0.300000 | standby | 0| false| 0(3 rows)

5.3.7. pcp_attach_node
Pgp o o l-II にノードを復帰させます。

[root@pgpool1 ~]# psql -U postgres -p 9999 -c "show pool_nodes;"node_id |hostname| port | status | lb_weight | role | select_cnt | load_balance_node |replication_delay---------+----------------+------+--------+-----------+---------+------------+-------------------+-----------------0| 192.168.1.228 | 5432 | up
| 0.300000 | primary | 8| true| 0
1| 192.168.1.229 | 5432 | up
| 0.400000 | standby | 0| false| 0
2| 192.168.1.230 | 5432 | down | 0.300000 | standby | 0| false| 0(3 rows)[root@pgpool1 ~]# pcp_attach_node -n 2 -Upostgres
Password:
pcp_attach_node -- Command Successful[root@pgpool1 ~]# psql -U postgres -p 9999 -c "show pool_nodes;"node_id |hostname| port | status | lb_weight | role | select_cnt | load_balance_node |replication_delay---------+----------------+------+--------+-----------+---------+------------+-------------------+-----------------0| 192.168.1.228 | 5432 | up
| 0.300000 | primary | 8| true| 0
1| 192.168.1.229 | 5432 | up
| 0.400000 | standby | 0| false| 0
2| 192.168.1.230 | 5432 | up
| 0.300000 | standby | 0| false| 0(3 rows)

Page 39 of 50

PostgreSQL Enterprise Consortium

5.3.8. pcp_promote_node
Pgp o o l-II のノードをマスタに昇格させます。ただし、Po stgreSQ L の昇格は行われません。

[root@pgpool1 ~]# psql -U postgres -p 9999 -c "show pool_nodes;"node_id |hostname| port | status | lb_weight | role | select_cnt | load_balance_node |replication_delay---------+----------------+------+--------+-----------+---------+------------+-------------------+-----------------0| 192.168.1.228 | 5432 | up
| 0.300000 | primary | 8| true| 0
1| 192.168.1.229 | 5432 | up
| 0.400000 | standby | 0| false| 0
2| 192.168.1.230 | 5432 | up
| 0.300000 | standby | 0| false| 0(3 rows)[root@pgpool1 pgpool-II-10]# psql -U postgres -h 192.168.1.228 -c "selectapplication_name,client_addr,state,sync_state from pg_stat_replication;"
application_name | client_addr | state | sync_state------------------+----------------+-----------+-----------walreceiver| 192.168.1.229 | streaming | async
walreceiver| 192.168.1.230 | streaming | async(2 rows)[root@pgpool1 ~]# pcp_promote_node -n 2 -Upostgres
Password:
pcp_promote_node -- Command Successful[root@pgpool1 ~]# psql -U postgres -p 9999 -c "show pool_nodes;"node_id |hostname| port | status | lb_weight | role | select_cnt | load_balance_node |replication_delay---------+----------------+------+--------+-----------+---------+------------+-------------------+-----------------0| 192.168.1.228 | 5432 | down | 0.300000 | standby | 8| false| 0
1| 192.168.1.229 | 5432 | down | 0.400000 | standby | 0| false| 0
2| 192.168.1.230 | 5432 | up
| 0.300000 | primary | 0| true| 0(3 rows)[root@pgpool1 pgpool-II-10]# psql -U postgres -h 192.168.1.228 -c "selectapplication_name,client_addr,state,sync_state from pg_stat_replication;"
application_name | client_addr | state | sync_state------------------+----------------+-----------+-----------walreceiver| 192.168.1.229 | streaming | async
walreceiver| 192.168.1.230 | streaming | async(2 rows)
上記のように、「 p cp _p ro mo te_n o de -n 2 -U p o stgres 」の実行によって Pgp o o l-II としては n o de 2 がマスタになりますが、Po stgreSQ L のレプリケーションの状態は変わりません。

5.3.9. pcp_stop_pgpool
Pgp o o l-II をシャットダウンします。

[root@pgpool1 ~]# pcp_stop_pgpool -m s -Upostgres
Password:
pcp_stop_pgpool -- Command Successful[root@pgpool1 ~]# pcp_node_count -Upostgres
Password:
ERROR: connection to socket "/tmp/.s.PGSQL.9898" failed with error "No such file or directory"

5.4. 障害での動作検証
今回の構成における障害発生点は大きく分けて

Page 40 of 50

PostgreSQL Enterprise Consortium

1. Po stgreSQ L サーバ
2. Pgp o o l-II サーバ
3. 各サーバ間のネットワークの３点になりますが、今回はW in do w s 環境における障害検知・切り替えの動作検証を実施するため、W in do w s 環境に関わる項番１のみ動作検証します。 なお、項番2,3 につきましては、2013 年W G 3 の成果物として公開していますので、そちらをご覧ください。

Po stgreSQ L サーバの障害が発生するケースとして、
Po stgreSQ L プロセスがダウンする
W in do w s サーバ自体がダウンする
DB クラスタを格納しているストレージが故障する
サービス側のネットワークが切断するなどを挙げることができます。いずれのパターンもPgp o o l-II からは定期的にバックエンドに接続を試みて、接続できなくなったら障害が発生したと判定しています。 そのため、上記ケースのいずれも Pgp o o l-II の障害判定は同じなので、本検証ではW in do w s の Po stgreSQ L サービスをシャットダウンして状況をシミュレーションします。
本検証の前提として、各ノードの初期状態は下記コマンドラインの例に示すように Pgp o o l-II のノードから見て 3 台の Po stgreSQ L が正常に動作し、192.168.1.228 のノード(n o de 0)がマスタとして、それ以外のノードはスレーブとして動作してかつ、各ノード間でストリーミングレプリケーションが行われている状態を初期状態とします。

[root@pgpool1 pgpool-II-10]# psql -p9999 -Upostgres
Password for user postgres:psql (10.1)
Type "help" for help.
postgres=# show pool_nodes;
node_id |hostname| port | status | lb_weight | role | select_cnt | load_balance_node |replication_delay---------+----------------+------+--------+-----------+---------+------------+-------------------+-----------------0| 192.168.1.228 | 5432 | up
| 0.300000 | primary | 11
| false| 0
1| 192.168.1.229 | 5432 | up
| 0.400000 | standby | 0| false| 0
2| 192.168.1.230 | 5432 | up
| 0.300000 | standby | 0| true| 0(3 rows)
postgres=# select * from pg_stat_replication;pid | usesysid | usename | application_name | client_addr | client_hostname | client_port |backend_start| backend_xmin | state | sent_lsn | write_lsn | flush_lsn | replay_lsn| write_lag | flush_lag | replay_lag | sync_priority | sync_state------+----------+----------+------------------+----------------+-----------------+-------------+------------------------------+--------------+-----------+------------+------------+------------+-----------+-----------+-----------+------------+---------------+-----------1456 |
10 | postgres | walreceiver| 192.168.1.230 ||
50328 |
2018-02-19 17:06:58.904175+09 || streaming | 0/D6000140 | 0/D6000140 | 0/D6000140 |
0/D6000140 ||||0 | async
3240 |
10 | postgres | walreceiver| 192.168.1.229 ||
50482 |
2018-02-19 16:51:28.101627+09 || streaming | 0/D6000140 | 0/D6000140 | 0/D6000140 |
0/D6000140 ||||0 | async(2 rows)
なお、Pgp o o l-II のログは環境構築で述べたとおり /var/lo g/p gp o o l/p gp o o l.lo g に出力されます。
以後の項では、スレーブDB がダウンした場合(5.4.1)
3 台中1 台目のマスタ DB がダウンした場合(5.4.2)
3 台中2 台目のマスタ DB がダウンした場合(5.4.3)の3 パターンの障害にについて、挙動と回復方法を検証します。

5.4.1. スレー ブ DBがダウ ン した場合の 障害検証
スレーブDB に障害が発生した時の状況の概念図が下記になります。

Page 41 of 50

PostgreSQL Enterprise Consortium

図 5.3 n o de 2 障害時の概念図
スレーブDB である(n o de 2)のPo stgreSQ L を停止すると、Pgp o o l-II は n o de 2 に接続できない事を検知し、ステータスをdo w n に変更してサービスを続行します。
障害検知
以下に実際の挙動を記載します。 スレーブDB (n o de 2)がダウンした時のPgp o o l-II のログは以下のようになりました。

2018-03-14 18:16:54: pid 3170: LOG: failed to connect to PostgreSQL server on"192.168.1.230:5432", getsockopt() detected error "Connection refused"2018-03-14 18:16:54: pid 3170: ERROR: failed to make persistent db connection
2018-03-14 18:16:54: pid 3170: DETAIL: connection to host:"192.168.1.230:5432" failed ※1
2018-03-14 18:16:54: pid 3170: LOG: health check failed on node 2 (timeout:0)
2018-03-14 18:16:54: pid 3170: LOG: received degenerate backend request for node_id: 2 from pid[3170]
2018-03-14 18:16:54: pid 3133: LOG: Pgpool-II parent process has received failover request
2018-03-14 18:16:54: pid 3133: DETAIL: kind: 1 flags: 1 node_count: 1 index:0
2018-03-14 18:16:54: pid 3133: DETAIL: starting to select new master node
2018-03-14 18:16:54: pid 3133: LOG: starting degeneration. shutdown host 192.168.1.230(5432)
2018-03-14 18:16:54: pid 3133: LOG: Do not restart children because we are switching over node id
2 host: 192.168.1.230 port: 5432 and we are in streaming replication mode
2018-03-14 18:16:54: pid 3133: LOG: execute command: /etc/pgpool-II-10/failover.sh 2 0 0
192.168.1.228 C:/PostgreSQL/10/data ※2
2018-03-14 18:16:54: pid 3133: LOG: failover: set new primary node: 0
2018-03-14 18:16:54: pid 3133: LOG: failover: set new master node: 0
failover done. shutdown host 192.168.1.230(5432)2018-03-14 18:16:54: pid 3133: LOG: failover done.
shutdown host 192.168.1.230(5432) ※3
2018-03-14 18:16:54: pid 3167: LOG: worker process received restart request
2018-03-14 18:16:55: pid 3166: LOG: restart request received in pcp child process
2018-03-14 18:16:55: pid 3133: LOG: PCP child 3166 exits with status 0 in failover()2018-03-14 18:16:55: pid 3133: LOG: fork a new PCP child pid 3178 in failover()2018-03-14 18:16:55: pid 3133: LOG: worker child process with pid: 3167 exits with status 256
2018-03-14 18:16:55: pid 3133: LOG: fork a new worker child process with pid: 3179
上記ログの ※1 で n o de 2(192.168.1.230)の障害を検出し、192.168.1.230 ※2 で failo ver.sh を実行しています。 しかし、スレーブDB なので、ノードを切り離すだけで処理が終了します。(※3)
この時の sh o w p o o l_n o des の結果は以下のようになりました。

Page 42 of 50

PostgreSQL Enterprise Consortium

node_id |hostname| port | status | lb_weight | role | select_cnt | load_balance_node |replication_delay---------+----------------+------+--------+-----------+---------+------------+-------------------+-----------------0| 192.168.1.228 | 5432 | up
| 0.300000 | primary | 1| true| 0
1| 192.168.1.229 | 5432 | up
| 0.400000 | standby | 0| false| 0
2| 192.168.1.230 | 5432 | down | 0.300000 | standby | 0| false| 0(3 rows)
statu s 列に着目すると、n o de 2 はプロセスダウンにより do w n となっています。その他は特に変更は無く、他の2 ノードは u p のままであり、 n o de 0 がマスタである事に変わりありません。
この時のレプリケーション状態は下記の通りでした。

[root@pgpool1 ~]# psql -U postgres -p 9999 -c "select * from pg_stat_replication;"pid | usesysid | usename | application_name | client_addr | client_hostname | client_port |backend_start| backend_xmin | state | sent_lsn | write_lsn | flush_lsn |replay_lsn | write_lag | flush_lag | replay_lag | sync_priority | sync_state------+----------+----------+------------------+----------------+-----------------+-------------+------------------------------+--------------+-----------+------------+------------+------------+-----------+-----------+-----------+------------+---------------+-----------4892 |
10 | postgres | walreceiver| 192.168.1.229 ||
54456 |
2018-03-01 14:39:22.521469+09 || streaming | 0/E6000140 | 0/E6000140 | 0/E6000140 |0/E6000140 ||||0 | async(1 row)n o de 1(192.168.1.229) のみレプリケーションが行われていて、n o de 2(192.168.1.230) はレプリケーションされていない状態となっています。
復旧手順
続いて、ダウンした n o de 2 を復旧し、Pgp o o l-II に再度参加させます。 復旧の大まかな流れは以下のようになります。

1. 障害が発生したノードを最新の状態に戻すため、現状のマスタ DB から p g_b aseb acku p を取得する
2. 障害が発生したノードをスレーブとして起動するために、コピーした DB クラスタ領域の直下に reco very.co n f を配置する
3. 障害が発生したノードの Po stgreSQ L を起動し、HA の状態を確認する
1. p g_b aseb acku p の取得
n o de 2 のDB サーバを現マスタ (n o de 0)と同期させます。これは本環境の構築時にスレーブDB を設定した時と同様に、p g_b aseb acku p を実行することで実現します。
p g_b aseb acku p の実行の前に、古くなった DB クラスタディレクトリ「 C:\Po stgreSQ L\10\data 」を削除又はリネームします。 削除が完了したら、下記のように
p g_b aseb acku p を実行します。

C:\PostgreSQL\10>pg_basebackup -h 192.168.1.228 -D ./data --verbose --progress -U postgres
pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 0/E6000060 on timeline 5
pg_basebackup: starting background WAL receiver
3094081/3094081 kB (100%), 1/1 tablespace
pg_basebackup: write-ahead log end point: 0/E6000140
pg_basebackup: waiting for background process to finish streaming ...
pg_basebackup: base backup completed
p g_b aseb acku p が完了したら、生成された「 C:\Po stgreSQ L\10\data 」のパーミッションを変更します。

C:\PostgreSQL\10>icacls "C:\PostgreSQL\10\data" /grant "NETWORK SERVICE:F" /T
処理ファイル: C:\PostgreSQL\10\data(中略)
処理ファイル: C:\PostgreSQL\10\data\pg_xact\0000
1377 個のファイルが正常に処理されました。0 個のファイルを処理できませんでした
p g_b aseb acku p が終了したら、「 C:\Po stgreSQ L\10\data 」が新たに作成されます。 コピーした DB クラスタ内に reco very.co n f と reco very.do n e が存在している事もありますが、これらは削除します。

Page 43 of 50

PostgreSQL Enterprise Consortium

C:\PostgreSQL\10\data>hostname
postgres3
C:\PostgreSQL\10\data>cd "C:\PostgreSQL\10\data"
C:\PostgreSQL\10\data>del recovery.conf
C:\PostgreSQL\10\data>del recovery.done
C:\PostgreSQL\10\data>
2. reco very.co n f の配置
レプリケーションのスレーブとして動作させるため「 5.2.6. W in do w s 版 Po stgreSQ L のレプリケーション環境構築」で記載した reco very.co n f を配置します。

C:\PostgreSQL\10\data>hostname
postgres3
C:\PostgreSQL\10\data>type recovery.conf
standby_mode = 'on'
primary_conninfo = 'user=postgres password=postgres host=192.168.1.228 port=5432'
C:\PostgreSQL\10>
3. Po stgreSQ L の起動と状態確認
reco very.co n f を配置して、レプリケーションのスレーブとして起動する準備が完了したら、n o de 2 のDB サーバを実際に起動します。 Po stgreSQ L の起動はこれまで通り、W in do w s のサービス経由で起動します。
n o de 2 のDB サーバの起動が完了したら、n o de 0 に接続して select * fro m p g_stat_rep licatio n を発行し、レプリケーションの状態を確認します。

[root@pgpool1 ~]# psql -U postgres -p 5432 -h 192.168.1.228 -c "select * from pg_stat_replication;"pid | usesysid | usename | application_name | client_addr | client_hostname | client_port |backend_start| backend_xmin | state | sent_lsn | write_lsn | flush_lsn |replay_lsn | write_lag | flush_lag | replay_lag | sync_priority | sync_state------+----------+----------+------------------+----------------+-----------------+-------------+------------------------------+--------------+-----------+------------+------------+------------+-----------+-----------+-----------+------------+---------------+-----------4892 |
10 | postgres | walreceiver| 192.168.1.229 ||
54456 |
2018-03-01 14:39:22.521469+09 || streaming | 0/E6000140 | 0/E6000140 | 0/E6000140 |0/E6000140 ||||0 | async
4980 |
10 | postgres | walreceiver| 192.168.1.230 ||
59779 |
2018-03-14 19:01:40.850203+09 || streaming | 0/E6000140 | 0/E6000140 | 0/E6000140 |0/E6000140 ||||0 | async(2 rows)
ノードの認識状況を下記のコマンドで確認します。

[root@pgpool1 ~]# psql -U postgres -p 9999 -c "show pool_nodes;"node_id |hostname| port | status | lb_weight | role | select_cnt | load_balance_node |replication_delay---------+----------------+------+--------+-----------+---------+------------+-------------------+-----------------0| 192.168.1.228 | 5432 | up
| 0.300000 | primary | 0| false| 0
1| 192.168.1.229 | 5432 | up
| 0.400000 | standby | 0| false| 0
2| 192.168.1.230 | 5432 | up
| 0.300000 | standby | 0| true| 0(3 rows)
上記のように、3 台ともstatu s がu p で、ro le も期待した配置になっていれば復旧は完了です。

5.4.2. 3台中 1台目の マスタ DBがダウ ン した場合の 障害検証

Page 44 of 50

PostgreSQL Enterprise Consortium
マスタ DB に障害が発生した時の状況の概念図が下記になります。

図 5.4 n o de 0 障害時の概念図
処理の概要

1. n o de 1 をマスタに昇格する
マスタ DB であるn o de 0 のPo stgreSQ L を停止すると、Pgp o o l-II は n o de 0 に接続できない事を検知し、Pgp o o l-II の failo ver_co mman d パラメータに記載した処理を実行します。この中で、n o de 1 がマスタに昇格します。

2. n o de 2 をn o de 1 のスレーブとして認識する
Pgp o o l-II の fo llo w _master_co mman d パラメータに記載した処理を行います。この中で n o de 2 を n o de 1 に同期させ、同期後に Pgp o o l-II のセカンダリノードとして接続します。
障害検知
以下に実際の挙動を記載します。

1. n o de 1 をマスタに昇格する
マスタ DB がダウンした時のPgp o o l-II のログは以下のようになりました。

2018-02-27 14:42:40: pid 23903: LOG: failed to connect to PostgreSQL server on"192.168.1.228:5432", getsockopt() detected error "Connection refused"2018-02-27 14:42:40: pid 23903: ERROR: failed to make persistent db connection ※4
2018-02-27 14:42:40: pid 23903: DETAIL: connection to host:"192.168.1.228:5432" failed(中略)2018-02-27 14:42:40: pid 23868: LOG: execute command: /etc/pgpool-II-10/failover.sh 0 0 1
192.168.1.229 C:/PostgreSQL/10/data(中略)
2018-02-27 14:42:45: pid 23868: LOG: find_primary_node: primary node id is 1 ※5
2018-02-27 14:42:45: pid 23868: LOG: starting follow degeneration. shutdown host
192.168.1.228(5432)
2018-02-27 14:42:45: pid 23868: LOG: starting follow degeneration. shutdown host
192.168.1.230(5432)
2018-02-27 14:42:45: pid 23868: LOG: failover: 2 follow backends have been degenerated
2018-02-27 14:42:45: pid 23868: LOG: failover: set new primary node: 1
2018-02-27 14:42:45: pid 23868: LOG: failover: set new master node: 1
2018-02-27 14:42:45: pid 23908: LOG: start triggering follow command.
2018-02-27 14:42:45: pid 23908: LOG: execute command: /etc/pgpool-II-10/follow_master.sh
192.168.1.228 0 192.168.1.229 0 0 ※6
上記は 14:42:35 頃に n o de 0 のPo stgreSQ L を停止した時のログになります。※4 の所で Pgp o o l-II がマスタ DB のダウンを検出し、即座に failo ver.sh が実行されます。その結果、5 秒後には ※5 で示す通り n o de 1 が新たなマスタ DB に昇格している事が確認できます。 また、新たなマスタ DB を認識した直後に※6 でfo llo w _master.sh が実行されている事も確認できます。
この時の sh o w p o o l_n o des の結果は以下のようになりました。

Page 45 of 50

PostgreSQL Enterprise Consortium[root@pgpool1 pgpool-II-10]# psql -U postgres -p 9999 -c "show pool_nodes;"node_id |hostname| port | status | lb_weight | role | select_cnt | load_balance_node |replication_delay---------+----------------+------+--------+-----------+---------+------------+-------------------+-----------------0| 192.168.1.228 | 5432 | down | 0.300000 | standby | 0| false| 0
1| 192.168.1.229 | 5432 | up
| 0.400000 | primary | 0| true| 0
2| 192.168.1.230 | 5432 | down | 0.300000 | standby | 0| false| 0
2. n o de 2 をn o de 1 のスレーブとして認識する
statu s 列に着目すると、n o de 0 はプロセスダウンにより do w n となっています。一方で n o de 1 は failo ver により マスタへプロモートしています。n o de 2 は fo llo w
master の処理によりp g_b aseb acku p 取得中であるため do w n となっています。
更に、この時のレプリケーション状態を p g_stat_rep licatio n を通じて確認します。

[root@pgpool1 pgpool-II-10]# psql -U postgres -p 9999 -c "select * from pg_stat_replication;"pid | usesysid | usename | application_name | client_addr | client_hostname | client_port |backend_start| backend_xmin | state |sent_lsn | write_lsn | flush_lsn | replay_lsn|
write_lag|
flush_lag| replay_lag| sync_priority | sync_state------+----------+----------+------------------+----------------+-----------------+-------------+------------------------------+--------------+-----------+------------+------------+------------+-----------+-----------------+-----------------+-----------------+---------------+-----------5408 |
10 | postgres | pg_basebackup| 192.168.1.230 ||53898 |
2018-02-27 14:42:52.118282+09 || streaming | 0/DF000108 | 0/DF000108 | 0/DF000000 || 00:00:02.920826 | 00:01:53.028275 | 00:01:53.028275 |0 | async
5484 |
10 | postgres | pg_basebackup| 192.168.1.230 ||53897 |
2018-02-27 14:42:51.369439+09 || backup
|
|
|
|
|
|
|
|
0 | async(2 rows)
上記より、n o de 2(192.168.1.230) で p g_b aseb acku p が実行中であることが確認できます。 この状態より更に待ち続けると、Pgp o o l-II のログに以下のようなメッセー
ジが出力されます。

2018-02-27 14:46:35: pid 23944: LOG: forked new pcp worker, pid=23954 socket=7
2018-02-27 14:46:35: pid 23954: LOG: received failback request for node_id: 2 from pid [23954]
2018-02-27 14:46:35: pid 23868: LOG: Pgpool-II parent process has received failover request
2018-02-27 14:46:35: pid 23868: LOG: starting fail back. reconnect host 192.168.1.230(5432) ※7
2018-02-27 14:46:35: pid 23868: LOG: Node 1 is not down (status: 2)
pcp_attach_node -- Command Successful
2018-02-27 14:46:35: pid 23868: LOG: Do not restart children because we are failing back node id 2
host: 192.168.1.230 port: 5432 and we are in streaming replication mode and not all backends weredown
2018-02-27 14:46:35: pid 23868: LOG: find_primary_node_repeatedly: waiting for finding a primarynode
2018-02-27 14:46:35: pid 23868: LOG: find_primary_node: checking backend no 0
2018-02-27 14:46:35: pid 23868: LOG: find_primary_node: checking backend no 1
2018-02-27 14:46:35: pid 23944: DEBUG: PCP child reaper handler※7 の付近でn o de 2(192.168.1.230)がPgp o o l-II に復帰しています。この出力の後で、sh o w p o o l_n o des 及び p g_stat_rep licatio n を確認すると、以下のようになります。

Page 46 of 50

PostgreSQL Enterprise Consortium[root@pgpool1 pgpool-II-10]# psql -U postgres -p 9999 -c "show pool_nodes;"node_id |hostname| port | status | lb_weight | role | select_cnt | load_balance_node |replication_delay---------+----------------+------+--------+-----------+---------+------------+-------------------+-----------------0| 192.168.1.228 | 5432 | down | 0.300000 | standby | 0| false| 0
1| 192.168.1.229 | 5432 | up
| 0.400000 | primary | 1| false| 0
2| 192.168.1.230 | 5432 | up
| 0.300000 | standby | 0| true| 0(3 rows)[root@pgpool1 pgpool-II-10]# psql -U postgres -p 9999 -c "select * from pg_stat_replication;"pid | usesysid | usename | application_name | client_addr | client_hostname | client_port |backend_start| backend_xmin | state | sent_lsn | write_lsn | flush_lsn | replay_lsn| write_lag | flush_lag | replay_lag | sync_priority | sync_state------+----------+----------+------------------+----------------+-----------------+-------------+------------------------------+--------------+-----------+------------+------------+------------+-----------+-----------+-----------+------------+---------------+-----------2764 |
10 | postgres | walreceiver| 192.168.1.230 ||
53899 |
2018-02-27 14:46:32.605142+09 || streaming | 0/E0000060 | 0/E0000060 | 0/E0000060 |0/E0000060 ||||0 | async(1 row)
この結果から、n o de 1 がマスタ、n o de 2 がスレーブとして起動している事が確認できます。 また、p g_stat_rep licatio n の結果から、残る2 台のDB サーバが正常にレプリケーションしている事も確認できます。
復旧手順
障害復旧手順は現在のサービスが停止しないように、旧マスタを新スレーブとして追加します。
手順は スレーブの復旧手順と同じになります。

5.4.3. 3台中 2台目の マスタ DBがダウ ン した場合の 障害検証
本項では「マスタ DB がダウンした場合の障害検証(3 台中1 台目の障害)」で fo llo w master が行われた状態から、更に n o de 1 がダウンした時の挙動を確認します。
状況を図に示すと以下のようになります。

図 5.5 n o de 1 障害時の概念図

n o de 1 がダウンして新たに n o de 2 がマスタに昇格し、レプリケーションは行われないままサービスを続行します。
障害検知
この時のPgp o o l-II のログは以下のようになりました。

Page 47 of 50

PostgreSQL Enterprise Consortium

2018-03-01 11:59:02: pid 25590: LOG: failed to connect to PostgreSQL server on"192.168.1.229:5432", getsockopt() detected error "Connection refused"2018-03-01 11:59:02: pid 25590: ERROR: failed to make persistent db connection
2018-03-01 11:59:02: pid 25590: DETAIL: connection to host:"192.168.1.229:5432" failed ※8(中略)
2018-03-01 11:59:02: pid 25554: LOG: execute command: /etc/pgpool-II-10/failover.sh 1 1 2
192.168.1.230 C:/PostgreSQL/10/data ※9
2018-03-01 11:59:04: pid 25596: ERROR: Failed to check replication time lag
2018-03-01 11:59:04: pid 25596: DETAIL: No persistent db connection for the node 1
2018-03-01 11:59:04: pid 25596: HINT: check sr_check_user and sr_check_password
2018-03-01 11:59:04: pid 25596: CONTEXT: while checking replication time lag
2018-03-01 11:59:04: pid 25596: LOG: failed to connect to PostgreSQL server on"192.168.1.229:5432", getsockopt() detected error "Connection refused"2018-03-01 11:59:04: pid 25596: ERROR: failed to make persistent db connection
2018-03-01 11:59:04: pid 25596: DETAIL: connection to host:"192.168.1.229:5432" failed
2018-03-01 11:59:06: pid 25554: LOG: find_primary_node_repeatedly: waiting for finding a primarynode
2018-03-01 11:59:06: pid 25554: LOG: find_primary_node: checking backend no 0
2018-03-01 11:59:06: pid 25554: LOG: find_primary_node: checking backend no 1
2018-03-01 11:59:06: pid 25554: LOG: find_primary_node: checking backend no 2
2018-03-01 11:59:06: pid 25554: LOG: find_primary_node: primary node id is 2 ※10
2018-03-01 11:59:06: pid 25554: LOG: starting follow degeneration. shutdown host
192.168.1.228(5432)
2018-03-01 11:59:06: pid 25554: LOG: starting follow degeneration. shutdown host
192.168.1.229(5432)
2018-03-01 11:59:06: pid 25554: LOG: failover: 2 follow backends have been degenerated
2018-03-01 11:59:06: pid 25554: LOG: failover: set new primary node: 2
2018-03-01 11:59:06: pid 25554: LOG: failover: set new master node: 2
2018-03-01 11:59:06: pid 25657: LOG: start triggering follow command.
2018-03-01 11:59:06: pid 25657: LOG: execute command: /etc/pgpool-II-10/follow_master.sh
192.168.1.228 0 192.168.1.230 1 1 ※11
2018-03-01 11:59:06: pid 25657: LOG: execute command: /etc/pgpool-II-10/follow_master.sh
192.168.1.229 1 192.168.1.230 1 1
failover done. shutdown host 192.168.1.229(5432)2018-03-01 11:59:06: pid 25554: LOG: failover
done. shutdown host 192.168.1.229(5432)
n o de 0 がダウンした時と同様に ※8 で n o de 1 のダウンを検出すると ※9 の所で failo ver.sh を実行し、4 秒程度で n o de 2 がマスタに昇格します。(※10) この時、※11 のように fo llo w _master.sh は実行されますが、fo llo w master を行うノードが無いので何も処理を行わないで終了します。 この時のsh o w p o o l_n o des の結果は以下のようになりました。

[root@pgpool1 ~]# psql -U postgres -p 9999 -c "show pool_nodes;"node_id |hostname| port | status | lb_weight | role | select_cnt | load_balance_node |replication_delay---------+----------------+------+--------+-----------+---------+------------+-------------------+-----------------0| 192.168.1.228 | 5432 | down | 0.300000 | standby | 0| false| 0
1| 192.168.1.229 | 5432 | down | 0.400000 | standby | 1| false| 0
2| 192.168.1.230 | 5432 | up
| 0.300000 | primary | 0| true| 0(3 rows)
n o de 2 がマスタに昇格し、他の2 ノードはdo w n している事が確認できます。
また select * fro m p g_stat_rep licatio n より、DB サーバ間でのレプリケーションが行われていない事も確認できます。

[root@pgpool1 ~]# psql -U postgres -p 9999 -c "select * from pg_stat_replication;"pid | usesysid | usename | application_name | client_addr | client_hostname | client_port |backend_start | backend_xmin | state | sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag |flush_lag | replay_lag | sync_priority | sync_state-----+----------+---------+------------------+-------------+-----------------+-------------+--------------+--------------+-------+----------+-----------+-----------+------------+-----------+----------+------------+---------------+-----------(0 rows)

Page 48 of 50

PostgreSQL Enterprise Consortium
復旧手順
障害復旧手順は、１台障害と同様に障害復旧で現在のサービスが停止しないように、障害が起きたサーバをスレーブとして追加します。
手順は スレーブの復旧手順と同じになります。

5.5. まとめ
本検証では、W in do w s 上に構築した Po stgreSQ L を Pgp o o l-II で管理するHA 構成の挙動を検証しました。 本検証で確認できたことは以下の通りです。

W in do w s でも共有ディスクを用いずに HA 構成を構築できる。
Pgp o o l-II を利用する事によって運用上はプラットフォームの差異を意識する必要が無い。
PCP コマンドはW in do w s 環境であっても、一部のコマンド除き(※1) 利用できる。
※1 現時点では p gp o o l-reco very はソースビルドする必要があり、W in do w s に対応していないため p cp _reco very_n o de が利用できない。
一方で下記に示すように、環境構築に関して課題も確認できました。

W in do w s に ssh をセットアップする必要があるが、W in do w s のssh は2018 年4 月時点ではベータ版(Th is is a p re-release (n o n -p ro du ctio n ready))となっており、使用するに当たっては検討が必要である。
Pgp o o l-II がW in do w s に対応してないので、Lin u x サーバが最低でも1 台必要になる。
Pgp o o l-II がW in do w s に向けて発行するssh コマンドや、呼び出すバッチの書き方等はW in do w s 特有のノウハウが必要になる。

Page 49 of 50

PostgreSQL Enterprise Consortium

6. 著者（企業・団体名順）
版
第1.0 版(2017 年度W G 3)

所属企業・ 団体名

部署名

氏名

NTTテクノクロス株式会社

Io Tイノベーション事業部

勝俣 智成

NTTテクノクロス株式会社

Io Tイノベーション事業部

原田 登志

株式会社日立製作所

O SS ソリューションセンタ

稲垣 毅

株式会社日立製作所

O SS ソリューションセンタ

田畑 義之

株式会社日立ソリューションズ

システム基盤本部 第１部

大田黒 顕仁富士通株式会社

ミドルウェア事業本部

山本 貢嗣

Page 50 of 50