пускаем базу данных AWS RDS Aurora / MySQL в кластере с устройством записи и экземпляром устройства чтения, где средство записи реплицируется для устройства чтения.

Приложение, обращающееся к базе данных, является стандартным приложением Java, использующим пул соединений HikariCP. Пул настроен на использование"SELECT 1" тестовый запрос при оформлении заказа.

Что мы заметили, так это то, что время от времени RDS отказывает от писателя к читателю. Отработка отказа также может быть реплицирована вручную, нажав «Действия экземпляра / Отработка отказа» в консоли AWS.

Пул соединений не может обнаружить аварийное переключение и тот факт, что он теперь подключен к базе данных считывателя, так как"SELECT 1" Тестовые запросы все еще успешны. Однако любые последующие обновления базы данных терпят неудачу с"java.sql.SQLException: The MySQL server is running with the --read-only option so it cannot execute this statement" ошибки.

Похоже, что вместо"SELECT 1" В тестовом запросе пул соединений может обнаружить, что теперь он подключен к считывателю с помощью"SELECT count(1) FROM test_table WHERE 1 = 2 FOR UPDATE" тестовый запрос.

Кто-нибудь сталкивался с такой же проблемой?Есть ли недостатки при использовании"FOR UPDATE" в тестовом запросе?Существуют ли какие-либо альтернативные или более эффективные подходы к обработке отказов при записи / считывании кластера AWS RDS?

Ваша помощь очень ценится

Bernie