Цель данного поста протестировать горизонтальное масштабирование SELECT запросов на реплику. Схема горизонтального масштабирования примерно такая.  Возьмем виртуальные машины для PostgreSQL по 2 ГБ ОЗУ, чтобы бд не ввлезала в память и 3 ноды Etcd по 1ГБ. Устанавливаем PostgreSQL кластер из репозитория https://github.com/vitabaks/postgresql_cluster Cхема работы этого кластера в Type A вот такая:  Изменяем адреса серверов в inventory на свои.  Правим параметры в var/main.yaml Выставляем синхронный режим Активируем Haproxy, который может отпределять кто Leader, а кто c помощью health check Выключаем pgbouncer, так как оне будет мешать экперименту. Добавляем создание пользователя test с паролем password Добавляем создание бд test с owner test Увеличиваем max_connections Добавляем бд и юзера test в pg_hba Тюнинг параметров можно выполнить здесь: http://pgconfigurator.cybertec.at/ После установки у вас должно быть примерно такая картина  Так как pgbench-у нельзя указать ip для реплики, то запустим 2 экземпляра pgbench: первый будет создавать update, второй будетсоздавать только select-only нагрузку. Заполняем тестовую базу Запускаем 2 консолях одновременно pgbench write-only и select-only, где все коннекты идут к master Вывод pgbench write-only: Вывод pgbench select-only: Запускаем 2 консолях одновременно pgbench write-only и select-only, где коннект write-only идет к master, а коннект select-only идет на реплику. Вывод pgbench write-only: Вывод pgbench select-only: Улучшение для write запросов в тесте pgbench при переводе SELECT запросов на реплику: (124-82)/82=0.51 или 51% Улучшение для select запросов в тесте pgbench при переводе SELECT запросов на реплику: (247-109)/109=1.26 или 126%  Без индекса update и select будут упираться в диск, если бд не влазит в ОЗУ. А это мешает эксперименту. Проверяем размер БД после генерации данных:  Поменять на  А строку содержащую несколько нод закоментировать меняем на  Должно получиться примерно так:
 Компилируем код Запускаем Java приложение Время выполнения транзакций, которые идут на Leader, и select, которые идут на Replica Поменять на  А строку содержащую несколько нод раскоментировать меняем на  Должно получиться примерно так:
 Компилируем код Запускаем Java приложение Время выполнения транзакций и select, если идет обращение только на Leader Как видим время запросов поменялось не сильно. Активируем бесконечный цикл SQL запросов в Java приложении. Переходим на 108 строку и расскоментируем while(true) {, комментируем for(int i=0; i < 100; i++ ) { Должно получиться примерно так:  Правим строку String nodes в файле JavaPostgreSqlRepl.java Поменять на  А строку содержащую несколько нод закоментировать меняем на  Должно получиться примерно так:
 Компилируем код Запускаем 49 раз Java приложение в фоне в бесконечном цикле. Проверяем что у нас запущено 49 приложений java Смотрим какие процессы postgres запущены на реплике  Запускаем Java приложение чтобы увидеть среднее время SQL запросов. Время выполнения транзакций и select, если идет обращение только на Leader Время выполнения транзакций, которые идут на Leader и select, которые идут на Replica  Исходные данные можно посмотреть по ссылке https://docs.google.com/spreadsheets/d/1jw5DAsHFNsO4wmYUxR2TmbGc1CS9J0w2beNhfI0NLhQ/edit?usp=sharing Чтобы подтвердить тесты pgbench из java приложений и потдвердить улучшение времени SQL запросов (TPS) на самом сервере приложений, нужно тестировать многопоточное Java приложение с Connection Pool (Например, HikariCP, C3PO), которое будет одновременно отправлять несколько десятков SQL запросов так как это делает pgbench. Возможно, кто-то это сделает. DevOps-инженер