A maneira mais rápida de mover o banco de dados MySQL para um novo sistema, minimizando o tempo de inatividade?

Question

Gostaria de minimizar o tempo de inatividade (durante o período de "transição").

Estamos trabalhando no EC2 com os dados em um volume do EBS. É seguro tirar um instantâneo do volume do banco de dados enquanto ele está em execução e usá-lo para restaurá-lo no novo ou preciso desligar o banco de dados antigo primeiro?

    

Answer 1

Eu sugeriria:

1. Tirar um instantâneo enquanto estiver brevemente no bloqueio de leitura com FLUSH TABLES WITH READ LOCK; .
2. Coloque esse conjunto de dados em sua máquina secundária e verifique a consistência.
3. Configure a replicação da máquina antiga para a nova.

Então, no seu ponto de transição:

1. Derrube o cliente com IP na máquina antiga (você tem um separado, certo?).
2. Emita FLUSH LOGS; na máquina antiga.
3. Verifique se a nova máquina está sincronizada. 0 segundos atrás.
4. Pare a máquina antiga e verifique novamente o último tamanho do binlog em relação à posição da nova máquina.
5. Emita STOP SLAVE; RESET MASTER; na nova máquina.
6. Chame o cliente com IP para a nova máquina e arpe para garantir que os clientes o vejam.

Existem alguns detalhes mais precisos, como se você é um usuário pesado do InnoDB. Mas essa é a teoria geral.

    

Answer 2

Por que não configurar o segundo servidor MYSQL como um escravo, replicar e depois reconfigurar o escravo para ser um mestre?

    

Answer 3

Dan C está certo sobre o dinheiro, mas eu gostaria de ser mais específico sobre os primeiros 3 passos

Por causa da velocidade, e para evitar desastres , faça tudo no cliente CLI mysql da seguinte forma:

sudo mysql -e "FLUSH TABLES; FLUSH TABLES WITH READ LOCK; SYSTEM ec2-create-snapshot vol-4d826724; UNLOCK TABLES;"

Estou contando com os seguintes pontos:

1. A aquisição do bloqueio de leitura pode levar algum tempo se houver um comando UPDATE, DELETE ou INSERT de longa duração. Eu emito TABELAS DE FLUSH preparatórias para minimizar o tempo de bloqueio de qualquer tabela.
2. O cliente mysql pode passar comandos para o sistema operacional host com o SYSTEM , e faz isso como o usuário executando o cliente mysql. (É por isso que eu usei sudo)
3. Quando você disse que usava ESB no EC2, que eu nunca usei, procurei esta documentação para você . Você tem que procurar o que colocar para o "vol-XXXXXXXX"
4. Simplifique um pouco sua vida e coloque uma senha em ~ root /. my.cnf

Eu vejo isso descrever ambiguamente, ou flagrantemente errado toda a internet! A documentação diz claramente: " Se uma conexão do cliente falhar, o servidor libera os bloqueios de tabela retidos pelo cliente. ". Então, você não pode abrir o cliente mysql, flush + lock, sair do cliente, fazer snapshot, abrir o cliente mysql, desbloquear tabelas. Você vai acabar com um instantâneo inconsistente.

Alguns leitores extra-afiados identificam corretamente que o "UNLOCK TABLES" é desnecessário, porque a conexão do cliente será fechada no final de qualquer forma. Eu coloco lá porque torna as pessoas mais confortáveis.

Eu citei seis fontes para você. Espero que você se sinta confiante fazendo isso agora. Deixe-nos saber se você tem mais incerteza.

    

Answer 4

Primeiro, verifique se os loglogs estão ativados. Faça um instantâneo no nível do sistema de arquivos (por exemplo, LVM ou similar) do diretório mysql sob o bloqueio de leitura global ( FLUSH TABLES WITH READ LOCK ). Use esse instantâneo para configurar o novo servidor e configure a replicação para o sistema antigo (você pode descobrir o nome e a posição do log binário ( master_log_file / master_log_pos ) observando o tamanho do log binário mais recente no instantâneo). / p>

Quando estiver pronto para mover, interrompa todas as gravações ( read_only=true , elimine todas as conexões) no servidor antigo e aguarde até que o novo servidor alcance a replicação. Em seguida, torne o novo servidor gravável e desative o servidor antigo.

Dependendo do tipo de consulta executado no banco de dados, você pode ter um tempo de inatividade na ordem de segundos. No entanto, isso depende de suas consultas de gravação serem determinísticas para que o servidor antigo e o novo tenham exatamente os mesmos dados.