Udostępnij za pośrednictwem

Obsługa przejściowych błędów łączności dla usługi Azure Database for PostgreSQL — serwer elastyczny

  • Artykuł

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

W tym artykule opisano sposób obsługi błędów przejściowych łączących się z serwerem elastycznym usługi Azure Database for PostgreSQL.

Błędy przejściowe

Błąd przejściowy, znany również jako błąd przejściowy, jest błędem, który sam się rozwiąże. Najczęściej te błędy manifestują się jako połączenie z serwerem bazy danych, który jest porzucony. Nie można również otworzyć nowych połączeń z serwerem. Błędy przejściowe mogą wystąpić na przykład w przypadku awarii sprzętu lub sieci. Innym powodem może być nowa wersja usługi PaaS, która jest wdrażana. Większość z tych zdarzeń jest automatycznie ograniczana przez system w mniej niż 60 sekund. Najlepszym rozwiązaniem w zakresie projektowania i opracowywania aplikacji w chmurze jest oczekiwanie na błędy przejściowe. Załóżmy, że mogą one wystąpić w dowolnym składniku w dowolnym momencie i mieć odpowiednią logikę do obsługi tych sytuacji.

Obsługa błędów przejściowych

Błędy przejściowe powinny być obsługiwane przy użyciu logiki ponawiania prób. Sytuacje, które należy rozważyć:

  • Podczas próby otwarcia połączenia występuje błąd
  • Bezczynne połączenie jest porzucane po stronie serwera. Podczas próby wydania polecenia nie można go wykonać
  • Aktywne połączenie, które aktualnie wykonuje polecenie, jest porzucane.

Pierwsze i drugie przypadki są dość proste do obsługi. Spróbuj ponownie otworzyć połączenie. Po pomyślnym zakończeniu błąd przejściowy został skorygowany przez system. Możesz ponownie użyć wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL. Zalecamy, aby przed ponowić próbę nawiązania połączenia. Wycofaj się, jeśli początkowe próby nie ponawiają się. Dzięki temu system może użyć wszystkich dostępnych zasobów, aby przezwyciężyć sytuację z błędem. Dobrym wzorcem do naśladowania jest:

  • Poczekaj 5 sekund przed pierwszą ponowną próbą.
  • Dla każdego z poniższych ponownych prób zwiększ wykładniczo czas oczekiwania do 60 sekund.
  • Ustaw maksymalną liczbę ponownych prób, w którym aplikacja uzna, że operacja nie powiodła się.

Jeśli połączenie z aktywną transakcją zakończy się niepowodzeniem, trudniej jest poprawnie obsłużyć odzyskiwanie. Istnieją dwa przypadki: jeśli transakcja była tylko do odczytu, można bezpiecznie ponownie otworzyć połączenie i ponowić próbę transakcji. Jeśli jednak transakcja była również zapisywana w bazie danych, musisz określić, czy transakcja została wycofana, czy zakończyła się pomyślnie, zanim wystąpi błąd przejściowy. W takim przypadku po prostu nie otrzymano potwierdzenia zatwierdzenia z serwera bazy danych.

Jednym ze sposobów wykonania tej czynności jest wygenerowanie unikatowego identyfikatora na kliencie, który jest używany dla wszystkich ponownych prób. Ten unikatowy identyfikator należy przekazać jako część transakcji do serwera i zapisać go w kolumnie z unikatowym ograniczeniem. W ten sposób można bezpiecznie ponowić próbę transakcji. Powiedzie się, jeśli poprzednia transakcja została wycofana, a w systemie nie istnieje jeszcze wygenerowany unikatowy identyfikator klienta. Zakończy się to niepowodzeniem wskazującym naruszenie zduplikowanego klucza, jeśli unikatowy identyfikator został wcześniej zapisany, ponieważ poprzednia transakcja została pomyślnie ukończona.

Gdy program komunikuje się z elastycznym serwerem usługi Azure Database for PostgreSQL za pośrednictwem oprogramowania pośredniczącego innej firmy, zapytaj dostawcę, czy oprogramowanie pośredniczące zawiera logikę ponawiania prób dla błędów przejściowych.

Pamiętaj, aby przetestować logikę ponawiania prób. Na przykład spróbuj wykonać kod podczas skalowania w górę lub w dół zasobów obliczeniowych wystąpienia elastycznego serwera usługi Azure Database for PostgreSQL. Aplikacja powinna obsługiwać krótki przestój, który występuje podczas tej operacji bez żadnych problemów.