Alta disponibilidade no SQL Server, contras e vantagens das soluções?

Question

Estou estudando sobre alta disponibilidade no SQL Server para minha tese. Eu aprendi que existem várias soluções para arquivar isso:

• Cluster de failover
• Envio de log
• Replicação

Como eu sei, essas soluções foram suportadas na versão anterior do SQL Server 2008. O SQLS 2008 fornece espelhamento de banco de dados, que é suposto como uma solução melhor . Eu realmente duvido disso. Você pode, por favor, me contar os contras e vantagens dessas soluções, quais estratégias devem ser usadas e quais estratégias não devem. Informações detalhadas e explicações me ajudariam muito

Muito obrigado.

    

Answer 1

O Brent cobriu o envio de logs e o espelhamento de banco de dados bem, então não vou entrar nisso. A leitura obrigatória sobre este tópico é o livro de Allan Hirt, High Availability do Pro SQL Server 2005 . Eu sei que isso é para 2005, mas é 95% relevante para o SQL Server 2008 também. Você deve ler isto para ter uma boa compreensão das opções disponíveis. Aqui estão minhas adições à resposta de Brent:

Cluster de failover

Se recursos financeiros, de energia e de sala de servidores não forem uma restrição, essa é minha escolha preferida para alta disponibilidade para o SQL Server. Você precisa de armazenamento em disco compartilhado, geralmente uma SAN para que isso funcione e eu prefiro colocar as unidades C na SAN também para DR fácil. A maneira como eu o configuro é ter um LUN (Q) de quorum, um LUN (M) do MSDTC e um ponto de montagem para cada Instância do SQL Server no cluster. Dentro do ponto de montagem, configure um LUN para SQLData, SQLLogs, SQLBackups e, opcionalmente, SQLtempdb. Para UMA instância, você terminará com D: \ SQLData, D: \ SQLLogs, D: \ SQLbackups, D: \ SQLtempdb (por exemplo). Para a próxima instância, você pode ter E: \ SQLData, E: \ SQLLogs, E: \ SQLBackups, E: \ SQLtempdb. Todos os discos compartilhados precisam ser apresentados a todos os nós no cluster. O failover é automático e demora cerca de 20 segundos no meu ambiente de produção. É robusto, mas pode ser difícil de configurar se você é inexperiente.

Servidores SQL Virtualizados

Uma opção que você não explorou é o uso do servidor vmware ESX para hospedar seus servidores de banco de dados. Eu realmente gosto dessa opção, mas ainda não tenho confiança para implantá-la em ambientes de produção. Eu o implantei com muito sucesso em ambientes de não produção e a tecnologia é excelente. Eu acho que é adequado apenas para SQL Servers moderados a levemente carregados e não deve ser usado se o desempenho for crítico ou se você tiver altas cargas de trabalho. Um mapeamento de um para um do SQL Server para hosts ESX é uma configuração muito desejável. vmware O VMotion é uma excelente tecnologia com tempos de inatividade muito mais curtos do que o clustering de failover. Eu vi uma demonstração de um vídeo sendo reproduzido em um servidor e o servidor falhou com o vídeo sendo executado sem problemas. Agora, isso é impressionante!

Replicação do SQL Server

Isso pode não funcionar bem para aplicativos de terceiros, pois pode exigir alterações no esquema. A replicação do SQL Server não foi projetada para alta disponibilidade, mas foi projetada para disponibilizar cópias de dados em outros locais. Eu não recomendaria usar isso para alta disponibilidade devido às complexidades do mesmo. No entanto, pode ser útil em determinados cenários devido ao baixo nível de granularidade que oferece - você pode fazer particionamento horizontal e vertical de dados, por exemplo.

Replicação de disco de terceiros

Uma solução como o double take da NSI também pode ser considerada para alta disponibilidade, no entanto, prefiro usá-la para recuperação de desastre em sistemas não baseados em SAN. Ele basicamente replica dados no nível de bloco para um servidor de destino e o servidor de destino assiste ao servidor de origem para disponibilidade. Se ele ficar indisponível, ele acionará uma condição de failover e você poderá configurá-lo para fazer failover ou alertar automaticamente para failover manual. Tempos de failover são semelhantes ao clustering do SQL Server. As vantagens são que você não precisa de nenhum hardware especial para fazer isso, mas as licenças de software podem ser caras.

Backup e restauração

Não é realmente uma solução de alta disponibilidade, mas para algumas pessoas com requisitos mais frouxos, essa solução muito simples pode oferecer tudo o que você precisa. Basta fazer backup dos bancos de dados em um agendamento para um servidor de backup e verificar se os arquivos de backup estão disponíveis na máquina de destino. Configure um trabalho para restaurar os arquivos à medida que eles são copiados e você tem uma solução bruta de alta disponibilidade a um preço baixo.

    

Answer 2

Envio de log:

Visão geral: as transações no principal são enfileiradas no disco e, em seguida, enviadas para espelhar com base no agendamento de replicação. Os logs são aplicados ao banco de dados espelhado com base em um agendamento.

SQL Edition: Standard, Enterprise

Esforço de administração: configure o compartilhamento de rede no espelho como local de eliminação para logs de transação, execute o assistente de SQL para configuração

Failover automático: não é possível, a menos que o servidor Witness esteja presente

Failover manual: envolve a aplicação de arquivos de log de transações não confirmados no banco de dados

Problemas de falha: Médio, pois depende do Windows apresentar um compartilhamento de rede no espelho. Se a aplicação dos logs de transação na parada do espelho, eles se acumularão

E / S: maior que o espelhamento

Espelhamento:

Visão geral: as transações no principal são confirmadas no principal e enviadas para o espelho. Quando o espelho confirma a transação, ele diz ao principal que está pronto para outro.

SQL Edition: Enterprise

Failover automático: não é possível, a menos que o servidor Witness esteja presente

Failover manual: se a conectividade estiver presente, alterne o modo de espelhamento para Síncrono. Se não houver conectividade, emita a instrução SQL para executar uma restauração do Serviço Forçado. Pares podem então ser re-sincronizados

Desempenho: baixo quando comparado ao envio de log

Trabalho de laboratório pessoal:

Realizado com o SQL 2005 Standard e Enterprise.

Descobri que o envio de logs era uma boa ideia no papel, mas era complicado configurar e executar um failover no meu laboratório. O espelhamento foi muito elegante e eu sabia que as transações se comprometeram com os dois pares.

Quando chega a hora de colocar o alvo como primário, não quero ter que mexer na aplicação de arquivos de log de transação. Se você precisa de um curto RTO, gostaria de labutar o espelhamento.

Você precisará ler mais sobre os modos de replicação síncronos (a transação é confirmada para os dois pares antes marcados como concluídos) versus os modos de replicação assíncronos (confirmar no principal, em seguida, enviados para o destino) para um par espelhado. Com uma LAN, você pode executá-los no modo síncrono, mas em uma WAN você terá que observar a latência no modo síncrono (com menos de 10 a 20ms), caso contrário seu tempo de resposta para o aplicativo diminuirá.

Observe que apenas o SQL 2005 Enterprise edition suporta assíncrono, que também é chamado de "Modo de alto desempenho" ou transforma a propriedade SAFETY "OFF" no servidor SQL.

Desculpe, não tenho experiência em cluster.

Fontes do MSDN

Visão geral do espelhamento de banco de dados link