Tijdelijke fouten afhandelen en efficiënt verbinding maken met Azure Database for MySQL

VAN TOEPASSING OP: Azure Database for MySQL - Enkele server

In dit artikel wordt beschreven hoe u tijdelijke fouten kunt afhandelen en efficiënt verbinding kunt maken met Azure Database for MySQL.

Tijdelijke fouten

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

Tijdelijke fouten verwerken

Tijdelijke fouten moeten worden afgehandeld met behulp van logica voor opnieuw proberen. Situaties die in aanmerking moeten worden genomen:

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

Het eerste en tweede geval 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 Azure Database for MySQL gebruiken. We raden u aan te wachten voordat u de verbinding opnieuw kunt proberen. Back-off als de eerste nieuwe keren mislukt. Op deze manier kan het systeem alle beschikbare resources gebruiken om de foutsituatie te ondervangen. Een goed patroon is:

• Wacht 5 seconden voordat u de eerste keer opnieuw doet.
• Voor elke volgende nieuwe poging neemt de wachttijd exponentieel toe tot 60 seconden.
• Stel een maximum aantal nieuwe pogingen in op het moment dat de toepassing de bewerking als mislukt beschouwt.

Wanneer een verbinding met een actieve transactie mislukt, is het moeilijker om het herstel correct te verwerken. Er zijn twee gevallen: als de transactie alleen-lezen van aard is, is het veilig om de verbinding opnieuw te openen en de transactie opnieuw uit te proberen. Als de transactie echter ook naar de database werd geschreven, moet u bepalen of de transactie is teruggedraaid of is geslaagd voordat de tijdelijke fout zich voordeed. In dat geval hebt u mogelijk niet de bevestiging van de door commit ontvangen van de databaseserver.

Een manier om dit te doen, is het genereren van een unieke id op de client die wordt gebruikt voor alle nieuwe proberen. U kunt deze unieke id als onderdeel van de transactie doorgeven aan de server en opslaan 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 in het systeem bestaat. Deze fout geeft een dubbele sleutelschending aan als de unieke id eerder is opgeslagen omdat de vorige transactie is voltooid.

Wanneer uw programma communiceert met Azure Database for MySQL via middleware van derden, vraagt u de leverancier of de middleware logica voor opnieuw proberen bevat voor tijdelijke fouten.

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 rekenbronnen van uw Azure Database for MySQL server. Uw toepassing moet de korte downtime die tijdens deze bewerking is aangetroffen, zonder problemen afhandelen.

Verbinding maken efficiënt om de Azure Database for MySQL

Databaseverbindingen zijn een beperkte resource, waardoor u effectief gebruik kunt maken van verbindingspooling voor toegang tot Azure Database for MySQL prestaties optimaliseert. In de onderstaande sectie wordt uitgelegd hoe u verbindingspooling of permanente verbindingen gebruikt om effectiever toegang te krijgen tot Azure Database for MySQL.

Toegang tot databases met behulp van verbindingsgroepering (aanbevolen)

Het beheren van databaseverbindingen kan een aanzienlijke invloed hebben op de prestaties van de toepassing als geheel. Om de prestaties van uw toepassing te optimaliseren, moet het doel zijn om het aantal keren te verminderen dat verbindingen tot stand worden gebracht en de tijd voor het tot stand brengen van verbindingen in sleutelcodepaden. We raden u ten zeerste aan om databaseverbindingspooling of permanente verbindingen te gebruiken om verbinding te maken met Azure Database for MySQL. Pooling van databaseverbindingen verwerkt het maken, beheren en toewijzen van databaseverbindingen. Wanneer een programma een databaseverbinding aanvraagt, krijgt de toewijzing van bestaande niet-actieve databaseverbindingen prioriteit in plaats van het maken van een nieuwe verbinding. Nadat het programma klaar is met het gebruik van de databaseverbinding, wordt de verbinding hersteld ter voorbereiding op verder gebruik, in plaats van eenvoudigweg te worden afgesloten.

Voor een betere illustratie bevat dit artikel een stukje voorbeeldcode dat java als voorbeeld gebruikt. Zie Apache Common DBCP voor meer informatie.

Toegang tot databases met behulp van permanente verbindingen (aanbevolen)

Het concept van permanente verbindingen is vergelijkbaar met het concept van verbindingspooling. Voor het vervangen van korte verbindingen door permanente verbindingen zijn slechts kleine wijzigingen in de code vereist, maar dit heeft een groot effect op het verbeteren van de prestaties in veel typische toepassingsscenario's.

Toegang tot databases met behulp van een mechanisme voor wachten en opnieuw proberen met korte verbindingen

Als u resourcebeperkingen hebt, raden we u ten zeerste aan databasepooling of permanente verbindingen te gebruiken voor toegang tot databases. Als uw toepassing korte verbindingen gebruikt en verbindingsfouten ervaart wanneer u de bovengrens voor het aantal gelijktijdige verbindingen nadert, kunt u het mechanisme voor wachten en opnieuw proberen proberen. U kunt een geschikte wachttijd instellen, met een kortere wachttijd na de eerste poging. Daarna kunt u meerdere keren wachten op gebeurtenissen.

Verificatiemechanismen configureren in clients om de effectiviteit van permanente verbindingen te bevestigen

De server configureert een time-outmechanisme om een verbinding te sluiten die al enige tijd inactief is om resources vrij te maken. Wanneer de client de database opnieuw gebruikt, komt dit overeen met het maken van een nieuwe verbindingsaanvraag tussen de client en de server. Configureer een verificatiemechanisme op de client om de effectiviteit van verbindingen te garanderen tijdens het gebruik ervan. Zoals in het volgende voorbeeld wordt weergegeven, kunt u Tomcat JDBC-verbindingspooling gebruiken om dit verificatiemechanisme te configureren.

Door de parameter TestOnBorrow in te stellen, controleert de verbindingsgroep automatisch de effectiviteit van beschikbare niet-actieve verbindingen wanneer er een nieuwe aanvraag is. Als een dergelijke verbinding effectief is, wordt de verbinding ingetrokken door de rechtstreeks geretourneerde verbindingsgroep. De verbindingsgroep maakt vervolgens een nieuwe effectieve verbinding en retourneert deze. Dit proces zorgt ervoor dat de database efficiënt wordt gebruikt.

Zie het officiële inleidingsdocument voor de JDBC-verbindingsgroep voormeer informatie over de specifieke instellingen. U moet voornamelijk de volgende drie parameters instellen: TestOnBorrow (ingesteld op true), ValidationQuery (ingesteld op SELECT 1) en ValidationQueryTimeout (ingesteld op 1). De specifieke voorbeeldcode wordt hieronder weergegeven:

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) {}
          }
      }
  }

Volgende stappen

• Verbindingsproblemen met Azure Databases for MySQL oplossen