Postgres Pro Shardman реализует простую клиент-серверную модель по схеме «процесс для пользователя». В такой схеме один клиентский процесс подключается к одному отдельному серверному процессу. Так как мы не знаем заранее, сколько подключений будет, нам нужен «главный процесс», который будет запускать новый процесс при каждом запросе подключения. Главный процесс называется postmaster и принимает входящие подключения в заданном порту TCP/IP. Получив запрос на подключение, процесс postgres порождает новый серверный процесс. Серверные задачи взаимодействуют между собой и другими процессами экземпляра СУБД через семафоры и разделяемую память, чтобы обеспечить целостность данных при одновременном обращении к ним.

В отличие от монолитных систем, в распределённом кластере требуется единообразие и видимость во всех экземплярах СУБД, у каждого из которых свои сеансы и подключения. Основная задача при таком сценарии — это обеспечить работу распределённых транзакций от лица разных пользователей (единая точка подключения для клиентский соединений). Это достигается с помощью режима работы postgres_fdw, при котором авторизация на сторонних серверах происходит от лица операционного пользователя, для которого на всех узлах кластера настроен SSL-сертификат. В момент прохождения SQL-запроса от лица конкретного пользователя соединение устанавливается от лица такого операционного пользователя. Однако как только сеанс начинается, ИД пользователя меняется на ИД того пользователя, который инициировал запрос на координаторе, с сохранением всех прав.

В то же время доверенные пользователи могут авторизоваться по SSL-сертификату (через авторизацию libpq), который генерируются для каждого сервера или кластера.

За подробной информацией обратитесь к схеме:

В Postgres Pro Shardman также есть альтернативное приложение для транспорта – Silk.

Обратите внимание, что клиентским процессом может быть любая программа, которая понимает протокол Postgres Pro Shardman, описанный в Главе 56. Многие клиенты базируются на библиотеке libpq для языка C, но есть и другие независимые реализации этого протокола, например, драйвер JDBC для Java.

Установив подключение, клиентский процесс может передать запрос серверу. Запрос передаётся в обычном текстовом виде, клиент не занимается его анализом. Сервер разбирает запрос, строит план выполнения, выполняет его и возвращает полученные строки клиенту, передавая их через установленное подключение.