Aktywna replikacja geograficzna

Dotyczy: baza danych Azure SQL

Aktywna replikacja geograficzna to funkcja, która umożliwia tworzenie stale synchronizowanej pomocniczej pomocniczej bazy danych z możliwością odczytu dla podstawowej bazy danych. Pomocnicza baza danych z możliwością odczytu może znajdować się w tym samym regionie świadczenia usługi Azure co podstawowy lub, częściej, w innym regionie. Ta pomocnicza baza danych z możliwością odczytu jest również nazywana pomocniczą lub geograficzną repliką geograficzną.

Aktywna replikacja geograficzna jest zaprojektowana jako rozwiązanie zapewniające ciągłość działalności biznesowej, które umożliwia szybkie odzyskiwanie po awarii poszczególnych baz danych w przypadku awarii regionalnej lub awarii na dużą skalę. Po skonfigurowaniu replikacji geograficznej możesz zainicjować przejście geograficzne w tryb failover do pomocniczego obszaru geograficznego w innym regionie świadczenia usługi Azure. Geograficzne przejście w tryb failover jest inicjowane programowo przez aplikację lub ręcznie przez użytkownika.

Uwaga

W przypadku geograficznego trybu failover wystąpień SQL Managed Instance użyj grup automatycznego trybu failover. Aby uzyskać więcej informacji, porównaj replikację geograficzną z grupami trybu failover. Aktywna replikacja geograficzna nie jest obsługiwana przez Azure SQL Managed Instance.

Uwaga

Aby przeprowadzić migrację baz danych SQL z platformy Azure (Niemcy) przy użyciu aktywnej replikacji geograficznej, zobacz Migrowanie SQL Database przy użyciu aktywnej replikacji geograficznej.

Jeśli aplikacja wymaga stabilnego punktu końcowego połączenia i automatycznej obsługi trybu failover geograficznego oprócz replikacji geograficznej, użyj grup automatycznego trybu failover.

Na poniższym diagramie przedstawiono typową konfigurację aplikacji w chmurze geograficznie nadmiarowej przy użyciu aktywnej replikacji geograficznej.

aktywna replikacja geograficzna

Jeśli z jakiegoś powodu podstawowa baza danych ulegnie awarii, możesz zainicjować przejście geograficzne w tryb failover do dowolnej pomocniczej bazy danych. Po podwyższeniu poziomu pomocniczego do roli podstawowej wszystkie inne pomocnicze pliki pomocnicze są automatycznie połączone z nowym elementem podstawowym.

Replikację geograficzną można zarządzać i inicjować przechodzenie w tryb failover geograficznie przy użyciu następujących elementów:

Aktywna replikacja geograficzna wykorzystuje technologię zawsze włączonej grupy dostępności do asynchronicznego replikowania dziennika transakcji wygenerowanego w repliki podstawowej do wszystkich replik geograficznych. Chociaż w dowolnym momencie pomocnicza baza danych może znajdować się nieco za podstawową bazą danych, dane w pomocniczej bazie danych mają gwarancję spójności transakcyjnej. Innymi słowy zmiany wprowadzone przez niezatwierdzone transakcje nie są widoczne.

Uwaga

Aktywna replikacja geograficzna replikuje zmiany przez przesyłanie strumieniowe dziennika transakcji bazy danych z repliki podstawowej do replik pomocniczych. Nie jest ona powiązana z replikacją transakcyjną, która replikuje zmiany, wykonując polecenia DML (INSERT, UPDATE, DELETE) dla subskrybentów.

Nadmiarowość regionalna zapewniana przez replikację geograficzną umożliwia aplikacjom szybkie odzyskiwanie po trwałej utracie całego regionu platformy Azure lub części regionu, spowodowanych klęskami żywiołowymi, katastrofalnymi błędami ludzkimi lub złośliwymi działaniami. Cel punktu odzyskiwania replikacji geograficznej można znaleźć w temacie Omówienie ciągłości działania.

Na poniższej ilustracji przedstawiono przykład aktywnej replikacji geograficznej skonfigurowanej przy użyciu podstawowej bazy danych w regionie Północno-środkowe stany USA i pomocniczego obszaru geograficznego w regionie Południowo-środkowe stany USA.

relacja replikacji geograficznej

Oprócz odzyskiwania po awarii aktywna replikacja geograficzna może być używana w następujących scenariuszach:

  • Migracja bazy danych: możesz użyć aktywnej replikacji geograficznej, aby przeprowadzić migrację bazy danych z jednego serwera do drugiego z minimalnym przestojem.
  • Uaktualnienia aplikacji: możesz utworzyć dodatkową pomocniczą kopię jako kopię powrotu po awarii podczas uaktualniania aplikacji.

Aby zapewnić pełną ciągłość działalności biznesowej, dodanie nadmiarowości regionalnej bazy danych jest tylko częścią rozwiązania. Odzyskiwanie kompleksowej aplikacji (usługi) po katastrofalnym niepowodzeniu wymaga odzyskania wszystkich składników, które składają się na usługę i wszelkie usługi zależne. Przykłady tych składników obejmują oprogramowanie klienckie (na przykład przeglądarkę z niestandardowym kodem JavaScript), frontony internetowe, magazyn i system DNS. Ważne jest, aby wszystkie składniki były odporne na te same błędy i stały się dostępne w ramach celu czasu odzyskiwania (RTO) aplikacji. W związku z tym należy zidentyfikować wszystkie usługi zależne i zrozumieć gwarancje i możliwości, które zapewniają. Następnie należy podjąć odpowiednie kroki, aby upewnić się, że funkcje usługi podczas pracy w trybie failover usług, od których zależy. Aby uzyskać więcej informacji na temat projektowania rozwiązań do odzyskiwania po awarii, zobacz Projektowanie rozwiązań w chmurze na potrzeby odzyskiwania po awarii przy użyciu aktywnej replikacji geograficznej.

Terminologia i możliwości aktywnej replikacji geograficznej

  • Automatyczna replikacja asynchroniczna

    Dla istniejącej bazy danych można utworzyć tylko pomocniczą bazę danych z replikacją geograficzną. Pomocnicza lokalizacja geograficzna może być tworzona na dowolnym serwerze logicznym innym niż serwer z podstawową bazą danych. Po utworzeniu replika pomocnicza geograficznie jest wypełniana danymi podstawowej bazy danych. Ten proces jest znany jako rozmieszczanie. Po utworzeniu i zainicjowaniu replikacji geograficznej pomocniczej aktualizacje podstawowej bazy danych są automatycznie i asynchronicznie replikowane do repliki pomocniczej geograficznej. Replikacja asynchroniczna oznacza, że transakcje są zatwierdzane w podstawowej bazie danych przed ich replikacją.

  • Repliki pomocnicze z możliwością odczytu

    Aplikacja może uzyskać dostęp do repliki pomocniczej geograficznie w celu wykonywania zapytań tylko do odczytu przy użyciu tych samych lub różnych podmiotów zabezpieczeń używanych do uzyskiwania dostępu do podstawowej bazy danych. Aby uzyskać więcej informacji, zobacz Używanie replik tylko do odczytu do odciążania obciążeń zapytań tylko do odczytu.

    Ważne

    Replikacja geograficzna umożliwia tworzenie replik pomocniczych w tym samym regionie co podstawowy. Tych pomocniczych można użyć do spełnienia scenariuszy skalowania odczytu w poziomie w tym samym regionie. Jednak replika pomocnicza w tym samym regionie nie zapewnia dodatkowej odporności na katastrofalne awarie lub awarie na dużą skalę, dlatego nie jest odpowiednim celem trybu failover na potrzeby odzyskiwania po awarii. Nie gwarantuje również izolacji strefy dostępności. Aby uzyskać izolację strefy dostępności, użyj konfiguracji strefowo nadmiarowej warstwy usług Krytyczne dla działania firmy lub warstwy usługi Premium albo konfiguracji strefowo nadmiarowej warstwy usługi Ogólnego przeznaczenia.

  • Planowana praca geograficzna w trybie failover

    Planowane przejście w tryb failover geograficznie przełącza role podstawowych i pomocniczych baz danych geograficznych po zakończeniu pełnej synchronizacji danych. Planowany tryb failover nie powoduje utraty danych. Czas trwania planowanego przejścia w tryb failover geograficzny zależy od rozmiaru dziennika transakcji na serwerze podstawowym, który musi zostać zsynchronizowany z pomocniczym obszarem geograficznym. Planowane geograficzne przejście w tryb failover jest przeznaczone dla następujących scenariuszy:

    • Wykonywanie próbnego odzyskiwania po awarii w środowisku produkcyjnym, gdy utrata danych jest niedopuszczalna;
    • Przenieś bazę danych do innego regionu;
    • Wróć bazę danych do regionu podstawowego po wyeliminowaniu awarii (znanej jako powrót po awarii).
  • Nieplanowana praca geograficzna w trybie failover

    Nieplanowane lub wymuszone przejście w tryb failover geograficzne natychmiast przełącza pomocnicze geograficznie do roli podstawowej bez żadnej synchronizacji z serwerem podstawowym. Wszystkie transakcje zatwierdzone na serwerze podstawowym, ale nie zostały jeszcze zreplikowane do pomocniczej, zostaną utracone. Ta operacja jest zaprojektowana jako metoda odzyskiwania podczas awarii, gdy podstawowy jest niedostępny, ale dostępność bazy danych musi zostać szybko przywrócona. Gdy oryginalny element podstawowy wróci do trybu online, zostanie automatycznie ponownie połączony, ponownie przekazany przy użyciu bieżących danych podstawowych i stanie się nowym pomocniczym obszarem geograficznym.

    Ważne

    Po zaplanowanym lub nieplanowanym trybie failover punkt końcowy połączenia dla nowych zmian podstawowych, ponieważ nowy serwer podstawowy znajduje się teraz na innym serwerze logicznym.

  • Wiele czytelnych lokalizacji geograficznych

    Dla bazy podstawowej można utworzyć maksymalnie cztery pomocnicze lokalizacje geograficzne. Jeśli istnieje tylko jedna pomocnicza i kończy się niepowodzeniem, aplikacja jest narażona na większe ryzyko do momentu utworzenia nowej pomocniczej. Jeśli istnieje wiele serwerów pomocniczych, aplikacja pozostaje chroniona, nawet jeśli jeden z serwerów pomocniczych ulegnie awarii. Dodatkowe pomocnicze można również użyć do skalowania obciążeń tylko do odczytu.

    Porada

    Jeśli używasz aktywnej replikacji geograficznej do tworzenia globalnie rozproszonej aplikacji i musisz zapewnić dostęp tylko do odczytu do danych w ponad czterech regionach, możesz utworzyć pomocniczą pomocniczą (proces znany jako łańcuch), aby utworzyć dodatkowe repliki geograficzne. Opóźnienie replikacji w łańcuchowych replikach geograficznych może być wyższe niż w przypadku replik geograficznych połączonych bezpośrednio z serwerem podstawowym. Konfigurowanie topologii replikacji geograficznej łańcuchowej jest obsługiwane tylko programowo, a nie z Azure Portal.

  • Replikacja geograficzna baz danych w elastycznej puli

    Każda pomocnicza lokalizacja geograficzna może być pojedynczą bazą danych lub bazą danych w elastycznej puli. Wybór elastycznej puli dla każdej pomocniczej bazy danych z replikacją geograficzną jest oddzielny i nie zależy od konfiguracji żadnej innej repliki w topologii (podstawowej lub pomocniczej). Każda elastyczna pula jest zawarta na jednym serwerze logicznym. Ponieważ nazwy baz danych na serwerze logicznym muszą być unikatowe, wiele serwerów geograficznych tego samego podstawowego nigdy nie może współużytkować elastycznej puli.

  • Sterowany przez użytkownika tryb geo-failover i powrót po awarii

    Pomocniczy obszar geograficzny, który zakończył wstępne rozmieszczanie, można jawnie przełączyć na rolę podstawową (przełączenie w tryb failover) w dowolnym momencie przez aplikację lub użytkownika. Podczas awarii, w której serwer podstawowy jest niedostępny, można użyć tylko nieplanowanego geograficznego trybu failover. Natychmiast podwyższa to poziom pomocniczego obszaru geograficznego, aby był nowym podstawowym elementem. Gdy awaria zostanie złagodzone, system automatycznie utworzy odzyskaną podstawową pomocniczą lokalizację geograficzną i przywróci ją do nowej podstawowej bazy danych. Ze względu na asynchroniczną naturę replikacji geograficznej ostatnie transakcje mogą zostać utracone podczas nieplanowanych trybów geograficznych trybu failover, jeśli podstawowy tryb failover zakończy się niepowodzeniem, zanim te transakcje zostaną zreplikowane do pomocniczego obszaru geograficznego. W przypadku przełączenia w tryb failover serwera podstawowego z wieloma serwerami geograficznymi system automatycznie ponownie konfiguruje relacje replikacji i łączy pozostałe pomocnicze lokalizacje geograficzne z nowo podwyższonym poziomem podstawowym bez konieczności interwencji użytkownika. Po usunięciu awarii, która spowodowała przejście w tryb failover geograficznego, może być pożądane przywrócenie podstawowego regionu pierwotnego. W tym celu należy wywołać planowany tryb geo-failover.

Przygotowanie do przejścia w tryb failover geograficznie

Aby upewnić się, że aplikacja może natychmiast uzyskać dostęp do nowego podstawowego po przejściu w tryb failover geograficznie, sprawdź, czy uwierzytelnianie i dostęp sieciowy dla serwera pomocniczego są prawidłowo skonfigurowane. Aby uzyskać szczegółowe informacje, zobacz SQL Database zabezpieczenia po odzyskiwaniu po awarii. Sprawdź również, czy zasady przechowywania kopii zapasowych w pomocniczej bazie danych są zgodne z zasadami przechowywania kopii zapasowych w podstawowej bazie danych. To ustawienie nie jest częścią bazy danych i nie jest replikowane z serwera podstawowego. Domyślnie pomocniczy obszar geograficzny jest konfigurowany z domyślnym okresem przechowywania pitr przez siedem dni. Aby uzyskać szczegółowe informacje, zobacz SQL Database automatycznych kopii zapasowych.

Ważne

Jeśli baza danych jest członkiem grupy trybu failover, nie można zainicjować jej trybu failover przy użyciu polecenia trybu failover replikacji geograficznej. Użyj polecenia trybu failover dla grupy. Jeśli musisz przejść w tryb failover dla pojedynczej bazy danych, musisz najpierw usunąć ją z grupy trybu failover. Aby uzyskać szczegółowe informacje, zobacz Grupy automatycznego trybu failover .

Konfigurowanie pomocniczego obszaru geograficznego

Zarówno podstawowy, jak i pomocniczy obszar geograficzny muszą mieć tę samą warstwę usługi. Zdecydowanie zaleca się również skonfigurowanie pomocniczego obszaru geograficznego z tą samą nadmiarowością magazynu kopii zapasowych i rozmiarem obliczeniowym (jednostkaMI DTU lub rdzeniami wirtualnymi) jako podstawowym. Jeśli w podstawowym przypadku występuje duże obciążenie zapisu, pomocnicza lokalizacja geograficzna o niższym rozmiarze obliczeniowym może nie być w stanie nadążyć. Spowoduje to opóźnienie replikacji w pomocniczym obszarze geograficznym i może w końcu spowodować niedostępność pomocniczego obszaru geograficznego. Aby wyeliminować te zagrożenia, aktywna replikacja geograficzna zmniejszy (ogranicza) szybkość dziennika transakcji podstawowego, jeśli jest to konieczne, aby umożliwić jego pomocniczym nadrobienie zaległości.

Kolejną konsekwencją niezrównoważonych konfiguracji pomocniczej geograficznej jest to, że po przejściu w tryb failover wydajność aplikacji może cierpieć z powodu niewystarczającej pojemności obliczeniowej nowego podstawowego. W takim przypadku konieczne będzie skalowanie bazy danych w górę, aby mieć wystarczające zasoby, co może zająć dużo czasu i będzie wymagać przejścia w tryb failover o wysokiej dostępności na końcu procesu skalowania w górę, co może spowodować przerwanie obciążeń aplikacji.

Jeśli zdecydujesz się utworzyć pomocniczy obszar geograficzny o niższym rozmiarze obliczeniowym, należy monitorować szybkość operacji we/wy dziennika na serwerze podstawowym w czasie. Pozwala to oszacować minimalny rozmiar obliczeniowy pomocniczego obszaru geograficznego wymaganego do utrzymania obciążenia replikacji. Jeśli na przykład podstawowa baza danych to P6 (1000 DTU), a jej operacje we/wy dziennika są utrzymywane na poziomie 50%, pomocniczy obszar geograficzny musi być co najmniej P4 (500 JEDNOSTEK DTU). Aby pobrać dane we/wy dziennika historycznego, użyj widoku sys.resource_stats . Aby pobrać najnowsze dane we/wy dziennika z wyższym stopniem szczegółowości, który lepiej odzwierciedla krótkoterminowe skoki, użyj widoku sys.dm_db_resource_stats .

Porada

Ograniczanie operacji we/wy dziennika transakcji na serwerze podstawowym z powodu mniejszego rozmiaru obliczeniowego pomocniczego obszaru geograficznego jest zgłaszane przy użyciu typu oczekiwania HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO widocznego w widokach bazy danych sys.dm_exec_requests i sys.dm_os_wait_stats .

We/Wy dziennika transakcji na podstawowym serwerze podstawowym mogą być ograniczane z powodów niepowiązanych z niższym rozmiarem obliczeniowym w pomocniczym obszarze geograficznym. Ten rodzaj ograniczania może wystąpić nawet wtedy, gdy pomocniczy obszar geograficzny ma taki sam lub wyższy rozmiar obliczeniowy niż podstawowy. Aby uzyskać szczegółowe informacje, w tym typy oczekiwania dla różnych rodzajów ograniczania operacji we/wy dziennika, zobacz Zarządzanie szybkością dzienników transakcji.

Domyślnie nadmiarowość magazynu kopii zapasowych pomocniczego obszaru geograficznego jest taka sama jak w przypadku podstawowej bazy danych. Możesz skonfigurować pomocniczy obszar geograficzny z inną nadmiarowością magazynu kopii zapasowych. Kopie zapasowe są zawsze wykonywane w podstawowej bazie danych. Jeśli pomocnicza jest skonfigurowana z inną nadmiarowością magazynu kopii zapasowych, po przejściu w tryb failover geograficznym po podwyższeniu poziomu geograficznego pomocniczego do podstawowego, nowe kopie zapasowe będą przechowywane i rozliczane zgodnie z typem magazynu (RA-GRS, ZRS, LRS) wybranym dla nowego podstawowego (poprzedniego pomocniczego).

Replikacja geograficzna między subskrypcjami

Aby utworzyć pomocniczą geograficznie w subskrypcji innej niż subskrypcja podstawowego (niezależnie od tego, czy jest to ta sama dzierżawa usługi Azure Active Directory, czy nie), wykonaj kroki opisane w tej sekcji.

  1. Dodaj adres IP maszyny klienckiej wykonującej poniższe polecenia języka T-SQL do zapór serwera zarówno serwerów podstawowych, jak i pomocniczych. Możesz potwierdzić ten adres IP, wykonując następujące zapytanie podczas nawiązywania połączenia z serwerem podstawowym z tej samej maszyny klienckiej.

    select client_net_address from sys.dm_exec_connections where session_id = @@SPID;
    

    Aby uzyskać więcej informacji, zobacz Konfigurowanie zapory.

  2. master W bazie danych na serwerze podstawowym utwórz identyfikator logowania uwierzytelniania SQL przeznaczony dla aktywnej konfiguracji replikacji geograficznej. Dostosuj nazwę logowania i hasło zgodnie z potrzebami.

    create login geodrsetup with password = 'ComplexPassword01';
    
  3. W tej samej bazie danych utwórz użytkownika na potrzeby logowania i dodaj go do dbmanager roli:

    create user geodrsetup for login geodrsetup;
    alter role dbmanager add member geodrsetup;
    
  4. Zanotuj wartość identyfikatora SID nowego identyfikatora logowania. Uzyskaj wartość identyfikatora SID przy użyciu następującego zapytania.

    select sid from sys.sql_logins where name = 'geodrsetup';
    
  5. Połącz się z podstawową bazą danych (a nie master bazą danych) i utwórz użytkownika dla tego samego identyfikatora logowania.

    create user geodrsetup for login geodrsetup;
    
  6. W tej samej bazie danych dodaj użytkownika do db_owner roli.

    alter role db_owner add member geodrsetup;
    
  7. W bazie danych master na serwerze pomocniczym utwórz te same dane logowania co na serwerze podstawowym, używając tej samej nazwy, hasła i identyfikatora SID. Zastąp wartość szesnastkowego identyfikatora SID w poniższym przykładowym poleceniu wartością uzyskaną w kroku 4.

    create login geodrsetup with password = 'ComplexPassword01', sid=0x010600000000006400000000000000001C98F52B95D9C84BBBA8578FACE37C3E;
    
  8. W tej samej bazie danych utwórz użytkownika na potrzeby logowania i dodaj go do dbmanager roli.

    create user geodrsetup for login geodrsetup;
    alter role dbmanager add member geodrsetup;
    
  9. Połącz się z bazą danych master na serwerze podstawowym przy użyciu nowego geodrsetup identyfikatora logowania i zainicjuj tworzenie pomocniczej lokalizacji geograficznej na serwerze pomocniczym. Dostosuj nazwę bazy danych i nazwę serwera pomocniczego zgodnie z potrzebami. Po wykonaniu polecenia można monitorować tworzenie pomocniczego obszaru geograficznego, wykonując zapytanie dotyczące widoku sys.dm_geo_replication_link_status w podstawowej bazie danych oraz widok sys.dm_operation_status w bazie danych master na serwerze podstawowym . Czas potrzebny do utworzenia pomocniczego obszaru geograficznego zależy od rozmiaru podstawowej bazy danych.

    alter database [dbrep] add secondary on server [servername];
    
  10. Po pomyślnym utworzeniu pomocniczego obszaru geograficznego można usunąć użytkowników, identyfikatory logowania i reguły zapory utworzone przez tę procedurę.

Uwaga

Operacje replikacji geograficznej między subskrypcjami, w tym konfiguracja i tryb failover geograficznie, są obsługiwane tylko przy użyciu poleceń języka T-SQL interfejsu API & REST.

Dodawanie pomocniczego obszaru geograficznego przy użyciu języka T-SQL nie jest obsługiwane podczas nawiązywania połączenia z serwerem podstawowym za pośrednictwem prywatnego punktu końcowego. Jeśli prywatny punkt końcowy jest skonfigurowany, ale dostęp do sieci publicznej jest dozwolony, dodanie pomocniczego obszaru geograficznego jest obsługiwane w przypadku połączenia z serwerem podstawowym z publicznego adresu IP. Po dodaniu pomocniczego obszaru geograficznego można odmówić dostępu do sieci publicznej.

Tworzenie pomocniczego obszaru geograficznego na serwerze logicznym w innej dzierżawie platformy Azure nie jest obsługiwane, gdy uwierzytelnianie usługi Azure Active Directory tylko dla Azure SQL jest aktywne (włączone) na serwerze podstawowym lub pomocniczym.

Zachowywanie poświadczeń i reguł zapory w synchronizacji

W przypadku korzystania z dostępu do sieci publicznej na potrzeby nawiązywania połączenia z bazą danych zalecamy używanie reguł zapory bazujących na adresach IP na poziomie bazy danych dla baz danych replikowanych geograficznie. Te reguły są replikowane z bazą danych, co gwarantuje, że wszystkie pomocnicze lokalizacje geograficzne mają te same reguły zapory adresów IP co podstawowe. Takie podejście eliminuje potrzebę ręcznego konfigurowania i obsługi reguł zapory na serwerach hostujących podstawowe i pomocnicze bazy danych. Podobnie korzystanie z użytkowników zawartej bazy danych w celu uzyskania dostępu do danych zapewnia, że zarówno podstawowe, jak i pomocnicze bazy danych zawsze mają te same poświadczenia uwierzytelniania. W ten sposób po przejściu w tryb failover geograficznym nie ma żadnych zakłóceń z powodu niezgodności poświadczeń uwierzytelniania. Jeśli używasz identyfikatorów logowania i użytkowników (a nie zawartych użytkowników), musisz wykonać dodatkowe kroki, aby upewnić się, że dla pomocniczej bazy danych istnieją te same identyfikatory logowania. Aby uzyskać szczegółowe informacje o konfiguracji, zobacz Jak skonfigurować identyfikatory logowania i użytkowników.

Skalowanie podstawowej bazy danych

Podstawową bazę danych można skalować w górę lub w dół do innego rozmiaru obliczeniowego (w ramach tej samej warstwy usługi) bez odłączania żadnych serwerów geograficznych. Podczas skalowania w górę zalecamy najpierw skalowanie w górę pomocniczego obszaru geograficznego, a następnie skalowanie w górę podstawowego. Podczas skalowania w dół odwróć kolejność: najpierw przeprowadź skalowanie w dół podstawowej, a następnie przeprowadź skalowanie w dół pomocniczej.

Uwaga

W przypadku utworzenia pomocniczego obszaru geograficznego w ramach konfiguracji grupy trybu failover nie zaleca się skalowania go w dół. Ma to na celu zapewnienie, że warstwa danych ma wystarczającą pojemność do przetwarzania zwykłego obciążenia po przejściu w tryb failover w obszarze geograficznym.

Ważne

Podstawowa baza danych w grupie trybu failover nie może przeprowadzić skalowania do wyższej warstwy usługi (wydania), chyba że pomocnicza baza danych zostanie najpierw przeskalowana do wyższej warstwy. Jeśli na przykład chcesz skalować w górę podstawową z Ogólnego przeznaczenia do Krytyczne dla działania firmy, musisz najpierw skalować pomocnicze geograficznie do Krytyczne dla działania firmy. Jeśli spróbujesz skalować podstawowy lub pomocniczy obszar geograficzny w sposób naruszający tę regułę, zostanie wyświetlony następujący błąd:

The source database 'Primaryserver.DBName' cannot have higher edition than the target database 'Secondaryserver.DBName'. Upgrade the edition on the target before upgrading the source.

Zapobieganie utracie danych krytycznych

Ze względu na duże opóźnienie sieci rozległych replikacja geograficzna używa mechanizmu replikacji asynchronicznej. Replikacja asynchroniczna sprawia, że utrata danych jest nieunikniona w przypadku awarii podstawowej. Aby chronić krytyczne transakcje przed utratą danych, deweloper aplikacji może wywołać sp_wait_for_database_copy_sync procedurę składowaną natychmiast po zatwierdzeniu transakcji. Wywołanie sp_wait_for_database_copy_sync blokuje wątek wywołujący do momentu przesyłania ostatniej zatwierdzonej transakcji i wzmacniania zabezpieczeń w dzienniku transakcji pomocniczej bazy danych. Jednak nie czeka na ponowne odtworzenie przesyłanych transakcji (redone) na pomocniczym. sp_wait_for_database_copy_sync jest ograniczone do określonego linku replikacji geograficznej. Każdy użytkownik z prawami połączenia do podstawowej bazy danych może wywołać tę procedurę.

Uwaga

sp_wait_for_database_copy_sync zapobiega utracie danych po przejściu w tryb failover geograficznym dla określonych transakcji, ale nie gwarantuje pełnej synchronizacji na potrzeby dostępu do odczytu. Opóźnienie spowodowane sp_wait_for_database_copy_sync przez wywołanie procedury może być znaczące i zależy od rozmiaru nieoprzesyłania dziennika transakcji na serwerze podstawowym w momencie wywołania.

Monitorowanie opóźnienia replikacji geograficznej

Aby monitorować opóźnienie w odniesieniu do celu punktu odzyskiwania, użyj kolumny replication_lag_sec sys.dm_geo_replication_link_status w podstawowej bazie danych. Pokazuje opóźnienie w sekundach między transakcjami zatwierdzonymi na serwerze podstawowym i wzmocnionym do dziennika transakcji w pomocniczej bazie danych. Jeśli na przykład opóźnienie wynosi jedną sekundę, oznacza to, że jeśli w tej chwili wystąpi awaria, a nastąpi zainicjowanie geograficznego przejścia w tryb failover, transakcje zatwierdzone w ciągu ostatniej sekundy zostaną utracone.

Aby zmierzyć opóźnienie w odniesieniu do zmian w podstawowej bazie danych, które zostały wzmocnione w pomocniczym obszarze geograficznym, porównaj last_commit czasu w pomocniczym obszarze geograficznym z tą samą wartością w bazie podstawowej.

Porada

Jeśli replication_lag_sec na serwerze podstawowym ma wartość NULL, oznacza to, że serwer podstawowy nie wie obecnie, jak daleko za pomocniczym obszarem geograficznym jest. Zwykle dzieje się to po ponownym uruchomieniu procesu i powinno być warunkiem przejściowym. Rozważ wysłanie alertu, jeśli replication_lag_sec zwróci wartość NULL przez dłuższy czas. Może to wskazywać, że pomocnicza lokalizacja geograficzna nie może komunikować się z serwerem podstawowym z powodu awarii łączności.

Istnieją również warunki, które mogą powodować różnicę między last_commit czasu w pomocniczym obszarze geograficznym a podstawowym, aby stać się duże. Jeśli na przykład zatwierdzenie jest dokonywane na serwerze podstawowym po długim okresie bez zmian, różnica zwiększy się do dużej wartości przed szybkim powrotem do zera. Rozważ wysłanie alertu, jeśli różnica między tymi dwiema wartościami pozostaje duża przez długi czas.

Programowe zarządzanie aktywną replikacją geograficzną

Jak wspomniano wcześniej, aktywna replikacja geograficzna może być również zarządzana programowo przy użyciu języka T-SQL, Azure PowerShell i interfejsu API REST. W poniższych tabelach opisano zestaw dostępnych poleceń. Aktywna replikacja geograficzna obejmuje zestaw interfejsów API usługi Azure Resource Manager do zarządzania, w tym interfejs API REST usługi Azure SQL Database i Azure PowerShell poleceń cmdlet. Te interfejsy API obsługują kontrolę dostępu opartą na rolach platformy Azure (Azure RBAC). Aby uzyskać więcej informacji na temat implementowania ról dostępu, zobacz Kontrola dostępu oparta na rolach (RBAC) platformy Azure.

T-SQL: Zarządzanie trybem failover geograficznym dla pojedynczych baz danych i baz danych w puli

Ważne

Te polecenia języka T-SQL dotyczą tylko aktywnej replikacji geograficznej i nie mają zastosowania do grup trybu failover. W związku z tym nie mają one również zastosowania do SQL Managed Instance, które obsługują tylko grupy trybu failover.

Polecenie Opis
ALTER DATABASE Użyj argumentu ADD SECONDARY ON SERVER , aby utworzyć pomocniczą bazę danych dla istniejącej bazy danych i uruchomić replikację danych
ALTER DATABASE Przełącz pomocniczą bazę danych w tryb failover lub FORCE_FAILOVER_ALLOW_DATA_LOSS , aby zainicjować tryb failover
ALTER DATABASE Użyj polecenia REMOVE SECONDARY ON SERVER, aby zakończyć replikację danych między SQL Database a określoną pomocniczą bazą danych.
sys.geo_replication_links Zwraca informacje o wszystkich istniejących łączach replikacji dla każdej bazy danych na serwerze.
sys.dm_geo_replication_link_status Pobiera czas ostatniej replikacji, opóźnienie ostatniej replikacji i inne informacje o linku replikacji dla danej bazy danych.
sys.dm_operation_status Pokazuje stan wszystkich operacji bazy danych, w tym zmian linków replikacji.
sys.sp_wait_for_database_copy_sync Powoduje, że aplikacja czeka, aż wszystkie zatwierdzone transakcje zostaną wzmocnione do dziennika transakcji pomocniczego obszaru geograficznego.

PowerShell: zarządzanie trybem failover geograficznym dla pojedynczych baz danych i baz danych w puli

Uwaga

W tym artykule użyto modułu Azure Az programu PowerShell, który jest zalecanym modułem programu PowerShell do interakcji z platformą Azure. Aby rozpocząć pracę z modułem Azure PowerShell, zobacz Instalowanie programu Azure PowerShell. Aby dowiedzieć się, jak przeprowadzić migrację do modułu Az PowerShell, zobacz Migracja programu Azure PowerShell z modułu AzureRM do modułu Az.

Ważne

Moduł Azure Resource Manager programu PowerShell jest nadal obsługiwany przez usługę Azure SQL Database, ale cały przyszły rozwój jest przeznaczony dla modułu Az.Sql. Aby uzyskać te polecenia cmdlet, zobacz AzureRM.Sql. Argumenty poleceń w module Az i modułach AzureRm są znacznie identyczne.

Polecenie cmdlet Opis
Get-AzSqlDatabase Pobiera co najmniej jedną bazę danych.
New-AzSqlDatabaseSecondary Tworzy pomocniczą bazę danych dla istniejącej bazy danych i rozpoczyna replikację danych.
Set-AzSqlDatabaseSecondary Przełącza pomocniczą bazę danych jako główną w celu zainicjowania trybu failover.
Remove-AzSqlDatabaseSecondary Przerywa replikację danych między bazą danych SQL Database i wybraną pomocniczą bazą danych.
Get-AzSqlDatabaseReplicationLink Pobiera łącza replikacji geograficznej dla bazy danych.

Interfejs API REST: zarządzanie trybem failover geograficznym dla pojedynczych baz danych i baz danych w puli

Interfejs API Opis
Tworzenie lub aktualizowanie bazy danych (createMode=Restore) Tworzy, aktualizuje lub przywraca podstawową lub pomocniczą bazę danych.
Uzyskiwanie stanu tworzenia lub aktualizowania bazy danych Zwraca stan podczas operacji tworzenia.
Ustawianie pomocniczej bazy danych jako podstawowej (planowana praca w trybie failover) Ustawia, która pomocnicza baza danych jest podstawowa, przechodząc w tryb failover z bieżącej podstawowej bazy danych. Ta opcja nie jest obsługiwana w przypadku SQL Managed Instance.
Ustaw pomocniczą bazę danych jako podstawową (nieplanowany tryb failover) Ustawia, która pomocnicza baza danych jest podstawowa, przechodząc w tryb failover z bieżącej podstawowej bazy danych. Ta operacja może spowodować utratę danych. Ta opcja nie jest obsługiwana w przypadku SQL Managed Instance.
Pobieranie linku replikacji Pobiera określony link replikacji dla danej bazy danych w połączeniu replikacji geograficznej. Pobiera informacje widoczne w widoku wykazu sys.geo_replication_links. Ta opcja nie jest obsługiwana w przypadku SQL Managed Instance.
Łącza replikacji — lista według bazy danych Pobiera wszystkie łącza replikacji dla danej bazy danych w powiązaniu replikacji geograficznej. Pobiera informacje widoczne w widoku wykazu sys.geo_replication_links.
Usuń łącze replikacji Usuwa link replikacji bazy danych. Nie można wykonać pracy w trybie failover.

Następne kroki