Обработка временных ошибок и эффективное подключение к Базе данных Azure для MySQL
ОБЛАСТЬ ПРИМЕНЕНИЯ:
База данных Azure для MySQL — отдельный сервер
Важно!
База данных Azure для MySQL один сервер находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить обновление до База данных Azure для MySQL гибкого сервера. Дополнительные сведения о миграции на гибкий сервер База данных Azure для MySQL см. в статье "Что происходит с одним сервером База данных Azure для MySQL?"
В этой статье описывается, как справиться с временными ошибками и обеспечить эффективное подключение к Базе данных Azure для MySQL.
Временные ошибки
Временная ошибка, также известная как временный сбой, является ошибкой, которая устраняется автоматически. Чаще всего эти ошибки проявляются в виде сброса соединения с сервером базы данных. При этом невозможно установить новые подключения к серверу. Временные ошибки могут возникать, например, при сбое оборудования или сети. Другая возможная причина — новая версия службы PaaS, для которой выполняется развертывание. Большинство этих событий автоматически устраняются системой менее чем за 60 секунд. При проектировании и разработке приложений в облаке рекомендуется учитывать возможность временных ошибок. Нужно учитывать, что они могут произойти в любом компоненте в любое время, и предусмотреть соответствующую логику для таких ситуаций.
Обработка временных ошибок
Временные ошибки следует обрабатывать с использованием логики повторных подключений. Нужно учитывать следующие ситуации.
- При попытке открыть соединение возникает ошибка.
- Неактивное подключение сбрасывается на стороне сервера. Попытка выполнить команду завершается сбоем.
- Активное подключение, по которому в настоящее время выполняется команда, сбрасывается.
Ошибки первого и второго типа достаточно просто устранить. Попробуйте открыть подключение еще раз. Когда вам это удастся, система устранит временную ошибку. Базу данных Azure для MySQL можно использовать снова. Мы рекомендуем подождать перед повторной попыткой подключения. Отключитесь, если исходные повторные попытки не дают результата. Таким образом, система может использовать все доступные ресурсы для устранения ошибки. Ниже приведен шаблон для выполнения.
- Подождите 5 секунд перед первой повторной попыткой.
- Для каждой следующей попытки увеличивайте время ожидания экспоненциально до 60 секунд.
- Задайте максимальное число повторных попыток, после чего приложение подтвердит сбой операции.
Когда происходит сбой подключения с активной транзакцией, управлять процессом восстановления становится сложнее. Существует два варианта: если транзакция была доступна только для чтения, вы можете безопасно повторно открыть подключение и повторить транзакцию. Однако если транзакция также была доступна и для записи в базу данных, то необходимо определить, был ли выполнен откат транзакции или же она была успешно проведена до возникновения временной ошибки. В этом случае вы могли просто не получить подтверждение фиксации от сервера базы данных.
Один из способов сделать это — создать уникальный идентификатор на клиенте, который используется для всех повторных попыток. Вы передаете этот уникальный идентификатор как часть транзакции на сервер и сохраняете его в столбце с уникальным ограничением. Таким образом можно безопасно повторить транзакцию. Это действие будет выполнено успешно, если при предыдущей транзакции был выполнен откат, а созданный клиентом уникальный идентификатор еще не существует в системе. Произойдет сбой с оповещением о дубликате ключа, если уникальный идентификатор был сохранен ранее в результате успешной транзакции.
Если программа взаимодействует с Базой данных Azure для MySQL через стороннее программное обеспечение промежуточного слоя, спросите поставщика, предусмотрена ли в этом программном обеспечении логика повторных попыток в случае временных ошибок.
Не забудьте проверить логику повторных попыток. Например, попробуйте выполнить свой код, увеличивая или уменьшая число вычислительных ресурсов сервера Базы данных Azure для MySQL. Ваше приложение должно без каких-либо проблем справиться с небольшим простоем во время этой операции.
Эффективное подключение к Базе данных Azure для MySQL
Подключения к базе данных — это ограниченный ресурс, поэтому эффективное использование пула подключений для доступа к Базе данных Azure для MySQL оптимизирует производительность. В следующем разделе объясняется, как использовать пулы подключений или постоянные подключения для более эффективного доступа к Базе данных Azure для MySQL.
Получение доступа к базам данных с помощью пула подключений (рекомендуется)
Управление подключениями к базе данных может оказать значительное влияние на производительность приложения в целом. Чтобы оптимизировать производительность приложения, необходимо уменьшить число установленных соединений и время установления соединений для ключевых путей кода. Мы настоятельно рекомендуем использовать для подключения к Базе данных Azure для MySQL пулы подключений к базам данных или постоянные подключения. Пул подключений к базе данных обеспечивает создание, управление и выделение подключений к базам данных. Когда программа запрашивает подключение к базе данных, она определяет приоритет выделения существующих бездействующих подключений к базе данных, а не создает новое подключение. После того как программа завершит использование подключения к базе данных, подключение восстанавливается в процессе подготовки к дальнейшему использованию, а не просто закрывается.
Для наглядности в этой статье представлен фрагмент примера кода, в котором используется Java. Дополнительные сведения см. в документации по Apache Commons DBCP.
Примечание.
Сервер настраивает механизм времени ожидания, который позволит закрывать подключения, которые находились в состоянии простоя в течение некоторого времени, для освобождения ресурсов. Обязательно настройте систему проверки, чтобы обеспечить эффективность постоянных подключений при их использовании. Дополнительные сведения см. в разделе Настройка систем проверки в клиентах для подтверждения эффективности постоянных подключений.
Доступ к базам данных с помощью постоянных подключений (рекомендуется)
Концепция постоянных подключений аналогична принципу использования пулов подключений. Замена краткосрочных подключений на постоянные требует лишь незначительных изменений в коде, но оказывает значительное влияние в плане повышения производительности во многих типичных прикладных сценариях.
Доступ к базам данных с помощью механизма ожидания и повторения попыток при использовании кратковременных подключений
При наличии ограничений ресурсов настоятельно рекомендуется использовать пулы баз данных или постоянные подключения к базам данных. Если в приложении используются кратковременные подключения и возникают сбои подключения при достижении верхнего предела числа одновременных подключений, можно попробовать использовать механизм ожидания и повторения попытки. Вы можете задать соответствующее время ожидания и уменьшить его после первой попытки. После этого можно попытаться несколько раз дождаться события.
Настройка механизмов проверки в клиентах для подтверждения эффективности постоянных подключений
Сервер настраивает механизм времени ожидания, который позволит закрывать подключения, находившиеся в состоянии простоя в течение некоторого времени, для освобождения ресурсов. Когда клиент снова получает доступ к базе данных, это эквивалентно созданию нового запроса на подключение между клиентом и сервером. Чтобы обеспечить эффективность подключений в процессе их использования, настройте механизм проверки в клиенте. Как показано в следующем примере, для настройки этого механизма проверки можно использовать пулы подключений Tomcat JDBC.
Если задать параметр TestOnBorrow, при наличии нового запроса пул подключений автоматически проверяет эффективность всех доступных простаивающих подключений. Если такое подключение становится действительным, оно возвращается непосредственно. В противном случае пул подключений отзывает подключение. Затем пул подключений создает новое действующее подключение и возвращает его. Этот процесс обеспечивает эффективный доступ к базе данных.
Сведения о конкретных параметрах см. в официальном документе, содержащем общие сведения о пуле подключений JDBC. Обычно необходимо задать следующие три параметра: TestOnBorrow (значение true), TestOnBorrow (значение SELECT 1) и ValidationQueryTimeout (значение 1). Ниже приведен конкретный пример кода.
public class SimpleTestOnBorrowExample {
public static void main(String[] args) throws Exception {
PoolProperties p = new PoolProperties();
p.setUrl("jdbc:mysql://localhost:3306/mysql");
p.setDriverClassName("com.mysql.jdbc.Driver");
p.setUsername("root");
p.setPassword("password");
// The indication of whether objects will be validated by the idle object evictor (if any).
// If an object fails to validate, it will be dropped from the pool.
// NOTE - for a true value to have any effect, the validationQuery or validatorClassName parameter must be set to a non-null string.
p.setTestOnBorrow(true);
// The SQL query that will be used to validate connections from this pool before returning them to the caller.
// If specified, this query does not have to return any data, it just can't throw a SQLException.
p.setValidationQuery("SELECT 1");
// The timeout in seconds before a connection validation queries fail.
// This works by calling java.sql.Statement.setQueryTimeout(seconds) on the statement that executes the validationQuery.
// The pool itself doesn't timeout the query, it is still up to the JDBC driver to enforce query timeouts.
// A value less than or equal to zero will disable this feature.
p.setValidationQueryTimeout(1);
// set other useful pool properties.
DataSource datasource = new DataSource();
datasource.setPoolProperties(p);
Connection con = null;
try {
con = datasource.getConnection();
// execute your query here
} finally {
if (con!=null) try {con.close();}catch (Exception ignore) {}
}
}
}