Команда pcp_recovery_node зависает при восстановлении режима ожидания

Первое исправление в EDIT1: действительно, pcp_attach_node помог исправить ошибку вывода show pool_nodes, но еще больше усложнил проблему, как и другие команды

pcp_watchdog_info -h 193.185.83.119 -p 9898 -U postgres [113 ]

начал застрять. Позже я обнаружил, что

pcp_attach_node -n 1

вообще не требовалось для добавления режима ожидания или исправления вывода show pool_nodes; на мастере ЕСЛИ оригинальный pcp_recovery_node завершается правильно.

Ну, коренная причина оригинальной проблемы, и сторожевой таймер возник из-за этого позже, было то, что сценарий pgpool_remote_start не завершался правильно даже после запуска режима ожидания. Я мог видеть это в

ps -ef | grep pgpool

на мастере.

Я связался с системой pgpool_bug_tracking по адресу здесь , и они помогли мне исправить ее. Это была неправильная команда запуска postgres в pgpool_remote_start, которая вызывала проблемы, и, следовательно, pcp_recover_node не завершалась, и никакая другая позже.

Правильная команда в pgpool_remote_start должна выглядеть примерно так (и я ее использовал):

ssh -T postgres@$REMOTE_HOST /usr/pgsql-10/bin/pg_ctl -w start -D /data/test/data 2>/dev/null 1>/dev/null </dev/null &

, когда я использовал

ssh -T postgres @ $ REMOTE_HOST / usr / pgsql-10 / bin / pg_ctl start -D / data / test / data

Я пропустил флаг -w. Также не было перенаправления stdout и stderr на / dev / null и отсутствовала передача сигнала EOF на него.

Мне все еще непонятно, но полезно кому-то, сталкивающемуся с подобной проблемой: сначала запустите pgpool.service в режиме ожидания или оставьте его запущенным, прежде чем вводить команду pcp на master.