Estratégia de failover do SQL Server 2008 - Envio de logs ou replicação?

Question

Acabamos de mudar do SQL Server 2000 para o SQL Server 2008.

Estávamos usando nosso próprio envio de log em 2000 para failover. Para 2008, precisamos decidir usar nosso próprio log shipping, log shipping ou replicação.

Temos muitos bancos de dados em nosso servidor (400+); alguns pequenos, alguns grandes.

Uma falha no servidor de banco de dados deve ser rara e podemos aceitar uma perda de dados de 15 a 30 minutos. Mais importante é fazer com que o segundo servidor de banco de dados seja rápido.

Com base nos critérios acima, sou melhor com o envio ou replicação de log?

Se o envio de log, há uma maneira fácil de garantir que ele se move sobre todos os bancos de dados?

    

Answer 1

Para todos aqueles que sugerem o espelhamento - não será possível espelhar 400 bancos de dados. Você ficará sem threads de trabalho antes de atingir 400, seja em 32 ou 64 bits. Há pelo menos 2 threads de trabalho por banco de dados no principal e pelo menos 3 por banco de dados no espelho.

Realmente não tem nada a ver com as habilidades do DBA. Depende inteiramente do que os requisitos de HA do negócio ou aplicativo são - esses são os fatores determinantes, e não o que o DBA pode suportar. Se uma solução mais complexa for exigida , então, obter um DBA para lidar com ela também é necessário . Limitar sua solução de HA por causa das habilidades do DBA é sem sentido.

O espelhamento de banco de dados também não é de detecção rápida e failover rápido - depende inteiramente de qual é a falha, qual é o tempo limite do parceiro de espelhamento, quais são as filas SEND e REDO. Pode demorar um pouco para que um failover termine, e o espelho decide se tornar o principal. Ajudei muitos clientes a implementar o espelhamento (tanto na Microsoft quando eu possuía espelhamento de banco de dados junto com o restante do Storage Engine), e desde a saída em 2007.

Esqueça o espelhamento desse número de bancos de dados.

Existem algumas perguntas fundamentais que você precisa responder antes de podermos lhe dar uma recomendação:

• Você quer ter uma cópia redundante de todos os bancos de dados ou apenas porções?
• Você quer poder usar as cópias redundantes? Para gravações ou apenas para leituras?
• Qual é a taxa de geração de log de transações dos bancos de dados?
• Qual é a largura de banda da rede entre os dois sites?

O envio de log é provavelmente o mais fácil para você, tanto em termos de configuração, monitoramento e capacidade de trazer as cópias redundantes apenas rapidamente e dentro dos seus limites de perda de dados. Com o envio de logs, você pode optar por colocar as cópias redundantes on-line sem concluir a restauração de todos os backups de log de transações enfileirados para restauração, aceitando a perda de dados.

Você também pode efetuar failovers simples usando uma tecnologia de roteamento intermediária ou até mesmo algo tão simples como o NLB do Windows com configuração 0/100 ou alternar para 100/0. Eu também vi clientes usando a comutação DNS para efetuar failovers quando o nome do servidor não pode mudar.

Com a replicação, você precisa lidar com a latência imprevisível entre as transações que estão sendo colhidas do log de transações do banco de dados da publicação, atingindo o banco de dados de distribuição e sendo então enviadas / recebidas para o banco de dados de assinaturas pelo agente de distribuição. A replicação também pode ser distorcida e dificultar a tarefa de descobrir e redefinir - o envio de logs é muito simples.

Considerando que você usa seu próprio envio de logs, acredito que a taxa de geração de logs e a largura de banda da rede não sejam um problema. Eu ficaria com o envio de logs e evitaria a replicação. Nem pense no espelhamento de banco de dados, pois ele não funcionará para o seu volume.

Espero que isso ajude - isso é realmente dois dias de discussão quando eu ensinar HA aos DBAs dentro da Microsoft - resumido em 5 minutos respondendo isso. Sinta-se à vontade para fazer follow-up com perguntas mais específicas nos comentários.

    

Answer 2

Usamos o espelhamento para recuperação on-the-up no local.

Para os backups externos da WAN (por exemplo, alta latência), usamos o envio de logs incorporado.

Note que na opção OUER você precisa configurar o PER DATABASE que, para 400 DBs, será uma dor gigantesca na parte traseira.

Você usa uma matriz de armazenamento (SAN ou NAS)? O método mais fácil parece ser a replicação em nível de bloco por meio de seus snaps de storage array (com o plug-in quiesce apropriado do SQL Server) - que capturará CADA banco de dados de forma automática.

    

Answer 3

Aqui estão alguns pensamentos adicionais:

Eu não acredito que a replicação é o caminho a percorrer. Normalmente, vejo a replicação como uma forma de distribuir dados e não como uma solução de DR. Ao tentar replicar 400 bancos de dados, você provavelmente enfatizará as funções do distribuidor e do editor, o que pode, eventualmente, colocar o servidor de joelhos. Além disso, será um pesadelo implementar, gerenciar e manipular alterações de esquema, já que você precisa configurar um editor e um assinante para cada banco de dados.

De uma perspectiva de envio de log, sim, isso pode ser feito, no entanto, novamente, será um desafio implementar e gerenciar, já que você precisa implementar o envio de log em cada banco de dados. Se ocorrer uma falha, você deverá colocar manualmente cada banco de dados online e voltar a apontar todos os seus aplicativos. Dependendo da sua carga de trabalho, provavelmente a solução não será dimensionada para 400 bancos de dados. Então, por favor teste.

Ao lidar com esses muitos bancos de dados, é melhor implementar uma solução de Geo-Cluster ou usar alguma forma de replicação de SAN e trabalhar no nível de volume ou bloco. Se você não tiver um SAN, softwares de terceiros, como o InMage ou o Doubletake, podem resolver o problema.

Lembre-se de que cada tecnologia, como Envio de Log, Espelhamento de Banco de Dados ou Replicação, pode aumentar significativamente a carga de trabalho e afetar negativamente o desempenho dos servidores. Portanto, conduza o teste de desempenho antes de começar a produção.

Se você decidir enviar o log, poderá fazer o script de todo o processo, incluindo o failover.

Ross Mistry, MVP de SQL

Autor - Gerenciamento e Administração do SQL Server 2008 e Windows Server 2008 Unleashed

Twitter - @RossMistry

    

Answer 4

Depende muito da habilidade do seu DBA.
Se você tiver um DBA habilitado, o espelhamento é a opção mais segura com o failover mais rápido se você configurá-lo com um servidor testemunha e, em seguida, o "cliente" não deve notar nada, exceto um pequeno atraso. Se o seu DBA é menos habilitado, o envio de log é o caminho a percorrer, mas ele possui uma rotina de failover mais complicada que envolve a reprodução de transações que ainda não foram confirmadas no arquivo de dados principal e que não foram transferidas. Se você não quer perder mais de 15 a 30 minutos de dados, o espelhamento seria a melhor opção.
Se você estiver fazendo isso com apenas dois servidores, deverá configurá-lo para o modo de alta segurança. O terceiro servidor Witness opcional pode ser uma instância do SQL2008 express, portanto, você está apenas com o custo mínimo de hardware, portanto não descarte isso como uma opção. Eu escrevi um guia sobre como espelhar dois servidores SQL 2005 que não são membros de um domínio neste modo e está disponível @ link
Neste cenário, o failover é manual (mas rápido), existe apenas a possibilidade de uma transação ser perdida (supondo que seu espelho esteja operando corretamente) MAS os clientes que estão se conectando a ele precisarão ser movidos mais manualmente (ou através de uma mudança de DNS se você está fazendo TCP / IP e não usando pipes nomeados, pipes nomeados podem muito bem funcionar, mas eu não poderia dizer com certeza)

    

Answer 5

Quanto dinheiro sua empresa tem?

Se eles forem fluentes e houver um requisito para mover todos os bancos de dados, um cluster ativo / passivo de dois nós com replicação SAN quente para outro cluster ativo / passivo fora do local faria o seguinte: )

Se não, mantenha o log-shipping - 2008 O Enterprise oferece os benefícios dos backups de log compactados (ao custo de cpu) e todas as edições do SQL a partir de 2005 têm a capacidade de fazer backups de log simultaneamente com backups completos ( que foi problemático em 2000 caixas com grandes volumes de atividade transacional).

    

Answer 6

O segundo banco de dados é apenas para failover ou você também poderá usá-lo, por exemplo, para relatórios de MI.

Já olhou para o espelhamento também?

Você tem um orçamento para isso ou está procurando usar as ferramentas internas? Eu usei o envio de log e replicação no passado, mas atualmente estou usando Double Take, que tem sido fantástico até agora.

    

Answer 7

Se você investiu muito tempo na criação do sistema para registrar manualmente mais de 400 bancos de dados, e funciona, eu continuaria com ele. Se ele for remendado e uma dor para continuar correndo (esteja lá), pode ser hora de mudar e ir com o espelhamento.

    

Answer 8

Se você tentar usar o espelhamento de banco de dados, eu acho que você vai ficar sem threads de trabalho bem antes de chegar a 100 bancos de dados, e muito menos 400 +. Dê uma olhada no this .

Cada banco de dados espelhado usa alguns segmentos e o SQL Server é configurado apenas para ser executado com 255 segmentos por padrão. Quando você fica sem threads de trabalho, coisas infelizes acontecem. Eu corri servidores que foram configurados com mais threads (512, IIRC), mas parecia deixar o MS muito nervoso. Fazer algo que deixa a MS nervosa tende a acabar mal.

Eu acho que você poderia ir com 400 bancos de dados enviados por logs, assumindo que não há muito tráfego de logs e que você escreve algumas ferramentas para ajudá-lo a configurá-los e monitorá-los. As ferramentas podem ser escritas em tsql ou algo parecido com o powershell.

Os problemas reais com o envio de log, para mim, foram mais para garantir que você tenha os mesmos logons / pacotes / servidores vinculados / etc no outro servidor, garantindo que os mesmos trabalhos estejam no servidor de failover (mas desativado até que você precise habilitá-los, e você precisa de uma maneira de habilitá-los e desativá-los), retornando de volta para o site primário original, como restabelecer o envio de log quando uma sequência de log for quebrada razão, esse tipo de coisa. Ao fazer implantações, é fácil esquecer de fazer o outro servidor.

    

Answer 9

link

Diz que 10 DBs espelhados são o máximo para uma máquina de 32 bits.