Delen via

Tijdelijke connectiviteitsfouten afhandelen voor Azure Database for PostgreSQL - Flexible Server

  • Artikel

VAN TOEPASSING OP: Azure Database for PostgreSQL - Flexibele server

In dit artikel wordt beschreven hoe u tijdelijke fouten kunt afhandelen die verbinding maken met een flexibele Azure Database for PostgreSQL-server.

Tijdelijke fouten

Een tijdelijke fout, ook wel een tijdelijke fout genoemd, is een fout die zichzelf oplost. Meestal zijn deze fouten zichtbaar als een verbinding met de databaseserver die wordt verwijderd. Er kunnen ook geen nieuwe verbindingen met een server worden geopend. Tijdelijke fouten kunnen bijvoorbeeld optreden wanneer er hardware- of netwerkfouten optreden. Een andere reden kan een nieuwe versie van een PaaS-service zijn die wordt geïmplementeerd. De meeste van deze gebeurtenissen worden in minder dan 60 seconden automatisch beperkt door het systeem. Een best practice voor het ontwerpen en ontwikkelen van toepassingen in de cloud is het verwachten van tijdelijke fouten. Stel dat ze op elk gewenst moment in elk onderdeel kunnen plaatsvinden en dat de juiste logica aanwezig is om deze situaties af te handelen.

Tijdelijke fouten afhandelen

Tijdelijke fouten moeten worden verwerkt met behulp van logica voor opnieuw proberen. Situaties die moeten worden overwogen:

  • Er treedt een fout op wanneer u probeert een verbinding te openen
  • Er wordt een niet-actieve verbinding aan de serverzijde verbroken. Wanneer u een opdracht probeert uit te geven, kan deze niet worden uitgevoerd
  • Een actieve verbinding die momenteel een opdracht uitvoert, wordt verwijderd.

De eerste en tweede gevallen zijn redelijk eenvoudig te verwerken. Probeer de verbinding opnieuw te openen. Wanneer u slaagt, is de tijdelijke fout opgelost door het systeem. U kunt uw flexibele Azure Database for PostgreSQL-serverexemplaren opnieuw gebruiken. U wordt aangeraden te wachten voordat u de verbinding opnieuw probeert uit te voeren. Teruggaan als de eerste nieuwe pogingen mislukken. Op deze manier kan het systeem alle beschikbare resources gebruiken om de foutsituatie te verhelpen. Een goed patroon is:

  • Wacht vijf seconden voordat u het opnieuw probeert.
  • Verhoog voor elke volgende nieuwe poging de wachttijd exponentieel, tot 60 seconden.
  • Stel een maximum aantal nieuwe pogingen in op welk punt de bewerking is mislukt door uw toepassing.

Wanneer een verbinding met een actieve transactie mislukt, is het moeilijker om het herstel correct te verwerken. Er zijn twee gevallen: als de transactie het kenmerk Alleen-lezen heeft, is het veilig om de verbinding opnieuw te openen en de transactie opnieuw uit te voeren. Als de transactie echter ook naar de database is geschreven, moet u bepalen of de transactie is teruggedraaid of als deze is geslaagd voordat de tijdelijke fout is opgetreden. In dat geval hebt u mogelijk niet de bevestiging van de doorvoer van de databaseserver ontvangen.

Een manier om dit te doen, is het genereren van een unieke id op de client die wordt gebruikt voor alle nieuwe pogingen. U geeft deze unieke id als onderdeel van de transactie door aan de server en slaat deze op in een kolom met een unieke beperking. Op deze manier kunt u de transactie veilig opnieuw proberen. Dit lukt als de vorige transactie is teruggedraaid en de door de client gegenereerde unieke id nog niet bestaat in het systeem. Er mislukt een schending van een dubbele sleutel als de unieke id eerder is opgeslagen omdat de vorige transactie is voltooid.

Wanneer uw programma communiceert met azure Database for PostgreSQL flexibele server via middleware van derden, vraagt u de leverancier of de middleware logica voor nieuwe pogingen voor tijdelijke fouten bevat.

Zorg ervoor dat u de logica voor opnieuw proberen test. Probeer bijvoorbeeld uw code uit te voeren tijdens het omhoog of omlaag schalen van de rekenresources van uw flexibele Azure Database for PostgreSQL-serverexemplaren. Uw toepassing moet de korte downtime verwerken die tijdens deze bewerking wordt aangetroffen zonder problemen.