Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Устойчивость подключения позволяет драйверу JDBC прозрачно восстановить неактивное подключение и повторить начальное подключение при сбое. В этой статье рассматриваются два свойства строки подключения, которые управляют этим поведением (connectRetryCount и connectRetryInterval), а также параметры keepalive, которые драйвер использует для обнаружения разорванного неактивного соединения. Устойчивость подключения доступна начиная с Microsoft JDBC Driver 10.2.0 для SQL Server. Для повторного подключения неактивного подключения требуется SQL Server 2014 или более поздней версии или База данных SQL Azure.
Tip
Отказоустойчивость подключения повторно пытается установить только начальное соединение и незаметно восстанавливает разорванные неактивные соединения. Чтобы автоматически повторно выполнять инструкции, завершившиеся с ошибкой (например, при ошибке 1205, когда транзакция выбрана жертвой взаимоблокировки, или при тайм-ауте блокировки 1222) либо расширить список ошибок для повторных попыток подключения, добавив пользовательские номера ошибок (например, временные ошибки Azure SQL, такие как 40197 или 40613), используйте настраиваемую логику повторных попыток. CRL основан на правилах: вы выбираете типы ошибок и резервный вариант, и он работает совместно с функциями, описанными в этой статье.
Как JDBC-драйвер выполняет повторные попытки
Драйвер JDBC предоставляет три независимых механизма повтора. Они работают вместе, поэтому вы можете одновременно использовать все из них:
| Механизм | Что делает | Где узнать больше |
|---|---|---|
| Устойчивость неактивного подключения | Прозрачно восстанавливает разорванное простаивающее подключение (например, подключение из пула, закрытое сервером или балансировщиком нагрузки). | Обнаружение разорванных неактивных соединений (эта статья) |
| Первоначальная повторная попытка подключения | Повторяет неудачную первоначальную попытку подключения по фиксированному расписанию при возникновении ошибок из встроенного списка временных ошибок. | Повторная попытка начального подключения (эта статья) |
| Настраиваемая логика повторных попыток (CRL) | Повтор по правилам для инструкций, завершившихся с ошибкой, и для пользовательских номеров ошибок. Представлено в Microsoft JDBC Driver 12.10. | Настраиваемая логика повторных попыток |
Повторить начальные подключения
Драйвер JDBC включает два свойства подключения, которые определяют частоту и время ожидания драйвера перед повторным повтором первоначального подключения. Добавьте эти свойства в строка подключения или задайте их с помощью свойств источника данных.
| Ключевое слово | Значения | По умолчанию. | Описание |
|---|---|---|---|
connectRetryCount |
Целое число от 0 до 255 (включительно). | 1 | Максимальное число попыток установить или восстановить подключение, прежде чем прекратить попытки. По умолчанию драйвер выполняет одну попытку повтора. Значение 0 отключает повторную попытку. |
connectRetryInterval |
Целое число от 1 до 60 (включительно). | 10 | Время между попытками повторного подключения (в секундах). Драйвер пытается повторно подключиться немедленно, когда обнаруживает неактивное подключение, а затем ожидает connectRetryInterval секунд, прежде чем повторить попытку. Это свойство игнорируется, если connectRetryCount имеет значение 0. |
Если connectRetryCount * connectRetryInterval больше loginTimeout, драйвер прекращает попытки подключения при достижении loginTimeout. В противном случае она продолжается до тех пор, пока connectRetryCount не будет исчерпана.
Эти свойства повторяют только встроенный список временных ошибок подключения. Полный список ошибок, описанных (4060, 40197, 40501, 40613, 49918-49920 и т. д.), см. в встроенном списке временных ошибок подключения. Чтобы добавить пользовательские номера ошибок в этот набор или заменить его полностью, используйте retryConn в логике настраиваемых повторных попыток. Чтобы повторить неудачные инструкции, используйте retryExec в той же статье.
Задайте свойства
Задайте connectRetryCount и connectRetryInterval в URL-адресе JDBC, объекте Properties или в объекте SQLServerDataSource.
В URL-адресе JDBC:
jdbc:sqlserver://server;databaseName=db;connectRetryCount=3;connectRetryInterval=10
С объектом Properties. В фрагментах кода Java в этой статье для краткости опущены импорты и объявления классов.
Properties props = new Properties();
props.setProperty("user", "...");
props.setProperty("password", "...");
props.setProperty("connectRetryCount", "3");
props.setProperty("connectRetryInterval", "10");
Connection c = DriverManager.getConnection("jdbc:sqlserver://server;databaseName=db", props);
С помощью SQLServerDataSource
SQLServerDataSource ds = new SQLServerDataSource();
ds.setServerName("server");
ds.setDatabaseName("db");
ds.setUser("...");
ds.setPassword("...");
ds.setConnectRetryCount(3);
ds.setConnectRetryInterval(10);
Обнаруживать неактивные подключения
Типичное неактивное подключение — это подключение, находящееся в пуле подключений. Драйвер считает соединение неактивным примерно через 30 секунд при отсутствии активности. Сервер или сетевое устройство между клиентом и сервером могут закрывать бездействующие подключения, поэтому драйвер должен заметить, что сокет неактивен перед выполнением следующего запроса.
Для обнаружения разорванных неактивных соединений драйвер использует пакеты TCP keepalive на уровне сокетов. В Linux и при использовании Java 11 или более поздней версии драйвер автоматически включает пакеты keepalive с интервалом 30 секунд (KeepAliveTime), с задержкой 1 секунду между повторными попытками при возникновении сбоя (KeepAliveInterval).
Внимание
В Windows, а также при использовании Java 11 или более ранней версии, необходимо вручную настроить keepalive-пакеты на уровне операционной системы, чтобы воспользоваться механизмом восстановления разорванных неактивных соединений. Сведения о том, как настроить пакеты keepalive, см. в разделе Подключение к базе данных Azure SQL.
Ограничения
Драйвер не может восстановить разорванное бездействующее соединение, если выполняется любое из следующих условий:
- Существует открытый результирующий набор, который не полностью проанализирован или буферирован.
- Подключение переключилось на базы данных Azure SQL.
- Существует открытая транзакция.