#postgresql #spring-boot #jooq #hikaricp #pg-jdbc
#postgresql #пружинный ботинок #jooq #hikaricp #pg-jdbc
Вопрос:
Я работаю с серверной службой (Spring Boot 2.2.13.RELEASE Hikari JOOQ), которая использует кластер баз данных AWS Aurora PostgreSQL, сконфигурированный с узлом записи (первичным) и узлом чтения (реплики чтения). Узел считывателя только что находился в режиме ожидания / прогрева, ожидая повышения до основного в случае сбоя.
Недавно мы решили начать обслуживать запросы исключительно с узла Reader для некоторых наших конечных точек GET. Для достижения этой цели мы использовали «разновидность» RoutingDataSource, так что всякий раз, когда сервис аннотируется с помощью @Transactional(только для чтения = true), запросы выполняются к источнику данных reader.
До этого все шло гладко. Однако после применения этого решения я заметил увеличение задержки до 3 раз по сравнению с основным источником данных. 
После детализации этого я обнаружил, что каждая транзакция выполняла пару дополнительных обходов в БД, чтобы УСТАНОВИТЬ ХАРАКТЕРИСТИКИ СЕАНСА:
УСТАНОВИТЬ ХАРАКТЕРИСТИКИ СЕАНСА ТОЛЬКО ДЛЯ ЧТЕНИЯ ФАКТИЧЕСКИЙ ЗАПРОС / ЗАПРОСЫ УСТАНОВИТЬ ХАРАКТЕРИСТИКИ СЕАНСА ЧТЕНИЕ ЗАПИСЬ
Чтобы улучшить это, я попытался поиграть с настройкой readOnlyMode, которая была введена в pg-jdbc pg-jdbc 42.2.10. Этот параметр позволяет управлять поведением, когда для соединения установлено значение только для чтения (только для чтения = true).
https://jdbc.postgresql.org/documentation/head/connect.html
В моей первой попытке я использовал только для чтения = true и readOnlyMode=всегда. Несмотря на то, что я опустился до просмотра инструкций SET SESSION CHARACTERISTICS , задержка осталась неизменной. Наконец, я попытался использовать readOnly=false и readOnlyMode=ignore . Эта последняя опция привела к уменьшению задержки, однако она все еще хуже, чем была раньше.
Есть ли у кого-нибудь еще опыт такой настройки? Какова оптимальная конфигурация? Мне не нужно помечать транзакцию как доступную только для чтения (кроме того, чтобы указать источнику данных маршрутизации использовать вместо этого реплику чтения), поэтому я хотел бы выяснить, можно ли сделать что-нибудь еще, чтобы задержка оставалась неизменной между узлами записи и чтения.
Примечание: На текущий момент узел считывания обслуживает только 1% всего трафика ( — 20req / s).
Комментарии:
1. Просто на всякий случай, поскольку вы упоминаете jOOQ: используете ли вы как эту
@Transactionalаннотацию, так и API транзакций jOOQ?2. Я просто использую аннотацию @Transactional.