Átmeneti csatlakozási hibák kezelése az Azure Database for PostgreSQL - Rugalmas kiszolgáló esetében

A következőkre vonatkozik: Azure Database for PostgreSQL – Rugalmas kiszolgáló

Ez a cikk azt ismerteti, hogyan kezelhetők a rugalmas Azure Database for PostgreSQL-kiszolgálóhoz csatlakozó átmeneti hibák.

Á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. Amikor megpróbál kiadni egy parancsot, 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. Újra használhatja rugalmas Azure Database for PostgreSQL-kiszolgálópéldányá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 növelje a várakozást exponenciálisan, akár 60 másodpercig.
• 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 a rugalmas Azure Database for PostgreSQL-kiszolgálóval, 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.

Mindenképpen tesztelje az újrapróbálkozás logikáját. Próbálja meg például végrehajtani a kódot a rugalmas Azure Database for PostgreSQL-kiszolgálópéldány 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.