Share via

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

  • Artikel

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

Viktigt!

Azure Database for MySQL – enskild server är på väg att dras tillbaka. Vi rekommenderar starkt att du uppgraderar till en flexibel Azure Database for MySQL-server. Mer information om hur du migrerar till en flexibel Azure Database for MySQL-server finns i Vad händer med 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 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.

Det första och andra fallet ä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 Azure Database for MySQL 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 å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 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 det klientgenererade unika ID:t ä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 Azure Database for MySQL 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 att försöka igen. Prova till exempel att köra koden när du skalar upp eller ned beräkningsresurserna för din Azure Database for MySQL-server. Ditt program bör hantera den korta stilleståndstid som påträffas under den här åtgärden utan problem.

Anslut effektivt till Azure Database for MySQL

Databasanslutningar är en begränsad resurs, så att effektivt använda anslutningspooler för att få åtkomst till Azure Database for MySQL optimerar prestandan. I avsnittet nedan beskrivs hur du använder anslutningspooler eller beständiga anslutningar för att få effektivare åtkomst till Azure Database for MySQL.

Att hantera 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 anslutningar upprättas och tid 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 till Azure Database for MySQL. Databasanslutningspooler hanterar skapande, hantering och allokering av databasanslutningar. När ett program begär en databasanslutning prioriteras allokeringen av befintliga inaktiva databasanslutningar i stället för att skapa en ny anslutning. När programmet har slutförts med databasanslutningen återställs anslutningen som förberedelse för ytterligare användning, i stället för att helt enkelt stängas.

För bättre illustration innehåller den här artikeln en exempelkod som använder JAVA som exempel. Mer information finns i Apache common DBCP.

Kommentar

Servern konfigurerar en timeout-mekanism för att stänga en anslutning som har varit i inaktivt tillstånd under en tid för att frigöra resurser. Se till att konfigurera verifieringssystemet för att säkerställa effektiviteten hos beständiga anslutningar när du använder dem. Mer information finns i Konfigurera verifieringssystem på klientsidan för att säkerställa effektiviteten hos 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 typiska programscenarier.

Få åtkomst till databaser med hjälp av mekanismen vänta och försök igen med korta anslutningar

Om du har resursbegränsningar rekommenderar vi starkt att du använder databaspooler eller beständiga anslutningar för att komma åt 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 prova att vänta och försöka igen. Du kan ange en lämplig väntetid med 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 timeout-mekanism för att stänga en anslutning som har varit i inaktivt tillstånd under en tid för att frigöra resurser. När klienten kommer åt 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 hos anslutningar under processen för att använda dem. Som du ser i följande exempel kan du använda Tomcat JDBC-anslutningspooler för att konfigurera den här 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 dras anslutningen tillbaka direkt i den annars returnerade 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 främst ange följande tre parametrar: TestOnBorrow (inställd på true), ValidationQuery (inställd 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