Entenda as diferenças entre MySQL Community, MySQL Enterprise, Percona e MariaDB

Nesta publicação quero explicar algumas diferenças interessantes entre o MySQL Community, MySQL Enterprise, Percona e MariaDB.

Normalmente sempre abordamos algumas coisas em nosso curso de MySQL, mas o tempo sempre é apertado e as vezes não é possível.

Sempre imaginei que estas diferenças fossem irrelevantes, mas em todas as aulas aparecem dúvidas a respeito e alguns clientes também perguntam sobre, sendo assim, resolvi juntar um apanhado das perguntas, mitos e receios a respeito dos outros “dois irmãos” do MySQL e compilá-los em uma única postagem em nosso blog junto com a versão Enterprise.

Quero reforçar que estas vertentes são compatíveis entre si mas com alguns cuidados a serem tomados em casos específicos. Do ponto de vista da administração e das aplicações que se conectam não há diferença.

MySQL

O MySQL continua sendo a principal distribuição encontrada por aí nas mais diversas infraestruturas e ainda hoje é o banco de dados de código aberto mais utilizado do mundo! Apareceu em 1994 na Suíça, criado por uma empresa chamada MySQL AB.

Alguns anos mais tarde, em 2008, a Sun Microsystems adquire a MySQL AB e em 2010 a Oracle adquire a Sun Microsystems, incluindo o nosso tão querido MySQL. No mesmo dia em que a Oracle anuncia a compra da Sun, um dos criadores do MySQL, Ulf Michael Widenius, faz um fork do MySQL criando o MariaDB.

Apesar da comunidade do software livre criticar a Oracle, e as vezes com razão, a Oracle de certo modo melhorou a forma como o MySQL é desenvolvido, unificando a versão enterprise e a versão community em uma só, tornando todas as características da versão enterprise em plugins  e facilitando a migração para ambos os lados.

A versão community do MySQL, infelizmente, não possui algumas facilidades das quais a versão enterprise se beneficia:

• Integração com LDAP
• Auditoria
• Hot Backups
• Monitoramento
• Firewall

Calma! Eu sei que muita gente sabe que quase todas essas características podem ser contornadas, e vou explicá-las uma a uma…

Integração com LDAP

Tudo bem, esta eu ficarei devendo, infelizmente a versão community não possui suporte a esta integração e não há uma forma de contorná-la.

Esta é uma das características citadas que eu menos entendo, normalmente existem poucos usuários que acessam um banco, como a aplicação e os administradores. Não existe uma necessidade tão grande assim para criar dezenas ou centenas de usuários como normalmente as pessoas dão a entender.

Mesmo assim ainda é possível facilitar a administração para uma grande quantidade de usuários, basta criar roles em versões do MySQL a partir da 8.0 ou usuários de proxy em versões anteriores, o único trabalho realmente seria criar o usuário em sí, tarefa facil de se automatizar.

Auditoria

Quem fez o que e aonde? Alguém tentou acessar algo que não deveria? LGPD?

Se está atrás destas perguntas provavelmente você precisa de logs de auditoria, a versão enterprise do MySQL possui um plugin perfeito para esse tipo de log de aplicação.

Mas não fique triste, a versão community não fica para trás e podemos utilizar o plugin de auditoria da McAffe! Se ficou interessado, é possível acessar a documentação em https://github.com/mcafee/mysql-audit, preste atenção apenas nas versões suportadas, normalmente o plugin não aceita a última versão do MySQL lançado pela Oracle.

Hot Backups

Talvez o mysqldump seja a única forma de “backup” que você utiliza, e isso é mais comum do que possa parecer. A versão enterprise do MySQL trás uma ferramenta para backups conhecida como mysqlbackup.

Através do mysqlbackup é possível fazer backups completos, incrementais e diferenciais! Tudo isso sem precisar parar o banco, e o melhor, em formato consistente! Não é preciso se preocupar com as transações que estão acontecendo.

Aqueles que utilizam a versão community podem fazer seus hot-backups com uma fantástica ferramenta da Percona chamada XtraBackup. Ela possui todas as vantagens do mysqlbackup com exceção dos backups diferenciais, mas isso não faz muito diferença.

Ambas as ferramentas geram e restauram backups muito mais rápidos que o mysqldump e podem ser utilizadas para enviar stream de dados entre máquinas sem necessariamente precisar salvar o arquivo no disco antes.

Isso mesmo, adeus “mysqldump –single-transaction…”.

Monitoramento

A ferramenta de monitoramento da versão enterprise chama-se MySQL Enterprise Monitor, eu realmente preciso tirar o meu chapéu, praticamente todo o necessário vem pronto, é possível analisar queries lentas, encontrar vulnerabilidades nas máquinas e nas versões do MySQL, receber dicas do que fazer com determinadas máquinas, analisar atraso de replicação, enfim, é uma ferramenta e tanto.

MySQL Query Analyzer

Aqueles que utilizam a versão community podem monitorar as instâncias através de muitas ferramentas, como por exemplo Zabbix ou Prometheus aliado ao Grafana. Existe também uma ferramenta da Percona chamada PMM que utiliza do próprio Prometheus + Grafana para fornecer diversas informações interessantes a respeito do MySQL que normalmente não encontramos nos exemplos por aí.

Pmm Query Analytics

Firewall

O conceito do firewall da versão enterprise do MySQL chamada MySQL Enterprise Firewall é bastante interessante, e é bem diferente do que normalmente esperaríamos.

Primeiro alimenta-se uma base de informações iniciando o firewall em modo de aprendizado para que o servidor entenda qual o perfil das conexões e o que elas normalmente executam. A partir de uma determinada quantidade de amostras coletadas o firewall pode ser habilitado em modo de bloqueio evitando qualquer comando que fuja do padrão conhecido.

O firewall é bastante útil para parar ataques de SQL Injection, intrusos e bloquear qualquer tipo de tráfego suspeito e roda diretamente no próprio serviço do MySQL, evitando qualquer necessidade de configuração externa.

Infelizmente não há nada que substitua o MySQL Enterprise Firewall na versão community além de boas práticas como utilizar prepared statements do lado da aplicação e estar ciente dos acessos e permissões do banco que foram criados e para quem foram entregues.

Cache

Sim, cache! O MySQL da Oracle é a unica versão (atualmente) a suportar o Memcached combinando-o com o MySQL. O Memcached passa a persistir os dados diretamente no InnoDB mas sem passar pelos mecanismos de otimização e interpretação do SQL que as queries normais passariam, tornando o processo muito similar ao original.

Desta forma as consultas feitas no Memcached carregam os dados no buffer pool do InnoDB e podem ser consultadas novamente pelo Memcached ou mesmo através de queries comuns no MySQL. Isso também facilita a inserção e a busca de dados não estruturados no MySQL, pois o Memcached abstrairia essa complexidade.

Eu não sei se ficou claro, é o Memcached… com toda a persistência e segurança do InnoDB!

Queries Lentas

Hoje o MySQL da Oracle suporta um formato de log de query lenta similar ao do Percona/MariaDB, mas como esta característica é relativamente recente, vou deixar este mérito com quem implementou primeiro.

De qualquer forma, saiba que a partir do MySQL 8.0.14 é possível melhorar o log com a variável log_slow_extra.

Clusters

Sim o MySQL suporta clusters “multi-masters” e partir da versão 8 suporta clusters “primary-secondary” com failover automático graças ao group replication.

Quem usa MySQL a mais tempo provavelmente já ouviu falar do Galera Cluster, talvez a solução multi-master mais famosa, testada e sólida. Infelizmente não é possível simplesmente plugá-la no MySQL, é preciso baixar uma versão específica do pessoal da Codership Oy com as modificações necessários para o  “Writeset Replication” e substituir o MySQL atual.

O MySQL 8 suporta nativamente o InnoDB Cluster, uma solução da própria Oracle para criar clusters de MySQL multi-master ou primary-secondary com failover automático e fácil configuração.

MariaDB

O MariaDB é a versão que mais se distancia do seu irmão mais velho, em compensação adiciona coisas interessantes com mais velocidade apesar de dificultar um pouquinho mais a migração pelas diferenças de nomenclaturas, binários e etc. A sua evolução também forçou o MySQL da Oracle a adicionar algumas coisas que eles mesmos implementaram como a possibilidade de “matar” apenas a query de um usuário e não a sua sessão toda.

Curiosamente o MariaDB suporta a engine XtraDB do Percona além de outras engines como Cassandra o que o torna uma alternativa perfeita para mais de uma forma de armazenamento mas sem necessariamente aprender os trejeitos de outra aplicação.

A ferramenta de backup do MariaDB hoje se chama mariabackup ou maria-backup nas versões mais recentes. É um fork do xtrabackup com as modificações necessárias para atender as diferenças do MariaDB em relação a criptografia e compressão.

Nomes

Atualmente o MariaDB utiliza outros nomes para as ferramentas e para o binário mas mantem links simbólicos para seus equivalentes:

MariaDB binários

Autenticação

Por padrão o usuário root pode acessar a instância do MySQL sem digitar senha alguma. Isso parece bobo mas não é, facilaita bastante, principalmente quando estamos constantemente criando ambientes de teste ou instalando nos mais variados clientes e executando comandos de forma automatizada.

Isso não é inseguro, já que o usuário root pode parar a instância e entrar com “skip-grant-tables” de qualquer forma. É possível fazer isso na versão da Oracle e da Percona, mas é preciso habilitar o plugin de “auth_socket” e modificar o usuário para usuá-lo.

Aria

A engine Aria é a padrão do MariaDB, ela ainda não suporta transações, mas está caminhando para esta direção. Esta engine é bastante otimizada para consultas com “ORDER BY” ou “GROUP BY” tomando o lugar da MyISAM e levando uma grande vantagem pois suporta recuperação automática.

Cliente

O cliente do MariaDB é mais atual e aceita atalhos do shell como “CTRL + W” para apagar apenas uma palavra para trás além de mostrar o progresso de uma determinada operação. Isso mesmo, aquele “ALTER TABLE” que demorava horas ainda demora horas, mas você saberá quando está acabando ou não:

MariaDB Progresso

Queries Lentas

A saída do log de query lenta do MariaDB parece bastante com a saída do Percona. Pode ser configurada entre o padrão, explain e query-plan, podendo combiná-las:

MariaDB Queries Lentas

• tmp_tables indica a criação ou não de tabelas temporárias, em memória (16mb) ou em disco, caso utilize-se mais do que 16mb de memória, isso é bastante útil para encontrar queries que criem tabelas derivadas imensas;
• full_scan quase sempre nos indica buscas sem índice ou com índices tão pobres que foram descartados;
• filesort este nome é um pouco confuso, mas indica ordenação sem utilização de índices e é bastante útil para encontrar ordenações gigantescas;

Clusters

O MariaDB é a única versão que suporta o Galera Cluster nativamente, é possível encontrar referências sobre isso na própria página do Galera Cluster. Isso significa que não precisamos reinstalar nada, simplesmente habilitamos o “Writeset Replication” no MariaDB instalado e estamos prontos para começar a transformar nossa instância isolada em um cluster.

Infelizmente o MariaDB não suporta o InnoDB Cluster.

Percona

Todas as ferramentas fornecidas pela Percona são livres e de código aberto.

A Percona surgiu em 2006, uma consultoria especializada em MySQL fundada por Peter Zaitsev e Vadim Tkachenko, possuem sua própria versão do MySQL chamada Percona Server for MySQL com modificações bastante interessantes não só no quesito de performance mas também de obtenção de informações.

Como se não bastasse, Peter Zaitsev e Vadim Tkachenko junto com Baron Schwartz são os autores das três primeiras versões do livro “MySQL High Performance”.

As versões do MySQL da Percona seguem a versão community do MySQL, construídas e compiladas com base no código fonte original. Isso significa que caso alguém queira migrar do MySQL Community, ou mesmo MySQL Enterprise para o Percona, basta encontrar a versão equivalente e simplesmente fazer os procedimentos de atualização.

Com suporte de todas as ferramentas livres e de código aberta citadas acima, o Percona Server for MySQL ainda suporta integração com LDAP e logs de Auditoria.

Queries Lentas

O log de queries lentas do Percona Server é muito mais detalhado que o log da versão community e além das informações que o MariaDB entrega (ver mais abaixo) podemos exibir uma quantidade enorme de informações úteis, como o próprio site a respeito informa.

Nesta imagem abaixo estamos extraindo informações com log_verbosity=full, o que nos trás indicativos a respeito do que aconteceu no InnoDB, isso é muito útil para entender se o lock time da query é por conta de um registro com lock ou por conta da quantidade de conexões na fila:

Percona Slow Query Estatísticas InnoDB

É possível obter mais informações ainda com uma maior verbosidade, abaixo temos uma saída com log_slow_verbosity=full,profiling:

Percona Profiling Slow – Saída modificada para melhorar visualização

Performance

Existem algumas modificações no Percona Server que melhoram a performance em relação a versão original do MySQL, algumas delas são:

• O InnoDB consegue uma performance de leitura maior pois envia um pedido de leitura para o kernel do Linux de múltiplas páginas de 16KB de uma vez ao invés de várias requisições de 16KB. Apenas por curiosidade, esta implementação é de autoria do pessoal do Facebook.
• O InnoDB não fará uma consulta ao “clustered index” caso todas as colunas necessárias estejam no índice secundário e o tamanho do campo a ser buscado seja menor do que o prefixo estipulado na criação deste índice secundário.
• A engine XtraDB tem uma performance melhor em situações de alta concorrência e gargalo de I/O pois o controle do buffer pool é feito por uma thread única e específica ao invés das threads de query que acabam se encavalando e criando muitas trocas de contexto.

Clusters

O Percona suporta o Galera Cluster com suas próprias modificações, que recebeu o nome de XtraDB Cluster, o funcionamento é o mesmo com a vantagem de já estar disponível nos repositórios da Percona, porém também utiliza um binário diferente, o que exige reinstalação.

Como o Percona segue as versões do MySQL, também é possível utilizar InnoDB Cluster.

Conclusão

Todas as versões são muito boas e cada uma tem a sua peculiaridade, mesmo a versão Community e a versão da Percona por mais semelhantes que sejam possuem diferenças, e o plugin do Memcached é uma delas.

O MariaDB está presente nos repositórios das distribuições Linux por padrão, e funciona no Alpine sem toda a dor de cabeça que normalmente temos ao trocar o glibc pelo musl. Isso nos permite criar contêineres com MariaDB muito menores do que seus outros irmãos.

Felizmente, ou infelizmente, o log de queries lentas do Percona é tão bom e facilita tanto a primeira análise que é difícil não dar preferência para esta versão.

Em contra partida, sair de uma instância “standalone” para um Galera Cluster com o MariaDB é uma tarefa tão simples que me faz perguntar o porque das outras versões não serem assim.

Com exceção da versão Enterprise do MariaDB e do MySQL todas elas são livres e de código aberto e podem ser utilizadas em ambientes de missão crítica.

Nenhuma versão é tão melhor que a outra, e eu não apontarei para nenhuma delas, sendo assim é preciso escolher a que melhor atende cada caso, o golfinho, a foca ou o felino.

Líder em Treinamento e serviços de Consultoria, Suporte e Implantação para o mundo open source. Conheça nossas soluções:

CURSOSCONSULTORIA