Conectar clientes a uma sessão de espelhamento de banco de dados (SQL Server)

Aplica-se a:SQL Server

Para se conectar a uma sessão de espelhamento de banco de dados, um cliente pode usar o SQL Server Native Client ou o .NET Framework Provedor de Dados para o SQL Server. Quando configurados para um banco de dados do SQL Server, esses provedores de acesso de dados dão suporte completo ao espelhamento de banco de dados. Para obter informações sobre as considerações de programação para usar um banco de dados espelho, consulte Using Database Mirroring. Além disso, a instância de servidor principal atual deve estar disponível e o logon do cliente deve ter sido criado na instância de servidor. Para obter mais informações, confira Solucionar problemas de usuários órfãos (SQL Server). As conexões de cliente com uma sessão de espelhamento de banco de dados não envolvem a instância de servidor testemunha, se essa existir.

Estabelecendo a conexão inicial com uma sessão de espelhamento de banco de dados

Para a conexão inicial com um banco de dados espelho, um cliente deve fornecer uma cadeia de conexão que no mínimo forneça o nome de uma instância de servidor. Esse nome de servidor exigido deve identificar a instância do servidor principal atual e é conhecido como nome do parceiro inicial.

Opcionalmente, a cadeia de conexão também pode fornecer o nome de outra instância de servidor que deverá identificar a instância do servidor espelho atual para uso, se o parceiro inicial estiver indisponível durante a primeira tentativa de conexão. O segundo nome é conhecido como nome do parceiro de failover.

A cadeia de conexão também deve fornecer um nome de banco de dados. Isso é necessário para permitir tentativas de failover do provedor de acesso a dados.

Ao receber uma string de conexão, o provedor de acesso a dados armazena o nome do parceiro inicial e o nome do parceiro de failover, se fornecido, em um cache na memória volátil do cliente (para código gerenciado, o cache tem escopo no domínio do aplicativo). Uma vez em cache, o nome do parceiro inicial nunca é atualizado pelo provedor de acesso de dados. Quando o cliente fornece o nome de parceiro de failover, o provedor de acesso de dados também armazena temporariamente esse nome, caso o provedor não possa se conectar usando o nome do parceiro inicial.

Uma sessão de espelhamento de banco de dados não protege contra problemas de acesso ao servidor que sejam específicos dos clientes, como quando um computador cliente está tendo problemas de comunicação com a rede. Uma tentativa de conexão com um banco de dados espelho também pode falhar por várias razões não relacionadas ao provedor de acesso de dados; por exemplo, uma tentativa de conexão pode falhar porque a instância do servidor principal está inativa, como acontece quando o banco de dados cai ou por causa de um erro de rede.

Ao tentar se conectar, o provedor de acesso de dados começa usando o nome do parceiro inicial. Se a instância de servidor especificada estiver disponível e for a instância de servidor principal atual, a tentativa de conexão geralmente será bem-sucedida.

Se essa tentativa não funcionar, o provedor de acesso a dados tentará usar o nome do parceiro de failover, se disponível. Se um dos nomes do parceiro identificar corretamente o servidor principal atual, o provedor de acesso a dados normalmente consegue abrir a conexão inicial. Ao concluir essa conexão, o provedor de acesso de dados obtém o nome da instância do servidor espelho atual. Esse nome é armazenado no cache como o nome do parceiro de failover, sobrescrevendo o nome do parceiro de failover fornecido pelo cliente, se houver. Depois disso, o provedor de dados .NET Framework para o SQL Server não atualiza o nome do parceiro de failover. Em contraste, o SQL Server Native Client atualiza o cache sempre que uma conexão subsequente ou redefinição de conexão retorna um nome de parceiro diferente.

A figura a seguir ilustra uma conexão de cliente com o parceiro inicial, Partner_A, para um banco de dados espelho denominado Db_1. Esta figura mostra um caso em que o nome do parceiro inicial fornecido pelo cliente identifica corretamente o servidor principal atual, Partner_A. A tentativa de conexão inicial tem sucesso e o provedor de acesso a dados armazena o nome do servidor espelho (atualmente Partner_B) como o nome do parceiro de failover no cache local. Finalmente, o cliente se conecta à cópia principal do banco de dados Db_1 .

A tentativa de conexão inicial pode falhar, por exemplo, por causa de um erro de rede ou uma instância de servidor inativa. Como o parceiro inicial está indisponível, para que o provedor de acesso de dados tente se conectar ao parceiro de failover, o cliente deve ter fornecido o nome do parceiro de failover na cadeia de conexão.

Nesse caso, se o nome do parceiro de failover estiver indisponível, a tentativa de conexão original continuará até que ocorra o tempo limite da conexão de rede ou um erro seja retornado (assim como em um banco de dados não espelhado).

Quando o nome do parceiro de failover é fornecido na cadeia de conexão, o comportamento do provedor de acesso de dados dependerá do protocolo de rede e do sistema operacional do cliente, como segue:

• Para TCP/IP, as tentativas de conexão são governadas por um algoritmo de nova tentativa de conexão específico ao espelhamento de banco de dados. O algoritmo de nova tentativa de conexão determina o tempo máximo (o tempo de nova tentativa) designado para abrir uma conexão em uma determinada tentativa de conexão.

• Para outros protocolos de rede

  Se um erro ocorrer ou se o parceiro inicial estiver indisponível, a tentativa inicial de conexão aguardará até o fim do tempo limite para conexão na rede ou para logon, no provedor de acesso de dados. Geralmente, essa espera é de 20 a 30 segundos. Depois disso, se o tempo limite do provedor de acesso de dados não tiver expirado, ele tentará se conectar ao parceiro de failover. Se o tempo limite expirar antes que a conexão aconteça ou o parceiro de failover esteja indisponível, a tentativa de conexão falhará. Se o parceiro de failover estiver disponível dentro do período de tempo limite de logon e agora for o servidor principal, a tentativa de conexão normalmente é bem-sucedida.

Cadeias de conexão para um banco de dados espelho

A cadeia de conexão fornecida pelo cliente contém informações que o provedor de acesso de dados usa para se conectar ao banco de dados. Esta seção discute as palavras-chave especificamente relevantes para conexão com um banco de dados espelhado usando uma conexão de Driver ODBC do SQL Server Native Client.

Atributo de rede

A cadeia de conexão deve conter o atributo Network para especificar o protocolo de rede. Isso assegura que o protocolo de rede especificado persista entre conexões com parceiros diferentes. O melhor protocolo para se conectar a um banco de dados espelhado é o TCP/IP. Para garantir que o cliente solicite o TCP/IP em cada conexão com os parceiros, uma cadeia de conexão fornece o seguinte atributo:

Network=dbmssocn;   

Alternativamente, para garantir que o cliente solicite pipes nomeados para cada conexão com os parceiros, uma cadeia de conexão fornece o seguinte atributo:

Network=dbnmpntw;   

Atributo de servidor

A cadeia de conexão deve conter um atributo Server que forneça o nome do parceiro inicial que deverá identificar a instância do servidor principal atual.

A forma mais simples de identificar a instância do servidor é especificando o nome dela, <nome_do_servidor>[\<nome_da_instância_do_SQL_Server>]. Por exemplo:

Server=Partner_A;

ou

Server=Partner_A\Instance_2;

No entanto, quando o nome do sistema for usado, o cliente deverá executar uma pesquisa DNS para obter o endereço IP do servidor e uma consulta com o SQL Server Browser para obter o número de porta do servidor em que o parceiro reside. Essas pesquisas e consultas podem ser ignoradas especificando o endereço IP e o número de porta do parceiro no atributo Server , em vez de especificar o nome do servidor. Isso é recomendado para minimizar a possibilidade de atrasos externos durante a conexão com esse parceiro.

Para especificar o endereço IP e a porta, o atributo Server usa o formato Server=<>,<porta>, por exemplo:

Server=123.34.45.56,4724;   

Atributo de banco de dados

Além disso, a cadeia de conexão deve especificar o atributo Database para fornecer o nome do banco de dados espelho. Se o banco de dados estiver indisponível quando o cliente tentar se conectar, uma exceção é ativada.

Por exemplo, para se conectar expressamente ao banco de dados AdventureWorks no servidor principal Partner_A, um cliente usa a seguinte cadeia de conexão:

" Server=Partner_A; Database=AdventureWorks "

Atributo do Parceiro de Failover

Além do nome do parceiro inicial, o cliente também pode especificar o nome do parceiro de failover, que deve identificar a instância atual do servidor espelho. O parceiro de failover é especificado por uma das palavras-chave do atributo de parceiro de failover. A palavra-chave desse atributo depende da API em uso. A tabela a seguir lista estas palavras-chave:

A forma mais simples de identificar a instância do servidor é pelo seu nome do sistema, <nome_do_servidor>[\<nome_da_instância_do_SQL_Server>].

Como alternativa, o endereço IP e número da porta podem ser fornecidos no atributo Failover Partner . Se a tentativa de conexão inicial falhar durante a primeira conexão com o banco de dados, a tentativa para se conectar ao parceiro de failover não precisará depender do DNS e do SQL Server Browser. Quando uma conexão é estabelecida, o nome do parceiro de failover será atualizado com esse nome; assim, se ocorrer um failover, as conexões redirecionadas dependerão de DNS e do SQL Server Browser.

Cadeia de conexão de exemplo

Por exemplo, para fazer a conexão explícita com o banco de dados AdventureWorks usando o TCP/IP em Partner_A ou Partner_B, um aplicativo cliente que utiliza o driver ODBC pode fornecer a seguinte cadeia de conexão:

"Server=Partner_A; Failover_Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"  

Alternativamente, o cliente pode usar o endereço IP e número da porta para identificar o parceiro inicial, Partner_A; por exemplo, se o endereço IP for 250.65.43.21 e o número da porta for 4734, a cadeia de conexão será:

"Server=250.65.43.21,4734; Failover_Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"  

Algoritmo de nova tentativa de conexão (para conexões TCP/IP)

Para uma conexão TCP/IP, quando ambos os nomes de parceiro estiverem no cache, o provedor de acesso a dados aderirá a um algoritmo de nova tentativa de conexão. Isto é verdade tanto para fazer a conexão inicial para a sessão como para reconectar depois de perder uma conexão estabelecida. Quando uma conexão tiver sido estabelecida, completar os passos de pré-logon e logon leva tempo adicional.

Se uma tentativa de conexão falhar ou o tempo de nova tentativa expirar antes da conexão acontecer, o provedor de acesso de dados tentará o outro parceiro. Se uma conexão não for aberta neste ponto, o provedor tentará alternadamente os nomes do parceiro inicial e do failover, até que uma conexão seja aberta ou o período de logon expire. O período do tempo limite de logon padrão é de 15 segundos. Nós recomendamos que o período de tempo limite de logon seja pelo menos de 5 segundos. Especificar um período de tempo limite menor poderia impedir quaisquer das tentativas de conexão de ter êxito.

O tempo de nova tentativa é uma porcentagem do período de login. O tempo de espera para uma nova tentativa de conexão é maior a cada rodada sucessiva. Na primeira rodada, o tempo de nova tentativa para cada uma das duas tentativas é de 8% do período total de logon. Em cada rodada sucessiva, o algoritmo de repetição aumenta o tempo máximo de nova tentativa no mesmo valor. Assim, os tempos de nova tentativa para as primeiras oito tentativas de conexão são os seguintes:

8%, 8%, 16%, 16%, 24%, 24%, 32%, 32%

O tempo de nova tentativa é calculado com base na seguinte fórmula:

RetryTime=PreviousRetryTime+( 0.08 *LoginTimeout)

Onde PreviousRetryTime é inicialmente 0.

Por exemplo, se usar o período de intervalo de logon padrão de 15 segundos, LoginTimeout= 15. Nesse caso, os tempos de nova tentativa alocados nos primeiros três turnos são os seguintes:

A figura a seguir ilustra esses intervalos de repetição para tentativas sucessivas de conexão, cada uma das quais expira por tempo limite.

Para o período limite de logon padrão, o tempo máximo estimado para os primeiros três turnos de tentativas de conexão é de 14.4 segundos. Se toda tentativa consumisse todo o tempo alocado, restariam apenas 0,6 segundo antes que o período de logon expirasse. Nesse caso, a quarta rodada seria encurtada, permitindo apenas uma tentativa final rápida de conexão usando o nome do parceiro inicial. No entanto, uma tentativa de conexão pode falhar antes de esgotar o tempo alocado para repetição, especialmente em rodadas posteriores. Por exemplo, a ocorrência de um erro de rede pode fazer com que uma tentativa termine antes de o tempo de nova tentativa expirar. Se as primeiras tentativas falharem devido a um erro de rede, haveria tempo adicional disponível para o quarto turno e, talvez, turnos adicionais.

Outra causa de uma tentativa malsucedida é uma instância de servidor inativa, como ocorre quando uma instância de servidor está realizando o failover de seu banco de dados. Neste caso, é aplicado um intervalo de espera entre tentativas para impedir que os clientes sobrecarreguem os parceiros com uma rápida sucessão de tentativas de conexão.

Atrasos de nova tentativa durante o failover

Se um cliente tentar se conectar a um parceiro que está em failover, o parceiro responderá imediatamente que é inativo. Neste caso, cada rodada de tentativas de conexão é bem mais curta do que o tempo alocado para novas tentativas. Isso significa que muitas rodadas de tentativas de conexão podem ocorrer antes que o período de logon expire. Para evitar a sobrecarga dos parceiros com uma rápida sequência de tentativas de conexão durante um failover, o provedor de acesso a dados adiciona um breve intervalo de repetição após cada ciclo de novas tentativas. A duração de um atraso de repetição específico é determinada pelo algoritmo de atraso de repetição. Depois do primeiro turno, o retardo é 100 milissegundos. Após cada uma das próximas três rodadas, o atraso entre tentativas dobra para 200, 400 e 800. Em todos os últimos turnos, o atraso de nova tentativa é de 1 segundo até que a tentativa de conexão tenha êxito ou expire.

A figura seguinte ilustra como o atraso de nova tentativa afeta as tentativas de conexão durante um failover manual, no qual os parceiros trocam suas funções. O tempo limite de login é de 15 segundos.

Reconectando-se a uma sessão de espelhamento de banco de dados

Se uma conexão estabelecida com uma sessão de espelhamento de banco de dados falhar por qualquer motivo, por exemplo, devido a um failover no espelhamento de banco de dados, e o aplicativo tentar se reconectar ao servidor inicial, o provedor de acesso a dados poderá tentar se reconectar usando o nome do parceiro de 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. Nesse ponto, o provedor de acesso a dados redireciona a conexão para o 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 em que a cadeia de conexão especificou um nome de parceiro de failover. Se a primeira tentativa de conexão falhar, as tentativas de conexão se alternarão entre o nome do parceiro inicial e o nome do parceiro de failover até que o cliente se conecte ao servidor principal ou que o tempo limite do provedor de acesso a dados seja atingido.

Se as conexões usarem TCP/IP, o algoritmo de nova tentativa de conexão determinará o período de tempo designado para as tentativas de conexão em cada turno.

Impacto do redirecionamento em um aplicativo cliente

Após um failover, o provedor de acesso a dados redireciona a conexão para a instância atual do servidor principal. 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, no momento, o servidor espelho, o cliente poderá parecer estar conectado ao servidor espelho e atualizando o banco de dados de 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 do Transact-SQL para usar um banco de dados diferente. Isso poderá acontecer se a instância do servidor principal atual (o parceiro de failover) tiver um conjunto de bancos de dados diferente do servidor principal original (o parceiro inicial).

O impacto de um nome de parceiro de failover desatualizado

O administrador do banco de dados pode alterar o parceiro de failover a qualquer momento. Portanto, um nome de parceiro de failover fornecido pelo cliente pode estar desatualizado ou obsoleto. Por exemplo, considere um parceiro de failover chamado Partner_B que é substituído por outra instância de servidor, Partner_C. Agora, se um cliente fornecer Partner_B como nome do parceiro de failover, esse nome estará desatualizado. Quando o nome do parceiro de failover fornecido pelo cliente está desatualizado, o comportamento do provedor de acesso de dados é equiparado ao caso em que um nome de parceiro de failover não é fornecido pelo cliente.

Por exemplo, considere uma situação em que um cliente usa uma cadeia de conexão para uma série de quatro tentativas de conexão. Na cadeia de conexão, o nome do parceiro inicial é Partner_A e o nome do parceiro de failover é Partner_B:

"Server=Partner_A; Failover Partner=Partner_B; Database=AdventureWorks"  

A tabela a seguir mostra quatro configurações de parceiro e indica para cada uma se essa cadeia de conexão funciona para conexão com o cliente pela primeira vez.

Conteúdo relacionado

• Espelhamento de banco de dados (SQL Server)
• Possíveis falhas durante espelhamento de banco de dados