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

Question

Это часть кластера , я строю. Когда я выполняю pcp_recovery_node на главном компьютере, чтобы создать резервный режим с нуля с помощью команды

pcp_recovery_node -h 193.185.83.119 -p 9898 -U postgres -n 1

Здесь 193.185.83.119 - это vip. Он успешно создает и запускает режим ожидания на узле-b (скажем, узлы-это-ноды-а и н-б), но в то же время вышеприведенная команда не возвращает и просто зависает в оболочке, как:

[postgres @ rollc-filesrvr1 data] $ pcp_recovery_node -h 193.185.83.119 -p 9898 -U postgres -n 1 Пароль:

Мне нужно использовать ctrl + c, чтобы выйти из этого сеанса. Позже, когда я пытаюсь создать тестовую базу данных на узле a (master), я получаю следующую ошибку:

      postgres=# create database test;
        ERROR:  source database "template1" is being accessed by other users
        DETAIL:  There is 1 other session using the database.

Я подтверждаю, что pgpool.service работает во время выполнения этой команды на узле a, и я попытался использовать pgpool.service вкл / выкл на узле b (в режиме ожидания) перед выполнением команды pcp. Результат остается прежним.

Также я попробовал поискать в Google и настроить следующие параметры в pgpool.conf. Я не уверен, что это может быть что-то с этими параметрами:

wd_lifecheck_dbname в pgpool.conf

Первоначально относящиеся к нему настройки были (и я получал тот же результат):

wd_lifecheck_dbname = 'template1'
wd_lifecheck_user = 'nobody'
wd_lifecheck_password = ''

позже я нашел другие настройки в здесь , здесь и одно предложение в здесь и попробовал различные комбинации, такие как:

wd_lifecheck_dbname = 'template1'
wd_lifecheck_user = 'postgres'
wd_lifecheck_password = ''

или

wd_lifecheck_dbname = 'postgres'
wd_lifecheck_user = 'postgres'
wd_lifecheck_password = ''

Но никто не помог изменить ситуацию ни на оболочке, ни позволил мне создать тестовую базу данных на master. Я чувствую, я зашел в тупик.

Я до сих пор не могу полностью понять назначение и значение вышеприведенных 3-х параметров в pgpool и почему-то подозреваю, что это те, которые я не правильно конфигурирую, хотя могут быть и другие причины.

просто чтобы помочь, вот еще раз подробности об окружающей среде.

• среда узлов-a и nod-b: rhel 7,6
• postgres версия: 10.7
• pgpool- || версия: 4.0.3
• слот для репликации + архив w

Вот журналы с узла-pgpool.service

Mar 18 21:10:17 node-a pgpool[16583]: 2019-03-18 21:10:17: pid 16642: LOG:  forked new pcp worker, pid=8534 socket=7
Mar 18 21:10:17 node-a pgpool[16583]: 2019-03-18 21:10:17: pid 8534: LOG:  starting recovering node 1
Mar 18 21:10:17 node-a pgpool[16583]: 2019-03-18 21:10:17: pid 8534: LOG:  executing recovery
Mar 18 21:10:17 node-a pgpool[16583]: 2019-03-18 21:10:17: pid 8534: DETAIL:  starting recovery command: "SELECT pgpool_recovery('recovery_1st_stage', 'node-a-ip', '/data/test/data', '5438', 1)"
Mar 18 21:10:17 node-a pgpool[16583]: 2019-03-18 21:10:17: pid 8534: LOG:  executing recovery
Mar 18 21:10:17 node-a pgpool[16583]: 2019-03-18 21:10:17: pid 8534: DETAIL:  disabling statement_timeout
Mar 18 21:10:18 node-a pgpool[16583]: 2019-03-18 21:10:18: pid 8534: LOG:  node recovery, 1st stage is done
Mar 18 21:11:37 node-a pgpool[16583]: 2019-03-18 21:11:37: pid 8534: LOG:  checking if postmaster is started
Mar 18 21:11:37 node-a pgpool[16583]: 2019-03-18 21:11:37: pid 8534: DETAIL:  trying to connect to postmaster on hostname:node-b-ip database:postgres user:postgres (retry 0 times)
...
...2 more times 
Mar 18 21:11:49 node-a pgpool[16583]: 2019-03-18 21:11:49: pid 8534: LOG:  checking if postmaster is started
Mar 18 21:11:49 node-a pgpool[16583]: 2019-03-18 21:11:49: pid 8534: DETAIL:  trying to connect to postmaster on hostname:node-a-ip database:template1 user:postgres (retry 0 times)
...it keeps on trying till i press ctrl+c on pcp command windows . I have seen it going upto 30 or more.

Также узел-b никогда не отображается как вверх при проверке с помощью pgpool.

postgres => show pool_nodes; идентификатор_узла | имя хоста | порт | статус | lb_weight | роль | select_cnt | load_balance_node | replication_delay | last_status_change --------- + ---------------- + ------ + -------- + ------- ---- + --------- + ------------ + ------------------- + - ----------------- + --------------------- 0 | узел-IP-адрес | 5438 | вверх | 0.500000 | первичный | 0 | правда | 0 | 2019-03-18 22:59:19 1 | узел-б-IP | 5438 | вниз | 0.500000 | в режиме ожидания | 0 | ложь | 0 | 2019-03-18 22:59:19 (2 ряда)

РЕДАКТИРОВАТЬ Теперь я, по крайней мере, могу исправить последнюю часть этого запроса. то есть добавление резервного узла в кластер:

[postgres @ имя-узла-хоста] $ pcp_attach_node -n 1 Пароль: pcp_attach_node - Команда выполнена успешно

и теперь последняя часть как минимум показывает правильную ситуацию:

postgres => show pool_nodes; идентификатор_узла | имя хоста | порт | статус | lb_weight | роль | select_cnt | load_balance_node | replication_delay | last_status_change --------- + ---------------- + ------ + -------- + ------- ---- + --------- + ------------ + ------------------- + - ----------------- + --------------------- 0 | узел-IP-адрес | 5438 | вверх | 0.500000 | первичный | 0 | ложь | 0 | 2019-03-18 22:59:19 1 | узел-б-IP | 5438 | вверх | 0.500000 | в режиме ожидания | 0 | правда | 0 | 2019-03-19 11:38:38 (2 ряда)

Но основная проблема, связанная с неспособностью создать базу данных на узле 1, все еще существует:

EDIT2: Я попытался вставить и обновить на главном компьютере, и они правильно реплицируются на узел 2, но создание базы данных по-прежнему не работает.

Answer 1

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

pcp_watchdog_info -h 193.185.83.119 -p 9898 -U postgres

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

pcp_attach_node -n 1

вообще не требовался для добавления режима ожидания или исправления вывода show pool_nodes; на мастере IF оригинальный 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.