2019年05月

スタンバイサーバーのpg_walディレクトリに大量のWALファイルが残ったままになる

スタンバイサーバーのpg_walディレクトリに大量のWALファイルが残ったままになる事象が発生しました。
結論から書くと、レプリケーションスロットの削除漏れでした。
参照されないレプリケーションスロットは削除しましょう。

状況
[root@erogamescape13 ap2]# cd /var/lib/pgsql/11/data/pg_wal/
[root@erogamescape13 pg_wal]# du -h
12K     ./archive_status
2.4G    .

[root@erogamescape13 pg_wal]# ls
00000007.history          000000090000000B000000A1  000000090000000B000000C9  000000090000000B000000F1
00000008.history          000000090000000B000000A2  000000090000000B000000CA  000000090000000B000000F2
000000080000000B0000007D  000000090000000B000000A3  000000090000000B000000CB  000000090000000B000000F3
00000009.history          000000090000000B000000A4  000000090000000B000000CC  000000090000000B000000F4
000000090000000B0000007D  000000090000000B000000A5  000000090000000B000000CD  000000090000000B000000F5
000000090000000B0000007E  000000090000000B000000A6  000000090000000B000000CE  000000090000000B000000F6
000000090000000B0000007F  000000090000000B000000A7  000000090000000B000000CF  000000090000000B000000F7
000000090000000B00000080  000000090000000B000000A8  000000090000000B000000D0  000000090000000B000000F8
000000090000000B00000081  000000090000000B000000A9  000000090000000B000000D1  000000090000000B000000F9
000000090000000B00000082  000000090000000B000000AA  000000090000000B000000D2  000000090000000B000000FA
000000090000000B00000083  000000090000000B000000AB  000000090000000B000000D3  000000090000000B000000FB
000000090000000B00000084  000000090000000B000000AC  000000090000000B000000D4  000000090000000B000000FC
000000090000000B00000085  000000090000000B000000AD  000000090000000B000000D5  000000090000000B000000FD
000000090000000B00000086  000000090000000B000000AE  000000090000000B000000D6  000000090000000B000000FE
000000090000000B00000087  000000090000000B000000AF  000000090000000B000000D7  000000090000000B000000FF
000000090000000B00000088  000000090000000B000000B0  000000090000000B000000D8  000000090000000C00000000
000000090000000B00000089  000000090000000B000000B1  000000090000000B000000D9  000000090000000C00000001
000000090000000B0000008A  000000090000000B000000B2  000000090000000B000000DA  000000090000000C00000002
000000090000000B0000008B  000000090000000B000000B3  000000090000000B000000DB  000000090000000C00000003
000000090000000B0000008C  000000090000000B000000B4  000000090000000B000000DC  000000090000000C00000004
000000090000000B0000008D  000000090000000B000000B5  000000090000000B000000DD  000000090000000C00000005
000000090000000B0000008E  000000090000000B000000B6  000000090000000B000000DE  000000090000000C00000006
000000090000000B0000008F  000000090000000B000000B7  000000090000000B000000DF  000000090000000C00000007
000000090000000B00000090  000000090000000B000000B8  000000090000000B000000E0  000000090000000C00000008
000000090000000B00000091  000000090000000B000000B9  000000090000000B000000E1  000000090000000C00000009
000000090000000B00000092  000000090000000B000000BA  000000090000000B000000E2  000000090000000C0000000A
000000090000000B00000093  000000090000000B000000BB  000000090000000B000000E3  000000090000000C0000000B
000000090000000B00000094  000000090000000B000000BC  000000090000000B000000E4  000000090000000C0000000C
000000090000000B00000095  000000090000000B000000BD  000000090000000B000000E5  000000090000000C0000000D
000000090000000B00000096  000000090000000B000000BE  000000090000000B000000E6  000000090000000C0000000E
000000090000000B00000097  000000090000000B000000BF  000000090000000B000000E7  000000090000000C0000000F
000000090000000B00000098  000000090000000B000000C0  000000090000000B000000E8  000000090000000C00000010
000000090000000B00000099  000000090000000B000000C1  000000090000000B000000E9  000000090000000C00000011
000000090000000B0000009A  000000090000000B000000C2  000000090000000B000000EA  000000090000000C00000012
000000090000000B0000009B  000000090000000B000000C3  000000090000000B000000EB  000000090000000C00000013
000000090000000B0000009C  000000090000000B000000C4  000000090000000B000000EC  000000090000000C00000014
000000090000000B0000009D  000000090000000B000000C5  000000090000000B000000ED  archive_status
000000090000000B0000009E  000000090000000B000000C6  000000090000000B000000EE
000000090000000B0000009F  000000090000000B000000C7  000000090000000B000000EF
000000090000000B000000A0  000000090000000B000000C8  000000090000000B000000F0
レプリケーションスロットの確認
ap2=# SELECT * FROM pg_replication_slots;
          slot_name          | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn
-----------------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------
 replication_slot_for_sakura |        | physical  |        |          | f         | t      |      31390 |      |              | C/1499CEC8  |
 replication_slot            |        | physical  |        |          | f         | f      |            |      |              | B/7D5B46A0  |
(2 行)
replication_slotというの名前のレプリケーションスロットのactiveはfなので使用していません。
このサーバーがprimaryだったことがあって、その際に作成したのが、replication_slotです。
フェイルオーバーが発生して、このサーバーをstandbyとして組み込んだのですが、その際にreplication_slotを削除していませんでした。
replication_slotを削除しないと、replication_slotを参照するstandbyサーバーが出現したときのためにWALをずっと保存し続けます。
レプリケーションスロットを削除します。
ap2=# select pg_drop_replication_slot('replication_slot');
 pg_drop_replication_slot
--------------------------

(1 行)
ap2=# SELECT * FROM pg_replication_slots;
          slot_name          | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn
-----------------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------
 replication_slot_for_sakura |        | physical  |        |          | f         | t      |      31390 |      |              | C/14B09F10  |
(1 行)
WALの保存設定はPostgreSQL11のデフォルト設定のももなので、無事WALファイルが自動的に削除されました。
[root@erogamescape13 pg_wal]# ls
00000007.history  00000009.history          000000090000000C00000015  000000090000000C00000017  archive_status
00000008.history  000000090000000C00000014  000000090000000C00000016  000000090000000C00000018

[root@erogamescape13 pg_wal]# du -h
12K     ./archive_status
81M     .
参考

postmaster on DB node 1 was shutdown by administrative command

pgpoolで以下のログを出力してPostgreSQLが切り離されてしまう事象が発生しました。
May 28 04:40:03 erogamescape13 pgpool[12457]: [74016-2] 2019-05-28 04:40:03: pid 12457: DETAIL:  postmaster on DB node 1 was shutdown by administrative command
May 28 04:40:03 erogamescape13 pgpool[12457]: [74017-1] 2019-05-28 04:40:03: pid 12457: LOG:  received degenerate backend request for node_id: 1 from pid [12457]
PostgreSQLの方では以下のログを出力しています。
2019-05-28 04:40:01.414 JST [12646] FATAL:  terminating connection due to administrator command
このメッセージを発生させるような処理はしていない…(pg_terminate_backendでプロセスを終了させると出るそうですが、そのような処理はしていない…)ので、何が起きたのか謎です。

出来ることはPostgreSQLのログのレベルを深くして、同じ事象が出た時に何かログに記録されることを期待します。
具体的には以下のとおりログのレベルを変更しました。
[root@erogamescape13 log]# emacs /var/lib/pgsql/11/data/postgresql.conf

- client_min_messages = notice
+ client_min_messages = log

- log_min_messages = warning
+ log_min_messages = info

- log_min_error_statement = error
+ log_min_error_statement = warning

ここまでたどり着くのにpgpoolのソースをおってしまったので、そのおいかたを記録に残しておきます。※自分、C言語はわからないので、雰囲気だけでおいました。
find . -type f | grep .c$ | xargs grep -n "postmaster on DB node"
で、postmaster on DB node 1 was shutdown by administrative commandのメッセージがどこで出力されるか調べる。
./src/protocol/pool_process_query.c:4858:

				r = detect_postmaster_down_error(CONNECTION(backend, i), MAJOR(backend));
				if (r == SPECIFIED_ERROR)
				{
					ereport(LOG,
							(errmsg("reading and processing packets"),
							 errdetail("postmaster on DB node %d was shutdown by administrative command", 
pool_process_query.cで、detect_postmaster_down_error関数の結果がSPECIFIED_ERRORの場合にpostmaster on DB node %d was shutdown by administrative commandが出る。
detect_postmaster_down_error関数を探して見てみる。
detect_postmaster_down_error(POOL_CONNECTION * backend, int major)
{
	int			r = detect_error(backend, ADMIN_SHUTDOWN_ERROR_CODE, major, 'E', false);

	return r;
}
SPECIFIED_ERRORがなんなのかわからないけど、detect_errorの引数にADMIN_SHUTDOWN_ERROR_CODEが与えられている。
ADMIN_SHUTDOWN_ERROR_CODEを探す。
#define ADMIN_SHUTDOWN_ERROR_CODE "57P01"
ADMIN_SHUTDOWN_ERROR_CODEは57P01のこと。
57P01をgoogleで検索すると以下のWebページがひっかかる。
57P01はadmin_shutdownのこと。

detect_error関数を見てみる。
detect_error(POOL_CONNECTION * backend, char *error_code, int major, char class, bool unread)
{
	int			is_error = 0;
	char		kind;
	int			readlen = 0,
				len;
	static char buf[8192];		/* memory space is large enough */
	char	   *p,
			   *str;

	if (pool_read(backend, &kind, sizeof(kind)))
		return -1;
	readlen += sizeof(kind);
	p = buf;
	memcpy(p, &kind, sizeof(kind));
	p += sizeof(kind);

	ereport(DEBUG5,
			(errmsg("detect error: kind: %c", kind)));


	/* Specified class? */
	if (kind == class)
	{
		/* read actual message */
		if (major == PROTO_MAJOR_V3)
		{
			char	   *e;

			if (pool_read(backend, &len, sizeof(len)) < 0)
				return -1;
			readlen += sizeof(len);
			memcpy(p, &len, sizeof(len));
			p += sizeof(len);

			len = ntohl(len) - 4;
			str = palloc(len);

			pool_read(backend, str, len);
			readlen += len;

			if (readlen >= sizeof(buf))
				ereport(ERROR,
						(errmsg("unable to detect error"),
						 errdetail("not enough space in buffer")));

			memcpy(p, str, len);

			/*
			 * Checks error code which is formatted 'Cxxxxxx' (xxxxxx is error
			 * code).
			 */
			e = str;
			while (*e)
			{
				if (*e == 'C')
				{				/* specified error? */
					is_error = (strcmp(e + 1, error_code) == 0) ? SPECIFIED_ERROR : 0;
					break;
				}
				else
					e = e + strlen(e) + 1;
			}
			pfree(str);
何をしてるのか詳細は分からないですが…、多分、PostgreqSQLのバックエンドから情報を引っ張ってきてエラーだったら「Cxxxxxx」という文字が取得でして、xxxxxxのところにエラーコードが入るのかなと思う。
xxxxxxは今回は57P01が入ってくるのかな…と思う。

以上から、PgpoolはPostgreSQLから57P01を受け取っただけ、と思いました。
その後、PostgreSQLのログを確認し
2019-05-28 04:40:01.414 JST [12646] FATAL:  terminating connection due to administrator command
を発見しました。
※ちなみに、一度、PostgreSQLのログを見たのですが、ログを見逃していて…、Pgpool側の問題かと思ってしまいました。凡ミスです…

スイッチオーバーなのにpg_rewind/pg_basebackupが必要になってしまう

ErogameScapeではpgpoolを使って負荷分散、PostgreSQL障害時の切り替えを実施しています。
PostgreSQLは同期レプリケーションでprimary、standbyの2台構成です。

primaryを正常に停止して(pg_ctl stopして)、standbyを昇格させた(pg_ctl promote)場合、旧primaryはrecovery.confに新primaryを指定して起動すれば、ちゃんとレプリケーションが開始されます。

ところが、pgpoolでfailover_commandとして、
1. 非同期モードに設定を変更(postgresql.confのsynchronous_standby_namesを''にしてreload)
2. standbyを昇格(pg_ctl promote)
というスクリプトを指定し、primaryをpg_ctl stopさせた、旧primaryに適切なrecovery.confを書いて起動させたにも関わらず、レプリケーションが開始出来ず、pg_rewindが必要になってしまいました。

ちゃんとした理由は未だに分からないのですが、おそらく、primaryのpg_ctl stopが完全に終わる前に、pgpoolがstandbyをpg_ctl promoteしてしまうからではないか…と想定しました。
※primaryをちゃんとstopせずに、standbyをpg_ctl promoteすると、経験上、多くの場合で、pg_rewindかpg_basebackupが必要になります。

そこで、failover_commandのスクリプトにsleepを10秒(根拠はありません…)いれてみたら、想定通りスイッチオーバーとしての動作となりました。
以下failover_commandのスクリプトです。
#! /bin/sh -x
# Execute command by failover.
# special values:  %d = node id
#                  %h = host name
#                  %p = port number
#                  %D = database cluster path
#                  %m = new master node id
#                  %M = old master node id
#                  %H = new master node host name
#                  %P = old primary node id
#                  %R = new master database cluster path
#                  %r = new master port number
#                  %% = '%' character

falling_node=$1          # %d
old_primary=$2           # %P
new_primary=$3           # %H
pgdata=$4                # %R
old_hostname=$5          # %h

pghome=/usr/pgsql-11
log=/var/log/pgpool/failover.log

date >> $log
echo "failed_node_id=$falling_node old_primary=$old_primary new_primary=$new_primary old_hostname=$old_hostname UID=$UID" >> $log

if [ $falling_node = $old_primary ]; then
    echo "failed_node_id=master" >> $log
    if [ $UID -eq 0 ]; then
        su postgres -c "ssh -T postgres@$new_primary $pgdata/synchronous_standby_names_change.sh"
        su postgres -c "ssh -T postgres@$new_primary $pghome/bin/pg_ctl reload -D $pgdata"
        sleep 10
        su postgres -c "ssh -T postgres@$new_primary $pghome/bin/pg_ctl promote -D $pgdata"
        su postgres -c "ssh -T postgres@$old_hostname cp -p $pgdata/recovery.conf.for.$old_hostname $pgdata/recovery.conf"
    else
        ssh -T postgres@$new_primary $pgdata/synchronous_standby_names_change.sh
        ssh -T postgres@$new_primary $pghome/bin/pg_ctl reload -D $pgdata
        sleep 10
        ssh -T postgres@$new_primary $pghome/bin/pg_ctl promote -D $pgdata
        ssh -T postgres@$old_hostname cp -p $pgdata/recovery.conf.for.$old_hostname $pgdata/recovery.conf
    fi
    exit 0;
else
    echo "failed_node_id=standby" >> $log
    if [ $UID -eq 0 ]; then
        su postgres -c "ssh -T postgres@$new_primary $pgdata/synchronous_standby_names_change.sh"
        su postgres -c "ssh -T postgres@$new_primary $pghome/bin/pg_ctl reload -D $pgdata"
    else
        ssh -T postgres@$new_primary $pgdata/synchronous_standby_names_change.sh
        ssh -T postgres@$new_primary $pghome/bin/pg_ctl reload -D $pgdata
    fi
fi;
exit 0;
synchronous_standby_names_change.shは、同期レプリケーションを非同期レプリケーションにするために、postgresql.confを書き換えるスクリプトです。
sed -i -e "/synchronous_standby_names/c\#synchronous_standby_names = 'sby'      # standby servers that provide sync rep" /var/lib/pgsql/11/data/postgresql.conf


could not fork new process for connection: Resource temporarily unavailable

PostgreSQLで以下のログを出力した場合、バックエンド・プロセスをforkできていません。
2019-05-26 19:58:26.308 JST [20730] LOG:  could not fork new process for connection: Resource temporarily unavailable
2019-05-26 19:58:27.313 JST [20730] LOG:  could not fork new process for connection: Resource temporarily unavailable
2019-05-26 19:58:27.315 JST [20730] LOG:  could not fork new process for connection: Resource temporarily unavailable
2019-05-26 19:58:28.026 JST [20730] LOG:  could not fork new process for connection: Resource temporarily unavailable
pgpoolを使用している場合、pgpool側では以下のログが出力されます。 ※PostgreSQLへのヘルスチェック機能を有効にしている場合に出力されると思います。
May 26 19:58:27 erogamescape13 pgpool[1696]: [159-1] 2019-05-26 19:58:27: pid 1696: ERROR:  failed to authenticate
May 26 19:58:27 erogamescape13 pgpool[1696]: [159-2] 2019-05-26 19:58:27: pid 1696: DETAIL:  invalid authentication message response type, Expecting 'R' and received 'E'
ヘルスチェックのリトライが指定の回数失敗すると、フェイルバック機能が動きます。
May 26 19:58:28 erogamescape13 pgpool[26104]: [9-1] 2019-05-26 19:58:28: pid 26104: LOG:  health check failed on node 0 (timeout:0)
May 26 19:58:28 erogamescape13 pgpool[26104]: [10-1] 2019-05-26 19:58:28: pid 26104: LOG:  received degenerate backend request for node_id: 0 from pid [26104]
バックエンド・プロセスをfork出来ない理由は、ErogameScapeの場合、プロセス数の上限に達してしまって、プロセスを生成できないことが原因でした。
プロセス数の上限は以下のコマンドで確認可能です。
[root@erogamescape13 ap2]# su - postgres
-bash-4.1$ ulimit -u
1024
postgresユーザーのプロセス上限数が知りたかったので、postgresユーザーでulimitを実行しています。
今、動いているpostmasterのpostgresユーザーのプロセス数の上限を知りたい場合は、まずpostmasterのプロセスIDを調べ
[ap2@erogamescape14 ~]$ ps aux | grep postmaster
ap2       5692  0.0  0.0 103336   900 pts/2    S+   20:45   0:00 grep postmaster
postgres 27012  0.1  0.9 4595684 158676 ?      S    20:11   0:03 /usr/pgsql-11/bin/postmaster -D /var/lib/pgsql/11/data
cat /proc/プロセスID/limitsを見ます。
[root@erogamescape14 ap2]# cat /proc/27012/limits
Limit                     Soft Limit           Hard Limit           Units
Max processes             2048                 63695                processes
Max open files            1024                 4096                 files
ErogameScapeのOSはCentOS6です。
CentOS6のデフォルトのMax processesの上限は1024です。
PostgreSQLのmax_connectionsの数だけ、バックエンドプロセスが生成されれる可能性があります。
ErogameScapeではmax_connectionsを1200に設定しているのですが、いろいろありまして、postgresユーザーのプロセスが1024を超えてしまい、バックエンドプロセスが生成できずcould not fork new process for connectionを出力していました。

Max processesの上限を変更するため、以下の通り/etc/security/limits.d/90-nproc.confを書き換えて、postgreSQLを再起動しました。
※この方法だと他のユーザーも全部書き換わってしまうので…おそらく /etc/init.d/postgresql-11にulimitコマンドで上限を変更するコマンドを追加するのが妥当な気もするのですが、セオリーが分かりませんでした…
# emacs /etc/security/limits.d/90-nproc.conf

- *          soft    nproc     1024
+ *          soft    nproc     2048

C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/childprocess-0.6.3/lib/childproces s/windows/process_builder.rb:43:in `join': incompatible character encodings: Win dows-31J and UTF-8 (Encoding::CompatibilityError)

WindowsでVagrant upを実行した際に以下のエラーが発生しました。
D:\vagrant\myCentOSVM>Vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'centos64'...
C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/childprocess-0.6.3/lib/childprocess/windows/process_builder.rb:43:in `join': incompatible character encodings: Windows-31J and UTF-8 (Encoding::CompatibilityError)
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/childprocess-0.6.3/lib/childprocess/windows/process_builder.rb:43:in create_command_pointer'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/childprocess-0.6.3/lib/childprocess/windows/process_builder.rb:27:in `start'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/childprocess-0.6.3/lib/childprocess/windows/process.rb:70:in `launch_process'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/childprocess-0.6.3/lib/childprocess/abstract_process.rb:82:in `start'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/util/subprocess.rb:153:in `block in execute'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/util/safe_chdir.rb:26:in `block (2 levels) in safe_chdir'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/util/safe_chdir.rb:25:in `chdir'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/util/safe_chdir.rb:25:in `block in safe_chdir'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/util/safe_chdir.rb:24:in `synchronize'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/util/safe_chdir.rb:24:in `safe_chdir'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/util/subprocess.rb:152:in `execute'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/util/subprocess.rb:22:in `execute'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/plugins/providers/virtualbox/driver/base.rb:451:in `block in raw'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/plugins/providers/virtualbox/driver/base.rb:450:in `raw'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/plugins/providers/virtualbox/driver/base.rb:388:in `block in execute'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/util/retryable.rb:17:in `retryable'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/plugins/providers/virtualbox/driver/base.rb:383:in `execute'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/plugins/providers/virtualbox/driver/version_6_0.rb:71:in `import'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/plugins/providers/virtualbox/action/import.rb:53:in `import'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/plugins/providers/virtualbox/action/import.rb:13:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/before_trigger.rb:23:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/after_trigger.rb:26:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/plugins/providers/virtualbox/action/prepare_clone_snapshot.rb:17:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/before_trigger.rb:23:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/after_trigger.rb:26:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/prepare_clone.rb:15:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/before_trigger.rb:23:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/after_trigger.rb:26:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/plugins/providers/virtualbox/action/customize.rb:40:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/before_trigger.rb:23:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/after_trigger.rb:26:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/before_trigger.rb:23:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:121:in `block in finalize_action'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/runner.rb:102:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/runner.rb:102:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/call.rb:53:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/before_trigger.rb:23:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/after_trigger.rb:26:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/before_trigger.rb:23:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/after_trigger.rb:26:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:121:in `block in finalize_action'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/after_trigger.rb:26:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/handle_box.rb:56:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/before_trigger.rb:23:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:121:in `block in finalize_action'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/runner.rb:102:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/runner.rb:102:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/call.rb:53:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/before_trigger.rb:23:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/after_trigger.rb:26:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/plugins/providers/virtualbox/action/check_virtualbox.rb:26:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builtin/before_trigger.rb:23:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/runner.rb:102:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/action/runner.rb:102:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/machine.rb:238:in `action_raw'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/machine.rb:209:in `block in action'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/environment.rb:615:in `lock'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/machine.rb:195:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/machine.rb:195:in `action'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.4/gems/vagrant-2.2.4/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'
私の環境はWindowsをセットアップする際に、素直に自分の名前を入れてしまったので、ホームディレクトリ(でいいのかな…)が
C:\Users\ひろいん
となっています。
Vagrantをインストールすると、Vagrantの設定ファイルが
C:\Users\ひろいん\.vagrant.d
という場所に作られます。

.vagrant.dが日本語(Windows-31Jなのかな…)を含むディレクトリにあるとvagrant upが失敗します。

対処は以下の手順を踏みます。
1. .vagrant.dを日本語を含まないディレクトリに移す。例えば、D:\vagrant
2. 環境変数 VAGRANT_HOMEをD:\vagrant\.vagrant.dに変更する。自分の環境はWindows8です。Windows8では、コントロールパネル→システム→システムの詳細設定→環境変数システム環境変数の新規→変数名に「VAGRANT_HOME」、変数値に.vagrant.dを置いた場所(例:D:\vagrant\.vagrant.d)を書いてOK→もう一度コマンドプロンプトを立ち上げて、vagrant upを実行

VBoxManage.exe: error: Appliance import failed

WindowsでVagrant upを実行した際に以下のエラーが発生しました。
D:\vagrant\myCentOSVM>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'centos64'...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["import", "\\\\?\\D:\\vagrant\\boxes\\centos64\\0\\virtualbox\\box.ovf", "--vsys", "0", "--vmname", "centos-6.6-x86_64_1558500516796_43015", "--vsys", "0", "--unit", "12", "--disk", "C:/Users/\u5E83\u54E1/VirtualBox VMs/centos-6.6-x86_64_1558500516796_43015/box-disk1.vmdk"]

Stderr: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Interpreting \\?\D:\vagrant\boxes\centos64\0\virtualbox\box.ovf...
OK.
0%...
Progress state: E_INVALIDARG
VBoxManage.exe: error: Appliance import failed
VBoxManage.exe: error: Code E_INVALIDARG (0x80070057) - One or more arguments are invalid (extended info not available)
VBoxManage.exe: error: Context: "enum RTEXITCODE __cdecl handleImportAppliance(struct HandlerArg *)" at line 957 of file VBoxManageAppliance.cpp

私の環境はWindowsをセットアップする際に、素直に自分の名前を入れてしまったので、ホームディレクトリ(でいいのかな…)が
C:\Users\ひろいん
となっています。
Oracle VM VirtualBoxをインストールすると、VirtualBox VMsというフォルダが
C:\Users\ひろいん\VirtualBox VMs
という場所に作られます。

ディレクトリに日本語が含まれていると失敗する…ようなので、VirtualBox VMsを日本語を含まないディレトリに移動し…例えば、D:\VirtualBox VMsに移動し、Oracle VM VirtualBox マネージャーで環境設定→一般→デフォルトの仮想マシンフォルダーの設定を「C:\Users\ひろいん\VirtualBox VMs」から「D:\VirtualBox VMs」に変更して、無事、vagrant upが完了しました。

解決にあたって参照した文書

fatal: 'D:gitmath' does not appear to be a git repository

独習Git
リック・ウマリ
翔泳社
2016-02-26

の、11.5 さらなる探求の関連です。

git cloneでdepthオプションを使う場合でかつソースがローカルにある場合は、file://を先頭につける必要があります。
$ git clone --depth 1 math math.clone6
Cloning into 'math.clone6'...
warning: --depth is ignored in local clones; use file:// instead.
done.
mathがD:\git\mathにある場合でかつWindowsの場合、$ git clone --depth 1 file://D:\git\math math.clone7とうつとfatalになって失敗します。
$ git clone --depth 1 file://D:\git\math math.clone7
Cloning into 'math.clone7'...
fatal: 'D:gitmath' does not appear to be a git repository
fatal: Could not read from remote repository.
が消えているので、おそらく\をエスケープすればいけるだろうと思いました。
$ git clone --depth 1 file://D:\\git\\math math.clone7
Cloning into 'math.clone7'...
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 4 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (4/4), done.
いけました。

pg_basebackupの--max-rateを適切に設定する

pg_basebackupはオプションでサーバから転送されるデータの最大転送速度を指定できます。
例えば
pg_basebackup -U replication_user -r 5M -X s -h 192.168.0.13 -p 5433 -D /var/lib/pgsql/11/data --write-recovery-conf
とすると、5MB…つまり40Mbpsに制限することができます。
このオプションを指定しないと全力でデータを転送しに行きます。
この転送はとてもサーバーに負荷をかけるのでサーバーのスペックによっては適切に値を設定すべきです。

ErogameScapeではPostgreSQLの冗長化のためにrsyncを使ってデータを同期していました。
rsyncでデータを転送する場合はI/O負荷はまったく問題なかったのに、pg_basebackupで-rオプションなしでデータを転送したところ、滅茶苦茶I/O負荷がかかって、現用サービスに影響を与えました。
※ErogameScapeのサーバーはいつ買ったかもう覚えていない頃のハードなので…この問題が問題になるのはErogameScapeだけかもしれません。

また、pg_basebackupをする元のサーバーと先のサーバーのネットワーク帯域も考慮する必要があります。
ErogameScapeは自宅サーバーで運用しているのですが、バックアップは非同期レプリケーションを使って専用サーバーにとっています。
専用サーバーにpg_basebackupする際は、I/O負荷ではなく帯域の制限を考慮して-rオプションを適切に設定してあげないと、ユーザーさんのトラヒックが流れなくなるくらい、pg_basebackupが帯域を使ってしまいます。

VACUUM waiting for 3/2E61F968

ErogameScapeのPostgreSQLを9.6から11にあげる時に発生した事象です。
再現試験をしていないのでメモです。

実行しないと、ErogameScapeでは、クエリの応答がとても遅くなります。
※データが少ない環境では、ANALYZEしなくても分からないと思います。

192.168.0.13(erogamescape13)がプライマリ
192.168.0.14がスタンバイ(同期レプリケーション)
という構成で、192.168.0.13でVACUUM ANALYZEコマンドを実行したら、いくら待っても応答が返ってこない事象が発生しました。
ap2=# VACUUM ANALYZE ;

[ap2@erogamescape13 ~]$ ps ax | grep VA
14098 pts/3    S+     0:00 grep VA
30871 ?        Ss     0:43 postgres: ap2 ap2 [local] VACUUM waiting for 3/2E61F968
何か待っています。
テスト環境でPostgreSQLを動かしているので、誰もデータの更新等はしていません。
統計情報を更新しているのでPostgreSQL内部ではデータが更新されていると思います。
全然応答が返らないのでCtrl-Cしてみました。
ap2=# VACUUM ANALYZE ;

^CCancel request sent
WARNING:  canceling wait for synchronous replication due to user request
DETAIL:  The transaction has already committed locally, but might not have been replicated to the standby.
ローカルではcommitしたけどstandbyではcommitしていないとのことでしたので…スタンバイを再起動すれば、WALの再生が始まるかな?と思い、スタンバイのpostgresqlを落としました。
このときの、pgpoolのSHOW POOL_NODESの結果は以下のとおりです。
[ap2@erogamescape14 ~]$ psql -p 8999 -h 192.168.0.101 -U postgres -c "SHOW POOL_NODES ;"
 node_id |   hostname   | port | status | lb_weight |  role   | select_cnt | load_balance_node | replication_delay | last_st
atus_change
---------+--------------+------+--------+-----------+---------+------------+-------------------+-------------------+--------
-------------
 0       | 192.168.0.14 | 5433 | down   | 0.500000  | standby | 242        | false             | 2073065311        | 2019-05
-05 12:54:04
 1       | 192.168.0.13 | 5433 | up     | 0.500000  | primary | 105        | true              | 0                 | 2019-05
-05 11:59:39
replication_delayの値が大変なことに…
スタンバイのpostgresqlを立ち上げたのですが、レプリケーション状態になりませんでした。
ログを確認すると以下のとおりWALがすでにないということでした。
[root@erogamescape14 ap2]# tail /var/lib/pgsql/11/data/log/postgresql-Sun.log
2019-05-05 13:04:31.122 JST [29843] LOG:  started streaming WAL from primary at 2/B2000000 on timeline 1
2019-05-05 13:04:31.122 JST [29843] FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 0000000100000002000000B2 has already been removed
アーカイブはとっていないので、レプリケーション状態にもっていくにはpg_basebackupをしないと駄目になりました。
VACUUM ANALYZしただけで、そんなにWALを生成するのか?と、確認したところ
[root@erogamescape13 pg_wal]# ls -lh
合計 1009M
-rw------- 1 postgres postgres  16M  5月  5 13:04 2019 0000000100000003000000BE
-rw------- 1 postgres postgres  16M  5月  5 12:57 2019 0000000100000003000000BF
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000C0
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000C1
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000C2
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000C3
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000C4
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000C5
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000C6
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000C7
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000C8
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000C9
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000CA
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000CB
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000CC
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000CD
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000CE
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000CF
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000D0
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000D1
-rw------- 1 postgres postgres  16M  5月  5 12:58 2019 0000000100000003000000D2
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000D3
-rw------- 1 postgres postgres  16M  5月  5 13:00 2019 0000000100000003000000D4
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000D5
-rw------- 1 postgres postgres  16M  5月  5 13:00 2019 0000000100000003000000D6
-rw------- 1 postgres postgres  16M  5月  5 13:01 2019 0000000100000003000000D7
-rw------- 1 postgres postgres  16M  5月  5 13:01 2019 0000000100000003000000D8
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000D9
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000DA
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000DB
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000DC
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000DD
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000DE
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000DF
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000E0
-rw------- 1 postgres postgres  16M  5月  5 13:03 2019 0000000100000003000000E1
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000E2
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000E3
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000E4
-rw------- 1 postgres postgres  16M  5月  5 13:03 2019 0000000100000003000000E5
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000E6
-rw------- 1 postgres postgres  16M  5月  5 13:03 2019 0000000100000003000000E7
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000E8
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000E9
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000EA
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000EB
-rw------- 1 postgres postgres  16M  5月  5 13:00 2019 0000000100000003000000EC
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000ED
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000EE
-rw------- 1 postgres postgres  16M  5月  5 12:59 2019 0000000100000003000000EF
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000F0
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000F1
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000F2
-rw------- 1 postgres postgres  16M  5月  5 13:03 2019 0000000100000003000000F3
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000F4
-rw------- 1 postgres postgres  16M  5月  5 13:00 2019 0000000100000003000000F5
-rw------- 1 postgres postgres  16M  5月  5 13:03 2019 0000000100000003000000F6
-rw------- 1 postgres postgres  16M  5月  5 13:03 2019 0000000100000003000000F7
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000F8
-rw------- 1 postgres postgres  16M  5月  5 13:01 2019 0000000100000003000000F9
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000FA
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000FB
-rw------- 1 postgres postgres  16M  5月  5 13:02 2019 0000000100000003000000FC
と1GBを超えるWALを短時間に生成していました。

ErogameScapeを9.6から11に移行する際は、リストア→ANALYZE→レプリケーションの順番に実行することにしました。

PostgreSQL関連の技術資料

私が読んだり目を通した中で一番内容が濃いPostgreSQLの技術資料はPostgreSQL エンタープライズ・コンソーシアムです。

ErogameScapeに本格的にストリーミングレプリケーションを導入するにあたって、障害発生時と復旧時の手順の確認をしているのですが、ワーキンググループ活動報告の課題検討WG (WG3)2017年度WG3活動報告書 レプリケーション調査編を最初に読んでからスタートすれば試行錯誤する時間が少なくてよかったなあ…と思います。

PostgreSQL関連の書籍は

が良書ですが、レプリケーションの章は内容が浅いです。
2017年度WG3活動報告書 レプリケーション調査編の方がとても詳細ですし、公式ドキュメントく具体的にどう設定したら分からない…(よく読めば分かるのですが、読まないと行けない箇所がいろいろなところに散らばっていて、読みながら設定していく…ということは出来ないと感じます)ので、大変お勧めです。
記事検索