Movendo bancos de dados do SQL 2005 para 2008 - transição rápida com espelhamento ou replicação

Question

Temos alguns bancos de dados do SQL 2005 em execução, que gostaria de migrar para o SQL 2008. A instância de 2008 está em funcionamento. Qual é a maneira recomendada de fazer um corte rápido de um servidor para o outro?

Eu gosto que o aplicativo esteja usando 2005, enquanto as transações também estão sendo empurradas para 2008, permitindo que eu configure as coisas de antemão. Em seguida, a equipe do aplicativo pode alterar sua conexão com a instância de 2008 e começar a testar e atualizar. Quando tudo estiver bem, poderíamos quebrar o mecanismo que está fazendo a transferência e usar 2008.

Estou um pouco familiarizado com o espelhamento e a replicação transacional. Parece que o espelhamento funcionará, mas eu precisaria falhar no banco de dados espelhado no momento certo. O banco de dados de 2005 seria inutilizável e não poderíamos fazer failback, já que as tabelas do sistema estariam no formato de 2008.

A replicação parece ser a melhor escolha para não precisar de nenhuma intervenção - mas também parece um pouco mais complicada com detalhes que eu provavelmente não estou ciente de que isso pode não funcionar.

Obrigado

    

Answer 1

Você não pode testar o banco de dados espelhado, pois ele não está acessível para leituras.

A replicação permitirá que você leia do assinante, mas a replicação não replica tudo.

Além disso, é muito pouco ortodoxo falar sobre a mudança e atualização da equipe do aplicativo enquanto a cópia está sendo atualizada. A equipe de aplicativos deve testar e atualizar um banco de dados teste , não um candidato para atualização de produção ... O que aconteceria com as alterações incompatíveis com o fluxo de atualizações recebidas?

Um cenário típico de atualização é assim:

• teste de desenvolvimento de aplicativos que funciona bem no antigo esquema do novo banco de dados. Se os problemas forem identificados, o aplicativo será corrigido (sem alterações de esquema no banco de dados).
• se as alterações no esquema forem necessárias, elas serão gravadas como scripts de atualização a serem implementados na implantação da nova versão.
A equipe de
• dev assina o procedimento de atualização (todas as modificações de aplicativo e todas as modificações de esquema)
A equipe de controle de qualidade
• faz uma cópia do banco de dados de produção e confirma que é possível fazer upgrade do aplicativo, aplicando todas as mudanças no esquema de alterações binárias após o upgrade, conforme recomendado pela equipe de desenvolvimento
A equipe de controle de qualidade
• assina o procedimento de atualização
• A equipe de operações prepara o upgrade. Usar o espelhamento é uma ótima maneira, mas por razões de minimizar o tempo de inatividade durante a atualização, não por razões de validação do aplicativo, como você sugere
• Execute a atualização:
  • Retire o aplicativo
  • Falha no banco de dados (ou quebra de espelhamento, se você quiser ter um caminho de retorno seguro / rápido)
  • Aplicar scripts de alterações de esquema ao novo banco de dados
  • Aplicar patches binários ao aplicativo
  • inicia a aplicação no novo db
  • execute alguns testes de validação mínimos
  • ativar o acesso ao aplicativo

Answer 2

Faça um backup a frio dos bancos de dados e restaure-os para a instância de 2008 como normal para a equipe de aplicativos testar se terão ou não problemas de compatibilidade. Quando isso estiver correto, use o espelhamento ou o envio de logs para manter os bancos de dados em sincronia. Em seu tempo de inatividade planejado, pare o LS / espelhamento, coloque os bancos de dados antigos offline e recupere os bancos de dados de 2008 e faça com que a equipe de aplicativos altere a cadeia de conexões ou use um alias de DNS para passar para o novo servidor.