Репликация Postgres, балансировка + failover PGPOOL2

@ILILIAI · Регистрация: 09.09.2015

Студворк — интернет-сервис помощи студентам

Помогите разобраться пожалуйста. Хочу попробовать настроить схему: 2 сервера postgres (master и slave). Нужна асинхронная репликация между ними. Версия Postgres 9.3. На мастере и на слейве выставляю настройки в конфиге. (считаю что параметр hot_standby на мастере можно не комментировать, тк в оф. документации сказано, что он игнорируется им):

Bash
1
2
3
4
5
6
7
8
listen_addresses = '*'
port = 5432
wal_level = hot_standby
archive_mode = on #на мастере
archive_command = 'cd .' #на мастере
wal_keep_segments = 64
max_wal_senders = 8
hot_standby = on

Репликация работает. Все изменения происходящие в мастере появляются на слейве. Слейв доступен только на чтение.
Далее устанавливаю pgpool. Вот в его работе и возникают вопросы.
Конфиг pgpool:

Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
listen_addresses = '*'
backend_hostname0 = 'ip mastera'                
backend_port0 = 5432                
backend_weight0 = 1                   
backend_data_directory0 = '/var/lib/postgresql/9.3/main'                     
backend_flag0 = 'ALLOW_TO_FAILOVER'
 
backend_hostname1 = 'ip slave'
backend_port1 = 5433
backend_weight1 = 1
backend_data_directory1 = '/var/lib/postgresql/9.3/main'
backend_flag1 = 'ALLOW_TO_FAILOVER'
 
enable_pool_hba = on
pool_passwd = 'pool_passwd'
pid_file_name = '/var/run/postgresql/pgpool.pid'
logdir = '/var/log/postgresql'
replication_mode = off
load_balance_mode = on
health_check_period = 5
health_check_timeout = 0
health_check_user = 'postgres'
master_slave_mode = true 
master_slave_sub_mode = 'stream'  
failover_command = '/etc/pgpool-II/failover.sh %d %H /var/lib/pgsql/data/failover'

Скрипт failover:

Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#! /bin/bash 
# ID упавшего узла
 FAILED_NODE=$1
 # IP нового мастера
 NEW_MASTER=$2
 # Путь к триггерному файлу 
TRIGGER_FILE=$3
 if [ $FAILED_NODE = 1 ]; 
    then echo "Ведомый сервер вышел из строя"
 exit 1 
fi 
        echo "Ведущий сервер вышел из строя" 
     echo "Новый ведущий сервер:
     $NEW_MASTER" ssh -T postgres@$NEW_MASTER touch $TRIGGER_FILE 
exit 0

После настройки pgpool работает, но есть моменты, мне не понятные.
1) Как происходит балансировка нагрузки? а именно если пользователь вставил данные в таблицу t1, потом запросил выборку из нее, если запрос на выборку pgpool отдаст слейву, а данные в него еще не успели прийти, получится пользователь получит не корректные данные? или в pgpool это предусмотрено?
2) В случае падения мастера слейв берет на себя возможность записи, обновления и удаления. Мастер я восстанавливаю в ручную, поднимаю postgres, говорю pgpool что мастер снова работает, после чего переименовываю файл recovery.done обратно на recovery.conf. Может возникнуть ситуация, что пока я запускаю его, пользователь начнет что то писать и у мастера со слейвом случится рассинхронизация? читала про pg_rewind, но его нет в 9.3. Можно ли как то иначе догнать слейву мастера. (или так же может случится пока поднимаю мастер - что в слейв кто-то что-то запишет) Или я неправильно понимаю принцип работы pgpool?
3) если я захочу что бы упавший мастер становился просто слейвом, а не обратно мастером. Верно ли я понимаю что функция failovera сработает только один раз, тк там есть условие $FAILED_NODE = 1, можно ли исправить ее, добавив например во входной параметр %М и проверять относительно его? пока не получилось, может кто то делал такое?
4) если я упавший мастер восстанавливаю как слейв (на нем доступно только чтение), то на узле масштабирования в списке нод по запросу psql: show pool_nodes; пишет status: primary. А тот узел что стал мастером в статусе standby. Хотя он доступен и на запись и удаление. Почему так происходит, правильно ли это? Считаю что не должно так быть (опять же потому что это слев и при его падении pgpool будет считать его мастером)
Друзья, помогите пожалуйста, может я вообще неправильно поняла что-то. Наставьте на путь истинный.

@grgdvo · 28.01.2017, 16:17

Бросилось в глаза.
Вы пишите

Сообщение от ILILIAI

Нужна асинхронная репликация между ними.

Само слово асинхронная как бы предполагает, что будет временной интервал (неизвестной величины) между комитом на мастере и репликацией данных на слейвы. И даже в документации по 9.3 это пишут.

asynchronous solutions allow some delay between the time of a commit and its propagation to the other servers, opening the possibility that some transactions might be lost in the switch to a backup server, and that load balanced servers might return slightly stale results.

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

1) По первому вопросу я думаю, что pgpool это предусматривает. Может быть потребуется поиграться параметром delay_threshold.
Смотрит ответ в документации в разделе 5.7.2.
2) Почему вы в ручную делаете?? если я правильно понял, pgpool должен участвовать в этом процессе. иначе случится то, что вы пишите в вопросе 4.
3) потоковая репликация предполагает, что либо слейв делаем мастером "навсегда" и к нему присабачиваем новый слейв, либо же через какое-то время восстанавливаем старый мастер. В первом случае, насколько я понял, потребуется переконфигурация pgpool, во втором случае достаточно failover_command и fallback_command, которые отключают и подключают старый мастер.

@ILILIAI · 30.01.2017, 09:12 **[ТС]**

Я думаю что мне нужна именно асинхронная потоковая репликация. Асинхронная в моем понятии означает, что условно транзакция не будет дожидаться пока слейв запишет данные, появившиеся на мастере. Пока слейв не догонит мастера (например могу делать basebaskup) он не запускается. Но в мастер будет постоянно происходить запись и пока я буду поднимать слейв случится опять рассинхронизация и Postgres на слейве не запустится. Поднимать ноды в ручную считаю более правильным и заключается в том, что бы сделать бейсбэкап с работающего мастера, создать recovery.conf и запустить ноду как слейв (Но при этом возникают вопросы 2,3,4) Или второй известный вариант настроить online-recovery в pgpool-е, но все равно восстанавливать ручками хотя бы потому, что команду на восстановление придется все же давать руками. Или я неправильно понимаю процесс восстановления ноды. Если есть хорошие статьи по этому поводу, прошу, дайте ссылку. Я что я поняла, так это - что мастер нереально восстановить в качестве мастера без остановки всей системы. А вот при восстановлении слева хорош pg_rewind, но его нет в 9.3

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .
И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .

@ILILIAI 0 / 0 / 0 Регистрация: 09.09.2015 Сообщений: 15
	30.01.2017, 09:12 [ТС]
	Я думаю что мне нужна именно асинхронная потоковая репликация. Асинхронная в моем понятии означает, что условно транзакция не будет дожидаться пока слейв запишет данные, появившиеся на мастере. Пока слейв не догонит мастера (например могу делать basebaskup) он не запускается. Но в мастер будет постоянно происходить запись и пока я буду поднимать слейв случится опять рассинхронизация и Postgres на слейве не запустится. Поднимать ноды в ручную считаю более правильным и заключается в том, что бы сделать бейсбэкап с работающего мастера, создать recovery.conf и запустить ноду как слейв (Но при этом возникают вопросы 2,3,4) Или второй известный вариант настроить online-recovery в pgpool-е, но все равно восстанавливать ручками хотя бы потому, что команду на восстановление придется все же давать руками. Или я неправильно понимаю процесс восстановления ноды. Если есть хорошие статьи по этому поводу, прошу, дайте ссылку. Я что я поняла, так это - что мастер нереально восстановить в качестве мастера без остановки всей системы. А вот при восстановлении слева хорош pg_rewind, но его нет в 9.3 0