Zpracování přechodných chyb a efektivní připojení ke službě Azure Database for MySQL

PLATÍ PRO: Azure Database for MySQL – Jeden server

Tento článek popisuje, jak zpracovat přechodné chyby a efektivně se připojit k Azure Database for MySQL.

Přechodné chyby

Přechodná chyba, označované také jako přechodná chyba, je chyba, která se vyřeší sama. Obvykle se tyto chyby manifestují jako připojení k databázovému serveru, který se zahodí. Není také možné otevřít nová připojení k serveru. K přechodným chybám může dojít například v případě selhání hardwaru nebo sítě. Dalším důvodem může být nová verze služby PaaS, která se zasažuje. Většinu těchto událostí systém automaticky zmírní za méně než 60 sekund. Osvědčeným postupem pro navrhování a vývoj aplikací v cloudu je očekávat přechodné chyby. Předpokládejme, že k těmto situacím může dojít kdykoli v jakékoli komponentě a mít odpovídající logiku pro zpracování těchto situací.

Zpracování přechodných chyb

Přechodné chyby by se měly zpracovat pomocí logiky opakování. Situace, které je třeba zvážit:

  • Při pokusu o otevření připojení dojde k chybě
  • Nečinné připojení se na straně serveru zahodí. Když se pokusíte vydat příkaz, není možné ho spustit.
  • Aktivní připojení, které aktuálně spouští příkaz, se zahodí.

První a druhý případ je poměrně jednoduchý na zpracování. Zkuste připojení otevřít znovu. Pokud uspějete, systém tuto přechodnou chybu zmírní. Můžete znovu použít Azure Database for MySQL. Před opakováním pokusu o připojení doporučujeme počkat. Pokud počáteční opakování selže, uraťte se. Systém tak může k překonání chybové situace využít všechny dostupné prostředky. Dobrým vzorem, který je třeba dodržovat, je:

  • Před prvním opakováním počkejte 5 sekund.
  • U každého následujícího opakování zvyšte čekání exponenciálně až na 60 sekund.
  • Nastavte maximální počet opakování, kdy vaše aplikace považuje operaci za neúspěšnou.

Pokud připojení k aktivní transakci selže, je obtížnější správně zpracovat obnovení. Existují dva případy: Pokud transakce byla jen pro čtení ze povahy, je bezpečné znovu otevřít připojení a opakovat transakci. Pokud však transakce byla také zápisu do databáze, musíte určit, zda transakce byla vrácena zpět, nebo zda byla úspěšná před přechodnou chybu došlo. V takovém případě jste možná od databázového serveru jen neobdržíte potvrzení o potvrzení.

Jedním ze způsobem, jak to udělat, je vygenerovat jedinečné ID na klientovi, které se používá pro všechna opakování. Toto jedinečné ID předáte jako součást transakce serveru a uložíte ho do sloupce s jedinečným omezením. Tímto způsobem můžete transakci bezpečně zopakovat. Pokud byla předchozí transakce vrácena zpět a jedinečné ID generované klientem ještě v systému neexistuje, bude úspěšné. Pokud bylo jedinečné ID dříve uloženo, protože předchozí transakce byla úspěšně dokončena, selže to značí porušení duplicitního klíče.

Když váš program komunikuje s Azure Database for MySQL prostřednictvím middlewaru třetí strany, zeptejte se dodavatele, jestli middleware obsahuje logiku opakování přechodných chyb.

Nezapomeňte logiku opakování otestovat. Zkuste například spustit kód při škálování na více nebo více výpočetních prostředků vašeho Azure Database for MySQL serveru. Vaše aplikace by měla zvládnout krátké výpadky, ke kterým dojde během této operace bez jakýchkoli problémů.

Připojení efektivní Azure Database for MySQL

Připojení k databázi jsou omezeným zdrojem, takže efektivní využití sdružování připojení pro přístup k Azure Database for MySQL optimalizuje výkon. Následující část vysvětluje, jak pomocí sdružování připojení nebo trvalých připojení efektivněji přistupovat k Azure Database for MySQL.

Správa databázových připojení může mít významný dopad na výkon aplikace jako celku. Pokud chcete optimalizovat výkon aplikace, měli byste snížit počet navazování připojení a čas navazování připojení v klíčových cestách kódu. Důrazně doporučujeme pro připojení k databázi použít sdružování připojení k databázi nebo trvalá Azure Database for MySQL. Sdružování připojení k databázi zajišťuje vytváření, správu a přidělování databázových připojení. Když program požádá o připojení k databázi, upřednostňuje přidělení existujících nečinných připojení k databázi, nikoli vytvoření nového připojení. Po dokončení programu pomocí připojení k databázi se připojení obnoví v rámci přípravy na další použití, místo aby se jednoduše ukončilo.

Pro lepší ilustraci tento článek obsahuje ukázkovou část kódu, která jako příklad používá javu. Další informace najdete v tématu Běžné připojení DBCP Apache.

Poznámka

Server nakonfiguruje mechanismus časového limitu pro ukončení připojení, které bylo po nějakou dobu v nečinnosti, aby se prostředky uchytly. Nezapomeňte nastavit ověřovací systém, abyste zajistili efektivitu trvalých připojení, když je používáte. Další informace najdete v tématu Konfigurace ověřovacích systémů na straně klienta, abyste zajistili efektivitu trvalých připojení.

Koncept trvalých připojení je podobný konceptu sdružování připojení. Nahrazení krátkých připojení trvalými připojeními vyžaduje pouze drobné změny kódu, ale má velký vliv na zlepšení výkonu v mnoha typických scénářích aplikací.

Přístup k databázím pomocí mechanismu čekání a opakování s krátkými připojeními

Pokud máte omezení prostředků, důrazně doporučujeme pro přístup k databázím používat sdružování databází nebo trvalá připojení. Pokud vaše aplikace používá krátká připojení a dochází k selháním připojení, když se blížíte k hornímu limitu počtu souběžných připojení, můžete vyzkoušet mechanismus čekání a opakování. Můžete nastavit vhodnou dobu čekání s kratší čekaní po prvním pokusu. Pak můžete zkusit několikrát čekat na události.

Konfigurace ověřovacích mechanismů v klientech pro potvrzení efektivity trvalých připojení

Server nakonfiguruje mechanismus časového limitu pro ukončení připojení, které je nějakou dobu v nečinnosti, aby se prostředky uchytly. Když klient znovu přistupuje k databázi, je to ekvivalentem vytvoření nové žádosti o připojení mezi klientem a serverem. Pokud chcete zajistit efektivitu připojení během procesu jejich používání, nakonfigurujte na klientovi ověřovací mechanismus. Jak je znázorněno v následujícím příkladu, tento ověřovací mechanismus můžete nakonfigurovat pomocí sdružování připojení Tomcat JDBC.

Když nastavíte parametr TestOnBorrow a dojde k novému požadavku, fond připojení automaticky ověří efektivitu všech dostupných nečinných připojení. Pokud je takové připojení efektivní, vrátí se přímo, jinak fond připojení zruší. Fond připojení pak vytvoří nové efektivní připojení a vrátí ho. Tento proces zajišťuje efektivní přístup k databázi.

Informace o konkrétních nastaveních najdete v oficiálním úvodním dokumentu fondu připojení JDBC. Musíte nastavit hlavně následující tři parametry: TestOnBorrow (nastaveno na true), ValidationQuery (nastaveno na SELECT 1) a ValidationQueryTimeout (nastaveno na 1). Konkrétní vzorový kód je zobrazený níže:

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

Další kroky