Otimizar MariaDB 10.11 no Rocky Linux 9: tuning essencial

16 min de leitura  ·  Guia técnico

Otimizar o MariaDB 10.11 no Rocky Linux 9 significa ajustar variáveis de configuração, habilitar logs de diagnóstico e calibrar recursos de memória para que o banco de dados entregue o máximo de throughput com o mínimo de latência. Para aplicar o tuning essencial, siga estes passos:

1. Faça backup do arquivo de configuração atual antes de qualquer alteração.
2. Ajuste innodb_buffer_pool_size para 50–70% da RAM disponível.
3. Configure max_connections, thread_cache_size e buffers de ordenação.
4. Ative o slow query log para identificar queries problemáticas.
5. Reinicie o serviço e valide as mudanças com SHOW GLOBAL STATUS.
6. Monitore continuamente e ajuste de forma iterativa.

Pré-requisitos para otimizar o MariaDB 10.11 no Rocky Linux 9

• Sistema operacional: Rocky Linux 9 (x86_64) com acesso root ou sudo.
• MariaDB: versão 10.11 instalada e em execução (systemctl status mariadb).
• RAM mínima recomendada: 2 GB; para produção, 4 GB ou mais.
• Editor de texto: vim ou nano disponível no servidor.
• Acesso SSH: consulte o guia Acessando servidores VPS Linux da AviraHost caso precise configurar o acesso.
• Backup recente: dump completo do banco via mysqldump antes de qualquer alteração estrutural.

Entendendo o arquivo de configuração do MariaDB no Rocky Linux 9

No Rocky Linux 9, as configurações do MariaDB são carregadas a partir de múltiplos arquivos. O principal é /etc/my.cnf, que inclui automaticamente todos os arquivos dentro de /etc/my.cnf.d/. O arquivo específico do servidor é /etc/my.cnf.d/mariadb-server.cnf, e é nele que você deve concentrar as alterações de tuning para evitar conflitos com atualizações futuras do pacote.

Antes de editar qualquer coisa, faça uma cópia de segurança:

cp /etc/my.cnf.d/mariadb-server.cnf /etc/my.cnf.d/mariadb-server.cnf.bak

Para verificar quais arquivos o MariaDB está lendo na inicialização, execute:

mariadbd --print-defaults

mariadbd  Ver 10.11.x-MariaDB for Linux on x86_64 (MariaDB Server)
/etc/my.cnf /etc/my.cnf.d/mariadb-server.cnf ~/.my.cnf

Conhecer a ordem de leitura evita que uma diretiva em arquivo errado sobrescreva silenciosamente o que você configurou. Variáveis definidas mais tarde na cadeia de leitura têm precedência sobre as anteriores.

Ajustando o InnoDB Buffer Pool e parâmetros de memória

O innodb_buffer_pool_size é a variável de maior impacto no desempenho do MariaDB: ela define quanto da RAM será reservado para cache de dados e índices InnoDB. Quanto mais dados couberem nesse buffer, menos leituras de disco serão necessárias.

Abra o arquivo de configuração:

vim /etc/my.cnf.d/mariadb-server.cnf

Localize ou crie a seção [mysqld] e adicione os parâmetros abaixo. O exemplo considera um servidor com 8 GB de RAM dedicado ao MariaDB:

[mysqld]
# InnoDB Buffer Pool — 60% da RAM total
innodb_buffer_pool_size         = 4G
innodb_buffer_pool_instances    = 4
innodb_buffer_pool_chunk_size   = 128M

# Redo log — aumentar melhora throughput de escrita
innodb_log_file_size            = 512M
innodb_log_buffer_size          = 64M
innodb_flush_log_at_trx_commit  = 2

# I/O
innodb_io_capacity              = 400
innodb_io_capacity_max          = 800
innodb_read_io_threads          = 4
innodb_write_io_threads         = 4

# Flush method — O_DIRECT evita double buffering com o SO
innodb_flush_method             = O_DIRECT

Atenção: alterar innodb_log_file_size exige parada completa do MariaDB. O daemon removerá e recriará os arquivos de redo log automaticamente na próxima inicialização, mas o processo pode demorar alguns segundos em bases grandes.

Sobre innodb_buffer_pool_instances: divida o buffer pool em múltiplas instâncias para reduzir contenção de mutex em cargas com alta concorrência. A regra prática é uma instância por gigabyte de buffer pool, com máximo de 64.

Configurando conexões, threads e buffers de sessão

O controle de conexões simultâneas e dos buffers alocados por sessão é fundamental para evitar que o MariaDB consuma RAM de forma descontrolada em picos de tráfego. Cada conexão aberta aloca individualmente os buffers de sessão configurados.

[mysqld]
# Conexões
max_connections          = 150
max_connect_errors       = 1000000
wait_timeout             = 300
interactive_timeout      = 300

# Cache de threads — reutiliza threads em vez de criar novos
thread_cache_size        = 50
thread_stack             = 256K

# Buffers de sessão (alocados por conexão ativa)
sort_buffer_size         = 2M
read_buffer_size         = 1M
read_rnd_buffer_size     = 2M
join_buffer_size         = 2M
tmp_table_size           = 64M
max_heap_table_size      = 64M

# Tabelas abertas
table_open_cache         = 4000
table_definition_cache   = 2000
open_files_limit         = 65535

Após reiniciar o serviço, verifique se o cache de threads está funcionando:

mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'Threads_created';"

+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Threads_created  | 12    |
+------------------+-------+

Um valor baixo de Threads_created em relação ao total de conexões indica que o cache está reaproveitando threads com eficiência. Se o número crescer rapidamente, aumente thread_cache_size.

Para ajustar max_connections sem reiniciar o serviço, use:

SET GLOBAL max_connections = 200;

Ativando e analisando o slow query log no MariaDB 10.11

O slow query log é a ferramenta mais eficaz para identificar queries que degradam a performance do banco. Ele registra automaticamente todas as consultas que ultrapassam o tempo definido em long_query_time, permitindo priorizar otimizações de índice e reescrita de SQL.

Adicione ao arquivo de configuração:

[mysqld]
slow_query_log          = 1
slow_query_log_file     = /var/log/mariadb/slow.log
long_query_time         = 1
log_queries_not_using_indexes = 1
min_examined_row_limit  = 100

Crie o diretório de log caso não exista e ajuste as permissões:

mkdir -p /var/log/mariadb
chown mysql:mysql /var/log/mariadb
chmod 750 /var/log/mariadb

Reinicie o MariaDB para aplicar:

systemctl restart mariadb

Após coletar dados por algumas horas em produção, analise as queries mais lentas:

mysqldumpslow -s t -t 10 /var/log/mariadb/slow.log

Reading mysql slow query log from /var/log/mariadb/slow.log
Count: 47  Time=3.21s (150s)  Lock=0.00s (0s)  Rows=1250.0 (58750), user@host
  SELECT * FROM pedidos WHERE status = 'pendente' ORDER BY criado_em DESC

O output mostra a query executada 47 vezes, com tempo médio de 3,21 segundos. Esse é o candidato prioritário para criação de índice composto em (status, criado_em).

Para verificar o uso do buffer pool em tempo real, consulte também as Dicas de Otimização de Servidores Linux para complementar o monitoramento no nível do sistema operacional.

Aplicando configurações de charset, collation e log binário

Definir o charset padrão corretamente evita problemas de encoding em aplicações PHP e WordPress, além de impactar o tamanho dos índices. O utf8mb4 é o padrão recomendado pois suporta o conjunto completo Unicode, incluindo emojis.

[mysqld]
character-set-server    = utf8mb4
collation-server        = utf8mb4_unicode_ci
init_connect            = 'SET NAMES utf8mb4'

[client]
default-character-set   = utf8mb4

[mysql]
default-character-set   = utf8mb4

Para ambientes com replicação ou recuperação point-in-time, ative o log binário com configurações seguras:

[mysqld]
log_bin                 = /var/log/mariadb/mariadb-bin
binlog_format           = ROW
expire_logs_days        = 7
max_binlog_size         = 100M
sync_binlog             = 1

Atenção: sync_binlog = 1 garante durabilidade máxima mas pode reduzir o throughput de escrita em discos lentos. Em SSDs NVMe, o impacto é mínimo. Em HDDs, considere sync_binlog = 0 apenas se a perda de transações em caso de crash for aceitável.

Verifique o charset após reiniciar:

mysql -u root -p -e "SHOW VARIABLES LIKE 'character_set%';"

+--------------------------+----------+
| Variable_name            | Value    |
+--------------------------+----------+
| character_set_client     | utf8mb4  |
| character_set_connection | utf8mb4  |
| character_set_database   | utf8mb4  |
| character_set_results    | utf8mb4  |
| character_set_server     | utf8mb4  |
+--------------------------+----------+

Validando o tuning com SHOW STATUS e SHOW ENGINE INNODB STATUS

Após reiniciar o MariaDB com as novas configurações, a validação do tuning é tão importante quanto a configuração em si. Use os comandos nativos do MariaDB para confirmar que os parâmetros estão ativos e que o banco está se comportando conforme esperado.

Verifique as variáveis globais aplicadas:

SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW GLOBAL VARIABLES LIKE 'max_connections';
SHOW GLOBAL VARIABLES LIKE 'slow_query_log';

Analise o status do InnoDB para verificar a taxa de acerto do buffer pool:

SHOW STATUS LIKE 'Innodb_buffer_pool_read%';

+---------------------------------------+----------+
| Variable_name                         | Value    |
+---------------------------------------+----------+
| Innodb_buffer_pool_read_requests      | 9842310  |
| Innodb_buffer_pool_reads              | 12450    |
+---------------------------------------+----------+

Calcule a taxa de acerto: (1 - reads / read_requests) * 100. No exemplo acima: (1 - 12450/9842310) * 100 ≈ 99,87%. Uma taxa acima de 99% indica que o buffer pool está dimensionado adequadamente. Taxas abaixo de 95% sugerem que o innodb_buffer_pool_size precisa ser aumentado.

Para uma análise detalhada do motor InnoDB:

SHOW ENGINE INNODB STATUS\G

Procure na seção BUFFER POOL AND MEMORY os campos Buffer pool hit rate e pages read ahead para entender o comportamento de prefetch.

Problemas comuns e como resolver

Sintoma: MariaDB não inicia após alterar innodb_log_file_size

Causa: O tamanho dos arquivos de redo log no disco não corresponde ao valor configurado. O MariaDB 10.11 detecta a inconsistência e recusa a inicialização para proteger a integridade dos dados.
Solução: Pare o serviço com systemctl stop mariadb, remova os arquivos antigos em /var/lib/mysql/ib_logfile* e inicie novamente. O MariaDB recriará os arquivos com o novo tamanho automaticamente. Confirme no log: journalctl -u mariadb -n 50.

Sintoma: Erro "Too many connections" em produção

Causa: O número de conexões simultâneas atingiu o limite definido em max_connections. Isso ocorre frequentemente quando a aplicação não usa pool de conexões ou quando há conexões ociosas acumuladas.
Solução: Aumente max_connections progressivamente com SET GLOBAL max_connections = 300; e implemente um pool de conexões na aplicação (ex: ProxySQL ou o pool nativo do PHP-FPM). Reduza wait_timeout e interactive_timeout para liberar conexões ociosas mais rapidamente.

Sintoma: Queries lentas mesmo após criar índices

Causa: O otimizador de queries pode não estar usando o índice correto, ou as estatísticas de tabela estão desatualizadas após grandes operações de INSERT/DELETE.
Solução: Execute ANALYZE TABLE nome_da_tabela; para atualizar as estatísticas. Use EXPLAIN SELECT ... para verificar qual índice o otimizador está escolhendo. Se necessário, force o índice com USE INDEX (nome_do_indice) na query para diagnóstico.

Sintoma: Alto consumo de memória além do innodb_buffer_pool_size configurado

Causa: Os buffers de sessão (sort_buffer_size, join_buffer_size, etc.) são alocados por conexão ativa. Com 150 conexões e 2 MB de sort_buffer_size, o consumo potencial adicional é de 300 MB apenas nesse buffer.
Solução: Reduza os buffers de sessão para valores menores (512K a 1M) e aumente apenas quando necessário via SET SESSION sort_buffer_size = 4M; em queries específicas. Monitore com ps aux | grep mariadb e compare com o valor configurado.

Perguntas frequentes sobre otimização do MariaDB 10.11

Como saber se o MariaDB está consumindo muita memória no Rocky Linux 9?

Execute mysqladmin -u root -p status ou consulte SHOW STATUS LIKE 'Innodb_buffer_pool%'; dentro do MariaDB. Você também pode usar htop ou ps aux | grep mariadb para verificar o consumo de RAM em tempo real. Se o processo ultrapassar 70% da RAM disponível, é sinal de que o innodb_buffer_pool_size precisa ser ajustado ou que os buffers de sessão estão superdimensionados para a carga atual.

Qual o valor ideal para innodb_buffer_pool_size no MariaDB?

A recomendação geral é definir o innodb_buffer_pool_size entre 50% e 70% da RAM total disponível no servidor, desde que o MariaDB seja o principal serviço em execução. Em um servidor com 4 GB de RAM dedicado ao banco de dados, um valor de 2G a 2,8G é adequado. Ajuste progressivamente e monitore o uso real com SHOW ENGINE INNODB STATUS — a taxa de acerto do buffer pool deve permanecer acima de 99% em cargas normais.

O query_cache do MariaDB ainda vale a pena ativar?

Em cargas de trabalho com muitas leituras repetidas e poucas escritas, o query_cache pode reduzir a latência. Porém, em ambientes com alta concorrência de escritas, ele gera contenção de mutex e degrada a performance. A partir do MariaDB 10.5, o query_cache está desabilitado por padrão e pode ser removido em versões futuras; prefira soluções como Redis ou Memcached para cache de aplicação em ambientes modernos.

Como ativar e analisar o slow query log no MariaDB 10.11?

Adicione slow_query_log = 1, slow_query_log_file = /var/log/mariadb/slow.log e long_query_time = 1 no arquivo /etc/my.cnf.d/mariadb-server.cnf e reinicie o serviço. Após coletar dados, use mysqldumpslow -s t /var/log/mariadb/slow.log para listar as queries mais lentas ordenadas por tempo total de execução — esse relatório é o ponto de partida para otimização de índices.

É necessário reiniciar o MariaDB para aplicar todas as configurações de tuning?

Algumas variáveis podem ser alteradas em tempo real com SET GLOBAL variavel = valor; sem reiniciar o serviço, como max_connections e sort_buffer_size. Porém, parâmetros estruturais como innodb_buffer_pool_size (em versões anteriores ao MariaDB 10.2) e innodb_log_file_size exigem reinicialização completa do daemon para entrar em vigor. No MariaDB 10.11, o buffer pool pode ser redimensionado dinamicamente em alguns cenários, mas a reinicialização ainda é a forma mais segura de garantir que todas as configurações foram aplicadas corretamente.

Conclusão

• Priorize o innodb_buffer_pool_size: defina entre 50–70% da RAM e monitore a taxa de acerto com SHOW STATUS LIKE 'Innodb_buffer_pool_read%' — esse único ajuste costuma gerar o maior ganho de performance.
• Use o slow query log como rotina: ative-o permanentemente em produção e analise semanalmente com mysqldumpslow; queries lentas identificadas cedo evitam degradação progressiva do sistema.
• Ajuste de forma iterativa: altere uma variável por vez, reinicie, monitore por 24–48 horas e só então faça o próximo ajuste — mudanças em lote dificultam identificar qual parâmetro causou melhora ou regressão.

Leia também

• Solucionar lentidão no MySQL 8.0 antes que derrube sua aplicação
• Otimizar MySQL: como reduzir uso de memória e acelerar consultas
• Configurar MariaDB 11.4 no AlmaLinux 9: do padrão ao máximo

Precisa de ajuda com tuning de MariaDB no seu servidor?

Configurar e otimizar um banco de dados em produção exige atenção a detalhes que variam conforme a carga, o hardware e a aplicação. Um VPS com recursos dedicados e suporte técnico especializado pode fazer diferença significativa no desempenho do seu ambiente.

Conheça os planos de VPS da AviraHost e escolha o servidor ideal para o seu banco de dados