#postgresql #pg-dump #pgbouncer
#postgresql #pg-dump #pgbouncer
Вопрос:
Моя сеть выглядит так:
App (many connections) pg_bouncer (few sessions) PostgreSql
nodes ----------------------- nodes ----------------- nodes
Таким образом, pg_bouncer мультиплексирует соединения, создавая у узлов приложения иллюзию, что все они подключены напрямую.
Проблема возникает, когда я запускаю pg_dump: через несколько миллисекунд после завершения дампа все узлы приложения завершаются ошибкой с сообщением «отношение xxxx не существует», хотя таблица или последовательность на самом деле есть. Я почти уверен, что причина в том, что pg_bouncer манипулирует переменной «search_path», так что узлы приложения больше не находят таблицы в моей схеме. Это происходит во время дампа, даже если файл дампа не импортирован и не выполнен.
Обратите внимание, я искал SO и Google, и я видел, что есть много потоков, спрашивающих о search_path в сгенерированном файле, но это не то, о чем я спрашиваю. У меня нет проблем с сгенерированным файлом, моя проблема заключается в сеансе pg_bouncer, который используют другие клиенты, и я ничего об этом не нашел.
Наиболее очевидным обходным путем, вероятно, было бы установить путь поиска вручную в приложении, но внимание, не впадайте в эту ошибку: приложению бесполезно делать это в начале, поскольку ему может быть назначен другой сеанс pg_bouncer при следующей транзакции. И я не могу устанавливать его постоянно.
Следующим наиболее очевидным обходным путем было бы вернуть ему заданное значение сразу после запуска pg_dump, но здесь есть условие гонки, и другие узлы работают достаточно быстро, так что я боюсь, что они все равно потерпят неудачу.
Есть ли способ не позволить pg_dump манипулировать этой переменной или убедиться, что она сбрасывает ее перед выходом?
(Кроме того, я считаю само собой разумеющимся, что причиной этого являются pg_dump и search_path, можете ли вы предложить способ подтвердить это? Все доказательства, которые у меня есть, — это ошибки через несколько миллисекунд и инструкция set search_path в сгенерированном файле, которая при выполнении выдает те же ошибки.)
Спасибо
Комментарии:
1. Вы используете объединение сеансов или транзакций?
2. @LaurenzAlbe объединение транзакций
Ответ №1:
Не подключайте pg_dump через pgbouncer с объединением транзакций. Просто измените номер порта, чтобы он подключался непосредственно к базе данных. pg_dump несовместим с объединением транзакций.
Возможно, вы сможете заставить его работать в любом случае, установив server_reset_query_always = 1
Комментарии:
1. Не уверен, что системные администраторы позволят мне подключиться напрямую. Есть ли какой-либо официальный документ, в котором говорится, что он несовместим? Возможно, было бы полезно обосновать мой запрос. Тем временем я взглянул на server_reset_query_always и server_reset_query, выглядит полезным, я надеюсь, что они согласятся добавить это. Спасибо!
2. Проблема в том, что при объединении транзакций параметры не сбрасываются.
3. Если прямое подключение невозможно, просто добавьте новый пул (1 размер) и подключитесь с его помощью.