Movendo bancos de dados para novos datacenters

Minha empresa está mudando nossa infraestrutura para um novo data center e estou tentando descobrir a melhor maneira de manter o banco de dados no novo servidor sincronizado com o banco de dados de produção atual até que os novos ambientes estejam prontos para entrar em operação. Não sendo um DBA em tempo integral, fiz algumas pesquisas e, pelo que li, parece que uma configuração de replicação transnacional melhor atenderia às nossas necessidades.

Alguns detalhes: o banco de dados de produção tem cerca de 90 GB de tamanho e, usando o Robocopy, demorou cerca de 9 horas para mover uma cópia dele para um dos novos servidores. O banco de dados de produção atual precisará permanecer online e acessível durante todo o processo de migração. Como a recuperação é simples, o espelhamento de banco de dados não está disponível.

Uma replicação transacional é o melhor método para manter os bancos de dados sincronizados?

Meu plano:

1. (Concluído) Transfira o banco de dados atual e faça logon no novo servidor e anexe-o à nova instância do SQL Server
2. Configure um distribuidor em nossa máquina de banco de dados de desenvolvimento e publique nele a partir do banco de dados de produção
3. Crie um assinante na nova máquina de banco de dados que aceite as atualizações enviadas pelo distribuidor, uma vez por noite

Há duas coisas em minha mente. A replicação transacional exige que cada tabela publicada tenha uma chave primária e muitas das tabelas no banco de dados de produção não tenham chaves primárias definidas. Não acho que isso seja um problema muito grande, pois minha principal preocupação é apenas sincronizar os bancos de dados. Testaremos os diferentes aplicativos que usam o banco de dados em dados posteriores, mas gostaria de garantir que não seja um problema sério. Em segundo lugar, também preciso mover quaisquer bancos de dados do sistema associados da instância original, como mestre? Estamos mudando para uma configuração do Active Directory no novo ambiente, por isso não me importo com os usuários e coisas assim, mas não tenho certeza sobre a necessidade dos bancos de dados do sistema.

E, em geral, estou entendendo esses conceitos corretamente?

Sua situação atual:

• Banco de dados de 90 GB que você deseja mover para um novo datacenter.
• O banco de dados está em recuperação simples.
• Você está pensando em usar o T-Rep para manter os dados sincronizados.
• Existem muitas tabelas no banco de dados que não possuem Chave Primária - este é um requisito para que todas as tabelas sejam publicadas.
• Você já possui um backup copiado para o data center de destino.

Vejo muitas desvantagens em sua abordagem:

• O T-Rep não é fácil de configurar em comparação com outras tecnologias. Se houver alguma alteração no esquema, será necessário um novo instantâneo.
• Se você estiver usando o T-REP, precisará fazer alterações no esquema - adicione a Chave Primária às tabelas que não possuem.
• Fazendo qualquer alteração no banco de dados existente, seu aplicativo deve ser totalmente testado para evitar qualquer comportamento inesperado.
• Se o seu banco de dados tiver um grande número de transações e, dependendo da largura de banda da rede entre os dois datacenters, também haverá latência de replicação.

Com base na minha experiência, abaixo está minha recomendação:

• Altere seu banco de dados para recuperação total. Este não é um grande impacto em comparação à criação de PKs.
• Envie o backup completo do banco de dados de origem - faça o backup com compactação e ative a inicialização instantânea de arquivos. Isso ajudará você a reduzir o tempo de restauração no data center de destino.
• Restaurar banco de dados no servidor de destino WITH NORECOVERY .
• Implemente o Logshipping e inicialize-o a partir do backup.
• Faça o logshipping enviar os logs a cada 1 min.
• Durante o dia do failover, faça um último backup do log de cauda na origem e restaure-o no destino usando WITH RECOVERY. Isso colocará o banco de dados de destino online.
• Depois que o banco de dados de destino estiver online, você deverá sincronizar os usuários .
• Você deve alterar seu web.config para apontá-lo para o novo servidor.

Você não precisa mover nenhum banco de dados do sistema. Certifique-se de fazer todo o trabalho de preparação antes de escrever manualmente logins, trabalhos, pacotes ssis, etc. e criá-los no servidor de destino.

Consulte esta resposta para obter as etapas pós-restauração e outras práticas recomendadas .

Nota: Você também pode implementar o espelhamento de banco de dados (SYNC ou ASYNC, dependendo da edição do servidor sql que estiver usando), mas o logshipping é apenas simples de implementar e, se você testá-lo, não irá decepcioná-lo. Mudei com êxito o banco de dados de terabytes de um datacenter para outro usando a técnica acima e funciona perfeitamente.

O banco de dados de produção atual precisará permanecer online e acessível durante todo o processo de migração.

Sempre haverá um tempo de inatividade e você deve agendá-lo. Mesmo se você investir pagando uma quantia alta em soluções como cluster, quando fizer o failover, haverá algum tempo de inatividade. Você precisa equilibrar quanto sua empresa pode investir em um tempo de inatividade próximo a zero versus o que está disponível com um tempo de inatividade aceitável.

Não tive chance de usar isso sozinho e acho que ainda está em pré-visualização, mas o SQL Data Sync na plataforma Azure pode ser uma opção em potencial:

https://azure.microsoft.com/en-gb/documentation/articles/sql-database-get-started-sql-data-sync/

Ele funciona com bancos de dados locais e SQL do Azure e parece ser uma ferramenta útil para manter os bancos de dados sincronizados.