Verwenden der Datenbankspiegelung (JDBC)

Bei der Datenbankspiegelung handelt es sich im Wesentlichen um eine Softwarelösung, um Datenbankverfügbarkeit und Datenredundanz zu verbessern. Microsoft SQL Server JDBC Driver beinhaltet eine implizite Unterstützung für die Datenbankspiegelung, sodass Entwickler keinen Code schreiben oder andere Aktionen ausführen müssen, wenn die Datenbankspiegelung für die Datenbank konfiguriert wurde.

Bei der Datenbankspiegelung, die für Datenbanken einzeln implementiert wird, befindet sich eine Kopie einer SQL Server-Produktionsdatenbank auf einem Standbyserver. Bei diesem Server handelt es sich abhängig von der Konfiguration und vom Status der Datenbank-Spiegelungssitzung um einen unmittelbar betriebsbereiten oder betriebsbereiten Standbyserver. Ein unmittelbar betriebsbereiter Standbyserver unterstützt einen schnellen Failover ohne Verlust von Transaktionen, für die ein Commit ausgeführt wurde. Ein betriebsbereiter Standbyserver sorgt lediglich dafür, dass der Dienst bereitgestellt wird (mit möglichem Datenverlust).

Die Produktionsdatenbank wird Prinzipaldatenbank genannt. Die Standbykopie wird Spiegeldatenbank genannt. Prinzipaldatenbank und Spiegeldatenbank müssen sich in getrennten Instanzen von SQL Server (Serverinstanzen) und nach Möglichkeit auf separaten Computern befinden.

Die Produktionsserverinstanz (Prinzipalserver) kommuniziert mit der Standbyserverinstanz (Spiegelserver). Prinzipal- und Spiegelserver fungieren in einer Datenbank-Spiegelungssitzung als Partner. Wenn der Prinzipalserver ausfällt, kann der Spiegelserver seine Datenbank über einen so genannten Failover als Prinzipaldatenbank bestimmen. Beispiel: Partner_A und Partner_B sind zwei Partnerserver, wobei sich die Prinzipaldatenbank zunächst auf Partner_A als Prinzipalserver und die Spiegeldatenbank auf Partner_B als Spiegelserver befindet. Wenn Partner_A in den Offlinemodus wechselt, kann die Datenbank auf Partner_B einen Failover ausführen und die aktuelle Prinzipaldatenbank werden. Wenn Partner_A wieder der Spiegelungssitzung beitritt, wird er der Spiegelungsserver und seine Datenbank die Spiegeldatenbank.

Falls der Server Partner_A irreparabel beschädigt wird, kann der Server Partner_C in den Onlinemodus versetzt werden und als Spiegelserver für Partner_B fungieren, der jetzt der Prinzipalserver ist. In diesem Szenario muss die Clientanwendung jedoch eine Programmlogik enthalten, die sicherstellt, dass die Verbindungszeichenfolgeneigenschaften mit den neuen Servernamen aktualisiert werden, die in der Datenbankspiegelungskonfiguration verwendet werden, da andernfalls keine Verbindung zu den Servern hergestellt werden kann.

Alternative Datenbankspiegelungskonfigurationen bieten andere Leistungsstufen und Datensicherheit und unterstützen andere Formen eines Failovers. Weitere Informationen finden Sie unter "Übersicht über die Datenbankspiegelung" in SQL Server-Onlinedokumentation.

Programmierüberlegungen

Wenn der Prinzipaldatenbankserver ausfällt, erhält die Clientanwendung nach API-Aufrufen Fehlermeldungen, die darauf hinweisen, dass die Verbindung zur Datenbank unterbrochen wurde. In diesem Fall gehen Änderungen verloren, für die kein Commit ausgeführt wurde, und für die aktuelle Transaktion wird ein Rollback ausgeführt. Die Anwendung muss dann die Verbindung schließen (oder das Datenquellenobjekt freigeben) und versuchen, eine neue Verbindung zu öffnen. Nachdem die Verbindung hergestellt wurde, wird die neue Verbindung transparent an die Spiegeldatenbank umgeleitet, die jetzt als Prinzipalserver fungiert, ohne dass der Client die Verbindungszeichenfolge oder das Datenquellenobjekt ändern muss.

Wenn die erste Verbindung hergestellt wird, sendet der Prinzipalserver die Identität seines Failoverpartners, der bei einem Failover verwendet wird, an den Client. Wenn eine Anwendung versucht, die erste Verbindung zu einem ausgefallenen Prinzipalserver herzustellen, kennt der Client die Identität des Failoverpartners nicht. Damit Clients in diesem Szenario eine Verbindung herstellen können, kann der Client mit der failoverPartner-Verbindungszeichenfolgeneigenschaft und optional mit der setFailoverPartner-Methode des Datenquellenobjekts die Identität des Failoverpartners selbst angeben. Die Clienteigenschaft wird nur in diesem Szenario verwendet. Sie wird nicht verwendet, wenn der Prinzipalserver verfügbar ist.

Wenn der vom Client angegebene Failoverpartnerserver kein Server ist, der als Failoverpartner für die angegebene Datenbank fungiert, wird die Verbindung vom Server abgelehnt. Obwohl die SQLServerDataSource-Klasse die getFailoverPartner-Methode enthält, gibt diese Methode nur den Namen des Failoverpartners zurück, der in der Verbindungszeichenfolge oder mit der setFailoverPartner-Methode festgelegt wurde. Mit der folgenden Transact-SQL-Anweisung können Sie den Namen des tatsächlichen Failoverpartners abrufen, der zurzeit verwendet wird:

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

Sie sollten erwägen, die Partnerinformationen zwischenzuspeichern, um die Verbindungszeichenfolge zu aktualisieren, oder eine Wiederholungsstrategie entwickeln, falls der erste Versuch, eine Verbindung herzustellen, fehlschlägt.

Beispiel

Im folgenden Beispiel wird versucht, zuerst eine Verbindung zum Prinzipalserver herzustellen. Wenn keine Verbindung hergestellt werden kann und eine Ausnahme ausgegeben wird, wird versucht, eine Verbindung zum Spiegelserver herzustellen, der zum neuen Prinzipalserver heraufgestuft wurde. Achten Sie auf die Verwendung der failoverPartner-Eigenschaft in der Verbindungszeichenfolge.

import java.sql.*;

public class clientFailover {

   public static void main(String[] args) {

      // Create a variable for the connection string.
      String connectionUrl = "jdbc:sqlserver://serverA:1433;" +
         "databaseName=AdventureWorks;integratedSecurity=true;" +
         "failoverPartner=serverB";

      // Declare the JDBC objects.
      Connection con = null;
      Statement stmt = null;

      try {
         // Establish the connection to the principal server.
         Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
         con = DriverManager.getConnection(connectionUrl);
         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.

         // Create and execute an SQL statement that inserts some data.
         stmt = con.createStatement();

         // 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)");
      }

      // Handle any errors that may have occurred.
      catch (SQLException se) {
         try {
            // The connection to the principal server failed,
            // try the mirror server which may now be the new
            // principal server.
            System.out.println("Connection to principal server failed, " +
            "trying the mirror server.");
            con = DriverManager.getConnection(connectionUrl);
            System.out.println("Connected to the new principal server.");
            stmt = con.createStatement();
            stmt.executeUpdate("INSERT INTO TestTable (Col2, Col3) VALUES ('a', 10)");
         }
         catch (Exception e) {
            e.printStackTrace();
         }
      }
      catch (Exception e) {
         e.printStackTrace();
      }
      // Close the JDBC objects.
      finally {
         if (stmt != null) try { stmt.close(); } catch(Exception e) {}
         if (con != null) try { con.close(); } catch(Exception e) {}
      }
   }
}

Siehe auch

Andere Ressourcen

Verbinden von SQL Server mit dem JDBC-Treiber