pgpool 4.1.0 healthcheck getsockopt () обнаружила ошибку В соединении отказано

Я пытаюсь настроить балансировщик нагрузки pgpool для кластера потоковой репликации Postgresql.

Я использую postgresql-12 и pgpool2-4.1.0 из репозитория Postgresql https://apt.postgresql.org/pub/repos/apt/ в Debian 10.2 (последняя стабильная версия).

Я настроил кластер Postgresql с потоковой репликацией с использованием физических слотов (не доставки WAL), и все, похоже, работает правильно. Вторичные реплики подключают реплицируемые данные без каких-либо проблем.

Затем я установил pgpool2-4.1.0 на те же сервера. Я внес соответствующие изменения в pgpool.conf в соответствии с wiki pgpool и включил сторожевой таймер.

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

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

Проблема появляется в журналах pgpool, из системного журнала я получаю:

Jan 13 15:10:30 debian10 pgpool[9826]: 2020-01-13 15:10:30: pid 9870: LOG:  failed to connect to PostgreSQL server on "pg1:5433", getsockopt() detected error "Connection refused"

Jan 13 15:10:30 debian10 pgpool[9826]: 2020-01-13 15:10:30: pid 9870: LOCATION:  pool_connection_pool.c:680

При проверке упомянутого выше PID я получаю процесс проверки работоспособности pgpool. I pg1, pg2, pg3 - это серверы баз данных, которые прослушивают все адреса на порте 5433, pg1 - первичный. pgpool слушает 5432.

Пользователь базы данных, который используется для проверки работоспособности, - «pgpool», я подтвердил, что могу подключиться к базе данных с помощью этого пользователя со всех хостов в конкретной подсети.

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


postgresql high-availability pgpool
person R.Giskard Reventlov    schedule 13.01.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Оказывается, это было разрешение имен в файле / etc / hosts и postgresql.conf.

В частности, файл / etc / hosts был таким:

vagrant@pg1:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 pg1
....
10.10.20.11 pg1
....

И postgresql.conf вот так:

....
listen_addresses = 'localhost,10.10.20.11' # what IP address(es) to listen on;
....

Поэтому, когда проверка работоспособности пыталась достичь локального узла на каждой машине, она проверяла через имя хоста (pg1, pg2 и т. Д.). В приведенном выше файле hosts, который приводит к 127.0.1.1, который postgresql не прослушивает, поэтому он не удастся, следовательно, возникнет ошибка, а затем попробуйте с 10.10.20.11, что будет успешным. Это также объясняет, почему при проверках работоспособности удаленных хостов не было ошибок.

Я изменил файл hosts на следующий:

vagrant@pg1:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 pg1-local
....
10.10.20.11 pg1
....

И логи понятны.

Это специфично для Debian, так как дистрибутивы на основе Red Hat не имеют

127.0.1.1 hostname

запись в их / etc / hosts

person R.Giskard Reventlov    schedule 21.01.2020