Manipulando erros de conectividade transitórios para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível

  • Artigo

APLICA-SE A: Banco de Dados do Azure para PostgreSQL - Servidor Flexível

Este artigo descreve como lidar com erros transitórios conectando-se ao Banco de Dados do Azure para servidor flexível PostgreSQL.

Erros transitórios

Um erro transitório, também conhecido como falha transitória, é um erro que se resolverá sozinho. Normalmente, esses erros se manifestam como uma conexão com o servidor de banco de dados que está sendo descartado. Além disso, novas conexões com um servidor não podem ser abertas. Erros transitórios podem ocorrer, por exemplo, quando ocorre falha de hardware ou rede. Outra razão pode ser uma nova versão de um serviço PaaS que está sendo implementado. A maioria desses eventos é automaticamente atenuada pelo sistema em menos de 60 segundos. Uma prática recomendada para projetar e desenvolver aplicativos na nuvem é esperar erros transitórios. Suponha que eles podem acontecer em qualquer componente a qualquer momento e ter a lógica apropriada para lidar com essas situações.

Tratamento de erros transitórios

Os erros transitórios devem ser tratados usando a lógica de repetição. Situações que devem ser consideradas:

  • Ocorre um erro quando tenta abrir uma ligação
  • Uma conexão ociosa é descartada no lado do servidor. Quando você tenta emitir um comando, ele não pode ser executado
  • Uma conexão ativa que atualmente está executando um comando é descartada.

O primeiro e o segundo casos são bastante simples de tratar. Tente abrir a conexão novamente. Quando você tiver êxito, o erro transitório foi atenuado pelo sistema. Você pode usar seu Banco de Dados do Azure para instância de servidor flexível PostgreSQL novamente. Recomendamos esperar antes de tentar novamente a conexão. Recue se as novas tentativas iniciais falharem. Desta forma, o sistema pode usar todos os recursos disponíveis para superar a situação de erro. Um bom padrão a seguir é:

  • Aguarde 5 segundos antes da primeira tentativa.
  • Para cada nova tentativa, aumente exponencialmente a espera, até 60 segundos.
  • Defina um número máximo de novas tentativas em que seu aplicativo considera que a operação falhou.

Quando uma conexão com uma transação ativa falha, é mais difícil lidar com a recuperação corretamente. Há dois casos: Se a transação foi somente leitura por natureza, é seguro reabrir a conexão e tentar novamente a transação. Se, no entanto, se a transação também estava gravando no banco de dados, você deve determinar se a transação foi revertida ou se foi bem-sucedida antes que o erro transitório acontecesse. Nesse caso, você pode simplesmente não ter recebido a confirmação de confirmação do servidor de banco de dados.

Uma maneira de fazer isso, é gerar um ID exclusivo no cliente que é usado para todas as tentativas. Você passa essa ID exclusiva como parte da transação para o servidor e a armazena em uma coluna com uma restrição exclusiva. Desta forma, você pode repetir a transação com segurança. Ele terá êxito se a transação anterior foi revertida e o ID exclusivo gerado pelo cliente ainda não existe no sistema. Ele falhará indicando uma violação de chave duplicada se o ID exclusivo foi armazenado anteriormente porque a transação anterior foi concluída com êxito.

Quando seu programa se comunica com o Banco de Dados do Azure para servidor flexível PostgreSQL por meio de middleware de terceiros, pergunte ao fornecedor se o middleware contém lógica de repetição para erros transitórios.

Certifique-se de testar sua lógica de repetição. Por exemplo, tente executar seu código enquanto dimensiona para cima ou para baixo os recursos de computação do seu Banco de Dados do Azure para instância de servidor flexível PostgreSQL. Seu aplicativo deve lidar com o breve tempo de inatividade encontrado durante esta operação sem problemas.