Transferindo um site sem tempo de inatividade

Question

Eu quero transferir meu site para um novo host. Eu mudei tudo para lá, mas quero minimizar a perda de banco de dados enquanto o DNS está apontando para os novos servidores de nomes.

Como posso fazer isso?

Mais detalhes:

• Transferiu arquivos e banco de dados para o novo host.

• Registros DNS alterados para os novos servidores de nomes, que levarão algum tempo para serem atualizados!

O que eu preciso: apontar o site no servidor antigo para o novo banco de dados no novo servidor para que os novos dados não sejam perdidos!

    

Answer 1

Eu faço essas migrações regularmente. Nenhum tempo de inatividade é difícil, mas o tempo de inatividade baixo ou quase imperceptível é possível. A ideia geral é:

• Faça um backup quente do servidor de origem para o novo; essa é uma cópia de trabalho completa enquanto sua origem ainda está funcionando (em um servidor LAMP: execute mysqldump na origem e então transfira todo o sistema de arquivos via rsync para o destino)
• 1 / coloque a origem no modo somente leitura ( shell> mount -remount o,ro /path/to/fs + mysql> flush tables with read lock ) se o aplicativo manuseá-lo bem ou 2 / exiba uma página de manutenção
• Faça um backup incremental a frio , ou seja. re-despeje seu SQL e transfira somente o que foi modificado desde o backup ativo. Com o rsync, o custo depende apenas do número de inodes (arquivos) no seu destino, pois todos eles devem ser testados para modificação; raramente é um problema de largura de banda. Em sites de 1 a 10 GB com inodes de 100 a 500 k, esse backup incremental leva de 1 segundo a 1 minuto em minha experiência.
• Configure um proxy reverso na origem que redirecione todo o tráfego para o novo alvo. Você está pronto e poderá retroceder em alguns segundos se houver um problema (elimine a parte do proxy reverso no servidor de origem). Obviamente você preparou a configuração para que uma simples chamada para apachectl graceful seja suficiente para aplicá-la.
• Se tudo correr bem, você pode finalizar a migração e atualizar seu DNS (normalmente faço isso 24 horas depois). Em seguida, aguarde o tráfego parar de fluir do seu servidor de origem (geralmente outro 24-48h).

Os detalhes são mais complicados, mas quando é o seu trabalho e você está acostumado, é realmente fácil. Além de saber como executar 'rsync', 'mysqldump' e configurar um proxy reverso com algumas linhas no Apache, está feito.

Muitas vezes você precisa ajustar algumas coisas que são diferentes do servidor de origem e de destino (como o nome do host). Neste caso eu escrevo um pequeno script que automatiza a parte de backup e as 'correções' (usando sed, perl, etc.). Com rsync -a --delete você pode usar o mesmo script para backups quentes e frios.

O bom disso é que você não depende do DNS. Na minha experiência, a hospedagem de DNS é sempre horrível ou mal controla o proprietário do site. As atualizações de DNS de muitos provedores de DNS são imprevisíveis e não-depuráveis. O TTL é ignorado ou desconfigurado pela maioria dos servidores DNS em cache. Você se depara com essa janela de tempo engraçada em que muitas pessoas não veem o mesmo servidor usando o mesmo nome e isso gera um relacionamento muito ruim com os clientes. Colocar o DNS fora da equação é uma grande vitória para mim (a menos que eu possa hospedar diretamente a zona DNS e, então, eu esteja 100% no controle, mas isso é outra história).

    

Answer 2

Como eu fiz isso antes é fazer master & leftrightarrow, master replicação entre os 2 bancos de dados. Dessa forma, qualquer que seja o servidor real que seu tráfego de entrada está atingindo, as atualizações do banco de dados ocorrem em ambos.

A replicação é um assunto bastante detalhado que não pode ser totalmente abordado aqui, e você não terá tempo suficiente agora antes de suas atualizações de DNS, mas é uma boa ideia para a próxima mudança.

    

Answer 3

É difícil fazer sem tempo de inatividade, mas é relativamente simples minimizar o tempo de inatividade.

• Configure os sites para serem executados simultaneamente com armazenamento de dados separado, tire um instantâneo da troca de sistema antiga dos registros de DNS e, quando estiver satisfeito com o fato de as alterações de DNS terem propagado, migre os dados acumulados desde a captura instantânea no site antigo para o novo.

• Permitir acesso ao armazenamento de dados do novo sistema do sistema antigo, sincronizar o armazenamento de novos sites, desativar o processamento no antigo e no novo, ressincronizar os dados para trazê-los de volta, alternar o DNS para aponte para o novo site e (ao mesmo tempo) altere o site antigo para usar o novo armazenamento

• configure um nome de domínio alternativo para o novo site (por exemplo, novo.exemplo.com e www.exemplo.com), mas não permita o processamento de nenhuma transação com o novo nome. Plano de fundo sincronize o armazenamento para a nova caixa ou copie sobre um instantâneo. Desative todo o processo de transação na máquina antiga e sincronize novamente os dados. Ativar o processamento de transações na nova máquina (ambos os nomes) Configure a máquina antiga para enviar um redirecionamento para o novo nome na nova máquina para todas as solicitações HTTP e reescreva todos os URLs codificados na camada HTML / lógica de ambos os sistemas para usar novos .example.com no lugar de www.example.com. Quando a máquina antiga não estiver mais sendo usada, reverta as URLs para www.example.com

Não é trivial, mas usando as ferramentas certas, ele deve ser capaz de automatizar a maior parte disso. Se você está usando geradores de sequência de banco de dados / colunas de incremento automático do MySQL, então você precisará de um plano para evitar colisões.

    

Answer 4

Foi assim que eu fiz:

• Backup completo no host antigo
• Faça o upload desse backup para o novo host.
• Pouco antes de alterar os servidores de nomes, carreguei o banco de dados do antigo para o novo host.
• Servidores de nomes alterados.
• Feito "em construção Home Page" no host antigo.

Em cerca de 2 horas, o nome do domínio estava apontando para o novo host.