Hantera tillfälliga anslutningsfel för Azure Database for PostgreSQL – flexibel server

  • Artikel

GÄLLER FÖR: Azure Database for PostgreSQL – flexibel server

Den här artikeln beskriver hur du hanterar tillfälliga fel vid anslutning till flexibel Azure Database for PostgreSQL-server.

Tillfälliga fel

Ett tillfälligt fel, även kallat ett tillfälligt fel, är ett fel som löser sig självt. Vanligtvis visas dessa fel som en anslutning till databasservern som tas bort. Det går inte heller att öppna nya anslutningar till en server. Tillfälliga fel kan inträffa till exempel när maskinvaru- eller nätverksfel inträffar. En annan orsak kan vara en ny version av en PaaS-tjänst som distribueras. De flesta av dessa händelser minimeras automatiskt av systemet på mindre än 60 sekunder. Bästa praxis för att utforma och utveckla program i molnet är att förvänta sig tillfälliga fel. Anta att de kan inträffa i valfri komponent när som helst och att ha rätt logik på plats för att hantera dessa situationer.

Hantera tillfälliga fel

Tillfälliga fel ska hanteras med hjälp av omprövningslogik. Situationer som måste beaktas:

  • Ett fel uppstår när du försöker öppna en anslutning
  • En inaktiv anslutning tas bort på serversidan. När du försöker utfärda ett kommando kan det inte köras
  • En aktiv anslutning som för närvarande kör ett kommando tas bort.

De första och andra fallen är ganska raka att hantera. Försök att öppna anslutningen igen. När du lyckas har det tillfälliga felet åtgärdats av systemet. Du kan använda din flexibla Serverinstans i Azure Database for PostgreSQL igen. Vi rekommenderar att du väntar innan du försöker ansluta igen. Säkerhetskopiera om de första återförsöken misslyckas. På så sätt kan systemet använda alla tillgängliga resurser för att lösa felsituationen. Ett bra mönster att följa är:

  • Vänta i 5 sekunder innan du försöker igen.
  • För varje efterföljande återförsök ökar du väntetiden exponentiellt, upp till 60 sekunder.
  • Ange ett maximalt antal återförsök då programmet anser att åtgärden misslyckades.

När en anslutning med en aktiv transaktion misslyckas är det svårare att hantera återställningen korrekt. Det finns två fall: Om transaktionen var skrivskyddad är det säkert att öppna anslutningen igen och försöka utföra transaktionen igen. Men om transaktionen också skrevs till databasen måste du avgöra om transaktionen har återställts eller om den lyckades innan det tillfälliga felet inträffade. I så fall kanske du inte har fått bekräftelsen av incheckningen från databasservern.

Ett sätt att göra detta är att generera ett unikt ID på klienten som används för alla återförsök. Du skickar detta unika ID som en del av transaktionen till servern och lagrar det i en kolumn med en unik begränsning. På så sätt kan du försöka utföra transaktionen igen på ett säkert sätt. Det lyckas om den tidigare transaktionen återställdes och klienten genererade unikt ID ännu inte finns i systemet. Det misslyckas med att ange en duplicerad nyckelöverträdelse om det unika ID:t tidigare lagrades eftersom den tidigare transaktionen slutfördes.

När programmet kommunicerar med en flexibel Azure Database for PostgreSQL-server via mellanprogram från tredje part frågar du leverantören om mellanprogrammet innehåller omprövningslogik för tillfälliga fel.

Testa logiken för återförsök. Prova till exempel att köra koden när du skalar upp eller ned beräkningsresurserna för din azure database for PostgreSQL-instans för flexibel server. Ditt program bör hantera den korta stilleståndstid som påträffas under den här åtgärden utan problem.