Uruchamiasz krytyczne obciążenie OLTP na pojedynczej bazie danych Azure SQL Database (Business Critical). Potrzebujesz automatycznego przełączania awaryjnego między regionami z minimalnymi zmianami w parametrach połączenia i chcesz, aby zapytania raportujące były domyślnie uruchamiane na serwerze pomocniczym. Które dwie konfiguracje należy zaimplementować?

Utworzenie grupy automatycznego przełączania awaryjnego między dwoma serwerami Azure SQL Database w sparowanych regionach i dodanie bazy danych jest kluczowe, ponieważ zapewnia automatyczne przełączanie awaryjne między regionami z minimalnymi zmianami w parametrach połączenia, co jest wymagane dla krytycznych obciążeń OLTP. Grupa przełączania awaryjnego automatyzuje proces, używając jednego punktu końcowego dla aplikacji. Skonfigurowanie klientów raportujących do łączenia się z punktem końcowym odbiornika tylko do odczytu grupy przełączania awaryjnego jest konieczne, aby zapytania raportujące były domyślnie uruchamiane na serwerze pomocniczym, co odciąża serwer podstawowy i spełnia wymaganie. Pozostałe opcje są nieprawidłowe, ponieważ: Aktywna replikacja geograficzna wymaga ręcznego przełączania awaryjnego i zmian w parametrach połączenia. Redundancja strefowa chroni przed awariami w obrębie regionu, a nie między regionami, a replika odczytu-skalowania serwera podstawowego nie jest serwerem pomocniczym w innym regionie. Azure Front Door nie jest przeznaczony do routingu ruchu TDS dla baz danych SQL w kontekście automatycznego przełączania awaryjnego.