2016-09-07 2 views
0

Я новичок в настройках Postgresql и Pgpool II. Я настроил баланс Postgresql HA/Load, используя Pgpool и Repmgr.Автоматическое восстановление поврежденного мастер-узла postgresql не работает с pgpool II

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) 

я следовал link сделать установку.

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

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

pgpool.conf файл на узле PGPool содержит параметр recovery_1st_stage_command. Я искал источники в Интернете и обнаружил, что параметр Parameter «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 [email protected]$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 &

Спасибо.

+0

Я обнаружил, что после восстановления после отказа резервный узел успешно продвигается как новый мастер-сервер. И теперь я должен запустить команду ** pcp_recovery_node ** вручную на узле ** Pgpool **. Эта команда выполняет скрипт ** basebackup.sh ** на новом главном сервере и успешно восстанавливает удаленный узел и присоединяет узел к кластеру. ** Я хочу автоматизировать эту команду pcp_recovery_node execuiton **. – yravi104

ответ

0

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

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

Смежные вопросы