Toda vez que faço isso, passamos por dois passes ...
- tire um instantâneo e, trabalhando em um servidor diferente, use-o para determinar o que deve ser feito para a migração e faça um script.
- depois de ter o script em mãos, o snapshop é restaurado no sistema de teste e é cronometrado para verificar se ele será executado dentro do tempo necessário ou se é ajustado e modificado até que seja possível.
- faça com que as partes interessadas assinem que nada parece errado com os dados no sistema de teste.
Em um fim de semana, você terá uma interrupção programada:
- Sexta à noite, os sistemas que usam o banco de dados são desativados, é feito um backup completo a frio e os scripts são executados para migrar / modificar / o que quer que seja para os dados
- Os sistemas são recuperados sob algum endereço privado ou de alguma forma configurados, para que não sejam abertos a ninguém, exceto às partes interessadas para teste de aceitação
- Se as partes interessadas aprovarem, o sistema será colocado online e tornado público; caso contrário, o banco de dados é restaurado a partir do backup feito na sexta-feira à noite e você inicia o processo novamente.
De acordo com nossa programação, o pessoal do banco de dados geralmente tinha das 18:00 na sexta-feira às 10:00 no sábado para executar os scripts de backup e migração. Nosso objetivo era que eles rodassem em menos de 8 horas (~ 6 delas eram backups), então nós ' d ter algum tempo para nossos testes e correções antes de serem liberados para as partes interessadas.
As partes interessadas receberam suas janelas de tempo com antecedência, então sabiam deixar o fim de semana aberto para testes no início da janela. Eles também seriam informados no final da janela, normalmente na tarde de domingo, onde, se todos não tivessem terminado, teríamos que começar a retroceder.
Ah, e claro ... se alguém teve uma mudança durante um dos testes de aceitação, e nós fizemos uma mudança, isso significava que todas as assinaturas das partes interessadas foram anuladas e elas tiveram que fazer um novo teste ... tentaríamos dar um tempo para procurar problemas e executar as correções em lote, em vez de aplicá-las uma por vez.
Felizmente, nas únicas vezes em que tive uma dessas situações em que não pudemos ter um tempo de inatividade significativo, os sistemas que eu estava migrando foram alimentados a partir de scripts, não da entrada do usuário, para que eu pudesse ter dois sistemas paralelos em funcionamento e trocá-los quando as coisas foram assinadas. (apenas uma vez houve um problema, quando meu chefe insistiu em fazer um backup completo, sem entender que tudo continuaria online com um IP diferente ... então o que deveria ter sido uma interrupção de 5 minutos em um dia ruim se tornou uma interrupção de 5 horas.)