Zpracování přechodných chyb a efektivní připojení ke službě Azure Database for MySQL
PLATÍ PRO:
Jednoúčelový server Azure Database for MySQL
Důležité
Jednoúčelový server Azure Database for MySQL je na cestě vyřazení. Důrazně doporučujeme upgradovat na flexibilní server Azure Database for MySQL. Další informace o migraci na flexibilní server Azure Database for MySQL najdete v tématu Co se děje s jednoúčelovým serverem Azure Database for MySQL?
Tento článek popisuje, jak zpracovávat přechodné chyby a efektivně se připojit ke službě Azure Database for MySQL.
Přechodné chyby
Přechodná chyba, označovaná také jako přechodná chyba, je chyba, která se vyřeší sama. Většina těchto chyb se obvykle projevuje jako připojení k databázovému serveru, který se zahodí. Nová připojení k serveru se také nedají otevřít. K přechodným chybám může dojít například v případě, že dojde k selhání hardwaru nebo sítě. Dalším důvodem může být nová verze služby PaaS, která se zavádí. Většina těchto událostí je systémem automaticky zmírněná za méně než 60 sekund. Osvědčeným postupem při návrhu a vývoji aplikací v cloudu je očekávat přechodné chyby. Předpokládejme, že k nim může dojít v libovolné komponentě kdykoli a aby byla k těmto situacím zavedená příslušná logika.
Zpracování přechodných chyb
Přechodné chyby by se měly zpracovat pomocí logiky opakování. Situace, které je potřeba zvážit:
- Při pokusu o otevření připojení dojde k chybě.
- Na straně serveru se přeruší nečinné připojení. Když se pokusíte vydat příkaz, nejde ho spustit
- Aktivní připojení, které právě spouští příkaz, se zahodí.
První a druhý případ jsou poměrně rovné pro zpracování. Zkuste připojení znovu otevřít. Pokud budete úspěšní, systém zmírní přechodnou chybu. Službu Azure Database for MySQL můžete znovu použít. Doporučujeme počkat před opakováním připojení. Pokud se počáteční opakování nezdaří, vraťte se zpět. Tímto způsobem může systém používat všechny prostředky, které jsou k dispozici k vyřešení chybové situace. Dobrým vzorem, který je třeba dodržovat, je:
- Počkejte 5 sekund před prvním opakováním.
- U každého následujícího opakování zvyšte exponenciální nárůst čekání až o 60 sekund.
- Nastavte maximální počet opakování v okamžiku, kdy vaše aplikace považuje operaci za neúspěšnou.
Pokud připojení s aktivní transakcí selže, je obtížnější správně zpracovat obnovení. Existují dva případy: Pokud transakce byla jen pro čtení v přírodě, je bezpečné znovu otevřít připojení a opakovat transakci. Pokud se však transakce také zapisovala do databáze, musíte určit, zda byla transakce vrácena zpět, nebo pokud byla úspěšná před přechodnou chybou. V takovém případě jste pravděpodobně neobdrželi potvrzení potvrzení z databázového serveru.
Jedním ze způsobů, jak to udělat, je vygenerovat jedinečné ID klienta, který se používá pro všechny opakování. Toto jedinečné ID předáte jako součást transakce serveru a uložíte ho ve sloupci 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 v systému ještě neexistuje jedinečné ID vygenerované klientem, proběhne úspěšně. Pokud bylo dříve uloženo jedinečné ID, protože předchozí transakce byla úspěšně dokončena, dojde k selhání indikující porušení duplicitního klíče.
Když váš program komunikuje se službou Azure Database for MySQL prostřednictvím middlewaru třetí strany, požádejte dodavatele, jestli middleware obsahuje logiku opakování přechodných chyb.
Nezapomeňte otestovat logiku opakování. Zkuste například spustit kód při vertikálním navýšení nebo snížení kapacity výpočetních prostředků serveru Azure Database for MySQL. Aplikace by měla zpracovávat krátké výpadky, ke kterým dochází během této operace bez jakýchkoli problémů.
efektivní Připojení do služby Azure Database for MySQL
Připojení k databázi jsou omezené prostředky, takže efektivní využití sdružování připojení pro přístup ke službě Azure Database for MySQL optimalizuje výkon. Následující část vysvětluje, jak používat sdružování připojení nebo trvalá připojení k efektivnějšímu přístupu ke službě Azure Database for MySQL.
Přístup k databázím pomocí sdružování připojení (doporučeno)
Správa databázových připojení může mít významný vliv na výkon aplikace jako celku. Pokud chcete optimalizovat výkon vaší aplikace, měli byste snížit počet připojení a čas vytvoření připojení v klíčových cestách kódu. Pro připojení ke službě Azure Database for MySQL důrazně doporučujeme používat sdružování připojení k databázi nebo trvalá připojení. Sdružování připojení k databázi zpracovává 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í stávajících nečinných databázových připojení místo vytvoření nového připojení. Jakmile program dokončí používání připojení k databázi, připojení se obnoví při přípravě na další použití, a nikoli při pouhém zavření.
Pro lepší ilustraci poskytuje tento článek část vzorového kódu , který jako příklad používá javu. Další informace najdete v tématu Apache common DBCP.
Poznámka:
Server nakonfiguruje mechanismus časového limitu pro zavření připojení, které bylo v nečinném stavu po určitou dobu, aby uvolnilo prostředky. Nezapomeňte nastavit ověřovací systém, aby se zajistila efektivita trvalých připojení při jejich používání. Další informace najdete v tématu Konfigurace ověřovacích systémů na straně klienta, abyste zajistili efektivitu trvalých připojení.
Přístup k databázím pomocí trvalých připojení (doporučeno)
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 menší změny kódu, ale má velký vliv na zlepšení výkonu v mnoha typických scénářích aplikace.
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í připojení při dosažení horního limitu počtu souběžných připojení, můžete zkusit počkat a opakovat mechanismus. Můžete nastavit odpovídající dobu čekání s kratší dobou čekání po prvním pokusu. Potom můžete zkusit čekat na události několikrát.
Konfigurace ověřovacích mechanismů v klientech pro potvrzení účinnosti trvalých připojení
Server nakonfiguruje mechanismus časového limitu pro zavření připojení, které je v nečinném stavu po určitou dobu, aby se uvolnily prostředky. Když klient znovu přistupuje k databázi, je ekvivalentem vytvoření nové žádosti o připojení mezi klientem a serverem. Pokud chcete zajistit efektivitu připojení během procesu jejich použití, nakonfigurujte na klientovi ověřovací mechanismus. Jak je znázorněno v následujícím příkladu, můžete ke konfiguraci tohoto mechanismu ověřování použít sdružování připojení Tomcat JDBC.
Nastavením parametru TestOnBorrow v případě nového požadavku fond připojení automaticky ověří účinnost všech dostupných nečinných připojení. Pokud je takové připojení účinné, jeho přímý vrácení v opačném případě fond připojení stáhne připojení. 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. Hlavně je potřeba nastavit následující tři parametry: TestOnBorrow (nastaveno na true), ValidationQuery (nastavené na SELECT 1) a ValidationQueryTimeout (nastaveno na 1). Konkrétní vzorový kód je uvedený 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) {}
}
}
}