Grandes organizações que usam plataformas de banco de dados MySQL ou MariaDB geralmente enfrentam a necessidade de realizar uma migração de banco de dados de um lugar para outro. Independentemente da plataforma, tipo de software de banco de dados (como de RDBMS para NoSQL ou NoSQL voltando para RDBMS), ou se for apenas uma migração de dados, realizar uma migração é uma quantidade enorme de trabalho e custos.
Uma migração de banco de dados sempre envolverá o processo de migração de dados de um ou mais bancos de dados de origem para um ou mais bancos de dados de destino. Isso pode envolver um serviço de migração de banco de dados ou um conjunto de ferramentas de mashup que os engenheiros construíram para criar um serviço e adaptar a esse tipo de problema.
Espera-se que uma migração de banco de dados não signifique que a plataforma de banco de dados de origem acabará com sua plataforma de destino exatamente como a origem de origem. Depois que uma migração for concluída, o conjunto de dados dos bancos de dados de destino pode acabar sendo reestruturado. O que mais importa, uma vez concluída a migração, é que os clientes que acessam o banco de dados sejam redirecionados para os bancos de dados recém-fonte. O novo banco de dados de origem deve fornecer a cópia exata dos dados da origem e sem impactos no desempenho que possam afetar a experiência geral do usuário.
Movimentar seus dados de uma plataforma para a plataforma de destino de destino é uma tarefa enorme. Isso é o que uma migração de banco de dados cobre quando uma organização ou empresa decide desligar sua luz para a plataforma atual por vários motivos. Os motivos comuns para a migração de dados são devido à relação custo-benefício para a plataforma de destino de destino ou por sua flexibilidade na implantação e escalabilidade. Embora a plataforma atual que hospeda os dados de produção atuais cause mais custos para suas atualizações e escalabilidade, é apenas oneroso ao implantar pequenas alterações que podem realmente ser implantadas em uma plataforma de microsserviço.
Neste blog vamos focar nas principais ferramentas de código aberto que você pode usar para migrações de MySQL e MariaDB em uma migração de banco de dados mais homogênea.
Ferramentas de backup para migração de dados
O caminho mais fácil de usar ao realizar a migração é usar ferramentas de backup de banco de dados. Veremos quais são essas ferramentas e como você pode usá-las durante a migração.
mysqldump/mysqlpump
Esta ferramenta é um dos utilitários mais famosos para MySQL ou MariaDB que um administrador de banco de dados ou administrador de sistema irá conectar esta ferramenta para migrar um banco de dados completo ou uma cópia parcial do banco de dados. Para administradores de banco de dados que não estão familiarizados com MySQL/MariaDB, esta ferramenta permitirá que você crie uma cópia de backup que gerará uma cópia lógica dos dados que você pode despejar no banco de dados de destino.
Uma configuração comum com o uso desta ferramenta é, sempre que um banco de dados de destino está localizado em outro lugar e está hospedado em uma plataforma diferente da fonte, o destino atua como um escravo ou réplica. Usar o mysqldump comumente invocado com --single-transaction em um sistema ocupado e com --master-data fornecerá as coordenadas para configurar um escravo no banco de dados de destino que será usado como host para migração de dados. Uma alternativa ao mysqldump também é o mysqlpump, mas com um recurso menor ainda pode fazer processamento paralelo de bancos de dados e de objetos dentro de bancos de dados, para acelerar o processo de despejo. A desvantagem é que, com o mysqlpump, não há nenhuma opção que você possa usar, como --master-data, que é muito útil se você deseja criar uma réplica que será usada como destino de destino para migração de banco de dados.
mysqlpump é vantajoso se seus dados estiverem mais ociosos ou forem colocados em modo de manutenção, de modo que nenhuma gravação processada ou alterações em andamento no banco de dados de origem. É mais rápido e mais rápido comparado ao mysqldump.
mydumper/myloader
mydumper/myloader é uma ferramenta muito bacana e eficiente que você pode usar para backup lógico, especialmente para importar dados em massa com velocidade de processamento mais rápida, pois oferece paralelismo, capacidade de enviar dados por partes, suporta limite e controle taxa através do número de encadeamentos, linhas, tamanho da instrução e compacta o resultado. Ele gera ou inclui arquivos de log binários e posições de log, o que é muito útil se você configurar a plataforma de destino de destino para atuar como uma réplica da fonte atual e do ambiente de produção.
Basicamente, mydumper é o binário e o comando que você deve invocar via linha de comando para criar o backup lógico. Considerando que myloader é o binário e o comando que você deve usar ao carregar dados para o destino de destino desejado. Sua flexibilidade permite que você gerencie a taxa desejada ao processar as ações, seja criando um backup ou carregando os dados. Usando mydumper, você também pode criar um backup completo ou apenas uma cópia de backup parcial do banco de dados de origem. Isso é muito útil no caso de você precisar de um grande esquema ou dados que deseja mover para longe do host de banco de dados atual e movê-lo levemente para outro destino de destino ao iniciar a configuração de novos fragmentos de banco de dados. Essa também pode ser uma maneira de migrar dados grandes, puxando um grande segmento do conjunto de dados e movendo-o, mas como um novo nó de fragmento.
mydumper/myloader também tem suas limitações. Ele foi interrompido pelas atualizações dos autores originais, mas salvo por Max Bube, mas a ferramenta ainda está sendo amplamente utilizada, mesmo para ambientes de produção.
Percona XtraBackup/MariaDB Backup
O XtraBackup da Percona é um presente para administradores de banco de dados que não querem usar e gastar dinheiro com o Oracle MySQL Enterprise Backup corporativo. Enquanto o MariaDB Backup é bifurcado e derivado do Percona XtraBackup, eles também possuem o MariaDB Enterprise Backup.
As duas ferramentas compartilham os mesmos conceitos ao realizar ou fazer um backup. É um backup binário que oferece um backup on-line quente, PITR, backup incremental e completo, backup parcial, também útil para recuperação de dados, pois entende a recuperação que produz arquivo de log binário e posição, suporta GTIDs e muito mais. Embora o MariaDB Backup e o Percona XtraBackup sejam dois tipos diferentes de software hoje em dia, pois são arquitetados para suportar o banco de dados focado em fornecer um backup. O MariaDB Backup é definitivamente aplicável se você pretende usar ou fazer backups de uma fonte de banco de dados MariaDB. Visto que o Percona XtraBackup é aplicável no Oracle MySQL e também no Percona Server ou em alguns servidores MySQL derivados, como o Percona XtraDB Server ou a versão Codership do Galera Cluster for MySQL.
Ambos os backups são muito benéficos para migrações de banco de dados. A execução de um backup online ativo é mais rápido e mais rápido e produz um backup que você pode usar diretamente para carregá-lo no banco de dados de destino. Mais frequentemente, o backup de streaming é útil, assim como você pode executar um backup online e transmitir os dados binários para o banco de dados de destino usando socat ou netcat. Isso permite que você reduza o tempo de migração, pois a movimentação de dados para o destino de destino está sendo transmitida diretamente.
A abordagem mais comum de migração de dados ao usar essa ferramenta é copiar os dados da origem e depois transmitir os dados para o destino de destino. Uma vez no destino do banco de dados de destino, você pode apenas preparar o backup binário com a opção --prepare onde aplica os logs que foram gravados durante o momento da criação do backup para que ele copie os dados completos como estão e exatamente a partir do momento onde o backup foi feito. Em seguida, defina o destino do banco de dados de destino como uma réplica para atuar como réplica ou escravo do cluster de origem existente e replicar todas as alterações e transações que ocorreram no cluster principal.
Claro que também há uma limitação de usar essa ferramenta, mas os administradores de banco de dados devem saber como usar essa ferramenta e também como regular e personalizar o uso de acordo com o uso desejado. Você pode não querer sobrecarregar seu banco de dados de origem se sua origem estiver recebendo muito tráfego ou grande processamento a partir desse momento. Sua limitação também garante que seja uma configuração homogênea onde a origem de destino seja de sistema compatível com Linux e não em um ambiente do tipo Windows, pois o Percona XtraBackup e o MariaDB Backup operam apenas no ambiente Linux.
Ferramentas de migração de esquema de banco de dados
A migração de banco de dados não fala por si só sobre uma ferramenta específica e uma tarefa específica, então a migração pode acontecer. Há muitas considerações e tarefas subsequentes subjacentes que precisam ser feitas para realizar uma migração completa do banco de dados. Uma delas é a migração de esquema ou migração de banco de dados. Um esquema no MySQL/MariaDB é uma coleção de dados que consiste em um grupo de tabelas com suas colunas e linhas, eventos, gatilhos, procedimentos armazenados ou rotinas e funções. Há ocasiões em que você pode querer migrar apenas um esquema ou apenas uma tabela. Digamos que uma tabela específica em um esquema exija uma alteração em sua estrutura de tabela e isso exija uma instrução DDL. O problema é que, executar uma instrução DDL direta como ALTER TABLE ...ENGINE=InnoDB bloqueia qualquer transação ou conexão de entrada que também fará referência ou usará a tabela de destino. Para algumas tabelas enormes que incluem definição de dados longos e estrutura da tabela, isso adiciona mais desafios reais e também complica mais, especialmente se a tabela for uma tabela quente. Considerando que em uma migração de banco de dados, pode ser difícil copiar a cópia completa exata da tabela completa sem tempo de inatividade da origem. Então vamos ver quais são esses.
pt-online-schema-change
É parte do famoso Percona Toolkit que originalmente derivou do Maatkit e do Aspersa. Esta ferramenta é muito útil ao realizar uma alteração de definição de tabela especialmente para uma tabela quente que consiste em uma grande quantidade de dados. Para alguma abordagem comum, porém ingênua, para realizar uma alteração na definição de tabela, executar ALTER TABLE pode fazer o trabalho. Embora seja suficiente, ALTER TABLE sem usar ALGORITHM=INPLACE causa uma cópia completa da tabela que adquire um bloqueio de metadados completo e isso significa que seu banco de dados pode ser empilhado e bloqueado por um longo período de tempo, especialmente se a tabela estiver enorme. Nesse caso, esta ferramenta é construída para resolver esse problema. Essa ferramenta é muito benéfica para a migração de banco de dados de forma que uma cópia inconsistente detectada de uma tabela quente com dados muito grandes do seu destino de banco de dados de destino já configurado. Em vez de realizar um backup usando uma cópia lógica ou binária/física, pt-online-schema-change pode ser usado, que copia as linhas da tabela de origem para sua tabela de destino pedaço por pedaço. Você pode até personalizar o comando com chamadas apropriadas para seus parâmetros, dependendo de seus requisitos.
Além de usar, pt-online-schema-change também usa gatilhos. Ao usar acionadores, qualquer tráfego subsequente ou contínuo que tente aplicar alterações nessa tabela de referência também deve ser copiado para o banco de dados de destino que atua como uma réplica do cluster de banco de dados de origem atual. Isso copia todos os dados exatamente os dados que o banco de dados de origem possui para o banco de dados de destino que está em uma plataforma diferente, por exemplo. O uso de gatilhos é aplicável para MySQL e MariaDB, desde que seu mecanismo seja InnoDB e tenha uma presença de chave primária nessa tabela, o que é um requisito. Você deve saber que o InnoDB usa um mecanismo de bloqueio de linha que permite que, para um certo número de blocos (um grupo de registros selecionados), pt-online-schema-change tente copiar isso e, em seguida, aplique a instrução INSERT à tabela de destino . A tabela de destino é uma tabela fictícia que atua como uma cópia de destino da futura substituição da tabela de origem existente. pt-online-schema-change permite que o usuário remova a tabela fictícia ou apenas deixe a tabela fictícia no lugar até que o administrador esteja pronto para remover essa tabela. Observe que, descartar ou remover uma tabela adquire um meta-datalock. Uma vez que adquire triggers, quaisquer alterações subsequentes devem ser copiadas exatamente para a tabela de destino, não deixando nenhuma discrepância na tabela de destino ou fictícia.
gh-ost
Compartilha o mesmo conceito que pt-online-schema-change. Esta ferramenta aborda de forma diferente em comparação com pt-online-schema-change. Devo dizer que essa migração da ferramenta de esquema aborda esses impedimentos baseados em produção que podem fazer com que seu banco de dados fique lento e possivelmente travado, fazendo com que seu cluster de banco de dados caia no modo de manutenção ou fique inativo por um período de tempo desconhecido, até que o problema seja resolvido. Esse problema é causado geralmente com gatilhos. Se você tiver uma tabela ocupada ou ativa que está passando por uma alteração de esquema ou alteração de definição de tabela, os gatilhos podem fazer com que seu banco de dados se acumule devido à contenção de bloqueio. Os gatilhos MySQL/MariaDB permitem que seu banco de dados defina gatilhos para INSERT, UPDATE e DELETE. Se a tabela de destino estiver em um ponto de acesso, ela pode acabar desagradável. Seu banco de dados começa a ficar mais lento até ficar travado, a menos que você consiga eliminar as consultas recebidas ou melhor remover os gatilhos, mas não é disso que se trata a abordagem ideal.
Por causa desses problemas, o gh-ost resolve esse problema. Ele age como se houvesse um servidor de log binário onde os eventos ou transações de entrada são registrados em um formato de log binário, especificamente usando RBR (Row Based Replication). Na verdade, é muito seguro e menos preocupações em termos de impacto que você precisa enfrentar. Na verdade, você também tem a opção de fazer um teste ou execução a seco (o mesmo que com pt-online-schema-change), mas testá-lo diretamente na réplica ou em um nó escravo. Isso é perfeito se você quiser brincar e verificar a cópia exata para o banco de dados de destino durante a migração.
Esta ferramenta é muito flexível de acordo com as suas necessidades e implica a garantia de que seu cluster não ficará travado ou provavelmente acabará realizando um failover ou recuperação de dados se piorar. Para mais informações e quiser aprender esta ferramenta, sugiro a leitura deste post do Github por Shlomi Noach.
Outras ferramentas OSC
Posso dizer que essas duas ferramentas são uma abordagem mais recomendável, mas outras alternativas que você também pode tentar. Principalmente, essas ferramentas aplicam gatilhos MySQL/MariaDB para que, de alguma forma, compartilhe o mesmo conceito que pt-online-schema-change. Aqui está a seguinte lista:
- LHM - As migrações de banco de dados no estilo Rails são uma maneira útil de evoluir seu esquema de dados de maneira ágil. A maioria dos projetos Rails começa assim e, no início, fazer alterações é rápido e fácil.
- OnlineSchemaChange - Criado e iniciado pelo Facebook. Esta ferramenta é usada para fazer alterações de esquema para tabelas MySQL sem bloqueio
- TableMigrator - Iniciado por Serious Business e ex-funcionários do Twitter. Essa ferramenta compartilha o mesmo princípio com migrações sem tempo de inatividade de grandes tabelas no MySQL. Ele é implementado usando Rails, portanto, pode ser útil se você tiver um ambiente de aplicativo Ruby-on-Rails.
- oak-online-alter-table - esta é uma ferramenta antiga criada por Shlomi Noach, embora de alguma forma se aproxime da mesma abordagem que pt-online-schema-change e execute uma operação ALTER TABLE sem bloqueio
Ferramentas do Assistente de Migração de Banco de Dados
Existem poucas ferramentas de migração que oferecem uso gratuito, o que é muito benéfico até certo ponto. O que é mais vantajoso em usar as ferramentas do assistente de migração é que elas têm GUI para a qual você pode ter a conveniência de ver a estrutura atual ou apenas seguir as etapas que a interface do usuário fornece durante a migração. Pode haver vários serviços ou ferramentas de assistente, mas não é de código aberto e não está disponível gratuitamente. É claro que uma migração de banco de dados é um processo muito complexo, mas sistemático, mas, em alguns casos, exige muito trabalho e esforços. Vamos dar uma olhada nessas ferramentas gratuitas.
MySQL Workbench
Como o nome sugere, é para MySQL e bancos de dados derivados, como o Percona Server, por exemplo, podem ser úteis quando se trata de migração de banco de dados. Como o MariaDB mudou totalmente para uma rota diferente, especialmente desde a versão 10.2, existem alguns problemas de incompatibilidade que você pode encontrar se tentar usar isso de uma origem ou destino do MariaDB. O Workbench pode ser usado para tipos heterogêneos de bancos de dados, como aqueles provenientes de bancos de dados de origem diferentes, e deseja despejar os dados no MySQL.
O MySQL Workbench é composto por versões comunitárias e corporativas. No entanto, a versão da comunidade está disponível gratuitamente como GPL, que você pode encontrar aqui https://github.com/mysql/mysql-workbench. Como afirma a documentação, MySQL Workbench permite migrar do Microsoft SQL Server, Microsoft Access, Sybase ASE, SQLite, SQL Anywhere, PostreSQL e outras tabelas, objetos e dados RDBMS para MySQL. A migração também suporta a migração de versões anteriores do MySQL para as versões mais recentes.
phpMyAdmin
Para aqueles que trabalham como desenvolvedores web usando a pilha LAMP, essa ferramenta não é surpresa por ser um dos canivetes suíços ao lidar com tarefas de banco de dados. phpMyAdmin é uma ferramenta de software livre escrita em PHP, destinada a lidar com a administração do MySQL pela Web. O phpMyAdmin suporta uma ampla variedade de operações no MySQL e no MariaDB. As operações usadas com frequência (gerenciamento de bancos de dados, tabelas, colunas, relações, índices, usuários, permissões, etc.) podem ser realizadas através da interface do usuário, enquanto você ainda tem a capacidade de executar diretamente qualquer instrução SQL.
Embora seja bastante simples quando se trata de importar e exportar, o importante é que ele faça o trabalho. Embora para uma migração maior e mais complexa, isso pode não ser suficiente para atender às necessidades desejadas.
HeidiSQL
HeidiSQL é um software livre e tem como objetivo ser fácil de aprender. "Heidi" permite ver e editar dados e estruturas de computadores que executam um dos sistemas de banco de dados MariaDB, MySQL, Microsoft SQL, PostgreSQL e SQLite. Inventado em 2002 por Ansgar, o HeidiSQL pertence às ferramentas mais populares para MariaDB e MySQL em todo o mundo.
Para fins de migração, permite exportar de um servidor/banco de dados diretamente para outro servidor/banco de dados. Ele também possui recursos de importação para permitir campos de texto, como CSV, e também exportar linhas de tabela para uma ampla variedade de tipos de arquivos suportados, como CSV, HTML, XML, SQL, LaTeX, Wiki Markup e PHP Array. Embora seja construído para gerenciar bancos de dados para fins de administração do servidor db, você pode usá-lo para coisas simples de migração.
Kit de ferramentas Percona como seu canivete suíço
Percona Toolkit é um software notável sendo distribuído como um software de código aberto sob a garantia da GPL. Percona Toolkit é uma coleção de ferramentas avançadas de linha de comando comumente usadas internamente pela Percona, mas também é aplicável a qualquer trabalho de banco de dados relacionado especialmente a servidores MySQL/MariaDB.
Então, como e por que também é útil para migração de dados, especialmente em migrações MySQL/MariaDB? Eles têm várias ferramentas aqui que são benéficas para uso na migração e após a migração.
Como mencionado anteriormente, uma abordagem comum de migração de dados é ter o servidor de destino de destino como uma réplica do cluster de banco de dados de origem principal, mas em uma configuração homogênea. Isso significa que, se a situação estiver mudando do local para um provedor de nuvem pública, você poderá configurar um nó eleito dessa plataforma e esse nó replicará todas as transações do cluster principal. Usando ferramentas de backup, você pode conseguir esse tipo de configuração de migração. Mas não termina aí. O Percona Toolkit possui ferramentas pt-table-checksum/pt-table-sync, por exemplo, para ajudá-lo a identificar inconsistências de dados entre o servidor de banco de dados local versus o destino de destino. Com pt-table-checksum, você pode realizar cálculos de checksum com base em uma série de blocos para todos os bancos de dados ou apenas checksum seletivo em bancos de dados específicos, ou tabelas específicas, ou até mesmo um intervalo de registros da tabela. pt-table-sync será usado para realizar a sincronização de dados para que seus bancos de dados de destino sejam atualizados novamente com uma nova cópia dos dados exatos do cluster de origem principal.
Por outro lado, pt-upgrade é muito útil após a migração das ferramentas de backup. Com o pt-upgrade, você pode usar essa ferramenta para realizar análises executando um conjunto de consultas, por exemplo, de um arquivo de log de consultas lentas. Esses resultados podem ser usados para comparar o banco de dados de origem e o servidor de banco de dados de destino.
Resumo
A migração de banco de dados, especialmente de uma configuração heterogênea, pode ser muito complicada. No entanto, em uma configuração homogênea, pode ser bastante direto; independentemente de os dados serem grandes ou pequenos, desde que você esteja equipado com as ferramentas adequadas e, é claro, a abordagem sistemática correta para determinar se a migração está completa com os dados consistentes. Pode haver momentos em que uma migração exija a consulta de especialistas, mas é sempre um ótimo começo tentar usar essas ferramentas de código aberto para realizar a tarefa de migração de banco de dados desejada.
