Zpracování přechodných chyb připojení pro flexibilní server Azure Database for PostgreSQL

  • Článek

PLATÍ PRO: Flexibilní server Azure Database for PostgreSQL

Tento článek popisuje, jak zpracovat přechodné chyby při připojování k flexibilnímu serveru Azure Database for PostgreSQL.

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řípady jsou poměrně rovné pro zpracování. Zkuste připojení znovu otevřít. Pokud budete úspěšní, systém zmírní přechodnou chybu. Instanci flexibilního serveru Azure Database for PostgreSQL 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ě počkejte až na 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 klient vygenerovaný jedinečný IDENTIFIKÁTOR ještě v systému neexistuje, bude ú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 s flexibilním serverem Azure Database for PostgreSQL prostřednictvím middlewaru třetích stran, požádejte dodavatele, jestli middleware obsahuje logiku opakování pro přechodné chyby.

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ů instance flexibilního serveru Azure Database for PostgreSQL. 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ů.