Проблема с подключением к базе данных после отработки отказа

У нас есть кластер серверов Tomcat в AWS BeansTalk, подключенных к AWS RDS (MySQL) с доступностью в нескольких зонах доступности.

Несколько дней назад к экземпляру RDS был применен патч к ОС, который запускал переключение на другой экземпляр RDS в зависимости от доступности в нескольких зонах доступности.

В результате производственная система не работала в течение нескольких часов (это было ночью), пока мы не перезапускали Tomcats в каждом случае. У нас были тысячи ошибок Connection refused в базе данных.

Согласно поддержке AWS, когда запускается отказоустойчивый экземпляр, конечная точка остается такой же, но ее IP-адрес изменяется, а мой Tomcats имеет кэшированный старый IP-адрес. Таким образом, после перезапуска Tomcat кеш был очищен, использовался новый IP-адрес и проблема с подключением была решена. Они отсылают меня к этому SO вопрос.

В этом есть смысл, однако я не смог воспроизвести проблему в контролируемом тесте с тем же приложением в производственной среде.

Я изменил IP-адрес домена в / etc / hosts, и мой текущий BeansTalk Production Tomcat обнаружил изменение IP-адреса через 30 секунд, поэтому он также должен был обнаружить изменение IP-адреса конечной точки RDS.

Свойство Java ttl в моей среде BeansTalk установлено как:

#networkaddress.cache.ttl=-1

Итак, по умолчанию для кеширования требуется 30 секунд, что соответствует моему эксперименту.

[РЕДАКТИРОВАТЬ] Как было предложено в комментариях, я попытался смоделировать аварийное переключение через DNS. В этом случае я изменил запись CNAME с одного домена на другой. Я проделал тот же тест, и через 30 секунд Tomcat снова обнаружил изменение.

Вы знаете, почему в этом случае изменение IP-адреса конечной точки RDS не было обнаружено Tomcat / JVM?