Embora compartilhe a mesma herança com o MySQL, o MariaDB é um banco de dados diferente. Ao longo dos anos, à medida que novas versões do MySQL e do MariaDB foram lançadas, ambos os projetos diferiram em duas plataformas RDBMS diferentes.
MariaDB se torna a principal distribuição de banco de dados em muitas plataformas Linux e está ganhando grande popularidade nos dias de hoje. Ao mesmo tempo, torna-se um sistema de banco de dados muito atraente para muitas corporações. Ele está obtendo recursos próximos às necessidades da empresa, como criptografia, backups dinâmicos ou compatibilidade com bancos de dados proprietários.
Mas como os novos recursos afetam a compatibilidade do MariaDB com o MySQL? Ainda é substituto para o MySQL? Como as últimas alterações amplificam o processo de migração? Tentaremos responder a isso neste artigo.
O que você precisa saber antes da atualização
MariaDB e MySQL diferem significativamente entre si nos últimos dois anos, especialmente com a chegada de suas versões mais recentes:MySQL 8.0, MariaDB 10.3 e MariaDB 10.4 RC (discutimos os novos recursos do MariaDB 10.4 RC recentemente, então Se você gostaria de leia mais sobre o que está por vir na versão 10.4, verifique dois blogs do meu colega Krzysztof, O que há de novo no MariaDB 10.4 e o segundo sobre o que há de novo no MariaDB Cluster 10.4).
Com o lançamento do MariaDB 10.3, o MariaDB surpreendeu muitos, pois não é mais um substituto imediato para o MySQL. O MariaDB não está mais mesclando novos recursos do MySQL com o MariaDB noir, resolvendo os bugs do MySQL. No entanto, a versão 10.3 está se tornando uma alternativa real ao Oracle MySQL Enterprise, bem como a outros bancos de dados corporativos proprietários, como o Oracle 12c (MSSQL na versão 10.4).
Verificação preliminar e limitações
A migração é um processo complexo, independentemente da versão para a qual você está atualizando. Há algumas coisas que você precisa ter em mente ao planejar isso, como alterações essenciais entre as versões do RDBMS, bem como testes detalhados que precisam liderar qualquer processo de atualização. Isso é especialmente crítico se você deseja manter a disponibilidade durante a atualização.
A atualização para uma nova versão principal envolve riscos e é importante planejar todo o processo cuidadosamente. Neste documento, veremos as novas mudanças importantes na versão 10.3 (e futura 10.4) e mostraremos como planejar o processo de teste.
Para minimizar o risco, vamos dar uma olhada nas diferenças e limitações da plataforma.
Começando com a configuração, existem alguns parâmetros que possuem valores padrão diferentes. MariaDB fornece uma matriz de diferenças de parâmetros. Pode ser encontrado aqui.
No MySQL 8.0, caching_sha2_password é o plugin de autenticação padrão. Esse aprimoramento deve melhorar a segurança usando o algoritmo SHA-256. O MySQL tem este plugin habilitado por padrão, enquanto o MariaDB não. Embora já exista uma solicitação de recurso aberta com o MariaDB MDEV-9804. O MariaDB oferece o plugin ed25519, que parece ser uma boa alternativa ao antigo método de autenticação.
O suporte do MariaDB para criptografia em tabelas e tablespaces foi adicionado na versão 10.1.3. Com suas tabelas sendo criptografadas, seus dados são quase impossíveis para alguém roubar. Esse tipo de criptografia também permite que sua organização esteja em conformidade com os regulamentos governamentais, como o GDPR.
O MariaDB oferece suporte a pools de threads de conexão, que são mais eficazes em situações em que as consultas são relativamente curtas e a carga é vinculada à CPU. Na edição da comunidade do MySQL, o número de threads é estático, o que limita a flexibilidade nessas situações. O plano corporativo do MySQL inclui recursos de pool de threads.
O MySQL 8.0 inclui o esquema sys, um conjunto de objetos que ajuda os administradores de banco de dados e engenheiros de software a interpretar os dados coletados pelo Esquema de Desempenho. Os objetos de esquema Sys podem ser usados para casos de uso de otimização e diagnóstico. O MariaDB não inclui esse aprimoramento.
Outra são as colunas invisíveis. Colunas invisíveis oferecem a flexibilidade de adicionar colunas a tabelas existentes sem o medo de quebrar um aplicativo. Este recurso não está disponível no MySQL. Ele permite criar colunas que não são listadas nos resultados de uma instrução SELECT *, nem precisam ser atribuídos a um valor em uma instrução INSERT quando seu nome não é mencionado na instrução.
O MariaDB decidiu não implementar o suporte nativo a JSON (um dos principais recursos do MySQL 5.7 e 8.0), pois afirmam que não faz parte do padrão SQL. Em vez disso, para dar suporte à replicação do MySQL, eles definiram apenas um alias para JSON, que na verdade é uma coluna LONGTEXT. Para garantir que um documento JSON válido seja inserido, a função JSON_VALID pode ser usada como uma restrição CHECK (padrão para MariaDB 10.4.3). MariaDB não pode acessar diretamente o formato MySQL JSON.
A Oracle automatiza muitas tarefas com o MySQL Shell. Além do SQL, o MySQL Shell também oferece recursos de script para JavaScript e Python.
Processo de migração usando mysqldump
Uma vez que conhecemos nossas limitações, o processo de instalação é bastante simples. Está praticamente relacionado à instalação e importação padrão usando mysqldump. A ferramenta de backup MySQL Enterprise não é compatível com MariaDB, portanto, a maneira recomendada é usar mysqldump. Aqui está o processo de exemplo feito no Centos 7 e no MariaDB 10.3.
Criar dump no servidor MySQL Enterprise
$ mysqldump --routines --events --triggers --single-transaction db1 > export_db1.sqlLimpe o índice de cache do yum
sudo yum makecache fastInstale o MariaDB 10.3
sudo yum -y install MariaDB-server MariaDB-clientInicie o serviço MariaDB.
sudo systemctl start mariadb
sudo systemctl enable mariadbProteja o MariaDB executando mysql_secure_installation.
# mysql_secure_installation
NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!
In order to log into MariaDB to secure it, we'll need the current
password for the root user. If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.
Enter current password for root (enter for none):
OK, successfully used password, moving on...
Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.
Set root password? [Y/n] y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
... Success!
By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.
Remove anonymous users? [Y/n] y
... Success!
Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.
Disallow root login remotely? [Y/n] y
... Success!
By default, MariaDB comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.
Remove test database and access to it? [Y/n] y
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!
Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.
Reload privilege tables now? [Y/n] y
... Success!
Cleaning up...
All done! If you've completed all of the above steps, your MariaDB
installation should now be secure.
Thanks for using MariaDB!Importar despejo
Mysql -uroot -p
> tee import.log
> source export_db1.sql
Review the import log.
$vi import.logPara implantar um ambiente, você também pode usar o ClusterControl, que tem a opção de implantar do zero.
ClusterControl Deploy MariaDB O ClusterControl também pode ser usado para configurar a replicação ou importar um backup do MySQL Enterprise Edition.
Processo de migração usando replicação
A outra abordagem para migração entre MySQL Enterprise e MariaDB é usar o processo de replicação. As versões do MariaDB permitem replicar para eles, a partir de bancos de dados MySQL - o que significa que você pode migrar facilmente bancos de dados MySQL para o MariaDB. As versões do MySQL Enterprise não permitem replicação de servidores MariaDB, portanto, essa é uma rota de mão única.
Com base na documentação do MariaDB:https://mariadb.com/kb/en/library/mariadb-vs- mysql-compatibilidade/. X refere-se à documentação do MySQL.Recursos relacionados ClusterControl for MariaDB O que há de novo no MariaDB 10.4 How to Manage MySQL - for Oracle DBAs Aqui estão algumas regras gerais apontadas pelo MariaDB.
- Replicar do MySQL 5.5 para o MariaDB 5.5+ deve funcionar. Você deseja que o MariaDB seja a mesma versão ou superior do seu servidor MySQL.
- Ao usar um MariaDB 10.2+ como escravo, pode ser necessário definir binlog_checksum como NONE.
- A replicação do MySQL 5.6 sem GTID para o MariaDB 10+ deve funcionar.
- A replicação do MySQL 5.6 com GTID, binlog_rows_query_log_events e eventos ignoráveis funciona a partir do MariaDB 10.0.22 e MariaDB 10.1.8. Nesse caso, o MariaDB removerá os GTIDs do MySQL e outros eventos desnecessários e, em vez disso, adicionará seus próprios GTIDs.
Mesmo que você não planeje usar a replicação no processo de migração/transferência, ter um é um bom gerador de confiança é replicar seu servidor de produção em um sandbox de teste e praticar nele.
Esperamos que esta postagem de blog introdutória tenha ajudado você a entender o processo de avaliação e implementação do MySQL Enterprise Migration to MariaDB.
