Migrar seu banco de dados para um novo datacenter pode ser um processo demorado e de alto risco. Um banco de dados contém estado e pode ser muito mais difícil de migrar em comparação com servidores web, filas ou servidores de cache.
Nesta postagem do blog, daremos algumas dicas sobre como migrar seus dados de um provedor de serviços para outro. O processo é um pouco semelhante ao nosso post anterior sobre como atualizar o MySQL, mas há algumas diferenças importantes.
Replicação MySQL ou Cluster Galera?
Mudar para outro provedor de serviços (por exemplo, mudar da AWS para a Rackspace ou de servidores colocalizados para a nuvem) muitas vezes significa que alguém construiria uma nova infraestrutura em paralelo, sincronizaria com a infraestrutura antiga e depois mudaria para ela. Para conectá-los e sincronizá-los, você pode aproveitar a replicação do MySQL.
Se você estiver usando o Galera Cluster, pode ser mais fácil mover seus nós Galera para um datacenter diferente. No entanto, observe que todo o cluster ainda precisa ser tratado como um único banco de dados. Isso significa que seu site de produção pode sofrer com a latência adicional introduzida ao estender o Galera Cluster pela WAN. É possível minimizar o impacto ajustando as configurações de rede no Galera e no sistema operacional, mas o impacto não pode ser totalmente eliminado. Também é possível configurar a Replicação MySQL assíncrona entre o cluster antigo e o novo, se o impacto da latência não for aceitável.
Configurando a conectividade segura
A Replicação do MySQL não é criptografada e, portanto, não é segura para uso na WAN. Existem várias maneiras de garantir que seus dados sejam transferidos com segurança. Você deve investigar se é possível estabelecer uma conexão VPN entre sua infraestrutura atual e seu novo provedor de serviços. A maioria dos provedores (por exemplo, Rackspace e AWS) fornece esse serviço - você pode conectar sua parte “nublada” ao seu datacenter existente por meio de uma rede privada virtual.
Se, por algum motivo, esta solução não funcionar para você (talvez exija um hardware ao qual você não tenha acesso), você pode usar um software para construir uma VPN - um deles será o OpenVPN. Essa ferramenta funcionará bem para configurar conexões criptografadas entre seus datacenters.
Se o OpenVPN não for uma opção, há mais maneiras de garantir que a replicação seja criptografada. Por exemplo, você pode usar SSH para criar um túnel entre datacenters antigos e novos e encaminhar a porta 3306 do escravo (ou mestre) MySQL atual para o novo nó. Isso pode ser feito de maneira muito simples, desde que você tenha conectividade SSH entre os hosts:
$ ssh -L local_port:old_dc_host:mysql_port_in_old_dc [email protected]_dc_host -N &Por exemplo:
$ ssh -L 3307:10.0.0.201:3306 [email protected] -N &Agora, você pode se conectar ao servidor remoto usando 127.0.0.1:3307
$ mysql -P3307 -h 127.0.0.1Ele funcionará de forma semelhante para a replicação, apenas lembre-se de usar 127.0.0.1 para o master_host e 3307 para o master_port
Por último, mas não menos importante, você pode criptografar sua replicação usando SSL. Esta postagem de blog anterior explica como isso pode ser feito e que tipo de impacto pode ter no desempenho da replicação.
Se você decidiu usar a replicação Galera em ambos os datacenters, as sugestões acima também se aplicam aqui. No que diz respeito ao SSL, escrevemos anteriormente sobre como criptografar o tráfego de replicação do Galera. Para uma solução mais completa, você pode querer criptografar todas as conexões de banco de dados de aplicativos cliente e qualquer infraestrutura de gerenciamento/monitoramento.
Configurando a nova infraestrutura
Depois de ter conectividade, você precisa começar a construir a nova infraestrutura. Para isso, você provavelmente usará xtrabackup ou mariabackup. Pode ser tentador combinar a migração com a atualização do MySQL, afinal você está configurando um ambiente totalmente novo no novo local. Não recomendamos fazer isso. A migração para uma nova infraestrutura é significativa o suficiente por si só, portanto, combiná-la com outra grande mudança aumenta a complexidade e o risco. Isso também é verdade para outras coisas - você deseja adotar uma abordagem passo a passo para as mudanças. Somente alterando as coisas, uma de cada vez, você pode entender os resultados das alterações e como elas afetam sua carga de trabalho. Se você fez mais de uma alteração em um determinado momento, não poderá ter certeza de qual delas é responsável por uma determinada (nova ) comportamento que você observou.
Quando você tem uma nova instância MySQL em execução no novo datacenter, você precisa escravizá-la do nó no datacenter antigo - para garantir que os dados em ambos os datacenters permaneçam sincronizados. Isso se tornará útil enquanto você se prepara para a transição final. Também é uma boa maneira de garantir que o novo ambiente possa lidar com sua carga de gravação.
O próximo passo será construir uma infraestrutura completa de staging no novo local e realizar testes e benchmarks. Esta é uma etapa muito importante que não deve ser ignorada - o problema aqui é que você, como DBA, precisa entender a capacidade de sua infraestrutura. Quando você muda de provedor, as coisas também mudam. Novos hardwares/vms são mais rápidos ou mais lentos. Há mais ou menos memória por instância. Você precisa entender novamente como sua carga de trabalho se encaixará no hardware que você usará. Para isso, você provavelmente usará o Percona Playback ou o pt-log-player para reproduzir algumas das consultas da vida real no sistema de teste. Você desejará testar o desempenho e garantir que esteja em um nível aceitável para você. Você também deseja realizar todos os testes de aceitação padrão executados em seus novos lançamentos - apenas para confirmar que tudo está funcionando. Em geral, todos os aplicativos devem ser construídos de forma que não dependam da configuração de hardware e de uma configuração atual. Mas algo pode ter escapado e seu aplicativo pode depender de alguns dos ajustes de configuração ou soluções de hardware que você não tem no novo ambiente.
Por fim, quando estiver satisfeito com seus testes, você desejará construir uma infraestrutura pronta para produção. Depois disso, você pode querer executar alguns testes somente leitura para verificação final. Este seria o passo final antes do cutover.
Corte
Após todos esses testes terem sido realizados e após a infraestrutura ser considerada pronta para produção, a última etapa é fazer o cutover do tráfego da infraestrutura antiga.
Globalmente falando, este é um processo complexo, mas quando estamos olhando para a camada de banco de dados, é mais ou menos a mesma coisa que o failover padrão - algo que você pode ter feito várias vezes no passado. Cobrimos isso em detalhes em um post anterior, resumindo as etapas são:parar o tráfego, garantir que ele seja interrompido, aguardar enquanto o aplicativo está sendo movido para o novo datacenter (os registros DNS mudam ou não), fazer alguns testes de fumaça para garantir tudo parece bom, vá ao vivo, monitore de perto por um tempo.
Essa transição exigirá algum tempo de inatividade, como podemos ver. O problema é garantir que tenhamos um estado consistente entre o site antigo e o novo. Se quisermos fazer isso sem tempo de inatividade, precisaremos configurar a replicação mestre-mestre. A razão é que, à medida que atualizamos o DNS e movemos as sessões do site antigo para o novo, ambos os sistemas estarão em uso ao mesmo tempo - até que todas as sessões sejam redirecionadas para o novo site. Enquanto isso, quaisquer alterações no novo site precisam ser refletidas no site antigo.
O uso do Galera Cluster, conforme descrito nesta postagem do blog, também pode ser uma maneira de manter os dados entre os dois sites sincronizados.
Estamos cientes de que esta é uma descrição muito breve do processo de migração de dados. Espero que seja suficiente para apontar uma boa direção e ajudá-lo a identificar quais informações adicionais você precisa procurar.
