MySQL Connector/J поддерживает отказоустойчивость сервера. Отказоустойчивость происходит при возникновении ошибок, связанных с подключением, для активного подключающегося объекта. По умолчанию ошибки подключения распространяются на клиент, который должен обрабатывать их, например, повторно создавая рабочие объекты (Statement, ResultSet и т. д.) и перезапуская процессы. Иногда драйвер может в конечном итоге вернуться к исходному хосту автоматически до продолжения работы клиентского приложения, в этом случае переключение хоста будет прозрачным, и клиентское приложение даже не заметит его.

Подключение с поддержкой отказоустойчивости работает так же, как и стандартное подключение: клиент не испытывает никаких нарушений в процессе отказоустойчивости. Это означает, что клиент может полагаться на тот же экземпляр подключения, даже если два последовательных запроса могут быть выполнены на двух разных физических хостах. Однако это не означает, что клиенту не нужно обрабатывать исключение, вызвавшее переключение сервера.

Отказоустойчивость настраивается на начальном этапе настройки подключения к серверу с помощью URL подключения (см. пояснения к его формату здесь):

jdbc:mysql://[primary host][:port],[secondary host 1][:port][,[secondary host 2][:port]]...[/[database]]»
[?propertyName1=propertyValue1[&propertyName2=propertyValue2]...]

Список хостов в URL подключения состоит из двух типов хостов: первичного и вторичных. При запуске нового подключения драйвер всегда пытается подключиться к первичному хосту, а при необходимости переходит к вторичным хостам в списке последовательно при возникновении проблем с обменом данными. Даже если первоначальное подключение к первичному хосту завершится ошибкой, и драйвер подключится к вторичному хосту, первичный хост никогда не потеряет своего специального статуса: например, он может быть настроен с режимом доступа, отличным от режимов вторичных хостов, и может быть помещен в более высокий приоритет при выборе хоста во время процесса отказоустойчивости.

Поддержка отказоустойчивости настраивается следующими свойствами подключения (их функции поясняются в последующих абзацах):

Настройка режима доступа к подключению

Как и в случае любого стандартного подключения, первоначальное подключение к первичному хосту происходит в режиме чтения/записи. Однако, если драйверу не удается установить первоначальное подключение к первичному хосту, и он автоматически переключается на следующий хост в списке, режим доступа теперь зависит от значения свойства failOverReadOnly, которое по умолчанию равно “true”. То же самое происходит, если драйвер первоначально подключен к первичному хосту и, из-за сбоя подключения, переключается на вторичный хост. Каждый раз, когда подключение возвращается к первичному хосту, его режим доступа будет читать/запись, независимо от того, подключался ли к первичному хосту ранее. Режим доступа к подключению можно изменить в любое время во время выполнения, вызвав метод Connection.setReadOnly(boolean), который частично переопределяет свойство failOverReadOnly. Когда failOverReadOnly=false, и режим доступа явно устанавливается либо в true, либо в false, он становится режимом для каждого подключения после переключения хоста, независимо от типа подключаемого хоста; но, если failOverReadOnly=true, изменить режим доступа на чтение/запись можно только при подключении к первичному хосту; однако, даже если режим доступа не может быть изменён для текущего подключения, драйвер запоминает последнее намерение клиента и, при возврате к первичному хосту, этот режим будет использован. Для иллюстрации см. следующие последовательности событий с подключением к двум хостам.

Разница между двумя сценариями заключается в шаге 4: режим доступа к вторичному хосту в сценарии A не меняется на этом шаге, но драйвер запоминает и использует установленный режим при возвращении к первичному хосту, который в противном случае был бы режимом только чтения; но в сценарии B режим доступа к вторичному хосту изменяется немедленно.

Настройка возврата к первичному хосту

Как уже упоминалось, первичный хост является специальным в схеме отказоустойчивости, когда речь идет о режиме доступа к хосту. Кроме того, по умолчанию драйвер пытается как можно скорее вернуться к первичному хосту, даже если не происходит никаких исключений в обмене данными. Два свойства, secondsBeforeRetrySource и queriesBeforeRetrySource, определяют, когда драйвер готов повторить попытку переподключения к первичному хосту (Source в именах свойств обозначает первичный хост нашего URL-адреса подключения, который не обязательно является хостом источника в настройке репликации):

В общем случае попытка возврата к первичному хосту предпринимается, когда выполняется хотя бы одно из условий, указанных в двух свойствах, и попытка всегда происходит на границах транзакции. Однако, если автоматический коммит выключен, проверка происходит только при вызове метода Connection.commit() или Connection.rollback(). Автоматический возврат к первичному хосту можно отключить, одновременно установив secondsBeforeRetrySource и queriesBeforeRetrySource в “0”. Установка только одного из свойств в “0” отключает только одну часть проверки.

Настройка попыток переподключения

При создании нового подключения или при возникновении события отказоустойчивости драйвер пытается последовательно подключиться к следующему кандидату в списке хостов. Когда конец списка достигается, он начинает всё сначала с начала списка; однако первичный хост пропускается, если (а) НЕ все вторичные хосты уже проверялись хотя бы один раз, И (б) условия возврата, определённые secondsBeforeRetrySource и queriesBeforeRetrySource, ещё не выполнены. Каждое прохождение по всему списку хостов (которое не обязательно завершается в конце списка) считается одной попыткой подключения. Драйвер пытается выполнить столько попыток подключения, сколько указано в значении свойства retriesAllDown.

Бесшовное переподключение

Хотя не рекомендуется, вы можете заставить драйвер выполнять переключение без аннулирования активных Statement или ResultSet экземпляров, установив параметр autoReconnect или autoReconnectForPools в true. Это позволяет клиенту продолжить использование тех же экземпляров объектов после события отказоустойчивости, не принимая никаких специальных мер. Однако это может привести к неожиданным результатам: например, если драйвер подключен к первичному хосту с режимом доступа чтение/запись и переключается на вторичный хост в режиме только чтения, дальнейшие попытки выполнения запросов изменения данных приведут к ошибкам, и клиент об этом не будет знать. Это ограничение особенно важно при использовании потоковой передачи данных: после переключения отказоустойчивости ResultSet выглядит нормально, но основное подключение может уже измениться, и уже нет доступного курсора.

Настройка отказоустойчивости сервера с использованием JDBC с DNS SRV

Подробности см. в разделе 6.14 «Поддержка записей DNS SRV».