Použití zrcadlení databáze (JDBC)

Stáhnout ovladač JDBC

Zrcadlení databáze je primárně softwarové řešení pro zvýšení dostupnosti databáze a redundance dat. Ovladač Microsoft JDBC pro SQL Server poskytuje implicitní podporu pro zrcadlení databáze, takže vývojář nemusí psát žádný kód ani provádět jakoukoli jinou akci, když je pro databázi nakonfigurován.

Zrcadlení databáze, které se implementuje pro každou databázi, uchovává kopii produkční databáze SQL Serveru na pohotovostním serveru. Tento server je buď horký nebo teplý pohotovostní server v závislosti na konfiguraci a stavu relace zrcadlení databáze. Aktivní pohotovostní server podporuje rychlé převzetí služeb při selhání bez ztráty potvrzených transakcí. Zahřátý záložní server podporuje nucené spuštění služby (s možnou ztrátou dat).

Produkční databáze se nazývá hlavní databáze a pohotovostní kopie se nazývá zrcadlová databáze. Hlavní databáze a zrcadlová databáze musí být na samostatných instancích SQL Serveru (instance serveru). Pokud je to možné, měly by se nacházet na samostatných počítačích.

Instance produkčního serveru (hlavní server) komunikuje s instancí pohotovostního serveru (zrcadlový server). Hlavní a zrcadlové servery fungují jako partneři v rámci relace zrcadlení databáze. Pokud hlavní server selže, může zrcadlový server povýšit jeho databázi na hlavní databázi procesem označovaným jako převzetí služeb při selhání. Například Partner_A a Partner_B jsou dva partnerské servery, hlavní databáze je zpočátku na Partner_A jako hlavní server a zrcadlová databáze umístěná na Partner_B jako zrcadlový server. Pokud Partner_A přejde do režimu offline, databáze na Partner_B může převzít úlohu primární databáze a stát se aktuální primární databází. Když se Partner_A znovu připojí k relaci zrcadlení, stane se zrcadlovým serverem a jeho databáze se stane zrcadlovou databází.

Pokud je server Partner_A nenávratně poškozený, lze uvést server Partner_C online, aby fungoval jako zrcadlový server pro Partner_B, což je nyní primární server. V tomto scénáři však klientská aplikace musí obsahovat programovací logiku, aby se zajistilo, že vlastnosti připojovacího řetězce budou aktualizovány novými názvy serverů použitých v konfiguraci zrcadlení databáze. Jinak může dojít k selhání připojení k serverům.

Alternativní konfigurace zrcadlení databáze nabízejí různé úrovně výkonu a bezpečnosti dat a podporují různé formy převzetí při selhání. Další informace naleznete v tématu "Přehled zrcadlení databáze" v SQL Server Books Online.

Aspekty programování

Když hlavní databázový server selže, klientská aplikace obdrží chyby v reakci na volání rozhraní API, což znamená, že připojení k databázi bylo ztraceno. Pokud dojde k těmto chybám, všechny nepotvrzené změny databáze budou ztraceny a aktuální transakce se vrátí zpět. V tomto scénáři by aplikace měla připojení zavřít (nebo uvolnit objekt zdroje dat) a pokusit se ho znovu otevřít. Při připojení je nové připojení transparentně přesměrováno do zrcadlové databáze, která teď funguje jako hlavní server, aniž by klient musel upravovat připojovací řetězec nebo objekt zdroje dat.

Při počátečním navázání připojení odešle hlavní server identitu svého partnera pro převzetí služeb při selhání klientovi, který bude použit v případě selhání. Když se aplikace pokusí navázat počáteční připojení k hlavnímu serveru, který selhal, klient nezná identitu partnera pro převzetí služeb při selhání. Pokud chcete klientům umožnit vyrovnat se s tímto scénářem, vlastnost připojovacího řetězce pro převzetí funkcí při selhání, a volitelně i metodu setFailoverPartner zdroje dat, umožňuje klientovi autonomně určit identitu partnera pro převzetí funkcí při selhání. Vlastnost klienta se používá pouze v tomto scénáři; pokud je hlavní server dostupný, nepoužívá se.

Poznámka:

Pokud je v připojovacím řetězci nebo u objektu zdroje dat zadaný parametr failoverPartner, musí být vlastnost databaseName také nastavena, nebo bude vyvolána výjimka. Pokud nejsou explicitně zadány hodnoty partnera pro převzetí služeb při selhání a názvu databáze, aplikace se při selhání hlavního databázového serveru nepokusí provést převzetí služeb při selhání. Jinými slovy, transparentní přesměrování funguje pouze pro připojení, která explicitně určují failoverPartner a název databáze. Další informace o vlastnosti failoverPartner a ostatních vlastnostech připojovacího řetězce naleznete v tématu Nastavení vlastností připojení.

Pokud partnerský server pro převzetí služeb při selhání poskytnutý klientem neodkazuje na server sloužící jako partnerský server pro převzetí služeb při selhání pro zadanou databázi a pokud je uvedený server/databáze v zrcadlovém uspořádání, server připojení odmítne. Ačkoli třída SQLServerDataSource poskytuje metodu getFailoverPartner, tato metoda vrátí pouze název partnera převzetí služeb při selhání zadaný v připojovacím řetězci nebo metodě setFailoverPartner. Pokud chcete načíst název skutečného partnera pro převzetí služeb při selhání, který se právě používá, použijte následující příkaz 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

Poznámka:

Tento prohlášení budete muset změnit tak, aby používalo název vaší zrcadlené databáze.

Zvažte uložení informací o partnerovi do mezipaměti, abyste aktualizovali připojovací řetězec nebo navrhli strategii opakování v případě, že první pokus o připojení selže.

Example

V následujícím příkladu se nejprve provede pokus o připojení k hlavnímu serveru. Pokud dojde k selhání a vyvolá se výjimka, provede se pokus o připojení k zrcadlenému serveru, který mohl být povýšen na nový hlavní server. Poznamenejte si použití vlastnosti failoverPartner v připojovacím řetězci.

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();
            }
        }
    }
}

Viz také

připojení k SQL Serveru pomocí ovladače JDBC