- バックアップ一覧
- 差分 を表示
- 現在との差分 を表示
- ソース を表示
- PostgreSQL/Pgpool-II/フェイルオーバー へ行く。
- 1 (2017-11-13 (月) 23:56:36)
- 2 (2017-11-13 (月) 23:57:45)
- 3 (2017-11-23 (木) 16:10:53)
- 4 (2017-11-23 (木) 23:34:19)
- 5 (2017-11-26 (日) 22:39:21)
- 6 (2017-11-27 (月) 00:17:33)
- 7 (2017-11-27 (月) 23:09:27)
- 8 (2017-11-29 (水) 01:26:39)
- 9 (2017-11-29 (水) 22:47:05)
- 10 (2017-12-02 (土) 21:06:08)
- 11 (2017-12-06 (水) 22:12:17)
- 12 (2017-12-08 (金) 22:47:05)
- 13 (2017-12-08 (金) 23:56:04)
- 14 (2017-12-09 (土) 11:43:37)
- 15 (2017-12-13 (水) 21:50:34)
- 16 (2017-12-15 (金) 01:14:08)
- 17 (2018-02-04 (日) 22:32:14)
ストリーミングレプリケーションモードを前提に記述する。
フェイルオーバー †
バックエンドノードへの障害が発生した場合、残りの稼働しているノードで運用を継続する。
障害発生したノードに対するコネクションの切り替え及びバックエンドのプライマリノードの切り替え(failover_commandの実行)機能を提供する。
なお、バックエンドのプライマリノードへの切り替えは、Pgpool2の出口コマンドを使用しなくとも可能である。
フェイルオーバーのタイミング †
- ヘルスチェックのタイムアウト
- バックエンドへのコネクション接続エラー
- バックエンドへのread/writeエラー
など
フェイルオーバーの内部動作 †
- フェイルオーバー契機が与えられると、フェイルオーバーリクエストが共有メモリ上の待ち行列に書き込まれる。続いて、フェイルオーバー処理依頼のシグナル(SIGUSR1)が親プロセスに送信される。
参考register_node_operation_request() - on https://git.postgresql.org/gitweb/?p=pgpool2.git - フェイルオーバー処理はPgpoolの親プロセスで実行され、以下の関数で行われる。
参考failover() - on https://git.postgresql.org/gitweb/?p=pgpool2.git
フェイルオーバーの設定 †
fail_over_on_backend_error
またはhealth_check_period
の指定(1以上整数)が必要。
いずれも設定されていない状態で、プライマリノード障害が発生した場合、クライアントからの接続は成功せず以下のエラーとなる。
psql: FATAL: failed to create a backend 0 connection DETAIL: not executing failover because fail_over_on_backend_error is off
なお、health_checkは親プロセスからforkしたworkerプロセスで実施される。参考do_health_check_child()
health_checkがタイムアウトすると、degenerate_backend_set関数が呼ばれフェイルオーバーリクエストが待ち行列に追加され、フェイルオーバー処理を通知するシグナルがpgpoolの親プロセスに送信される。
フェイルオーバープロセス概要 †
failover()関数の処理概要は以下の通りである。(詳細は、ソースコードを参照のこと)
- 共有メモリの待ち行列にスイッチ中のフラグを立て、待ち行列のリクエスト処理ループに入る。
- 待ち行列のセマフォのロック。待ち行列にリクエストがなければ、アンロックして終了。
- 待ち行列からリクエストを取り出し、セフォマのアンロック。
- リクエストが「CLOSE_IDLE_REQUEST」ならば、すべての子プロセスにSIGUSR1シグナルを送信する。
(子プロセスは、SIGUSR1シグナルを受信するとアイドル状態のバックエンド接続を閉じる) - watchdogが有効ならば、watchdogにフェイルオーバー処理を通知する。
- 待ち行列のリクエストごとに以下の分岐
- NODE_UP_REQUESTの場合
・バックエンドが全てダウンしていないか調べる。
・バックエンドのステータスをCON_CONNECT_WAITにセットする。
・リクエストがREQ_DETAIL_UPDATEでなければfailback_commandを実行する。 - PROMOTE_NODE_REQUESTの場合
node_idがVALID_BACKENDでなければループをcontinueする。 - NODE_DOWN_REQUEST && NODE_QUARANTINE_REQUESTの場合
プライマリノードがダウンした場合など、このステップを通過する。NODE_QUARANTINE_REQUESTは、watchdogでクォーラムを組んでいる時のリクエスト種別である。ここで、障害でダウンしたデータベースノードを調べる。
- NODE_UP_REQUESTの場合
- 新しいマスタノードを決める。
- 待ち行列のリクエストごとに以下の分岐
- ストリーミングレプリケーションかつNODE_UP_REQUESTかつバックエンドが全てダウンしていない場合
need_to_restart_children = false、partial_restart = false
- ストリーミングレプリケーションかつ(NODE_DOWN_REQUESTまたはNODE_QUARANTINE_REQUEST)かつREQ_DETAIL_SWITCHOVERでプライマリノードでない場合
need_to_restart_children = true、partial_restart = true
- それ以外(プライマリノードダウンはここ)
すべての子プロセスにシグナルSIGQUITが送信される(すべての子プロセスは終了する)。子プロセス再起動のフラグを立てる。
need_to_restart_children = true、partial_restart = false
(ユーザーからのリクエストをacceptする子プロセスがいなくなる。)
- ストリーミングレプリケーションかつNODE_UP_REQUESTかつバックエンドが全てダウンしていない場合
- 待ち行列のリクエストがNODE_DOWN_REQUESTの場合、failover_commandに指定されたスクリプトを実行する。新しいプライマリノード候補のpromoteが実行される。
- 新しいプライマリノードを探索(pg_is_in_recovery()でチェック、探索時間はsearch_primary_node_timeoutパラメータ)
- ストリーミングレプリケーションモードの場合、follow_master_commandを実行する。この動作は、プロセスをforkして子プロセスで実行される。
- need_to_restart_childrenがtrueであれば、子プロセスの再起動を行なう。need_to_restart_childrenがfalseの場合は、リスタートフラグを立てるだけ。(子プロセス中でセッションが終了したタイミングで再起動される。)
参考check_restart_request() - on https://git.postgresql.org/gitweb/?p=pgpool2.git - workerにSIGUSR1シグナル(再起動通知)を送信する。
- sync_requiredがtrueならば、watchdogのフェイルオーバの終了処理。
- スイッチフラグを解除。
- pcpプロセスにSIGUSR2シグナルを送信し、failover/failbackの完了を通知。
- pcp再起動。
プライマリノードの検出 †
1 secのインターバルでsearch_primary_node_timeout
になるまでpg_is_in_recovery()
関数を使ってプライマリノードの検出を試みる。
参考 verify_backend_node_status()
障害ケースとプロセス †
ケース:プライマリノードダウン+fail_over_on_backend_error = onの場合 †
<テスト条件>
- プライマリノードダウン
pg_ctl -m i -D pgdata stop
- クライアント
- psqlで更新クエリを連続実行
- pgpool 3.7RC1
- num_init_children = 1
- fail_over_on_backend_error = on
- health_check_period = 0
- OS
- Mac OS X
- PostgreSQL
- 10.0
<実行>
連続クエリ実行中にプライマリノード障害を発生させ、親プロセスにシグナル送信される過程のスタックトレースが以下。
シグナル送信前にブレークポイントを設定している。
* thread #1: tid = 0x89d759, 0x0000000107d9ec63 pgpool`signal_user1_to_parent_with_reason(reason=SIG_FAILOVER_INTERRUPT) + 35 at pgpool_main.c:535, queue = 'com.apple.main-thread', stop reason = breakpoint 24.1 * frame #0: 0x0000000107d9ec63 pgpool`signal_user1_to_parent_with_reason(reason=SIG_FAILOVER_INTERRUPT) + 35 at pgpool_main.c:535 frame #1: 0x0000000107d9c4dc pgpool`register_node_operation_request(kind=NODE_DOWN_REQUEST, node_id_set=0x00007fff57e605c0, count=1, flags='\x01') + 460 at pgpool_main.c:508 frame #2: 0x0000000107d9f458 pgpool`degenerate_backend_set_ex(node_id_set=0x00007fff57e60824, count=1, flags='\x01', error='\0', test_only='\0') + 1720 at pgpool_main.c:1089 frame #3: 0x0000000107d9ed92 pgpool`degenerate_backend_set(node_id_set=0x00007fff57e60824, count=1, flags='\x01') + 50 at pgpool_main.c:1138 frame #4: 0x0000000107d9ed54 pgpool`notice_backend_error(node_id=0, flags='\x01') + 148 at pgpool_main.c:988 frame #5: 0x0000000107dd9ca8 pgpool`new_connection(p=0x00007fc8ec003248) + 792 at pool_connection_pool.c:873 frame #6: 0x0000000107dd94e1 pgpool`pool_create_cp + 225 at pool_connection_pool.c:248 frame #7: 0x0000000107dc9c1c pgpool`connect_backend(sp=0x00007fc8ed801f88, frontend=0x00007fc8ed800038) + 44 at child.c:868 frame #8: 0x0000000107dc6795 pgpool`get_backend_connection(frontend=0x00007fc8ed800038) + 981 at child.c:2326 frame #9: 0x0000000107dc465a pgpool`do_child(fds=0x00007fc8ebe00620) + 1898 at child.c:337 frame #10: 0x0000000107d9aac0 pgpool`fork_a_child(fds=0x00007fc8ebe00620, id=0) + 160 at pgpool_main.c:607 frame #11: 0x0000000107d979c6 pgpool`PgpoolMain(discard_status='\x01', clear_memcache_oidmaps='\0') + 1878 at pgpool_main.c:363 frame #12: 0x0000000107d95ea8 pgpool`main(argc=9, argv=0x00007fff57e6b7a8) + 2232 at main.c:318 frame #13: 0x00007fff920465ad libdyld.dylib`start + 1 frame #14: 0x00007fff920465ad libdyld.dylib`start + 1
notice_backend_error関数の実行後、子プロセスはabortして終了する。参考pool_connection_pool.c#new_connection()
pgpoolのログは以下のとおりである。
2017-11-23 23:11:07: pid 87593: [CHILD:269] LOG: DB node id: 0 backend pid: 87759 statement: insert into foo_t values(53); 2017-11-23 23:11:07: pid 87593: [CHILD:270] LOCATION: pool_proto_modules.c:3116 2017-11-23 23:11:07: pid 87593: [CHILD:271] LOG: DB node id: 0 backend pid: 87759 statement: DISCARD ALL 2017-11-23 23:11:07: pid 87593: [CHILD:272] LOCATION: pool_proto_modules.c:3116 2017-11-23 23:11:07: pid 87593: [CHILD:273] LOG: DB node id: 1 backend pid: 87760 statement: DISCARD ALL 2017-11-23 23:11:07: pid 87593: [CHILD:274] LOCATION: pool_proto_modules.c:3116 2017-11-23 23:11:07: pid 87593: [CHILD:275] LOG: connection closed. 2017-11-23 23:11:07: pid 87593: [CHILD:276] DETAIL: retry to create new connection pool 2017-11-23 23:11:07: pid 87593: [CHILD:277] LOCATION: pool_connection_pool.c:149 2017-11-23 23:11:07: pid 87593: [CHILD:278] LOG: failed to connect to PostgreSQL server by unix domain socket 2017-11-23 23:11:07: pid 87593: [CHILD:279] DETAIL: connect to "/tmp/.s.PGSQL.11002" failed with error "Undefined error: 0" 2017-11-23 23:11:07: pid 87593: [CHILD:280] LOCATION: pool_connection_pool.c:522 2017-11-23 23:11:07: pid 87593: [CHILD:281] LOG: received degenerate backend request for node_id: 0 from pid [87593] 2017-11-23 23:11:07: pid 87593: [CHILD:282] LOCATION: pgpool_main.c:1053 2017-11-23 23:11:07: pid 87593: [CHILD:283] FATAL: failed to create a backend connection 2017-11-23 23:11:07: pid 87593: [CHILD:284] DETAIL: executing failover on backend <== 子プロセスはabort 2017-11-23 23:11:07: pid 87593: [CHILD:285] LOCATION: pool_connection_pool.c:876 2017-11-23 23:11:07: pid 87587: [MAIN:17] LOG: Pgpool-II parent process has received failover request <== 親プロセスでfailover開始 2017-11-23 23:11:07: pid 87587: [MAIN:18] LOCATION: pgpool_main.c:1502 2017-11-23 23:11:07: pid 87587: [MAIN:19] LOG: starting degeneration. shutdown host /tmp(11002) 2017-11-23 23:11:07: pid 87587: [MAIN:20] LOCATION: pgpool_main.c:1714 2017-11-23 23:11:07: pid 87587: [MAIN:21] LOG: Restart all children <== 子プロセスは全てkillされる 2017-11-23 23:11:07: pid 87587: [MAIN:22] LOCATION: pgpool_main.c:1835 2017-11-23 23:11:07: pid 87587: [MAIN:23] LOG: execute command: /Users/guest/workspace/pgpool/test/etc/failover.sh 0 /tmp 11002 /Users/guest/workspace/pgpool/test/data0 1 0 /tmp 0 11003 /Users/guest/workspace/pgpool/test/data1 2017-11-23 23:11:07: pid 87587: [MAIN:24] LOCATION: pgpool_main.c:2795 2017-11-23 23:11:07: pid 87587: [MAIN:25] LOG: find_primary_node_repeatedly: waiting for finding a primary node 2017-11-23 23:11:07: pid 87587: [MAIN:26] LOCATION: pgpool_main.c:2967 2017-11-23 23:11:07: pid 87587: [MAIN:27] LOG: find_primary_node: checking backend no 0 2017-11-23 23:11:07: pid 87587: [MAIN:28] LOCATION: pgpool_main.c:2910 2017-11-23 23:11:07: pid 87587: [MAIN:29] LOG: find_primary_node: checking backend no 1 2017-11-23 23:11:07: pid 87587: [MAIN:30] LOCATION: pgpool_main.c:2910 2017-11-23 23:11:07: pid 87587: [MAIN:31] LOG: find_primary_node: primary node id is 1 2017-11-23 23:11:07: pid 87587: [MAIN:32] LOCATION: pgpool_main.c:2940 2017-11-23 23:11:07: pid 87587: [MAIN:33] LOG: starting follow degeneration. shutdown host /tmp(11002) 2017-11-23 23:11:07: pid 87587: [MAIN:34] LOCATION: pgpool_main.c:1928 2017-11-23 23:11:07: pid 87587: [MAIN:35] LOG: failover: 1 follow backends have been degenerated 2017-11-23 23:11:07: pid 87587: [MAIN:36] LOCATION: pgpool_main.c:1946 === follow_master_commandを実行するプロセスがforkされる === 2017-11-23 23:11:07: pid 87587: [MAIN:37] LOG: failover: set new primary node: 1 2017-11-23 23:11:07: pid 87587: [MAIN:38] LOCATION: pgpool_main.c:1961 2017-11-23 23:11:07: pid 87587: [MAIN:39] LOG: failover: set new master node: 1 2017-11-23 23:11:07: pid 87587: [MAIN:40] LOCATION: pgpool_main.c:1968 === ここで新しい子プロセスがforkされる === failover done. shutdown host /tmp(11002)2017-11-23 23:11:07: pid 87587: [MAIN:41] LOG: failover done. shutdown host /tmp(11002) 2017-11-23 23:11:07: pid 87587: [MAIN:42] LOCATION: pgpool_main.c:2074 2017-11-23 23:11:07: pid 87596: [WORKER:1] LOG: worker process received restart request 2017-11-23 23:11:07: pid 87596: [WORKER:2] LOCATION: pool_worker_child.c:155 2017-11-23 23:11:07: pid 88001: [UTILITY:1] LOG: start triggering follow command. <== follow_master_commandが実行される 2017-11-23 23:11:07: pid 88001: [UTILITY:2] LOCATION: pgpool_main.c:2995 2017-11-23 23:11:07: pid 88001: [UTILITY:3] LOG: execute command: /Users/guest/workspace/pgpool/test/etc/follow_master.sh 0 /tmp 11002 /Users/guest/workspace/pgpool/test/data0 1 0 /tmp 0 11003 /Users/guest/workspace/pgpool/test/data1 2017-11-23 23:11:07: pid 88001: [UTILITY:4] LOCATION: pgpool_main.c:2795 2017-11-23 23:11:07: pid 88002: [CHILD:1] LOG: DB node id: 1 backend pid: 88004 statement: insert into foo_t values(55); <== クエリのリトライ 2017-11-23 23:11:07: pid 88002: [CHILD:2] LOCATION: pool_proto_modules.c:3116 2017-11-23 23:11:07: pid 88002: [CHILD:3] LOG: DB node id: 1 backend pid: 88004 statement: DISCARD ALL 2017-11-23 23:11:07: pid 88002: [CHILD:4] LOCATION: pool_proto_modules.c:3116
メモ
子プロセスはfailover関数の早いうちにSIGQUITシグナルを受信しexitするため、Pgpoolのソケットに対するacceptは実行されない。したがってクライアントは子プロセスが再起動されるまで待ち状態となる。(listenキューのバックログ)
フェイルオーバー処理の途中でPgpoolへコネクション接続があった場合 †
以下のようなケースの場合はどうか検証してみる。それぞれ、デバッガーで停止させて検証してみた。
-- (1) グローバルステータスをダウンに更新 -- (2) ダウンしたノードに接続している子プロセスのkill
以下の(1)(2)は、スタンバイノードダウン+fail_over_on_backend_error = onの場合も同様である。
- (1)の場合
- グローバルのバックエンドステータス更新前かつ子プロセスにSIGQUITが送信される前にクライアントからのPgpoolへのコネクション接続があった場合、子プロセスはバックエンドの接続に失敗しexitするためクライアントのPgpoolへのコネクション接続は失敗する。
グローバルのバックエンドステータスはノードダウンのリクエストが通知されるとfailover関数内でCON_DOWNに更新される。(ソース解析と動作からおそらくそうなる)
参考pool_connection_pool.c#new_connection()
仮に親プロセスのfailover処理が実行されずグローバルのバックエンドステータスがCON_DOWNに更新されない場合、preforkされている子プロセスはクライアントからPgpoolへのコネクション接続があるたびにバックエンドへのコネクション接続で失敗しexitする。num_init_childrenで設定された子プロセスが全てexitするとacceptする子プロセスがいなくなり、クライアントのPgpoolへのコネクション接続は待ち状態となる(listenキューのバックログ)。
- グローバルのバックエンドステータス更新前かつ子プロセスにSIGQUITが送信される前にクライアントからのPgpoolへのコネクション接続があった場合、子プロセスはバックエンドの接続に失敗しexitするためクライアントのPgpoolへのコネクション接続は失敗する。
- (2)の場合
- 途中でEXEC_BAD_ACCESSになってしまう。
* thread #1: tid = 0x130de1b, 0x000000010ecb7e5c pgpool`connect_backend(sp=0x00007fdc2c803588, frontend=0x00007fdc2c801638) + 652 at child.c:891, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10) * frame #0: 0x000000010ecb7e5c pgpool`connect_backend(sp=0x00007fdc2c803588, frontend=0x00007fdc2c801638) + 652 at child.c:891 frame #1: 0x000000010ecb4775 pgpool`get_backend_connection(frontend=0x00007fdc2c801638) + 981 at child.c:2326 frame #2: 0x000000010ecb263a pgpool`do_child(fds=0x00007fdc2be00000) + 1898 at child.c:337 frame #3: 0x000000010ec88a30 pgpool`fork_a_child(fds=0x00007fdc2be00000, id=3) + 160 at pgpool_main.c:607 frame #4: 0x000000010ec85936 pgpool`PgpoolMain(discard_status='\x01', clear_memcache_oidmaps='\0') + 1878 at pgpool_main.c:363 frame #5: 0x000000010ec83e18 pgpool`main(argc=9, argv=0x00007fff50f7d7a8) + 2232 at main.c:318 frame #6: 0x00007fff920465ad libdyld.dylib`start + 1 frame #7: 0x00007fff920465ad libdyld.dylib`start + 1
が、おそらくBugだとは思う。コネクションスロットの参照でNULLポインタへアクセスしているためである。この時、psqlからの接続では以下のようなエラーが返ってくる。psql: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request.
子プロセスが再起動され、DBコネクション接続のグローバルステータスが更新され、ローカルステータスも更新されると正常処理に戻る。
なお、接続済みのプールされたコネクションも途中でソケットのbrokenチェックがされ、エラーであればcloseされて、またnew_connection()の処理へと進む。
- 途中でEXEC_BAD_ACCESSになってしまう。
フェイルオーバー処理で新プライマリノードに切り替わらない場合 †
以下のケースではどうか。
failover() // 以下便宜上番号を振る 1. グローバルステータスをダウンに更新 2. ダウンしたノードに接続している子プロセスのkill 3. failover_commandの実行(あれば) <-- 指定しない(新プライマリノードに切り替わらない場合) 4. プライマリノードの検出 5. follow_master_commandの実行(あれば) 6. 子プロセス起動 7. worker、popの再起動
この場合、負荷分散可能であれば、6番のステップ以降、スタンバイノードで処理が継続できる。
ただし、更新クエリを実行する場合はマスターノードが選択されるが、プライマリノードでないためエラーとなる。
参考 pool_set_node_to_be_sent()
* thread #1: tid = 0x168c4f3, 0x000000010f3c940d pgpool`send_to_where(node=0x00007fba6a8093e8, query="insert into foo_t (id) values (9999);") + 45 at pool_query_context.c:1185, queue = 'com.apple.main-thread', stop reason = step in * frame #0: 0x000000010f3c940d pgpool`send_to_where(node=0x00007fba6a8093e8, query="insert into foo_t (id) values (9999);") + 45 at pool_query_context.c:1185 frame #1: 0x000000010f3c8766 pgpool`pool_where_to_send(query_context=0x00007fba6a022c38, query="insert into foo_t (id) values (9999);", node=0x00007fba6a8093e8) + 710 at pool_query_context.c:449 frame #2: 0x000000010f3ae768 pgpool`SimpleQuery(frontend=0x00007fba6b800038, backend=0x000000010f85d078, len=38, contents="insert into foo_t (id) values (9999);") + 3528 at pool_proto_modules.c:480 frame #3: 0x000000010f3b67ee pgpool`ProcessFrontendResponse(frontend=0x00007fba6b800038, backend=0x000000010f85d078) + 1134 at pool_proto_modules.c:2358 frame #4: 0x000000010f39eb38 pgpool`read_packets_and_process(frontend=0x00007fba6b800038, backend=0x000000010f85d078, reset_request=0, state=0x00007fff5088e374, num_fields=0x00007fff5088e392, cont="\x01\377) + 4168 at pool_process_query.c:4729 frame #5: 0x000000010f39cd3a pgpool`pool_process_query(frontend=0x00007fba6b800038, backend=0x000000010f85d078, reset_request=0) + 1226 at pool_process_query.c:226 frame #6: 0x000000010f3967cd pgpool`do_child(fds=0x00007fba69e00000) + 2301 at child.c:383 frame #7: 0x000000010f36ca40 pgpool`fork_a_child(fds=0x00007fba69e00000, id=1) + 160 at pgpool_main.c:607 frame #8: 0x000000010f370558 pgpool`failover + 8424 at pgpool_main.c:2024 frame #9: 0x000000010f36bc1c pgpool`sigusr1_interupt_processor + 1164 at pgpool_main.c:1511 frame #10: 0x000000010f369d59 pgpool`PgpoolMain(discard_status='\x01', clear_memcache_oidmaps='\0') + 2921 at pgpool_main.c:436 frame #11: 0x000000010f367e28 pgpool`main(argc=9, argv=0x00007fff508997a8) + 2232 at main.c:318 frame #12: 0x00007fff920465ad libdyld.dylib`start + 1 frame #13: 0x00007fff920465ad libdyld.dylib`start + 1
以下、sqlの実行例である。
$ psql -p 11000 -c "select count(*) from foo_t;" foo count ------- 10000 (1 row) $ psql -p 11000 -c "insert into foo_t (id) values (9999);" foo ERROR: cannot execute INSERT in a read-only transaction
pgpoolのログも参考に掲載する。
以下は、フェイルオーバー処理実行のログである。
2017-12-02 19:59:43: [MAIN] pid 49506: LOG: failover: no follow backends are degenerated 2017-12-02 19:59:43: [MAIN] pid 49506: LOCATION: pgpool_main.c:1944 2017-12-02 19:59:43: [MAIN] pid 49506: LOG: failover: set new primary node: -1 <-- プライマリノードは検出できず 2017-12-02 19:59:43: [MAIN] pid 49506: LOCATION: pgpool_main.c:1966 2017-12-02 19:59:43: [MAIN] pid 49506: LOG: failover: set new master node: 1 2017-12-02 19:59:43: [MAIN] pid 49506: LOCATION: pgpool_main.c:1973
psqlでクエリを実行した時のログ。
2017-12-02 20:01:17: [CHILD] pid 52617: LOG: DB node id: 1 backend pid: 53369 statement: select count(*) from foo_t; 2017-12-02 20:01:17: [CHILD] pid 52617: LOCATION: pool_proto_modules.c:3116 2017-12-02 20:01:17: [CHILD] pid 52617: LOG: DB node id: 1 backend pid: 53369 statement: DISCARD ALL 2017-12-02 20:01:17: [CHILD] pid 52617: LOCATION: pool_proto_modules.c:3116 2017-12-02 20:01:19: [CHILD] pid 52617: LOG: DB node id: 1 backend pid: 53369 statement: insert into foo_t (id) values (9999); 2017-12-02 20:01:19: [CHILD] pid 52617: LOCATION: pool_proto_modules.c:3116 2017-12-02 20:01:19: [CHILD] pid 52617: LOG: pool_send_and_wait: Error or notice message from backend: : DB node id: 1 backend pid: 53369 statement: "insert into foo_t (id) values (9999);" message: "cannot execute INSERT in a read-only transaction" 2017-12-02 20:01:19: [CHILD] pid 52617: LOCATION: pool_proto_modules.c:3132 2017-12-02 20:01:19: [CHILD] pid 52617: LOG: DB node id: 1 backend pid: 53369 statement: DISCARD ALL 2017-12-02 20:01:19: [CHILD] pid 52617: LOCATION: pool_proto_modules.c:3116