Pgpool выполняет запросы на резервных узлах вместо главного, когда репликация находится в режиме ожидания - PullRequest
Новая
       12

Pgpool выполняет запросы на резервных узлах вместо главного, когда репликация находится в режиме ожидания

0 голосов
/ 30 октября 2018

У меня есть master db postgresql 10 с двумя серверами горячего резервирования с потоковой репликацией, и репликация работает правильно. synchronous_commit установлен на remote_write

Также у меня есть pgpool 3.7.5, настроенный с параметрами: 

delay_threshold = 1
sr_check_period = 1

И следующие веса:

  • мастер: 1
  • узел1: 3
  • узел2: 3

В журнале я вижу, что node1 и node2 отстают: 

Replication of node:1 is behind 75016 bytes from the primary server (node:0)

Документы pgpool говорят:

delay_threshold (integer)

Задает максимальный уровень допуска задержки репликации в байтах WAL на резервном сервере по отношению к основному серверу. Если задержка превышает этот сконфигурированный уровень, Pgpool-II прекращает отправку запросов SELECT на резервный сервер и начинает маршрутизацию всего на основной сервер, даже если включена load_balance_mode, пока резервный сервер не догонит основной. Установка этого параметра в 0 отключает проверку задержки. Эта проверка порогового значения задержки выполняется каждый sr_check_period. По умолчанию 0.

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

Я временно включил log_per_node_statement = on, чтобы видеть, какой узел выполняет запрос, и я вижу, что запросы отправляются узлам, даже если нет синхронизации, когда delay_threshold этого следует избегать.

Я что-то упустил? Когда узлы находятся за мастером, запросы не должны идти мастером?

Заранее спасибо.

Другие значения конфигурации pgpool: 

num_init_children = 120
max_pool = 3
connection_cache = off
load_balance_mode = on
master_slave_sub_mode = 'stream'
replication_mode = off
sr_check_period = 1

1 Ответ

0 голосов
/ 31 октября 2018

во-первых, я думаю, что вы должны проверить результат "show pool_nodes" и проверить, правильно ли установлены три узла с правильной ролью (основной, резервный, резервный).

секунду, вы установили "app_name_redirect_preference_list" или "database_redirect_preference_list"? Если это так, это может повлиять на выбор узла для запроса SELECT.

И по моему мнению, delay_threshold = 1 является строгим, единица измерения - байтами, и в моем случае я использую "10000000" для PROD. почему бы вам просто не написать комментарий "/ NO LOAD BALANCE /", чтобы отправить конкретные запросы только мастеру?

И я просто рекомендую вам обновить версию pgpool до 4.0.0 (выпущена 2018-10-19). 3.7.x имеет загадочную ошибку при балансировке нагрузки.

Я также столкнулся с подобной проблемой, что балансировка нагрузки не работает должным образом с версией (3.7.5), даже когда у нашей конфигурации нет проблем. Случайно pgpool. Мы даже связались с командой разработчиков pgpool, чтобы решить эту проблему, но они не смогли найти причину. Вы можете проверить детали в ссылке ниже.

https://www.pgpool.net/mantisbt/view.php?id=435.

И это было решено как очарование путем обновления до версии 4.0.0.

...