Processamento de erros de conectividade transitórios da Base de Dados do Azure para PostgreSQL – Servidor Único
APLICA-SE A:
Banco de Dados do Azure para PostgreSQL - Servidor Único
Importante
O Banco de Dados do Azure para PostgreSQL - Servidor Único está no caminho da desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único PostgreSQL?.
Este artigo descreve como lidar com erros transitórios conectando-se ao Banco de Dados do Azure para 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 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 seguinte, o aumento exponencial da 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 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 servidor PostgreSQL. Seu aplicativo deve lidar com o breve tempo de inatividade encontrado durante esta operação sem problemas.