Как jackc/pgx работает с несколькими хостами
У меня есть кластер PostreSQL, в котором есть главный и подчиненный серверы. Я видел, что pgx/pgxpool поддерживает одновременное подключение к нескольким хостам, но не понимаю, как тогда будут выполняться запросы. Может ли pgx понять, где находится мастер? (Я не нашел, чтобы он мог это сделать.) И будет ли pgx вообще работать, если у меня есть мастер и слейв, а на слейве могут выполняться только запросы только на чтение.
Помогите пожалуйста разобраться в проблеме
У меня была мысль, что запросы будут разбросаны по кругу, но подтверждения я не нашел. И я не знаю, что будет, если запрос на запись попадет на слейв.
Я примерно понимаю, как можно написать обертку вокруг пула, чтобы он поддерживал такую архитектуру, но не понимаю, нужно это или нет.
@eik, Верно, я ошибся, спасибо
Ответы 1
относительно нескольких хостов: pgx переопределяет те же правила для атрибутов строки подключения, что и реализация postgresql.
В документе PostgreSQL упоминается циклический перебор до тех пор, пока одно соединение не будет соответствовать критериям (соединение установлено и target_session_attrs не будет сопоставлено).
ссылка на документ postgres:
Можно указать несколько хостов для подключения, чтобы они проверялись в заданном порядке.
- target_session_attrs (для подключения к мастеру вы, вероятно, захотите установить
target_session_attrs=primaryилиtarget_session_attrs=read-write)
Этот параметр определяет, должен ли сеанс иметь определенные свойства, чтобы быть приемлемым. Обычно он используется в сочетании с несколькими именами хостов для выбора первой приемлемой альтернативы среди нескольких хостов.
Что касается pgx дела:
Документ pgx.ParseConfig приведет вас (2 ссылки) к pgconn.ParseConfig
В документации явно упоминается поддержка нескольких хостов, поддержка target_session_attrs менее очевидна — это подразумевается из того факта, что PGTARGETSESSIONATTRS поддерживается, и из ссылки на атрибуты строки подключения — но она поддерживается.
В коде pgx проверка target_session_attrs при соединении проходит через одну из функций ValidateConnectTargetSessionAttrs*
Спасибо за ответ! У меня еще есть еще один вопрос. Если я установлю target_session_attrs для своих хостов PostgreSQL и во время работы программы произойдет сбой ведущего устройства, и ведомое устройство станет главным. Будет ли это автоматически обрабатываться драйвером или мне следует реализовать это самостоятельно?
Как только подчиненное устройство станет ведущим: да, любое действие pgx, начинающееся с «открыть новое соединение», будет работать. pgxpool, например, автоматически закроет неработающие соединения и откроет новые.
Для иллюстрации: у нас есть код, который прослушивает события postgresql. Для этой цели мы открываем соединение, которое обрабатывается вне пула и которое будет оставаться открытым в течение длительного периода времени. Для этого конкретного соединения мы сами обрабатываем цикл повторного подключения и повторной попытки в случае ошибки. Однако строка подключения статична и содержит сообщение host=server1,server2 target_session_attrs=primary
Получается, как только раб становится господином. pgxpool воссоздаст пулы, и пул, который раньше был доступен только для чтения, станет доступным для чтения и записи?
Существует pgx/pgxpool, который обрабатывает пул подключений к одному и тому же хосту. Откуда вы взяли информацию о «pgx/pgxpoll»?