Händelser
POSETTE En händelse för Postgres
14 nov. 23 - 9 feb. 23
Inbjudan till förslag är öppen till den 9 februari för det här kostnadsfria och virtuella utvecklarevenemanget.
Kom igångDen här webbläsaren stöds inte längre.
Uppgradera till Microsoft Edge och dra nytta av de senaste funktionerna och säkerhetsuppdateringarna, samt teknisk support.
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.
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.
Tillfälliga fel ska hanteras med hjälp av omprövningslogik. Situationer som måste beaktas:
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:
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.
Händelser
POSETTE En händelse för Postgres
14 nov. 23 - 9 feb. 23
Inbjudan till förslag är öppen till den 9 februari för det här kostnadsfria och virtuella utvecklarevenemanget.
Kom igång