pgpool 4.1.0 healthcheck getsockopt () обнаружил ошибку «Соединение отказано» - PullRequest
Новая
       63

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

0 голосов
/ 13 января 2020

Я пытаюсь настроить балансировщик нагрузки 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 в соответствии с вики 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", я подтвердил, что могу подключиться к базе данных, используя этого пользователя, со всех хостов на конкретном su bnet.

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

1 Ответ

0 голосов
/ 21 января 2020

Оказывается, это было разрешение имен в файле / 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;
....

Поэтому, когда healthcheck пытался достичь локального узла на каждой машине, он проверял бы через имя хоста (pg1, pg2, et c). С приведенным выше файлом 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 c, поскольку в дистрибутивах Red Hat нет записи 

127.0.1.1 hostname

в их / etc / hosts

...