Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dublowanie baz danych to przede wszystkim rozwiązanie programowe zwiększające dostępność bazy danych i nadmiarowość danych. Sterownik JDBC firmy Microsoft dla programu SQL Server zapewnia niejawną obsługę dublowania bazy danych, dzięki czemu deweloper nie musi pisać żadnego kodu ani podejmować żadnych innych działań, gdy została skonfigurowana dla 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 rezerwy dynamicznej obsługuje szybkie przechodzenie w tryb failover bez utraty zatwierdzonych transakcji. Ciepły serwer rezerwowy obsługuje wymuszanie usługi (z możliwością utraty danych).
Produkcyjna baza danych jest nazywana bazą danych główną, a kopia rezerwowa bazą danych lustrzaną. Główna baza danych i baza danych lustrzana muszą znajdować się w oddzielnych wystąpieniach programu SQL Server (wystąpieniach serwera). Powinny one znajdować się na oddzielnych komputerach, jeśli to możliwe.
Wystąpienie serwera produkcyjnego (serwer główny) komunikuje się z wystąpieniem serwera rezerwowego (serwer lustrzany). Serwery główny i lustrzany działają jako partnerzy w ramach sesji dublowania bazy danych. Jeśli serwer główny ulegnie awarii, serwer lustrzany może zamienić swoją bazę danych na bazę główną za pomocą procesu nazywanego trybem przełączenia awaryjnego. 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.
Jeśli serwer Partner_A jest nieodwracalnie uszkodzony, serwer Partner_C może zostać przeniesiony do trybu online jako serwer dublowania dla Partner_B, który jest teraz serwerem głównym. Jednak w tym scenariuszu aplikacja kliencka musi zawierać logikę programowania, aby upewnić się, że właściwości parametrów połączenia są aktualizowane przy użyciu nowych nazw serwerów używanych w konfiguracji dublowania bazy danych. W przeciwnym razie połączenie z serwerami może zakończyć się niepowodzeniem.
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 "Omówienie dublowania bazy danych" w książkach programu SQL Server Online.
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 przypadku wystąpienia tych błędów wszelkie niezatwierdzone zmiany w bazie danych zostaną utracone i bieżąca transakcja zostanie wycofana. W tym scenariuszu aplikacja powinna zamknąć połączenie (lub zwolnić obiekt źródła danych) i spróbować otworzyć go ponownie. W przypadku połączenia nowe połączenie jest przezroczysto przekierowywane do dublowanej bazy danych, która obecnie pełni rolę serwera głównego, bez konieczności modyfikowania parametrów połączenia lub obiektu źródła danych.
Po nawiązaniu połączenia serwer główny wysyła tożsamość swojego partnera awaryjnego do klienta, który będzie używany w przypadku awarii. Gdy aplikacja próbuje nawiązać początkowe połączenie z serwerem głównym, który zakończył się niepowodzeniem, klient nie zna tożsamości partnera trybu failover. Aby umożliwić klientom radzenie sobie z tym scenariuszem, właściwość parametrów połączenia trybu failoverPartner i opcjonalnie metoda źródła danych setFailoverPartner umożliwia klientowi określenie tożsamości partnera trybu failover samodzielnie. Właściwość klienta jest używana tylko w tym scenariuszu; Jeśli serwer główny jest dostępny, nie jest używany.
Uwaga / Notatka
Jeśli element failoverPartner jest określony w parametrach połączenia lub w obiekcie źródła danych, właściwość databaseName musi być również ustawiona lub zostanie zgłoszony wyjątek. Jeśli program failoverPartner i databaseName nie zostaną jawnie określone, aplikacja nie podejmie próby przejścia w tryb failover, gdy główny serwer bazy danych ulegnie awarii. Innymi słowy, przezroczyste przekierowanie działa tylko dla połączeń, które jawnie określają failoverPartner i databaseName. Aby uzyskać więcej informacji na temat właściwości failoverPartner i innych właściwości ciągów połączenia, zobacz Ustawianie właściwości połączenia.
Jeśli serwer partnera trybu failover dostarczony przez klienta nie odwołuje się do serwera działającego jako partner trybu failover dla określonej bazy danych, a jeśli serwer/baza danych jest w układzie dublowanym, połączenie zostanie odrzucone przez serwer. Mimo że klasa SQLServerDataSource udostępnia metodę getFailoverPartner , ta metoda zwraca tylko nazwę partnera trybu failover określonego w parametrach połączenia lub metodzie setFailoverPartner. Aby pobrać nazwę rzeczywistego partnera trybu failover, który jest obecnie używany, użyj następującej instrukcji Transact-SQL:
SELECT m.mirroring_role_DESC, m.mirroring_state_DESC,
m.mirroring_partner_instance FROM sys.databases as db,
sys.database_mirroring AS m WHERE db.name = 'MirroringDBName'
AND db.database_id = m.database_id
Uwaga / Notatka
Należy zmienić to wyrażenie, aby użyć nazwy bazy danych mirroringu.
Rozważ buforowanie informacji o partnerze, aby zaktualizować parametry połączenia lub opracować strategię ponawiania prób w przypadku pierwszej próby nawiązania połączenia.
Example
W poniższym przykładzie najpierw podjęto próbę nawiązania połączenia z serwerem podstawowym. Jeśli to się nie powiedzie i zostanie zgłoszony wyjątek, zostanie podjęta próba nawiązania połączenia z serwerem lustrzanym, który mógł zostać podwyższony do nowego serwera głównego. Zwróć uwagę na użycie właściwości failoverPartner w parametrach połączenia.
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.sql.Statement;
public class ClientFailover {
public static void main(String[] args) {
String connectionUrl = "jdbc:sqlserver://serverA:1433;"
+ "encrypt=true;databaseName=AdventureWorks;integratedSecurity=true;"
+ "failoverPartner=serverB";
// Establish the connection to the principal server.
try (Connection con = DriverManager.getConnection(connectionUrl);
Statement stmt = con.createStatement();) {
System.out.println("Connected to the principal server.");
// Note that if a failover of serverA occurs here, then an
// exception will be thrown and the failover partner will
// be used in the first catch block below.
// Execute a SQL statement that inserts some data.
// Note that the following statement assumes that the
// TestTable table has been created in the AdventureWorks
// sample database.
stmt.executeUpdate("INSERT INTO TestTable (Col2, Col3) VALUES ('a', 10)");
}
catch (SQLException se) {
System.out.println("Connection to principal server failed, " + "trying the mirror server.");
// The connection to the principal server failed,
// try the mirror server which may now be the new
// principal server.
try (Connection con = DriverManager.getConnection(connectionUrl);
Statement stmt = con.createStatement();) {
System.out.println("Connected to the new principal server.");
stmt.executeUpdate("INSERT INTO TestTable (Col2, Col3) VALUES ('a', 10)");
}
// Handle any errors that may have occurred.
catch (SQLException e) {
e.printStackTrace();
}
}
}
}
Zobacz także
nawiązywanie połączenia z programem SQL Server za pomocą sterownika JDBC