PostgreSQL: балансировка чтения, пул соединений и failover
Для PostgreSQL различайте три задачи: повторное использование соединений, распределение подходящих запросов чтения и переход на другой узел при отказе. Один компонент не обязательно решает все три.
Primary и replicas
В типичном варианте streaming replication запись идёт на primary, а hot standby может обслуживать чтение. При асинхронной репликации replica отстаёт: немедленное чтение только что записанных данных может потребовать primary.
Роли инструментов
- PgBouncer прежде всего pooler. Режимы session/transaction/statement меняют срок закрепления server connection; это не обещание автоматического анализа SELECT и распределения по replicas.
- Pgpool-II имеет правила load balancing SELECT, с ограничениями по транзакциям, функциям и другим свойствам запросов.
- Общий TCP-балансировщик должен знать, какой узел действительно принимает нужный тип нагрузки; открытый порт не доказывает роль узла.
Проверка маршрутизации
- Зафиксируйте требования к свежести и назначьте write/read маршруты.
- Проверьте, что транзакция и зависящее от неё чтение не расходятся неожиданно по узлам.
- Измеряйте lag и поведение длинных запросов на standby.
- Для transaction pooling проверьте совместимость session state, prepared statements и используемых драйвером функций.
Отказоустойчивость
Failover требует отдельного решения о promotion и предотвращении двух active primary. Балансировщик сам не гарантирует отсутствие потери транзакций. Испытайте отказ на стенде и проверьте повтор запросов приложением. Увеличение числа узлов не обещает линейного ускорения любого запроса.