Обработка временных ошибок подключения к Базе данных Azure для MariaDB
Важно!
База данных Azure для MariaDB находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить миграцию в База данных Azure для MySQL. Дополнительные сведения о переходе на База данных Azure для MySQL см. в статье "Что происходит с База данных Azure для MariaDB?".
В этой статье описывается, как обрабатывать временные ошибки, связанные с подключением к Базе данных Azure для MariaDB.
Временные ошибки
Временная ошибка, также известная как временный сбой, является ошибкой, которая устраняется автоматически. Чаще всего эти ошибки проявляются в виде сброса соединения с сервером базы данных. При этом невозможно установить новые подключения к серверу. Временные ошибки могут возникать, например, при сбое оборудования или сети. Другая возможная причина — новая версия службы PaaS, для которой выполняется развертывание. Большинство этих событий автоматически устраняются системой менее чем за 60 секунд. При проектировании и разработке приложений в облаке рекомендуется учитывать возможность временных ошибок. Нужно учитывать, что они могут произойти в любом компоненте в любое время, и предусмотреть соответствующую логику для таких ситуаций.
Обработка временных ошибок
Временные ошибки следует обрабатывать с использованием логики повторных подключений. Нужно учитывать следующие ситуации.
- При попытке открыть соединение возникает ошибка.
- Неактивное подключение сбрасывается на стороне сервера. Попытка выполнить команду завершается сбоем.
- Активное подключение, по которому в настоящее время выполняется команда, сбрасывается.
Ошибки первого и второго типа достаточно просто устранить. Попробуйте открыть подключение еще раз. Когда вам это удастся, система устранит временную ошибку. Базу данных Azure для MariaDB можно использовать снова. Мы рекомендуем подождать перед повторной попыткой подключения. Отключитесь, если исходные повторные попытки не дают результата. Таким образом, система может использовать все доступные ресурсы для устранения ошибки. Ниже приведен шаблон для выполнения.
- Подождите 5 секунд перед первой повторной попыткой.
- Для каждой следующей попытки увеличивайте время ожидания экспоненциально до 60 секунд.
- Задайте максимальное число повторных попыток, после чего приложение подтвердит сбой операции.
Когда происходит сбой подключения с активной транзакцией, управлять процессом восстановления становится сложнее. Существует два варианта: если транзакция была доступна только для чтения, вы можете безопасно повторно открыть подключение и повторить транзакцию. Однако если транзакция также была доступна и для записи в базу данных, необходимо определить, был ли выполнен откат транзакции или же она была успешно проведена до возникновения временной ошибки. В этом случае вы могли не получить подтверждение фиксации от сервера базы данных.
Один из способов сделать это — создать уникальный идентификатор на клиенте, который используется для всех повторных попыток. Вы передаете этот уникальный идентификатор как часть транзакции на сервер и сохраняете его в столбце с уникальным ограничением. Таким образом можно безопасно повторить транзакцию. Это действие будет выполнено успешно, если при предыдущей транзакции был выполнен откат, а созданный клиентом уникальный идентификатор еще не существует в системе. Произойдет сбой с оповещением о дубликате ключа, если уникальный идентификатор был сохранен ранее в результате успешной транзакции.
Если программа взаимодействует с Базой данных Azure для MariaDB через стороннее программное обеспечение промежуточного слоя, спросите поставщика, предусмотрена ли в этом программном обеспечении логика повторных попыток в случае временных ошибок.
Не забудьте проверить логику повторных попыток. Например, попробуйте выполнить свой код, увеличивая или уменьшая число вычислительных ресурсов сервера Базы данных Azure для MariaDB. Ваше приложение должно без каких-либо проблем справиться с небольшим простоем во время этой операции.