Używanie dublowania bazy danych

Dotyczy:SQL Server

pobierz sterownik OLE DB

Note

Ta funkcja zostanie usunięta w przyszłej wersji programu SQL Server. Unikaj używania tej funkcji w nowych pracach programistycznych i zaplanuj modyfikowanie aplikacji, które obecnie korzystają z tej funkcji. Zamiast tego użyj grup dostępności Always On.

Lustrzane odbicie baz danych, wprowadzone w SQL Server 2005 (9.x), jest rozwiązaniem zwiększującym dostępność baz danych i redundancję danych. OLE DB Driver for SQL Server zapewnia niejawne wsparcie dla mirroringu bazy danych, dzięki czemu programista nie musi pisać żadnego kodu ani podejmować innych działań po skonfigurowaniu bazy danych.

Dublowanie bazy danych, które jest implementowane na podstawie poszczególnych baz danych, przechowuje kopię produkcyjnej bazy danych programu SQL Server na serwerze rezerwowym. Ten serwer jest gorącym lub ciepłym serwerem rezerwowym, w zależności od konfiguracji i stanu sesji mirroringu bazy danych. Serwer gotowości na gorąco obsługuje szybkie przełączanie awaryjne bez utraty zobowiązanych transakcji, a serwer czujności w trybie gorącym obsługuje wymuszanie usługi (z możliwością utraty danych).

Baza produkcyjna nazywana jest główną bazą danych, a kopia rezerwowa to baza mirror. Główna baza danych i baza mirror muszą znajdować się na oddzielnych instancjach SQL Server (instancjach serwerowych) i, jeśli to możliwe, powinny znajdować się na oddzielnych komputerach.

Instancja serwera produkcyjnego, zwana serwerem głównym, komunikuje się z instancją serwera rezerwowego, zwaną serwerem lustrzanym. Serwery główne i lustrzane działają jako partnerzy w sesji mirroringu bazy danych. Jeśli serwer główny ulegnie awarii, serwer lustrzany może przekształcić swoją bazę danych w główną bazę danych poprzez proces zwany failover. Na przykład Partner_A i Partner_B są dwoma serwerami partnerskimi, z główną bazą danych początkowo na Partner_A jako serwer główny, a baza danych lustrzana znajdująca się na Partner_B jako serwer lustrzany. Jeśli Partner_A przejdzie w tryb offline, baza danych na Partner_B może przejść w tryb failover, aby stać się bieżącą główną bazą danych. Gdy Partner_A ponownie dołączy do sesji dublowania, staje się serwerem dublowania, a jego baza danych staje się dublowaniem bazy danych.

Alternatywne konfiguracje dublowania baz danych oferują różne poziomy wydajności i bezpieczeństwa danych oraz obsługują różne formy trybu failover. Aby uzyskać więcej informacji, zobacz Dublowanie bazy danych (SQL Server).

Możliwe jest użycie aliasu przy określaniu nazwy mirror database.

Note

Aby uzyskać informacje o początkowych próbach połączenia i próbach ponownego połączenia z bazą danych lustrzaną, zobacz Connect Clients to a Database Mirroring Session (SQL Server).

Zagadnienia dotyczące programowania

Gdy główny serwer bazy danych ulegnie awarii, aplikacja kliencka otrzymuje błędy w odpowiedzi na wywołania interfejsu API, co wskazuje, że połączenie z bazą danych zostało utracone. W takiej sytuacji wszelkie niezatwierdzone zmiany w bazie danych są tracone, a bieżąca transakcja jest cofana. Jeśli tak się stanie, aplikacja powinna zamknąć połączenie (lub zwolnić obiekt źródłowy danych) i ponownie je otworzyć. Połączenie jest przekierowywane transparentnie do bazy danych lustrzanej, która teraz pełni rolę serwera głównego.

Po nawiązaniu połączenia serwer główny wysyła do klienta identyfikator swojego serwera partnerskiego trybu failover, aby mógł go użyć w przypadku przełączenia awaryjnego. Gdy aplikacja próbowała nawiązać połączenie po awarii serwera głównego, klient nie zna tożsamości partnera awaryjnego. Aby dać klientom możliwość radzenia sobie z takim scenariuszem, właściwość inicjalizacji oraz powiązane słowo kluczowe parametry połączenia pozwalają klientowi samodzielnie określić tożsamość partnera failover. Atrybut klienta jest używany tylko w tym scenariuszu; jeśli główny serwer jest dostępny, nie jest używany. Jeśli serwer partnera awaryjnego dostarczony przez klienta nie odnosi się do serwera działającego jako partner awaryjny, połączenie zostaje odrzucone przez serwer. Aby umożliwić aplikacjom dostosowanie się do zmian konfiguracji, tożsamość faktycznego partnera awaryjnego można ustalić, sprawdzając atrybut po nawiązaniu połączenia. Powinieneś rozważyć buforowanie danych partnera, aby zaktualizować parametry połączenia lub opracować strategię ponownego nawiązania w przypadku niepowodzenia pierwszej próby połączenia.

Note

Musisz wyraźnie określić, która baza danych ma być używana przez połączenie, jeśli chcesz użyć tej funkcji w DSN, parametry połączenia lub właściwości/atrybutie połączenia. OLE DB Driver for SQL Server nie będzie próbował przełączać się do partnerskiej bazy danych, jeśli tego nie zrobimy.

Lustrzane odbicie jest funkcją bazy danych. Aplikacje korzystające z wielu baz danych mogą nie być w stanie wykorzystać tej funkcji.

Ponadto nazwy serwerów są nierozróżniające wielkością liter, ale nazwy baz danych są wrażliwe na wielkość liter. Dlatego powinieneś upewnić się, że używasz tej samej obudowy w DSN i stringach połączeń.

Sterownik OLE DB dla programu SQL Server

OLE DB Driver for SQL Server obsługuje mirroring baz danych poprzez atrybuty connection i parametry połączenia. Własność SSPROP_INIT_FAILOVERPARTNER została dodana do zbioru DBPROPSET_SQLSERVERDBINIT, a słowo kluczowe FailoverPartner to nowy atrybut parametry połączenia dla DBPROP_INIT_PROVIDERSTRING. Więcej informacji można znaleźć w artykule Using Connection String Keywords with OLE DB Driver for SQL Server.

Pamięć podręczna failover jest utrzymwana tak długo, jak długo dostawca jest ładowany, czyli do momentu wywołania CoUninitialize lub dopóki aplikacja ma referencję do jakiegoś obiektu zarządzanego przez OLE DB Driver for SQL Server, takiego jak obiekt źródła danych.

Szczegóły dotyczące OLE DB Driver for SQL Server wsparcia dla mirroringu baz danych można znaleźć w sekcji Inicjalizacja i Właściwości Autoryzacji.

Treści powiązane

  • Last updated on