Reconectando uma sessão de espelhamento de banco de dados
Se uma conexão estabelecida para uma sessão de espelhamento de banco de dados falhar por qualquer razão, por exemplo, devido a um banco de dados que espelha failover e o aplicativo tentar reconectar ao servidor inicial, o provedor de acesso de dados pode tentar reconectar usando o nome de parceiro do failover armazenado no cache do cliente. Porém, a reconexão não é automática. O aplicativo deve se dar conta do erro. Então, o aplicativo precisa fechar a conexão com falha e abrir uma conexão nova que use os mesmos atributos de cadeia de caracteres de conexão. Neste momento, o provedor de acesso de dados redireciona a conexão ao parceiro de failover. Se a instância de servidor identificada por este nome for atualmente o servidor principal, a tentativa de conexão normalmente terá sucesso. Caso estiver obscuro se uma transação foi confirmada ou revertida, o aplicativo deve inspecionar o estado da transação, da mesma maneira como ao reconectar a uma instância de servidor autônoma.
A reconexão se assemelha a uma conexão inicial para a qual a cadeia de caracteres de conexão forneceu um nome de parceiro de failover. Se a primeira tentativa de conexão falhar, as tentativas de conexão alternarão seguidamente entre o nome do parceiro inicial e o nome do parceiro de failover até que o cliente conecte ao servidor principal ou o provedor de acesso de dados expire o tempo limite.
Observação |
---|
O SQL Server Native Client verifica que se conecta a uma instância de servidor principal, mas não se esta instância é o parceiro de instância de servidor especificado no nome de parceiro inicial da cadeia de caracteres de conexão. |
Se as conexões usarem o TCP/IP e o cliente usar Windows XP ou uma versão posterior, o algoritmo da nova tentativa de conexão determina a quantia de hora destinada às tentativas de conexão em cada turno. Para obter mais informações, consulte Usando palavras-chave da cadeia de conexão com o SQL Server Native Client.
Importante |
---|
Se o cliente for desconectado do banco de dados, o provedor de acesso de dados não tentará reconectar. O cliente deverá emitir uma solicitação de conexão nova. Também, se um aplicativo desligar ao perder a conexão, perderá os nomes do parceiro em cache. Se a conexão se perder porque o servidor principal ficou indisponível, o único modo pelo qual o aplicativo pode reconectar ao servidor espelho é provendo o nome do parceiro de failover em sua cadeia de caracteres de conexão. |
Impacto da redireção em um aplicativo cliente
Depois de um failover, o provedor de acesso de dados redireciona a conexão com a instância do servidor principal atual. Porém, a redireção é transparente aos clientes. Para um cliente, uma conexão redirecionada parece ser uma conexão com a instância de servidor identificada pelo nome do parceiro inicial. Quando o parceiro inicial for atualmente o servidor espelho, o cliente poderá parecer estar conectado ao servidor espelho e atualizando o banco de dados espelho. Porém, de fato o cliente foi redirecionado ao parceiro de failover que é o banco de dados principal atual e o cliente está atualizando o banco de dados principal novo.
Depois de ser redirecionado ao parceiro de failover, um cliente pode experimentar resultados inesperados ao usar uma instrução USE Transact-SQL para usar um banco de dados diferente. Isto poderá acontecer se a instância de servidor principal atual (o parceiro de failover) tiver um conjunto de bancos de dados diferente do servidor principal original (o parceiro inicial).
Consulte também