pool size = сколько коннектов базы может использовать баунсер для комбинации имя_пользователя + имя_бд.
Может быть равен количеству бекенд серверов разве что по случайному совпадению.
при pool mode=transaction коннект базы предоставляется подключённому к баунсеру клиенту на время этой транзакции (запрос вне транзакции так же есть транзакция). Пришло условно одновременно 30 запросов от разных клиентов - при pool size 20, 20 клиентов получили по коннекту с базой и начали выполняться, остальные начинают ждать пока освободится коннект базы. После завершения транзакции освободившийся коннект передаётся следующему желающему что-то сделать с базой.
Один процесс базы не может выполнять одновременно два запроса, а значит получаем, что если запрос выполняется за 10мс, то при pool size 10 будет теоретический предел пропускной способности 1000rps.
При том, что очень важно, это не значит что на всего 8-ядерном CPU при pool size 20 будет возможно удвоить результат. Результат может стать даже хуже, потому что конкурентные процессы будут драться между собой за CPU и активно мешать друг другу работать.
Размер пула подбирается по действительной ситуации и по мониторингу.
contrib - это не про контрибьюторов, это contrib, набор всяких расширений в репозитории postgresql. Теоретически их можно не ставить, но фактически нужны буквально на каждой продовой базе, потому что именно там расположен pg_stat_statements. Даже если приложению не требуются какие-нибудь pgcrypto/ltree/pg_trgm или ещё чего полезное.
лет 5 назад в deb репу даже прекратили собирать contrib в отдельный пакет, а перенесли в пакет сервера базы. Dervim пока что продолжает собирать отдельно для rpm.
смотря на сколько корректно атомарный снэпшот при этом получается (и не выключали ли fsync, как 1с-ники обожают себе отстреливать ноги). В идеальном случае получается crash recovery, аналогичный сбою по питанию. С точки зрения СУБД ситуация ожидаемая, но тестировать бекап на возможность восстановиться из него всё равно нужно будет.
Снимать файловый бекап при запущенной базе можно. Это делают все серьёзные утилиты бекапа postgresql: pgbackrest, wal-g, barman и прочие. Но для этого нужно соблюдать правила, которые требует сама база. К внимательному прочтению. Вот если у базы не попросить потребные данные для файлового бекапа - то это к приключениям и бекап выполнен неверно.
Только в случае постгреса эти файлы не переносимы, развернуть их на другом сервере не выйдет.
Ограниченно переносимы.
Развернуть на подходящем сервере выйдет. Это просто частный случай настройки потоковой репликации. Копируется именно физический PGDATA, а не логический дамп.
Основные ограничения: совпадение критичных для бинарной совместимости флагов компиляции. Сюрприз, даже другая аппаратная архитектура может не быть препятствием. Мы однажды с amd64 на arm64 перевозили базу физической репликацией даже.
я бы предложил сперва в MPTCP потыкаться, чем с агрегированием туннелей. Всё равно нужен гейт в обычную сеть, но по крайней мере MPTCP проектировался под такое использование.
В интерфейсе админа домена должен быть включен IMAP.
У каждого имени пользователя должен быть включен IMAP в своих настройках.
Пароль для IMAP - не пароль учётки в яндексе, а отдельный пароль приложения (на вкладке безопасности каждого пользователя)
По крайней мере так для меня с mbsync в новое место. Я не организация на сотню сотрудников, а одно физическое лицо со своим личным доменом.
Александр Борисович, sudo apt install postgresql-15 . Всё, что вы упрощаете вкорячивая в этот элементарный процесс докер, кроме привнесения дополнительный проблем?
ничего подобного, обычный alter type .. add value для добавления значения в enum, самый обычный alter table ... set default для значения по-умолчанию как для всех прочих типов данных.
какие софтварные пределы, вы о чём? Простейшая полностью логичная идея оптимизации задачи: прочесть блок с одного диска и отправить на запись из памяти на несколько дисков параллельно вместо многократного чтения диска-источника.
а топологию подключения дисков можно обсуждать, когда вопрос будет про поиск источника замедления при одновременной записи нескольких десятков HDD. Я так понял, даже упомянутые выше 15 дисков не планируется подключить одновременно, куда там упираться?
покажите мне HDD, который способен упереться в полосу не то что SATA III, а хотя бы SATA II.
но да, общий процесс записи будет болтаться на уровне возможностей самого медленного из дисков. Но по времени это всё равно существенно быстрее, чем копировать каждый диск в отдельности. Время X записи самого медленного диска никуда не денется, как его не переставляй.
Смотря какой базе. MVCC базам проще как раз удалить.