Usando o / etc / hosts para redirecionar o tráfego durante o comutador do DNS

Question

Estou migrando um site bastante movimentado para outro cluster de servidores.

O site com um mestre MySQL e dois servidores escravos. Eu gostaria de ter o menor tempo de inatividade possível durante a troca, e minha maior preocupação é o tempo que a mudança de DNS leva para se propagar.

O servidor de banco de dados mestre opera sob o mysql.domain.com.

Meu pensamento foi copiar o banco de dados mestre para o nosso novo servidor e, em seguida, mudar o DNS para mysql.domain.com para o IP do novo mestre. No entanto, isso significará que terei solicitações chegando aos dois servidores principais até que o DNS tenha propagado em todo o mundo, causando estragos em meus dados.

Meu plano é alterar o arquivo / etc / hosts no servidor mestre antigo, para que quaisquer solicitações para mysql.domain.com sigam para o IP do novo servidor.

Alguém vê riscos potenciais com isso?

    

Answer 1

Se os dois servidores estiverem localizados um ao lado do outro, por que não transferir o endereço IP do servidor antigo para o novo. Você pode ter dois (ou mais) endereços IP por servidor. Ter sua nova resposta de servidor para ambos atenua todos os seus problemas.

Se possível, eu votaria:

• Encerrar o servidor antigo
• Ativar novo servidor com novo IP E o IP do servidor antigo
• Se necessário: forneça um IP diferente para o servidor antigo e coloque-o novamente.

Alternativamente, configure qualquer mecanismo de failover de IP com o qual você se sinta confortável. Certifique-se de que seu novo mestre tenha todos os dados do antigo.

Com relação à sua pergunta:

Isso significa que você está fornecendo um serviço mysql "internacional" ou está falando de um farm de servidores web ou similar que por acaso usa uma instalação do mysql em cluster em segundo plano? Você controla os computadores que se conectam ao banco de dados? Isso abriria ainda mais possibilidades

    

Answer 2

Não sigo o que sua proposta alcança. Como os ajustes do /etc/hosts no SQL mestre antigo ajudarão você a minimizar o atraso de propagação de DNS?

Se você controlar os servidores DNS e resolvedores nos hosts, poderá publicar o antigo mestre com um TTL mais curto antes da alteração e, quando fizer a alteração, reiniciar qualquer nscd processa.

Melhor, com base no que estou supondo ser a escala do seu negócio, seria declarar uma janela de interrupção durante a qual você considera os bancos de dados como somente leitura.

    

Answer 3

Isso não está funcionando assim. O / etc / hosts não tem nada a ver com redirecionamento, você teria que editar este arquivo em todos os sistemas cliente até que o DNS tenha se propagado completamente para que funcionasse somente se você controlasse todos os clientes.

O que pode funcionar é configurar um redirecionamento via iptables ou ssh na máquina antiga para a nova.

Algo para tentar (não testado, apenas uma idéia rápida, 192.168.0.2 é o novo, 192.168.0.1 é o servidor antigo):

No servidor antigo, desative o mysql. No novo servidor, inicie uma sessão ssh assim:

ssh [email protected] -R 3306:192.168.0.2:3306 

e mantenha-o aberto. Isso deve redirecionar o tráfego que chega à porta 3306 para o novo servidor, a porta 3306. Se você usar outra porta para o mysql, adapte-se de acordo.

    

Answer 4

Não seria mais fácil editar as configurações da Zona DNS e modificar o registro A do mysql.domain.com para apontar para o novo ip do novo servidor? Se alguma solicitação ainda for disparada para o servidor antigo (devido ao atraso de propagação do DNS), as novas configurações de Zona deverão apontá-las corretamente para o novo servidor.