Átmeneti csatlakozási hibák kezelése rugalmas Azure Database for PostgreSQL-kiszolgálón

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

Átmeneti hibák

Az átmeneti hiba, más néven átmeneti hiba egy olyan hiba, amely megoldja önmagát. Leggyakrabban ezek a hibák abban nyilvánulnak meg, hogy megszakad az adatbázis-kiszolgálóhoz való kapcsolat. 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 rendszer kevesebb mint 60 másodperc alatt automatikusan mérsékli a legtöbb ilyen eseményt. 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 egy inaktív kapcsolat bontásra kerül. 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 kezelése meglehetősen egyszerű. Próbálja meg újra megnyitni a kapcsolatot. Miután a rendszer enyhíti az átmeneti hibát, sikeresen csatlakozhat. Ú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. Álljon le, ha a kezdeti újrapróbálkozások sikertelenek. Í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ó csak olvasható 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, 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 jelez ismétlődő kulcssértést, 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 bekövetkező rövid leállást.

Mi az Azure Database for PostgreSQL?