É tecnicamente possível mover um único banco de dados mysql de um servidor para outro, sem tempo de inatividade?

Question

Este é complicado. Eu quero ter a capacidade de mover um único banco de dados de um servidor para outro, sem tempo de inatividade. Eu poderia tirar um instantâneo dos dados no primário, passar para o secundário, iniciar a replicação, obter dados atualizados no secundário, mover as consultas para o secundário.

Mas e se o servidor secundário já for um servidor MySQL de produção, que eu não possa reiniciar, e que ele tenha que aceitar "bancos de dados transferidos" recebidos de vários servidores de fontes diferentes?

Gostaria apenas de ter uma breve introdução ao assunto.

    

Answer 1

Então, a maneira correta de fazer isso é com clustering / replicação. Veja algumas maneiras incorretas (mas provavelmente funcionais em casos especiais) de fazer isso:

1. Se você estiver usando o MyISAM no ZFS ou algum outro sistema de arquivos que suporte instantâneos, é possível bloquear a tabela para escrever, emitir tabelas de liberação, fazer instantâneos do sistema de arquivos e desbloquear tabelas. Em seguida, vá para o instantâneo, copie todos os arquivos para fora e carregue-os no servidor escravo. É claro que colocá-los no servidor escravo é uma espécie de reversão do procedimento acima, exceto que há um delete & move em vez de um snapshot reverso. Nota: Eu não recomendaria seriamente isso a ninguém em um sistema de produção.

2. Você pode escrever um script que crie tabelas temporárias no sistema escravo usando a definição das tabelas nas quais será replicado, conecte-se ao sistema mestre, faça um select * e copie os resultados em as tabelas de memória de destino, quando todas estiverem concluídas, bloquear (ou transaccionar) as tabelas e copiar os dados da memória para as tabelas reais (isto é, apagar, substituir, substituir e depois apagar); então, destrave e pequenino.

Ambos exigem efetivamente nenhum tempo de inatividade (dependendo do tamanho da tabela, etc, ele pode bloquear os bancos de dados por um breve período, provavelmente no máximo alguns segundos, o que provavelmente é bom se você não fizer isso com muita frequência).

No entanto, essas duas soluções não são ótimas, pois criam picos de carga e resultam em períodos entre sincronizações em que os dados do escravo não estão atualizados. Você não especificou que precisava disso na sua pergunta, daí as sugestões, mas apenas apontando que, se isso é realmente necessário, então sim, você precisa de replicação.

Eu uso algo como a primeira idéia de fazer backups em um servidor de banco de dados muito específico que temos (e eles funcionam bem) e o segundo para sincronizar dados de uma fonte upstream Eu não controlei para um servidor que eu controlei que eu possa trabalhar com os dados. Como eu disse, não há ótimas soluções gerais lá, mas nesses casos específicos elas funcionam bem.

    

Answer 2

Como isso é muito difícil de fazer sem ter suporte nativo no próprio banco de dados, você pode querer olhar para um cluster MySQL com replicação assíncrona. Isto irá , no entanto, requer que você use a distribuição do MySQL Cluster, não a distribuição normal do MySQL.

Caso contrário, como a resposta do @ RolandoMySQLDBA sugere, simplesmente não há como replicar o banco de dados sem ter algum suporte subjacente para espelhar as atualizações em cada banco de dados. O que ele não esclarece é que isso não causa tempo de inatividade - o site pode permanecer em um estado somente leitura enquanto o banco de dados é descartado e carregado.

    

Answer 3

Eu também acho que um cluster MySQL é a sua solução. Você pode definir uma solução ativa / passiva. O que eu fiz foi configurar o failover no meu servidor DNS se não conseguir equilibrar o servidor ao passivo e então fiz o failover ...

Claro que a melhor solução ativa / ativa é a melhor, mas quando eu fiz isso não foi trivial ou eu era muito mais estúpido do que agora: P

De qualquer forma, acho que sua solução será definitivamente voltada para a configuração de cluster.