A melhor maneira de migrar um enorme banco de dados do SQL Server com baixo tempo de inatividade na rede

Definição de problema

Nosso servidor de banco de dados precisa ser transferido para outro datacenter. É executado no Microsoft SQL Server 2012 Enterprise (64 bits) e contém dois bancos de dados de cerca de 2 TB e 1 TB.

Ter pouco ou nenhum tempo de inatividade para isso seria o ideal.

Carga de trabalho

Esses bancos de dados são usados ​​para um site .NET e são atualizados constantemente.

Tê-lo indisponível no fim de semana seria aceitável. O banco de dados atualmente em uso permaneceria o único em uso até a mudança para o novo.

Idealmente, essa opção seria feita apenas alterando as entradas DNS para apontar para o novo servidor de banco de dados, garantindo que o banco de dados não esteja sendo atualizado.

Além disso, o tempo gasto por essa operação realmente não importa, desde que a troca de um servidor para outro (tempo de inatividade) seja mantida baixa.

Abordagens consideradas

• Backup e restauração

  Isso já foi feito no passado, mas envolveu um alto tempo de inatividade, apesar de ter sido feito através de uma rede interna, de forma mais eficiente do que através da Internet

• Envio de log

  Pelo que entendi, essa abordagem minimizaria o tempo de inatividade, configurando um mestre / escravo e transferindo uma cópia exata do banco de dados mestre para o seu escravo sendo somente leitura. Como mencionado acima, nenhum acesso ao escravo seria necessário e precisamos apenas de uma réplica do banco de dados mestre sem corrupção de dados.

  Também parece ser bastante eficiente em termos de utilização de recursos e não afetaria muito o desempenho principal.

  Eu posso estar errado sobre essa abordagem, então fique à vontade para me corrigir.

• Espelhamento de banco de dados

  Não estou muito ciente dessa abordagem, mas parece uma opção válida. Não é necessário ter sincronização em tempo real e o desempenho do mestre é muito importante; portanto, o modo assíncrono seria o caminho a seguir se essa abordagem fosse escolhida.

• Outras opções?

  Esse servidor é executado diretamente no hardware bare metal, portanto, soluções de nível inferior infelizmente não são uma opção. Talvez haja uma maneira melhor de fazer isso?

Restrições

Conforme descrito, esses bancos de dados são muito grandes a ponto de serem difíceis de manter, mas esse é outro problema.

As versões do SQL Server serão as mesmas (Microsoft SQL Server 2012 Enterprise de 64 bits).

Ele precisará ser transferido pela rede entre dois datacenters, provavelmente pela Internet. Enviar discos de um site para outro para uma sincronização inicial infelizmente não é uma opção. Ter algum tipo de segurança para a transferência seria ideal, mas faremos o melhor possível nessa situação.

Isso deve fornecer uma boa visão geral de nossas necessidades para esta tarefa e, esperamos, que alguns de vocês já tenham enfrentado essa situação antes.

O backup e a restauração diretos estão obviamente fora. Eu também não consideraria a replicação de qualquer tipo.

O espelhamento de banco de dados é relativamente simples de configurar, mas requer conectividade em tempo real entre os dois servidores, configuração de parceiros e terminais etc. Grupos de disponibilidade podem ser uma opção, mas, além das complicações de rede, você também precisa ter os dois servidores como membros do mesmo WSFC - o que significa que ambos devem estar no mesmo domínio. Essa não é uma configuração típica (ou pode ser feita para funcionar temporariamente) para uma mudança no data center.

Meu voto seria para envio de logs. O bom disso é que você pode usar os backups e os backups de log que já está fazendo (certo?) E não precisa necessariamente ter conectividade em tempo real entre os dois bancos de dados - eles não precisam saber sobre cada outro, você não precisa configurar pontos de extremidade para espelhamento, parceiros, segurança etc. Você só precisa de uma maneira de obter arquivos do servidor antigo para um local onde eles possam ser restaurados no novo servidor. Você pode fazer um backup completo com bastante antecedência, transferi-lo para o novo servidor, restaurá-lo e aplicar (possivelmente diffs) backups de log incrementais a partir desse ponto até o momento da interrupção. O processo é realmente bastante simples e existem muitos tutoriais sobre envio de logs disponíveis on-line, se você encontrar alguma dificuldade.

Se o aplicativo Web estiver se movendo com o banco de dados, já que o DNS pode demorar um pouco para se propagar, convém alterar as cadeias de conexão do aplicativo antigo para fazê-los apontar para o IP do novo servidor de banco de dados assim que ele for gravável. , já que - mesmo após a troca, e mesmo se as configurações de TTL forem rígidas - os clientes poderão continuar atingindo os servidores Web antigos. Tudo depende de quanto respeito seus fornecedores fornecem aos seus TTLs.

Recentemente, migrei 15 TB em 6 bancos de dados usando o espelhamento. Muito simples e funcionou perfeitamente com apenas alguns segundos de tempo de failover.

Edições:

Eu tinha dois novos servidores SQL virtualizados. Os bancos de dados eram provenientes de três servidores que haviam acabado de crescer e estavam afetando o desempenho nos bancos de dados menores hospedados neles.

O processo foi muito simples.

1. Aguarde a conclusão dos backups completos do fim de semana
2. Restaurar sem recuperação para novos servidores
3. Quando essas restaurações estiverem concluídas, pause os backups
4. Execute uma restauração adicional até o backup de log mais recente dos originais, sem recuperação
5. Comece a espelhar todos os seis
6. Retomar backups

Eu escolhi deixá-los no modo assíncrono até que estivéssemos prontos para fazer o failover deles para reduzir a carga na rede etc. O espelhamento tem reputação de causar latência durante a manutenção (índice / estatísticas) e outras atividades de alto volume, mas não o fiz. ache isso verdade. Eles precisam ser alternados para o modo síncrono antes do failover manual.

Durante a próxima janela de manutenção, eu falhei manualmente sobre cada banco de dados e, após alguns testes de fumaça, desliguei o espelhamento e, eventualmente, removi os arquivos de dados antigos dos servidores de origem. Uma peculiaridade desse processo é que a falha em um banco de dados espelhado deixa o antigo primário em um estado de recuperação; portanto, a menos que você se sinta confortável em descartá-lo, é necessário trazê-lo novamente para a Internet e desanexá-lo, ou qualquer que seja o seu método preferido de remoção. . Além disso, não configurei uma testemunha para nada disso, porque não queria failover automático. Este foi um evento controlado.

Entre em contato se desejar mais detalhes. Eu deixei de fora as especificações de servidor e rede, mas posso fornecer se você desejar.

obrigado