Átmeneti hibák kezelése, és hatékony csatlakozás az Azure Database for MySQL-hez
A következőkre vonatkozik:
Azure Database for MySQL – Önálló kiszolgáló
Fontos
Az önálló Azure Database for MySQL-kiszolgáló a kivonási útvonalon van. Határozottan javasoljuk, hogy frissítsen rugalmas Azure Database for MySQL-kiszolgálóra. További információ a rugalmas Azure Database for MySQL-kiszolgálóra való migrálásról: Mi történik az önálló Azure Database for MySQL-kiszolgálóval?
Ez a cikk azt ismerteti, hogyan kezelheti az átmeneti hibákat, és hogyan csatlakozhat hatékonyan az Azure Database for MySQL-hez.
Átmeneti hibák
Az átmeneti hiba, más néven átmeneti hiba egy olyan hiba, amely megoldja magát. Ezek a hibák általában az elvetett adatbázis-kiszolgálóval létesített kapcsolatként nyilvánulnak meg. A kiszolgálóval létesített új kapcsolatok sem nyithatóak meg. Átmeneti hibák fordulhatnak elő például hardver- vagy hálózati hiba esetén. Egy másik ok lehet a PaaS-szolgáltatás új verziója, amelyet bevezetnek. A legtöbb ilyen eseményt a rendszer kevesebb mint 60 másodperc alatt automatikusan enyhíti. A felhőbeli alkalmazások tervezésének és fejlesztésének ajánlott eljárása az átmeneti hibákra való várakozás. Tegyük fel, hogy bármelyik összetevőben bármikor előfordulhatnak, és a megfelelő logikával rendelkeznek az ilyen helyzetek kezeléséhez.
Átmeneti hibák kezelése
Az átmeneti hibákat újrapróbálkozási logikával kell kezelni. Megfontolandó helyzetek:
- Hiba történik egy kapcsolat megnyitásakor
- A kiszolgálóoldalon megszakad egy tétlen kapcsolat. Ha parancsot próbál kiadni, az nem hajtható végre
- A parancsot jelenleg végrehajtó aktív kapcsolat megszakad.
Az első és a második eset meglehetősen egyenesen előre kezelhető. Próbálja meg újra megnyitni a kapcsolatot. Ha sikerül, az átmeneti hibát a rendszer enyhítette. Ismét használhatja az Azure Database for MySQL-t. Javasoljuk, hogy várjon a kapcsolat újrapróbálkozása előtt. Vissza, ha a kezdeti újrapróbálkozási művelet sikertelen. Így a rendszer az összes rendelkezésre álló erőforrást felhasználhatja a hibahelyzet leküzdésére. A követendő minta a következő:
- Várjon 5 másodpercet az első újrapróbálkozás előtt.
- Minden következő újrapróbálkozáshoz a várakozás exponenciálisan, akár 60 másodpercig is növelhető.
- Adja meg az újrapróbálkozések maximális számát, amikor az alkalmazás sikertelennek tekinti a műveletet.
Ha egy aktív tranzakcióval való kapcsolat meghiúsul, nehezebb helyesen kezelni a helyreállítást. Két eset van: Ha a tranzakció írásvédett volt, biztonságosan újra megnyithatja a kapcsolatot, és újrapróbálhatja a tranzakciót. Ha azonban a tranzakció az adatbázisba is íródott, meg kell állapítania, hogy a tranzakció vissza lett-e állítva, vagy sikeres volt-e az átmeneti hiba bekövetkezése előtt. Ebben az esetben előfordulhat, hogy nem kapta meg a véglegesítés nyugtázását az adatbázis-kiszolgálótól.
Ennek egyik módja egy egyedi azonosító létrehozása az ügyfélen, amelyet az összes újrapróbálkozáshoz használnak. Ezt az egyedi azonosítót a tranzakció részeként adja át a kiszolgálónak, és egy egyedi korlátozással rendelkező oszlopban tárolja. Így biztonságosan újrapróbálhatja a tranzakciót. Sikeres lesz, ha az előző tranzakció vissza lett állítva, és az ügyfél által létrehozott egyedi azonosító még nem létezik a rendszerben. Nem jelenik meg ismétlődő kulcssértés, ha az egyedi azonosítót korábban tárolták, mert az előző tranzakció sikeresen befejeződött.
Amikor a program harmadik féltől származó köztes szoftveren keresztül kommunikál az Azure Database for MySQL-vel, kérdezze meg a szállítót, hogy a köztes szoftver tartalmaz-e újrapróbálkozási logikát átmeneti hibák esetén.
Győződjön meg arról, hogy teszteli az újrapróbálkozás logikáját. Próbálja meg például végrehajtani a kódot az Azure Database for MySQL-kiszolgáló számítási erőforrásainak fel- vagy leskálázása közben. Az alkalmazásnak probléma nélkül kell kezelnie a művelet során fellépő rövid állásidőt.
Csatlakozás hatékonyan az Azure Database for MySQL-be
Az adatbázis-kapcsolatok korlátozott erőforrást jelentenek, ezért a kapcsolatkészletezés hatékony használata az Azure Database for MySQL eléréséhez optimalizálja a teljesítményt. Az alábbi szakasz bemutatja, hogyan használhat kapcsolatkészletezést vagy állandó kapcsolatokat az Azure Database for MySQL hatékonyabb eléréséhez.
Adatbázisok elérése kapcsolatkészletezéssel (ajánlott)
Az adatbázis-kapcsolatok kezelése jelentős hatással lehet az alkalmazás egészének teljesítményére. Az alkalmazás teljesítményének optimalizálása érdekében a cél az, hogy csökkentse a kapcsolatok létrehozásának és a kapcsolatok kulcskód-elérési utakon való létrehozásának idejét. Erősen ajánlott adatbázis-kapcsolatkészletezést vagy állandó kapcsolatokat használni az Azure Database for MySQL-hez való csatlakozáshoz. Az adatbázis-kapcsolatkészletezés kezeli az adatbázis-kapcsolatok létrehozását, kezelését és lefoglalását. Amikor egy program adatbázis-kapcsolatot kér, az új kapcsolat létrehozása helyett a meglévő inaktív adatbázis-kapcsolatok lefoglalását rangsorolja. Miután a program befejezte az adatbázis-kapcsolat használatát, a kapcsolat helyreáll a további használatra való felkészülés során, ahelyett, hogy egyszerűen bezárul.
A jobb ábra érdekében ez a cikk egy mintakódot tartalmaz, amely a JAVA-t használja példaként. További információ: Apache common DBCP.
Megjegyzés:
A kiszolgáló egy időtúllépési mechanizmust konfigurál egy olyan kapcsolat bezárásához, amely egy ideje inaktív állapotban van az erőforrások felszabadításához. Mindenképpen állítsa be az ellenőrző rendszert az állandó kapcsolatok hatékonyságának biztosítása érdekében, amikor használja őket. További információ: Ellenőrző rendszerek konfigurálása az ügyféloldalon az állandó kapcsolatok hatékonyságának biztosítása érdekében.
Adatbázisok elérése állandó kapcsolatok használatával (ajánlott)
Az állandó kapcsolatok fogalma hasonló a kapcsolatkészletezéshez. A rövid kapcsolatok állandó kapcsolatokra való lecserélése csak kisebb módosításokat igényel a kódban, de jelentős hatással van a teljesítmény javítására számos tipikus alkalmazásforgatókönyvben.
Adatbázisok elérése várakozási és újrapróbálkozási mechanizmussal, rövid kapcsolatokkal
Ha erőforráskorlátokkal rendelkezik, javasoljuk, hogy adatbáziskészletezést vagy állandó kapcsolatokat használjon az adatbázisok eléréséhez. Ha az alkalmazás rövid kapcsolatokat használ, és csatlakozási hibákat tapasztal, amikor eléri az egyidejű kapcsolatok számának felső korlátját, kipróbálhatja a várakozási és újrapróbálkozási mechanizmust. Beállíthatja a megfelelő várakozási időt, az első kísérlet után rövidebb várakozási idővel. Ezt követően többször is megpróbálhat eseményekre várni.
Az ügyfelek ellenőrzési mechanizmusainak konfigurálása az állandó kapcsolatok hatékonyságának megerősítéséhez
A kiszolgáló egy időtúllépési mechanizmust konfigurál egy olyan kapcsolat bezárásához, amely egy ideje tétlen állapotban van az erőforrások felszabadításához. Amikor az ügyfél ismét hozzáfér az adatbázishoz, az egyenértékű azzal, hogy új kapcsolatkérést hoz létre az ügyfél és a kiszolgáló között. A kapcsolatok hatékonyságának biztosítása érdekében a használatuk során konfiguráljon egy ellenőrzési mechanizmust az ügyfélen. Az alábbi példában látható módon a Tomcat JDBC-kapcsolatkészletezéssel konfigurálhatja ezt az ellenőrzési mechanizmust.
A TestOnBorrow paraméter beállításával új kérés esetén a kapcsolatkészlet automatikusan ellenőrzi az elérhető tétlen kapcsolatok hatékonyságát. Ha egy ilyen kapcsolat érvényes, a közvetlenül visszaadott, ellenkező esetben a kapcsolatkészlet visszavonja a kapcsolatot. A kapcsolatkészlet ezután létrehoz egy új hatékony kapcsolatot, és visszaadja azt. Ez a folyamat biztosítja az adatbázis hatékony elérését.
A konkrét beállításokról a JDBC kapcsolatkészlet hivatalos bevezető dokumentumában olvashat. Elsősorban a következő három paramétert kell beállítania: TestOnBorrow (igaz értékre), ValidationQuery (Standard kiadás LECT 1 értékre) és ValidationQueryTimeout (1 értékre). Az adott mintakód alább látható:
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) {}
}
}
}