Share via

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

  • Статья

Область применения: гибкий сервер Базы данных Azure для PostgreSQL

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

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

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

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

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

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

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

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

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

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

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

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