Łączenie klientów z sesją dublowania bazy danych (SQL Server)

Dotyczy:SQL Server

Aby połączyć się z sesją mirroringu bazy danych, klient może użyć SQL Server Native Client lub .NET Framework Dostawca danych for SQL Server. Po skonfigurowaniu dla bazy danych SQL Server, obie te dostawcy dostępu do danych w pełni wspierają mirroring baz danych. Informacje o aspektach programowania przy korzystaniu z bazy danych lustrzanej można znaleźć w artykule Wykorzystanie mirroringu bazy danych. Dodatkowo aktualna instancja głównego serwera musi być dostępna, a logowanie klienta musi zostać utworzone na instancji serwera. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z osieroconymi użytkownikami (SQL Server). Połączenia klientów z sesją kopii lustrzanej bazy danych nie dotyczą instancji serwera świadka, jeśli taka istnieje.

Nawiązywanie początkowego połączenia z sesją dublowania bazy danych

Aby uzyskać początkowe połączenie z lustrzaną bazą danych, klient musi dostarczyć parametry połączenia, który minimalnie podaje nazwę instancji serwera. Ta wymagana nazwa serwera powinna identyfikować aktualną główną instancję serwera i jest znana jako początkowa nazwa partnera.

Opcjonalnie, parametry połączenia może również podać nazwę innej instancji serwera, która powinna identyfikować aktualną instancję serwera lustrzanego, do użycia, gdy początkowy partner jest niedostępny podczas pierwszej próby połączenia. Druga nazwa znana jest jako nazwa partnera failover.

Ciąg parametry połączenia musi również zawierać nazwę bazy danych. Jest to konieczne, aby umożliwić próby awaryjnego przełączenia przez dostawcę dostępu do danych.

Po otrzymaniu parametrów połączenia dostawca dostępu do danych przechowuje nazwę partnera podstawowego oraz nazwę partnera przełączenia awaryjnego, jeśli została podana, w pamięci podręcznej znajdującej się w pamięci ulotnej klienta (w przypadku kodu zarządzanego pamięć podręczna jest ograniczona do domeny aplikacji). Po buforowaniu początkowa nazwa partnera nigdy nie jest aktualizowana przez dostawcę dostępu do danych. Gdy klient poda nazwę partnera awaryjnego, dostawca dostępu do danych tymczasowo przechowuje tę nazwę partnera awaryjnego na wypadek, gdyby nie mógł nawiązać połączenia przy użyciu początkowej nazwy partnera.

Sesja mirroring bazy danych nie chroni przed problemami dostępu do serwera specyficznymi dla klientów, na przykład gdy komputer kliencki ma problemy z komunikacją z siecią. Próba połączenia z lustrzaną bazą danych może również zakończyć się niepowodzeniem z różnych powodów niezwiązanych z dostawcą dostępu do danych; na przykład próba połączenia może się nie powiódć, ponieważ główna instancja serwera jest nieaktywna, co ma miejsce podczas awaryjnego przełączania bazy danych lub z powodu błędu sieciowego.

Podczas próby połączenia dostawca dostępu do danych zaczyna od używania nazwy początkowego partnera. Jeśli dana instancja serwera jest dostępna i jest aktualną główną instancją serwera, próba połączenia zazwyczaj kończy się sukcesem.

Note

Jeśli sesja dublowania jest wstrzymana, klient zazwyczaj łączy się z serwerem podstawowym i pobiera nazwę partnera. Jednak baza danych pozostaje niedostępna dla klienta, dopóki dublowanie nie zostanie wznowione.

Jeśli ta próba się nie powiedzie, dostawca dostępu do danych próbuje użyć nazwy partnera przełączenia awaryjnego, jeśli jest dostępna. Jeśli którakolwiek z nazw partnerów prawidłowo identyfikuje bieżący serwer podstawowy, dostawca danych zazwyczaj pomyślnie otwiera początkowe połączenie. Po zakończeniu tego połączenia dostawca dostępu do danych pobiera nazwę instancji serwera aktualnego serwera lustrzanego. Ta nazwa jest przechowywana w pamięci podręcznej jako nazwa partnera awaryjnego, nadpisując nazwę partnera awaryjnego dostarczoną przez klienta, jeśli taka istnieje. Od tego czasu .NET Framework Dostawca danych for SQL Server nie aktualizuje nazwy partnera awaryjnego. Natomiast SQL Server Native Client aktualizuje pamięć podręczną za każdym razem, gdy kolejne połączenie lub reset połączenia zwraca inną nazwę partnera.

Poniższy rysunek ilustruje połączenie klienta z początkowym partnerem, Partner_A, dla bazy danych lustrzanej o nazwie Db_1. Ten rysunek pokazuje przypadek, w którym początkowa nazwa partnera podana przez klienta poprawnie identyfikuje aktualny główny serwer, Partner_A. Początkowa próba połączenia kończy się sukcesem, a dostawca dostępu do danych przechowuje nazwę serwera lustrzanego (obecnie Partner_B) jako nazwę partnera awaryjnego w lokalnej pamięci podręcznej. Na koniec klient łączy się z główną kopią bazy Db_1 .

Początkowa próba połączenia może się nie powiódć na przykład z powodu błędu sieciowego lub nieaktywnej instancji serwera. Ponieważ początkowy partner jest niedostępny, aby dostawca dostępu do danych mógł próbować połączyć się z partnerem failover, klient musiał podać nazwę partnera failover w parametry połączenia.

W takim przypadku, jeśli nazwa partnera trybu failover jest niedostępna, pierwotna próba nawiązania połączenia jest kontynuowana do momentu upłynięcia limitu czasu połączenia sieciowego lub zwrócenia błędu (podobnie jak w przypadku bazy danych nieobjętej dublowaniem).

Gdy w parametry połączenia podana jest nazwa partnera awaryjnego, zachowanie dostawcy dostępu do danych zależy od protokołu sieciowego i systemu operacyjnego klienta, w następujący sposób:

• W przypadku TCP/IP próby połączenia są regulowane przez algorytm powtórki połączenia, specyficzny dla mirroringu bazy danych. Algorytm próby ponownej próby połączenia określa maksymalny czas (czas próby) przeznaczony na otwarcie połączenia w danej próbie połączenia.

• Dla innych protokołów sieciowych

  Jeśli wystąpi błąd lub początkowy partner jest niedostępny, początkowa próba połączenia czeka do wygaśnięcia okresu przerwy połączenia sieciowego lub do momentu wygasnięcia okresu logowania u dostawcy dostępu do danych. Zazwyczaj to oczekiwanie wynosi od 20 do 30 sekund. Następnie, jeśli u dostawcy dostępu do danych nie wystąpiło przekroczenie limitu czasu, podejmuje on próbę połączenia z partnerem trybu failover. Jeśli limit czasu połączenia upłynie, zanim połączenie zostanie nawiązane, lub partner przejęcia awaryjnego będzie niedostępny, próba połączenia zakończy się niepowodzeniem. Jeśli partner przełączania awaryjnego jest dostępny w czasie limitu logowania i jest teraz serwerem podstawowym, próba połączenia zazwyczaj kończy się powodzeniem.

Łańcuchy połączeń dla bazy danych lustrzanej

Parametry połączenia podane przez klienta zawierają informacje, które dostawca dostępu do danych wykorzystuje do połączenia z bazą danych. Ta sekcja omawia słowa kluczowe szczególnie istotne do łączenia się z lustrzaną bazą danych za pomocą SQL Server Native Client ODBC Driver Connection.

Atrybut sieci

Ciąg parametry połączenia powinien zawierać atrybut Network do określenia protokołu sieciowego. Zapewnia to, że określony protokół sieciowy jest zachowywany przy połączeniach z różnymi partnerami. Najlepszym protokołem do łączenia się z lustrzaną bazą danych jest TCP/IP. Aby zapewnić, że klient żąda TCP/IP dla każdego połączenia partnerów, parametry połączenia dostarcza następującą cechę:

Network=dbmssocn;   

Ważna

Zalecamy utrzymywanie TCP/IP na szczycie listy protokołów klienta. Jeśli jednak parametry połączenia określają atrybut Network, ma on pierwszeństwo przed kolejnością na liście.

Alternatywnie, aby zapewnić, że klient żąda nazwanych potoków dla każdego połączenia z partnerami, ciąg połączenia zawiera następujący atrybut:

Network=dbnmpntw;   

Ważna

Ponieważ nazwane potoki nie korzystają z algorytmu ponawiania połączeń TCP/IP, w wielu przypadkach próba połączenia za pomocą nazwanych potoków może przekroczyć limit czasu przed nawiązaniem połączenia z lustrzaną bazą danych.

Atrybut serwera

Ciąg parametry połączenia musi zawierać atrybut serwera, który podaje początkową nazwę partnera, co powinno identyfikować aktualną główną instancję serwera.

Najprostszym sposobem identyfikacji instancji serwera jest podanie jej nazwy ,< server_name>[\<SQL_Server_instance_name>]. Przykład:

Server=Partner_A;

lub

Server=Partner_A\Instance_2;

Jednak gdy używana jest nazwa systemu, klient musi przeprowadzić wyszukiwanie DNS, aby uzyskać adres IP serwera, oraz zapytanie przeglądarki SQL Server, aby uzyskać numer portu serwera, na którym znajduje się partner. Te wyszukiwania i zapytania można ominąć, określając adres IP i numer portu partnera w atrybucie serwera , zamiast określać nazwę serwera. Zaleca się to, aby zminimalizować ryzyko zewnętrznych opóźnień podczas łączenia się z partnerem.

Note

Zapytanie w przeglądarce SQL Server jest konieczne, jeśli parametry połączenia podaje nazwę instancji, a nie port.

Aby określić adres IP i port, atrybut Server przyjmuje następującą formę, Server=<na przykład ip_address>,<port>:

Server=123.34.45.56,4724;   

Note

Adres IP może być adresem IP w wersji 4 (IPv4) lub IP w wersji 6 (IPv6).

Atrybut bazy danych

Dodatkowo parametry połączenia musi podać atrybut Database, aby podać nazwę mirrorowanej bazy danych. Jeśli baza danych jest niedostępna podczas próby połączenia przez klienta, zgłaszany jest wyjątek.

Na przykład aby jawnie połączyć się z bazą danych AdventureWorks na serwerze głównym Partner_A, klient używa następujących parametrów połączenia:

" Server=Partner_A; Database=AdventureWorks "

Note

Ten ciąg nie zawiera informacji o uwierzytelnianiu.

Ważna

Łączenie prefiksu protokołu z atrybutem Server (Server=tcp:<servername>) jest niezgodne z atrybutem sieci , a określenie protokołu w obu miejscach prawdopodobnie spowoduje błąd. Dlatego zalecamy, aby parametry połączenia określał protokół za pomocą atrybutu Network i określał tylko nazwę serwera w atributie Server ("Network=dbmssocn; Server=<servername>").

Atrybut partnera awaryjnego

Oprócz nazwy początkowego partnera, klient może również określić nazwę partnera awaryjnego, która powinna identyfikować aktualną instancję serwera lustrzanego. Partner przełączenia awaryjnego określa się za pomocą jednego ze słów kluczowych atrybutu partnera przełączenia awaryjnego. Słowo kluczowe dla tego atrybutu zależy od API, którego używasz. Poniższa tabela przedstawia następujące słowa kluczowe:

API	Słowo kluczowe dla atrybutu partnera awaryjnego
Dostawca bazy danych OLE	FailoverPartner
Sterownik ODBC	Failover_Partner
Obiekty danych ActiveX (ADO)	Partner awaryjny

Najprostszym sposobem identyfikacji instancji serwera jest jej nazwa systemowa server_name>[<\<SQL_Server_instance_name>].

Alternatywnie, adres IP i numer portu mogą być podany w atrybucie Failover Partner . Jeśli początkowa próba połączenia nie powiodła się podczas pierwszego połączenia z bazą danych, próba połączenia z partnerem awaryjnym zostanie zwolniona z polegania na DNS i przeglądarce SQL Server. Po nawiązaniu połączenia nazwa partnera awaryjnego zostanie nadpisana nazwą partnera awaryjnego, więc jeśli dojdzie do awaryjnego połączenia, przekierowane połączenia będą wymagały DNS i przeglądarki SQL Server.

Note

Gdy podana jest tylko nazwa początkowego partnera, programiści aplikacji nie muszą podejmować żadnych działań ani pisać kodu poza informacjami o sposobie ponownego połączenia.

Note

Programiści tworzący aplikacje w kodzie zarządzanym podają nazwę partnera przełączania awaryjnego w elemencie ConnectionString obiektu SqlConnection. Aby uzyskać informacje na temat używania tego ciągu połączenia, zobacz temat „Obsługa dublowania bazy danych w dostawcy danych .NET Framework dla programu SQL Server” w dokumentacji ADO.NET, która wchodzi w skład zestawu SDK platformy Microsoft .NET Framework.

Przykładowy ciąg połączeń

Na przykład, aby jawnie połączyć się za pomocą TCP/IP z bazą danych AdventureWorks na Partner_A lub Partner_B, aplikacja kliencka korzystająca ze sterownika ODBC mogłaby dostarczyć następujące parametry połączenia:

"Server=Partner_A; Failover_Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"  

Alternatywnie, klient mógł użyć adresu IP i numeru portu do identyfikacji początkowego partnera, Partner_A; na przykład, jeśli adres IP to 250.65.43.21, a numer portu to 4734, parametry połączenia będzie wyglądał:

"Server=250.65.43.21,4734; Failover_Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"  

Algorytm próby ponownego połączenia (dla połączeń TCP/IP)

Dla połączenia TCP/IP, gdy w pamięci podręcznej znajdują się obie nazwy partnerów, dostawca dostępu do danych stosuje algorytm powtórki połączenia. Dotyczy to zarówno nawiązania pierwszego połączenia z sesją, jak i ponownego połączenia po utracie ustalonego połączenia. Po otwarciu połączenia wykonanie kroków przed logowaniem i logowaniem zajmuje dodatkowy czas.

Note

Czas poświęcony na nawiązanie połączenia może przekroczyć czas powtórek z powodu czynników zewnętrznych, takich jak wolne wyszukiwanie DNS, wolny kontroler domeny/Kerberos Key Distribution Center (KDC), czas spędzony na kontakcie z przeglądarką SQL Server, przeciążenie sieci i tym podobne. Takie czynniki zewnętrzne mogą uniemożliwić klientowi połączenie z lustrzaną bazą danych. Ponadto czynniki zewnętrzne mogą spowodować, że otwarcie połączenia zajmuje więcej czasu niż przewidziany czas powtórki. Informacje na temat omijania DNS i przeglądarki SQL Server w próbie połączenia z początkowym partnerem można znaleźć w artykule Making the Initial Connection to a Database Mirroring Session, wcześniej w tym temacie.

Jeśli próba nawiązania połączenia nie powiedzie się lub limit czasu ponowienia upłynie, zanim zakończy się ona powodzeniem, dostawca dostępu do danych próbuje użyć drugiego partnera. Jeśli do tego czasu połączenie nie zostanie otwarte, dostawca naprzemiennie próbuje użyć nazw partnera podstawowego i partnera przełączania awaryjnego, aż do nawiązania połączenia albo do upływu limitu czasu logowania. Domyślny limit czasu logowania wynosi 15 sekund. Zalecamy, aby okres logowania wynosił co najmniej 5 sekund. Wskazanie krótszego czasu przerwy może uniemożliwić powodzenie prób połączenia.

Czas powtórki to procent okresu logowania. Czas powtórki próby połączenia jest dłuższy w kolejnej rundzie. W pierwszej rundzie czas powtórki dla każdej z dwóch prób wynosi 8 procent całego okresu logowania. W każdej kolejnej rundzie algorytm powtórki zwiększa maksymalny czas powtórki o tę samą wartość. Zatem czasy powtórek dla pierwszych ośmiu prób połączenia są następujące:

8%, 8%, 16%, 16%, 24%, 24%, 32%, 32%

Czas ponownej próby oblicza się według następującego wzoru:

RetryTime=PreviousRetryTime+( 0.08 *LoginTimeout)

Gdzie PreviousRetryTime początkowo wynosi 0.

Na przykład, jeśli domyślny czas logowania wynosi 15 sekund, LoginTimeout= 15. W tym przypadku czasy powtórek przydzielone w pierwszych trzech rundach są następujące:

Okrągły	Obliczenie czasu ponownego próbowania	Czas ponowienia dla każdej próby
1	0 +(0,08 * 15)	1,2 sekundy
2	1.2 +(0.08 * 15)	2,4 sekundy
3	2.4 +(0.08 * 15)	3,6 sekundy
4	3.6 +(0.08 * 15)	4,8 sekundy

Poniższy rysunek przedstawia czasy ponawiania kolejnych prób połączenia, z których każda kończy się przekroczeniem limitu czasu.

Dla domyślnego okresu przejścia logowania maksymalny czas przydzielony na pierwsze trzy rundy prób połączenia wynosi 14,4 sekundy. Gdyby każda próba wykorzystała cały przydzielony czas, pozostałoby tylko 0,6 sekundy przed upływem okresu logowania. W takim przypadku czwarta runda zostałaby skrócona, pozwalając jedynie na ostatnią szybką próbę połączenia się z użyciem pierwotnego imienia partnera. Jednak próba połączenia może zakończyć się niepowodzeniem w krótszym czasie niż przewidziany czas powtórki, szczególnie w późniejszych rundach. Na przykład otrzymanie błędu sieciowego może spowodować zakończenie próby przed upływem czasu powtórki. Jeśli wcześniejsze próby zakończą się niepowodzeniem z powodu błędu sieci, dodatkowy czas zostanie dostępny na czwartą rundę, a być może także na kolejne rundy.

Inną przyczyną nieudanej próby jest nieaktywna instancja serwera, na przykład gdy instancja serwera jest w trakcie przełączania awaryjnego swojej bazy danych. W takim przypadku wprowadzane jest opóźnienie przed ponowną próbą, aby zapobiec przeciążaniu systemów partnerów serią szybko następujących po sobie prób połączenia.

Note

Gdy obie nazwy partnerów są dostępne, a czas wylotu logowania jest nieskończony, klient próbuje ponownie łączyć się z serwerami na czas nieokreślony, na przemian używając nazwy początkowego partnera i nazwy partnera awaryjnego.

Opóźnienia w ponownym próbowaniu podczas przełączania awaryjnego

Jeśli klient próbuje połączyć się z partnerem, który jest w trakcie przełączania awaryjnego, partner natychmiast odpowiada, że jest nieaktywny. W tym przypadku każda runda prób połączenia jest znacznie krótsza niż przydzielony czas powtórki. Oznacza to, że wiele prób połączenia może się zdarzyć zanim okres logowania się skończy. Aby uniknąć przeciążenia partnerów szybką serią prób połączenia podczas przełączania awaryjnego, dostawca dostępu do danych dodaje krótkie opóźnienie powtórki po każdym cyklu prób. Długość danego opóźnienia ponowienia próby jest określana przez algorytm opóźnienia ponowienia próby. Po pierwszym wybuchu opóźnienie wynosi 100 milisekund. Po każdej z kolejnych trzech rund opóźnienie powtórki podwaja się do 200, 400 i 800. We wszystkich późniejszych rundach opóźnienie powtórki wynosi 1 sekundę do zakończenia lub wygaśnięcia próby połączenia.

Note

Jeśli instancja serwera zostanie zatrzymana, żądanie połączenia natychmiast się nieudaje.

Poniższy rysunek ilustruje, jak opóźnienie powtórki wpływa na próby połączenia podczas ręcznego przełączania awaryjnego, w którym partnerzy zamieniają się rolami. Czas na logowanie wynosi 15 sekund.

Ponowne łączenie z sesją dublowania bazy danych

Jeśli ustanowione połączenie z sesją dublowania bazy danych zostanie zerwane z jakiegokolwiek powodu, na przykład wskutek przełączenia awaryjnego dublowania bazy danych, a aplikacja spróbuje ponownie połączyć się z pierwotnym serwerem, dostawca dostępu do danych może podjąć próbę ponownego połączenia przy użyciu nazwy partnera przełączenia awaryjnego przechowywanej w pamięci podręcznej klienta. Ponowne połączenie nie jest jednak automatyczne. Aplikacja musi być świadoma błędu. Następnie aplikacja musi zamknąć nieudane połączenie i otworzyć nowe połączenie z tymi samymi atrybutami parametry połączenia. W tym momencie dostawca dostępu do danych przekierowuje połączenie do partnera awaryjnego. Jeśli instancja serwera oznaczona tą nazwą jest obecnie głównym serwerem, próba połączenia zwykle kończy się sukcesem. Jeśli nie jest jasne, czy transakcja została zatwierdzona czy cofnięta, aplikacja musi sprawdzić jej stan, tak samo jak przy ponownym łączeniu z samodzielną instancją serwera.

Ponowne połączenie jest podobne do połączenia początkowego, w przypadku którego parametry połączenia zawierały nazwę partnera przełączenia awaryjnego. Jeśli pierwsza próba nawiązania połączenia zakończy się niepowodzeniem, kolejne próby połączenia są podejmowane naprzemiennie z użyciem nazwy partnera początkowego i nazwy partnera awaryjnego, aż klient połączy się z serwerem podstawowym albo u dostawcy dostępu do danych upłynie limit czasu.

Note

Natywny klient SQL Server weryfikuje, że łączy się z główną instancją serwera, ale nie sprawdza, czy ta instancja jest partnerem instancji serwera określonej w początkowej nazwie partnera parametry połączenia.

Jeśli połączenia korzystają z TCP/IP, algorytm powtórki połączenia określa czas przeznaczony na próby połączenia w każdej rundzie.

Ważna

Jeśli klient zostanie odłączony od bazy danych, dostawca dostępu do danych nie próbuje ponownie się połączyć. Klient musi wydać nowe żądanie połączenia. Ponadto, jeśli aplikacja zostanie zamknięta po utracie połączenia, straci buforowane nazwy partnerów. Jeśli połączenie zostało utracone, ponieważ główny serwer stał się niedostępny, jedynym sposobem na ponowne połączenie się z serwerem lustrzanym jest podanie nazwy partnera failover w parametry połączenia.

Wpływ przekierowania na aplikację klienta

Po przełączeniu awaryjnym dostawca dostępu do danych przekierowuje połączenie do bieżącej instancji serwera podstawowego. Jednak przekierowanie jest dla klientów przejrzyste. Dla klienta połączenie przekierowane wydaje się być połączeniem do instancji serwera identyfikowanej przez początkową nazwę partnera. Gdy początkowym partnerem jest obecnie serwer lustrzany, klient może wydawać się być połączony z serwerem lustrzanym i aktualizować bazę danych lustrzanych. W rzeczywistości jednak klient został przekierowany do partnera awaryjnego, czyli obecnej głównej bazy danych, a klient aktualizuje nową główną bazę danych.

Po przekierowaniu do partnera awaryjnego klient może doświadczyć nieoczekiwanych rezultatów, gdy używa instrukcji Transact-SQL USE do korzystania z innej bazy danych. Może się to zdarzyć, jeśli obecna instancja serwera głównego (partner failover) ma inny zestaw baz danych niż oryginalny serwer główny (partner początkowy).

Wpływ przestarzałej nazwy partnera awaryjnego

Administrator bazy danych może w dowolnym momencie zmienić partnera awaryjnego. Dlatego nazwa partnera przełączenia awaryjnego podana przez klienta może być nieaktualna lub przestarzała. Na przykład rozważmy partnera awaryjnego o nazwie Partner_B, który zostaje zastąpiony inną instancją serwera Partner_C. Jeśli klient poda Partner_B jako nazwę partnera failover, ta nazwa jest już nieaktualna. Gdy nazwa partnera awaryjnego dostarczona przez klienta jest nieaktualna, zachowanie dostawcy dostępu do danych odpowiada sytuacji, w której klient nie poda nazwy partnera awaryjnego.

Na przykład rozważmy sytuację, w której klient używa jednego parametry połączenia do serii czterech prób połączenia. W parametry połączenia początkowa nazwa partnera to Partner_A, a nazwa partnera awaryjnego to Partner_B:

"Server=Partner_A; Failover Partner=Partner_B; Database=AdventureWorks"  

Poniższa tabela przedstawia cztery konfiguracje partnerów i wskazuje dla każdej z nich, czy ten parametry połączenia działa przy pierwszym połączeniu klienta.

Note

Aplikacja może śledzić zmiany konfiguracji i odpowiednio dostosowywać parametry połączenia. Wymaga to dodatkowego kodu, ale zmniejsza obciążenie administracyjne.

Configuration	Serwer główny	Serwer dublowania	Zachowanie przy próbie połączenia z określeniem Partner_A i Partner_B
Oryginalna konfiguracja lustrzana.	Partner_A	Partner_B	Partner_A jest buforowana jako początkowa nazwa partnera. Klientowi udaje się nawiązać kontakt z Partner_A. Klient pobiera nazwę serwera lustrzanego, Partner_B, i zapisuje ją w pamięci podręcznej, ignorując nazwę partnera awaryjnego dostarczoną przez klienta.
Na Partner_A występuje awaria sprzętu i następuje przełączenie awaryjne (co powoduje rozłączenie klientów).	Partner_B	none	Partner_A jest nadal buforowany jako początkowa nazwa partnera, ale nazwa partnera awaryjnego dostarczona przez klienta, Partner_B, pozwala klientowi na połączenie z aktualnym głównym serwerem.
Administrator bazy danych przestaje mirrorować (odłączać klientów), zastępuje Partner_A Partner_C i ponownie uruchamia mirroring.	Partner_B	Partner_C	Klient próbuje połączyć się z Partner_A i nie udaje mu się; Następnie klient próbuje Partner_B (obecny główny serwer) i odnosi sukces. Dostawca dostępu do danych pobiera nazwę aktualnego serwera lustrzanego, Partner_C, i zapisuje ją jako aktualną nazwę partnera awaryjnego.
Usługa została ręcznie przełączona awaryjnie do Partner_C (powodując rozłączenie klientów).	Partner_C	Partner_B	Klient próbuje najpierw połączyć się z Partner_A, a następnie z Partner_B. Obie nazwy nie działają, a ostatecznie żądanie połączenia przekracza limit czasu i kończy się niepowodzeniem.

Treści powiązane

• Dublowanie bazy danych (SQL Server)
• Możliwe błędy podczas dublowania bazy danych