Обработка временных ошибок подключения в Базе данных Azure для PostgreSQL

В этой статье описывается, как обрабатывать временные ошибки, связанные с подключением к гибкому экземпляру сервера Базы данных Azure для PostgreSQL.

Временные ошибки

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

Обработка временных ошибок

Временные ошибки следует обрабатывать с использованием логики повторных подключений. Нужно учитывать следующие ситуации.

• При попытке открыть соединение возникает ошибка.
• Неактивное подключение сбрасывается на стороне сервера. Попытка выполнить команду завершается сбоем.
• Активное подключение, по которому в настоящее время выполняется команда, сбрасывается.

Ошибки первого и второго типа достаточно просто устранить. Попробуйте открыть подключение еще раз. Как только система устранит временную ошибку, вам удастся подключиться. Вы можете снова использовать гибкий экземпляр сервера База данных Azure для PostgreSQL. Мы рекомендуем подождать перед повторной попыткой подключения. Отключитесь, если исходные повторные попытки не дают результата. Таким образом, система может использовать все доступные ресурсы для устранения ошибки. Ниже приведен шаблон для выполнения.

• Подождите 5 секунд перед первой повторной попыткой.
• Для каждой следующей попытки увеличьте время ожидания в экспоненциально до 60 секунд.
• Задайте максимальное число повторных попыток, после чего приложение подтвердит сбой операции.

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

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

Когда ваша программа взаимодействует с гибким сервером базы данных Azure для PostgreSQL через стороннее ПО промежуточного слоя, спросите у поставщика, содержит ли это ПО логику повторных попыток для переходящих ошибок.

Не забудьте проверить логику повторных попыток. Например, попробуйте выполнить код во время масштабирования вычислительных ресурсов База данных Azure для PostgreSQL гибкого экземпляра сервера. Ваше приложение должно без каких-либо проблем справиться с небольшим простоем во время этой операции.

Связанный контент

Что такое База данных Azure для PostgreSQL?