Hantera tillfälliga fel och ansluta effektivt till Azure Database for MySQL

  • Artikel
  • 6 minuter för att läsa

GÄLLER FÖR: Azure Database for MySQL – enskild server

Den här artikeln beskriver hur du hanterar tillfälliga fel och ansluter effektivt till Azure Database for MySQL.

Tillfälliga fel

Ett tillfälligt fel, även kallat tillfälligt fel, är ett fel som löser sig självt. De flesta felen visas vanligtvis som en anslutning till databasservern som tas bort. Nya anslutningar till en server kan inte heller öppnas. 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. Ett bra sätt att utforma och utveckla program i molnet är att förvänta sig tillfälliga fel. Anta att de kan inträffa i alla komponenter när som helst och ha rätt logik på plats för att hantera dessa situationer.

Hantera tillfälliga fel

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

  • Ett fel inträffar 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.

Det första och andra fallet är ganska enkelt 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 Azure Database for MySQL igen. Vi rekommenderar att du väntar innan du försöker ansluta igen. Backa av 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 felläget. Ett bra mönster att följa är:

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

När en anslutning till en aktiv transaktion misslyckas är det svårare att hantera återställningen på rätt sätt. Det finns två fall: Om transaktionen var skrivskyddade är det säkert att öppna anslutningen igen och försöka utföra transaktionen igen. Om transaktionen också skrevs till databasen måste du avgöra om transaktionen återställdes eller om den lyckades innan det tillfälliga felet inträffade. I så fall kanske du inte har fått bekräftelsen av bekräftelsen 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 på ett säkert sätt försöka utföra transaktionen igen. Det lyckas om den tidigare transaktionen återställdes och det klientgenererade unika ID:t ännu inte finns i systemet. Det misslyckas vilket indikerar en överträdelse av dubblettnyckeln om det unika ID:t tidigare lagrades eftersom den tidigare transaktionen slutfördes korrekt.

När programmet kommunicerar med Azure Database for MySQL via mellanprogram från tredje part frågar du leverantören om mellanprogrammet innehåller logik för omprövning av tillfälliga fel.

Testa omprövningslogiken. Prova till exempel att köra din kod när du skalar upp eller ned beräkningsresurserna för din Azure Database for MySQL server. Programmet bör hantera den korta stilleståndstiden som uppstår under den här åtgärden utan problem.

Anslut effektivt till Azure Database for MySQL

Databasanslutningar är en begränsad resurs, så effektiv användning av anslutningspooler för åtkomst Azure Database for MySQL optimerar prestanda. I avsnittet nedan förklaras hur du använder anslutningspooler eller beständiga anslutningar för att få mer Azure Database for MySQL.

Hantering av databasanslutningar kan ha en betydande inverkan på programmets prestanda som helhet. För att optimera programmets prestanda bör målet vara att minska antalet gånger som anslutningar upprättas och tiden för att upprätta anslutningar i nyckelkodsökvägar. Vi rekommenderar starkt att du använder databasanslutningspooler eller beständiga anslutningar för att ansluta Azure Database for MySQL. Databasanslutningspooler hanterar skapande, hantering och allokering av databasanslutningar. När ett program begär en databasanslutning prioriterar det allokeringen av befintliga inaktiva databasanslutningar i stället för att skapa en ny anslutning. När programmet har slutfört användningen av databasanslutningen återställs anslutningen som förberedelse för vidare användning, i stället för att helt enkelt stängas.

Den här artikeln innehåller en del exempelkod som använder JAVA som exempel för en bättre illustration. Mer information finns i Apache Common DBCP.

Anteckning

Servern konfigurerar en tidsgränsmekanism för att stänga en anslutning som har varit inaktiv under en viss tid för att frigöra resurser. Se till att konfigurera verifieringssystemet för att säkerställa effektiviteten för beständiga anslutningar när du använder dem. Mer information finns i Konfigurera verifieringssystem på klientsidan för att säkerställa effektiviteten för beständiga anslutningar.

Begreppet beständiga anslutningar liknar begreppet anslutningspooler. Att ersätta korta anslutningar med beständiga anslutningar kräver bara mindre ändringar i koden, men det har en stor effekt när det gäller att förbättra prestanda i många vanliga programscenarier.

Få åtkomst till databaser med hjälp av vänte- och återförsöksmekanismen med korta anslutningar

Om du har resursbegränsningar rekommenderar vi starkt att du använder databaspooler eller beständiga anslutningar för att få åtkomst till databaser. Om programmet använder korta anslutningar och får anslutningsfel när du närmar dig den övre gränsen för antalet samtidiga anslutningar kan du försöka vänta och försöka igen. Du kan ange en lämplig väntetid med en kortare väntetid efter det första försöket. Därefter kan du prova att vänta på händelser flera gånger.

Konfigurera verifieringsmekanismer i klienter för att bekräfta effektiviteten hos beständiga anslutningar

Servern konfigurerar en tidsgränsmekanism för att stänga en anslutning som har varit inaktiv under en viss tid för att frigöra resurser. När klienten får åtkomst till databasen igen motsvarar det att skapa en ny anslutningsbegäran mellan klienten och servern. Konfigurera en verifieringsmekanism på klienten för att säkerställa effektiviteten för anslutningar under användningen av dem. Som du ser i följande exempel kan du använda Tomcat JDBC-anslutningspoolen för att konfigurera verifieringsmekanismen.

Genom att ange parametern TestOnBorrow verifierar anslutningspoolen automatiskt effektiviteten för alla tillgängliga inaktiva anslutningar när det finns en ny begäran. Om en sådan anslutning är effektiv, returneras anslutningen direkt. Annars returneras anslutningspoolen. Anslutningspoolen skapar sedan en ny effektiv anslutning och returnerar den. Den här processen säkerställer att databasen används effektivt.

Information om de specifika inställningarna finns i det officiella introduktionsdokumentet för JDBC-anslutningspoolen. Du behöver huvudsakligen ange följande tre parametrar: TestOnBorrow (inställd på true), ValidationQuery (inställt på SELECT 1) och ValidationQueryTimeout (inställd på 1). Den specifika exempelkoden visas nedan:

public class SimpleTestOnBorrowExample {
      public static void main(String[] args) throws Exception {
          PoolProperties p = new PoolProperties();
          p.setUrl("jdbc:mysql://localhost:3306/mysql");
          p.setDriverClassName("com.mysql.jdbc.Driver");
          p.setUsername("root");
          p.setPassword("password");
            // The indication of whether objects will be validated by the idle object evictor (if any). 
            // If an object fails to validate, it will be dropped from the pool. 
            // NOTE - for a true value to have any effect, the validationQuery or validatorClassName parameter must be set to a non-null string. 
          p.setTestOnBorrow(true); 

            // The SQL query that will be used to validate connections from this pool before returning them to the caller.
            // If specified, this query does not have to return any data, it just can't throw a SQLException.
          p.setValidationQuery("SELECT 1");

            // The timeout in seconds before a connection validation queries fail. 
            // This works by calling java.sql.Statement.setQueryTimeout(seconds) on the statement that executes the validationQuery. 
            // The pool itself doesn't timeout the query, it is still up to the JDBC driver to enforce query timeouts. 
            // A value less than or equal to zero will disable this feature.
          p.setValidationQueryTimeout(1);
            // set other useful pool properties.
          DataSource datasource = new DataSource();
          datasource.setPoolProperties(p);

          Connection con = null;
          try {
            con = datasource.getConnection();
            // execute your query here
          } finally {
            if (con!=null) try {con.close();}catch (Exception ignore) {}
          }
      }
  }

Nästa steg