#java #postgresql #hibernate #high-availability
#java #postgresql #переход в спящий режим #высокая доступность
Вопрос:
У нас есть распределенная (примечание: не микросервисная) система, которая подключается к одной огромной базе данных (PostgresSQL — 9.3.13). В прошлом году у нас были разные сбои в этой базе данных. БД также является своего рода HA, и виртуальный IP-адрес корректно передается подчиненному устройству.
Наше приложение использует Java, и как только Мастер больше недоступен, наше приложение начинает кричать (через журналы, что нормально), но, к сожалению, не подключается к новому мастеру.
Как кто-то может сделать это более устойчивым способом? Лучше всего было бы, если бы соединение оставалось активным, и CP подключался к новому мастеру, как только он стал доступен, и (в лучшем случае) все запущенные обновления / вставки откатываются и запускаются снова на новом мастере.
Для меня проблема, похоже, заключается в виртуальном IP, и пул соединений явно не подключается повторно.
Мы используем DBCP2 в качестве пула соединений. Уровень данных находится в режиме гибернации.
Комментарии:
1. Поместите что-то вроде pgbouncer или pgpool перед двумя серверами, они могут сделать сбой практически невидимым для клиента. Или используйте более современный пул соединений, такой как собственный пул Apache Tomcat, который лучше обрабатывает повторные подключения.
2. Извините за поздний ответ. Мы используем DBCP2, который должен быть очень похож на реализацию Tomcats. Насколько готовы к работе pgbouncer и pgpool. Есть опыт? У нас здесь был консультант, который утверждал, что только приложение отвечает за эту проблему устойчивости. И он сказал, что оба (pgbouncer и pgpool) на самом деле не готовы к производству. Я, с другой стороны (как разработчик приложения), обвиняет HA-материал в БД.