Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
O espelhamento de bases de dados é principalmente uma solução de software para aumentar a disponibilidade das bases de dados e a redundância dos dados. O Microsoft JDBC Driver para SQL Server fornece suporte implícito para espelhamento de bases de dados, para que o programador não precise de escrever qualquer código ou tomar qualquer outra ação quando este estiver configurado para a base de dados.
O espelhamento de bases de dados, que é implementado por base de dados, mantém uma cópia de uma base de dados de produção SQL Server num servidor de espera. Este servidor é um servidor de espera quente ou morno, dependendo da configuração e do estado da sessão de espelhamento da base de dados. Um servidor de espera quente suporta failover rápido sem perda de transações comprometidas. Um servidor de espera quente suporta o forcing service (com possível perda de dados).
A base de dados de produção é chamada de base de dados principal , e a cópia de reserva é chamada de base de dados espelhada . A base de dados principal e a base de dados espelhada devem estar em instâncias separadas de SQL Server (instâncias servidor). Devem estar em computadores separados, se possível.
A instância do servidor de produção (o servidor principal) comunica com a instância do servidor de espera (o servidor espelho). Os servidores principal e os servidores espelho atuam como parceiros dentro de uma sessão de espelhamento de base de dados. Se o servidor principal falhar, o servidor espelho pode tornar a sua base de dados a base de dados principal através de um processo chamado failover. Por exemplo, Partner_A e Partner_B são dois servidores parceiros, com a base de dados principal inicialmente em Partner_A como servidor principal, e a base de dados espelhada a residir em Partner_B como servidor espelho. Se Partner_A ficar offline, a base de dados na Partner_B pode fazer failover para se tornar a base de dados principal atual. Quando Partner_A volta a juntar-se à sessão de espelhamento, torna-se o servidor espelho e a sua base de dados torna-se a base de dados espelhada.
Se o servidor Partner_A for irremediavelmente danificado, um servidor Partner_C pode ser ativado para atuar como servidor espelho para o Partner_B, que é agora o servidor principal. No entanto, neste cenário, a aplicação cliente deve incluir lógica de programação para garantir que as propriedades da string de ligação sejam atualizadas com os novos nomes de servidores usados na configuração de espelhamento da base de dados. Caso contrário, a ligação aos servidores pode falhar.
Configurações alternativas de espelhamento de bases de dados oferecem diferentes níveis de desempenho e segurança de dados, e suportam diferentes formas de failover. Para mais informações, consulte "Visão Geral do Espelhamento de Bases de Dados" em SQL Server Books Online.
Considerações de programação
Quando o servidor principal da base de dados falha, a aplicação cliente recebe erros em resposta a chamadas de API, que indicam que a ligação à base de dados foi perdida. Quando estes erros ocorrem, quaisquer alterações não comprometidas na base de dados são perdidas e a transação atual é revertida. Neste cenário, a aplicação deve fechar a ligação (ou libertar o objeto fonte de dados) e tentar reabri-la. Na ligação, a nova ligação é redirecionada de forma transparente para a base de dados espelhada, que agora atua como servidor principal, sem que o cliente tenha de modificar a string de ligação ou o objeto fonte de dados.
Quando uma ligação é inicialmente estabelecida, o servidor principal envia a identidade do seu parceiro de failover para o cliente que será usado quando ocorrer o failover. Quando uma aplicação tenta estabelecer uma ligação inicial com um servidor principal avariado, o cliente não conhece a identidade do parceiro de failover. Para permitir que os clientes tenham a oportunidade de lidar com este cenário, a propriedade de cadeia de conexão FailoverPartner, e opcionalmente o método de fonte de dados setFailoverPartner, permite que o cliente especifique a identidade do parceiro de contingência por conta própria. A propriedade cliente é usada apenas neste cenário; Se o servidor principal estiver disponível, não é utilizado.
Observação
Quando um failoverPartner é especificado, seja na string de conexão ou com um objeto de fonte de dados, a propriedade databaseName também deve ser definida, caso contrário, será lançada uma exceção. Se o Parceiro de failover e o Nome da base de dados não forem especificados explicitamente, a aplicação não tentará fazer failover quando o servidor principal da base de dados falhar. Ou seja, a redireção transparente só funciona para ligações que especificam explicitamente o failoverPartner e o databaseName. Para mais informações sobre o FailoverPartner e outras propriedades da cadeia de ligação, consulte Definir as propriedades da ligação.
Se o servidor parceiro de failover fornecido pelo cliente não se referir a um servidor a atuar como parceiro de failover para a base de dados especificada, e se o servidor/base de dados referido estiver numa configuração espelhada, a ligação é recusada pelo servidor. Embora a classe SQLServerDataSource forneça o método getFailoverPartner , este método apenas devolve o nome do parceiro de failover especificado na string de ligação ou do método setFailoverPartner. Para recuperar o nome do parceiro de failover real que está atualmente a ser utilizado, use a seguinte Transact-SQL instrução:
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
Observação
Terá de modificar esta instrução para utilizar o nome da sua base de dados de espelhamento.
Considere armazenar em cache a informação do parceiro para, caso a primeira tentativa de conexão falhe, atualizar a cadeia de conexão ou criar uma estratégia de repetição.
Example
No exemplo seguinte, faz-se primeiro uma tentativa de ligação ao servidor principal. Se isso falhar e for lançada uma exceção, faz-se uma tentativa de ligação ao servidor espelho, que pode ter sido promovido para o novo servidor principal. Note a utilização da propriedade failoverPartner na string de conexão.
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();
}
}
}
}