そこで、いくつかのおもちゃの postgresql インフラストラクチャをいくつかのローカル仮想マシンでテストして、フェールオーバー時に pgpool がどのように動作するかを判断しています。2 つのデータベース マシン (192.168.0.2 と 192.168.0.3) と pgpool マシン (192.168.0.4) を持つ基本的なセットアップを構成しました。192.168.0.3 は、ストリーミング レプリケーションを使用して 192.168.0.2 のスレーブとして設定されています。pgpool-ii は以下を使用して構成されています。
listen_addresses = '*'
backend_hostname0 = '192.168.0.2'
backend_port0 = 5432
backend_weight0 = 1
backend_data_directory0 = '/var/lib/postgresql/9.4/main/'
backend_flag0 = 'ALLOW_TO_FAILOVER'
backend_hostname1 = '192.168.0.3'
backend_port1 = 5432
backend_weight1 = 1
backend_data_directory1 = '/var/lib/postgresql/9.4/main/'
backend_flag1 = 'ALLOW_TO_FAILOVER'
enable_pool_hba = on
replication_mode = false
master_slave_mode = on
master_slave_sub_mode = 'stream'
fail_over_on_backend_error = true
failover_command = '/root/pgpool_failover_stream.sh %d %H /tmp/postgresql.trigger.5432'
load_balance_mode = false
これですべて動作することを確認しました。つまり、マスター データベースを変更してもレプリケーションは機能しており、サンプル アプリケーションを使用してマスター、スレーブ、および pgpool-ii に接続し、期待どおりの結果を得ることができます。
service postgresql stopここで、pgpool に接続する長時間実行されるアプリケーションを開始し、マスター データベース サーバーに SSH で接続して ( root として) postgres タスクを強制的に終了することにより、フェールオーバーを引き起こそうとしました。アプリケーションはクエリを正しく実行し続けますが、フェイルオーバーは発生しません (スクリプトが実行されていません)。master データベースに直接接続することもテストしましたが、postgres サービスを停止すると、アプリケーションがクラッシュしてしまいます。
私は何か間違ったことをしていますか？pgpool を正しく構成していませんか? または、フェイルオーバーをトリガーするより良い方法はありますか?
編集: 要求に応じて、最初のエラーが発生したログの部分を次に示します。
...
2016-03-15 18:47:15: pid 1232: DEBUG: initializing backend status
2016-03-15 18:47:15: pid 1231: DEBUG: initializing backend status
2016-03-15 18:47:15: pid 1230: DEBUG: initializing backend status
2016-03-15 18:47:15: pid 1209: ERROR: failed to authenticate
2016-03-15 18:47:15: pid 1209: DETAIL: invalid authentication message response type, Expecting 'R' and received 'E'
2016-03-15 18:47:15: pid 1209: LOG: find_primary_node: checking backend no 1
2016-03-15 18:47:15: pid 1209: ERROR: failed to authenticate
2016-03-15 18:47:15: pid 1209: DETAIL: invalid authentication message response type, Expecting 'R' and received 'E'
2016-03-15 18:47:15: pid 1209: DEBUG: find_primary_node: no primary node found
...
奇妙なことに、私はまだpgpoolに接続してクエリを実行できるので、明らかにそこにあるものを理解していません.
編集2:これらはservice postgresql shutdown、マスターで発生したエラーです。pgpoolのシャットダウン開始までのすべてを表示します。
...
2016-03-16 17:24:57: pid 1012: DEBUG: session context: clearing doing extended query messaging. DONE
2016-03-16 17:24:57: pid 1012: DEBUG: session context: setting doing extended query messaging. DONE
2016-03-16 17:24:57: pid 1012: DEBUG: session context: setting query in progress. DONE
2016-03-16 17:24:57: pid 1012: DEBUG: reading backend data packet kind
2016-03-16 17:24:57: pid 1012: DETAIL: backend:0 of 2 kind = 'E'
2016-03-16 17:24:57: pid 1012: DEBUG: processing backend response
2016-03-16 17:24:57: pid 1012: DETAIL: received kind 'E'(45) from backend
2016-03-16 17:24:57: pid 1012: ERROR: unable to forward message to frontend
2016-03-16 17:24:57: pid 1012: DETAIL: FATAL error occured on backend
2016-03-16 17:24:57: pid 1012: DEBUG: session context: setting query in progress. DONE
2016-03-16 17:24:57: pid 1012: DEBUG: decide where to send the queries
2016-03-16 17:24:57: pid 1012: DETAIL: destination = 3 for query= "DISCARD ALL"
2016-03-16 17:24:57: pid 1012: DEBUG: waiting for query response
2016-03-16 17:24:57: pid 1012: DETAIL: waiting for backend:0 to complete the query
2016-03-16 17:24:57: pid 1012: FATAL: unable to read data from DB node 0
2016-03-16 17:24:57: pid 1012: DETAIL: EOF encountered with backend
2016-03-16 17:24:57: pid 998: DEBUG: reaper handler
2016-03-16 17:24:57: pid 998: LOG: child process with pid: 1012 exits with status 256
2016-03-16 17:24:57: pid 998: LOG: fork a new child process with pid: 1033
2016-03-16 17:24:57: pid 998: DEBUG: reaper handler: exiting normally
2016-03-16 17:24:57: pid 1033: DEBUG: initializing backend status
2016-03-16 17:25:02: pid 1031: DEBUG: PCP child receives shutdown request signal 2
2016-03-16 17:25:02: pid 1029: LOG: child process received shutdown request signal 2
...
私のサンプル アプリケーションは、マスターがシャットダウンされたときに実際に終了したことに注意してください。
編集 3: を適切に設定した後、新しいログにsr_check_periodエラーsr_check_userが表示されsr_check_passwordます。以前のエラーはすべてなくなりました。
2016-03-31 17:45:00: pid 18363: DEBUG: detect error: kind: 1
2016-03-31 17:45:00: pid 18363: DEBUG: reading backend data packet kind
2016-03-31 17:45:00: pid 18363: DETAIL: backend:0 of 2 kind = '1'
...
2016-03-31 17:45:00: pid 18363: DEBUG: detect error: kind: S