Автоматическое восстановление сбойного главного узла postgresql не работает с pgpool II

Question

Я новичок в настройках Postgresql и Pgpool II. Я настроил Postgresql HA/ Балансировка нагрузки, используя Pgpool и Repmgr.

The setup consist of 3 nodes and verison of Application and OS is as mentioned below:  
**Pgpool node** => 192.168.0.4, **Postgresql Nodes** => 192.168.0.6, 192.168.0.7   
**OS version** => CentOS 6.8 (On all the 3 nodes)  
**Pgpool II version** =>  pgpool-II version 3.5.0 (ekieboshi).  
**Postgresql Version** => PostgreSQL 9.4.8  
**Repmgr Version** => repmgr 3.1.3 (PostgreSQL 9.4.8)  

Я перешел по ссылке, чтобы выполнить настройку.

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

Я хочу автоматизировать процесс восстановления.

Файл pgpool.conf на узле pgpool содержит параметр recovery_1st_stage_command. Я искал источники в Интернете и обнаружил, что параметр "recovery_1st_stage_command" должен быть установлен в файле конфигурации pgpool.conf на узле Pgpool.

Я установил параметр recovery_1st_stage_command = 'basebackup.sh'. Я поместил файл сценария basebackup.sh на оба узла Postgresql в каталоге данных /var/lib/pgsql/9.4/data.

Также я разместил скрипт pgpool_remote_start на обоих узлах базы данных в каталоге /var/lib/pgsql/9.4/data.

Также созданы расширения pgpool pgpool_recovery и pgpool_adm на обоих узлах базы данных.

Когда главный узел остановлен, происходит аварийное переключение, но сценарий восстановления basebackup.sh не выполняется.
Я проверил журналы pgpool и включил уровень отладки. Все еще не могу найти, был ли выполнен скрипт или нет.

Пожалуйста, помогите мне с автоматическим онлайн восстановлением неисправного узла. Найдите сценарии, используемые мной.

basebackup.sh

#!/bin/bash
# first stage recovery
# $1 datadir
# $2 desthost
# $3 destdir

#as I'm using repmgr it's not necessary for me to know datadir(master) $1
RECOVERY_NODE=$2
CLUSTER_PATH=$3
#repmgr needs to know the master's ip
MASTERNODE=`/sbin/ifconfig eth0 | grep inet | awk '{print $2}' | sed 's/addr://'`

cmd1=`ssh postgres@$RECOVERY_NODE "repmgr -D $CLUSTER_PATH --force standby clone $MASTERNODE"`
echo $cmd1

Скрипт pgpool_remote_start.

#! /bin/sh

if [ $# -ne 2 ]
then
    echo "pgpool_remote_start remote_host remote_datadir"
    exit 1
fi

DEST=$1
DESTDIR=$2
PGCTL=/usr/pgsql-9.4/bin/pg_ctl

ssh -T $DEST $PGCTL -w -D $DESTDIR start 2>/dev/null 1>/dev/null < /dev/null &

Благодарю.

Answer 1

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

Если вы действительно этого хотите, то вы можете изменить сценарий отработки отказа таким образом, чтобы он выполнял операцию pcp_recovery на старом главном компьютере после продвижения ведомого. Но тогда то, что вы на самом деле делаете, это переключение... это должно быть записано в виде последовательности шагов. Аварийное переключение для случая, когда есть реальная проблема с мастером (например, машина не отвечает)