Espelhamento de Banco de Dados com o SQL Server 2005
Autor: Marivaldo de Souza | Publicado: 2011-07-10T17:25:00-07:00

O SQL Server 2005 trouxe um novo recurso para garantir a alta disponibilidade  das bases de dados, o recurso de espelhamento de bases de dados.  

O espelhamento de  uma base de dados se assemelha a uma evolução dos recursos de log shipping.  Através do espelhamento das bases de dados é feita a transferência e restauração  de logs automaticamente entre dois servidores.
O SQL Server 2005 trouxe um novo recurso para garantir a alta disponibilidade  das bases de dados, o recurso de espelhamento de bases de dados.  O espelhamento de  uma base de dados se assemelha a uma evolução dos recursos de log shipping.  Através do espelhamento das bases de dados é feita a transferência e restauração  de logs automaticamente entre dois servidores. A mirror de bases,  porém, é mais versátil que o log shipping, permitindo inclusive o desvio  automático dos acessos para o servidor espelho no caso da queda do servidor  principal. Então vamos fazer,  passo a passo, a implementação do database mirroring. Faremos esta implementação  utilizando o banco Northwind. O banco Northwind não é instalado por default no  SQL Server 2005, você precisa baixar os bancos de exemplo em ... e fazer a  instalação. Para fazer o  exemplo de mirroring precisaremos de 3 servidores. Não necessariamente 3  servidores em máquinas diferentes, neste exemplo instalarei 3 instâncias  diferentes do SQL Server 2005 na mesma máquina e farei o mirror entre estas 3  instâncias. Primeiramente,  precisamos que o banco de dados do servidor principal, que será espelhado,  esteja configurado com Recovery Model Full. O Recovery Model Full garante que o  log de transações será mantido para, desta forma, permitir o espelhamento.  Precisamos então  realizar um backup full do banco no servidor principal e fazer a recuperação do  backup no servidor espelho para então dar inicio ao processo de mirror.  No processo de  recuperação de um backup temos as opções Recovery e No Recovery que devemos  escolher para completar o processo. Trata-se da forma como o log de transações  será tratado. Na opção Recovery o servidor faz um processo (checkpoint) no log  de forma a manter o log integro e deixar o banco de dados no ar. Porém ao fazer  isso impede-se que novos backups sejam recuperados. Já com a opção NoRecovery,  isso não é realizado e consequentemente novos backups podem ser recuperados.  Como no nosso caso  estamos fazendo o restore em uma mesma máquina, devemos ter o cuidado de  direcionar a restauração do banco para um local diferente de onde estão os  arquivos do Principal.  O processo de  mirroring é de fato uma transferência do log de transações e restore do log.  Portanto precisamos fazer o restore do banco Northwind selecionando a opção  NoRecovery, para que possamos estabelecer o mirroring. Você deve ter  observado que desde o inicio citei que usaremos 3 instâncias para fazer o  mirror. Mas por que 3 ? Além do servidor  principal e do espelho, o processo de mirroring utiliza um 3o servidor chamado e  Witness. O servidor Witness tem a tarefa de garantir a alta disponibilidade do  mirror. O Witness vai observar falhas no servidor principal ou espelho e  inverter o papel de principal e espelho entre os dois. O uso de um  servidor witness é opcional, pode ser feito ou não. Mas apenas com o uso do  servidor witness a troca do servidor principal em caso de falha é feita  automaticamente. Por fim, vamos dar  inicio ao procedimento de espelhamento. Primeiramente é necessário  estabelecermos canais de comunicação entre os servidores.   Os canais de  comunicação são estabelecidos através de um novo recurso do SQL Server 2005  chamado HTTP Endpoint. Http EndPoints são pontos de comunicação HTTP que o  servidor pode criar para realizar a troca de dados.  Um HTTP EndPoint é  estabelecido através da especificação de uma porta e um protocolo de comunicação  - que é estabelecido na forma da especificação do tipo de mensagens que serão  trocadas.  No caso da  execução de mirroring, existem 3 opções de mensagens a serem trocadas pelos  servidores, as mensagens são definidas de acordo com a atuação do servidor no  processo de mirror : Partner, Witness ou ALL. Porém ao fazermos a configuração  pela interface visual isso será definido para nós. Como estaremos  trabalhando com uma única máquina, estaremos utilizando diferentes portas de  comunicação para cada http Endpoint, 5022, 5023 e 5024.    Observe a  possibilidade de criptografar a troca de dados    Cada servidor com  uma porta diferente por serem instâncias em uma mesma máquina   Cada servidor  precisa de acesso aos demais. Então se os servidores estiverem utilizando contas  de serviço diferentes, é preciso especifica-las para que ganhem acesso aos  servidores. Caso os servidores estejam utilizando as mesmas contas, basta deixar  em branco e clicar next.   Ao fazer a  configuração do mirror, temos mais uma escolha a fazer : Fazer o espelhamento  sincrono ou assincrono.   Espelhamento  Sincrono : No espelhamento sincrono a gravação no servidor de espelho é feita  transacionalmente junto com a gravação no servidor principal. Esta opção é  utilizada em caso de alta disponibilidade da comunicação entre os servidores.  Apenaso espelhamento sincrono permite a recuperação automatica em caso de  falhas, desde que esteja presente um servidor atuando como witnessEspelhamento  Assincrono : No espelhamento assincrono as transações são realizadas no servidor  principal e posteriormente espelhadas para o partner. Isso permite o  funcionamento do espelhamento em ambientes com instabilidade na comunicação  entre os servidores. Esta opção não permite a recuperação automatica com um  servidor witness   Vamos então criar  uma aplicação windows para demonstrar a forma como a aplicação será desviada de  um servidor para outro automaticamente. 1) Crie um novo  projeto windows 2) Na janela  DataSources, crie uma nova origem de dados apontando para o banco Northwind,  tabela Products, pegue os campos ProductID, ProductName, UnitPrice,  UnitsInStock   3) Na janela  datasources, selecione o formato details para a tabela products  4) Arraste a  tabela products para o formulário 5) Insira um botão  cmdRefresh com o texto Refresh 6) Insira um label  no formulário   7) Altere o código  do load, separe o código em uma sub chamanda "conectando" 8) Chame a sub  "conectando" do Load e do botão cmdRefresh      Private Sub Form1_Load(ByVal  sender As System.Object, ByVal e As  System.EventArgs) Handles MyBase.Load         conectando()    End Sub      Private Sub cmdRefresh_Click(ByVal sender As  System.Object, ByVal e As System.EventArgs) Handles cmdRefresh.Click         conectando()    End Sub 9) Na sub  conectando, implemente o código da seguinte forma :      Sub conectando()        Try            Me.ProductsTableAdapter.Connection.Open()            Me.ProductsTableAdapter.Fill(Me.DsProdutos.Products)            Label1.Text = Me.ProductsTableAdapter.Connection.DataSource            Me.ProductsTableAdapter.Connection.Close()            tentou = 0        Catch            If tentou =  0 Then                tentou = 1                Me.ProductsTableAdapter.Connection.Close()                conectando()            Else                MsgBox("Deu  tudo errado")            End If        End Try    End Sub Fazemos o  preenchimento do label com o nome do datasource, que é obtido pelo objeto de  conexão. A conexão ligada ao tableAdapter, então a linha de código :              Label1.Text = Me.ProductsTableAdapter.Connection.DataSource Separamos a  abertura e fechamento da conexão. Isso não é obrigatório para que o desvio da  conexão aconteça. Se não fizermos essa separação, o método Fill abrirá e fechará  a conexão automaticamente e o desvio de um servidor para outro acontecerá  normalmente. Mas apenas separando a conexão podemos identificar o servidor no  qual estamos conectando e fazer o preenchimento do label. O preenchimento do  label não funciona se a conexão já estiver fechada (não apontará para o servidor  certo). Quanto ao  tratamento de erro, quando um desvio de servidor vai acontecer, é devolvido um  erro para o client. Então tratamos o erro, fechamos a conexão e repetimos o  processo. É feita então a conexão ao servidor espelho e não ao principal, que  encontra-se off-line. Como  funciona ? No ADO.NET 2.0,  utilizando o data provider do SQL Server, no momento em que a conexão é feita o  servidor principal avisa ao client a existência de um mirror e o client faz o  cache do nome do mirror. Desta forma quando a conexão ao principal falha, o  desvio para o mirror acontece automaticamente. Para o caso da  primeira conexão falhar, podemos especificar o servidor de mirror diretamente na  string de conexão. Porém a especificação na string de conexão é utilizada apenas  no caso da falha na primeira conexão. Após a primeira conexão o client recebe o  nome do servidor de mirror do principal e guarda o nome em cache, passando a  ignorar o nome na string de conexão. Veja como  adicionar o mirror na connectionString :  ";Failover  Partner=PartnerServerName"  Teste  a aplicação  1) Rode a  aplicação2) Altere um  registro e grave3) Faça um stop no  servidor principal4) Clique no botão  refresh Você observará que  o nome do servidor no label irá mudar, agora você está conectado no mirror. Mas  a atualização da informações continua consistente.   5) Reinicie  novamente o serviço do servidor Principal Faça refresh na  pasta databases se necessário, você observará que agora o Principal retorna como  mirror e o mirror se mantem como principal6) Clique no botão  refresh A conexão continua  sendo feita ao antigo mirror, que agora atua como principal7) No mirror, que  agora é principal, clique com o botão direito no banco Northwind,  Tasks-&gt;Mirror e clique no botão FailOver.  Isso irá inverter  novamente o Principal e o espelho   8) Clique no botão  refresh da aplicação. Novamente a aplicação volta ao Principal
Fonte: http://www.bufaloinfo.com.br/artigos/coluna40.asp