Os maiores dias de compras online do ano estão chegando. Seu banco de dados está pronto? Ao ajustar 20 variáveis-chave do sistema MariaDB, você aumentará o desempenho do seu banco de dados , escalabilidade e disponibilidade , garantindo que cada cliente em potencial tenha uma experiência de usuário tranquila. As seguintes variáveis de sistema aparecem repetidamente na configuração de um ambiente de servidor MariaDB ideal. Implemente nossas recomendações para os valores mais ajustados e torne o período Black Friday–Cyber Monday deste ano o melhor de todos.
Algumas notas importantes:
- Não aceite essas sugestões cegamente. Cada ambiente MariaDB é único e requer uma reflexão adicional antes de fazer qualquer alteração. Você provavelmente precisará ajustar essas configurações para seu caso de uso e ambiente específicos.
- O arquivo de configuração do MariaDB está localizado em /etc/my.cnf. Toda vez que você modificar este arquivo, você precisará reiniciar o serviço MySQL para que as novas alterações tenham efeito.
20 recomendações de ajuste de Black Friday e Cyber Monday
1. Tamanho do buffer do InnoDB
O tamanho do buffer pool do InnoDB esta é a configuração nº 1 a ser observada em qualquer instalação usando o InnoDB. O conjunto de buffers é onde os dados e índices são armazenados em cache; tê-lo o maior possível garantirá que você use memória e não discos para a maioria das operações de leitura.
2. Tamanho do arquivo de log do InnoDB
innodb_log-file-size é o tamanho dos redo logs, que são usados para garantir que as gravações sejam rápidas e duráveis. Há duas sugestões gerais para o dimensionamento do arquivo de registro do InnoDB:
- Defina o tamanho total combinado dos arquivos de registro do InnoDB maior que 25–50% do tamanho do buffer pool do InnoDB
ou
- Defina o tamanho do registro combinado do arquivo de registro do InnoDB igual a uma hora de entradas de registro durante o pico de carga
Arquivos de registro maiores podem levar a uma recuperação mais lenta em caso de falha do servidor. No entanto, eles também reduzem o número de pontos de verificação necessários e reduzem a E/S de disco.
Avalie o tamanho de uma hora de logs binários sob carga operacional e decida se aumentar o tamanho dos arquivos de log do InnoDB.
Acertar os tamanhos dos arquivos de log innodb é importante para obter um bom desempenho do sistema. O mecanismo de armazenamento InnoDB do MariaDB usa um espaço de redo log de tamanho fixo (circular). O tamanho é controlado por innodb_log_file_size e innodb_log_files_in_group (padrão 2). Multiplique esses valores para obter o espaço de redo log disponível para uso. Embora tecnicamente não deva importar se você usa a variável innodb_log_file_size ou innodb_log_files_in_group para controlar o tamanho do espaço de redo, a maioria das pessoas apenas trabalha com o innodb_log_file_size e deixa innodb_log_files_in_group sozinho.
O tamanho do espaço de redo do InnoDB é uma das opções de configuração mais importantes para cargas de trabalho com uso intenso de gravação. No entanto, ele vem com trocas. Quanto mais espaço de redo configurado, melhor o InnoDB pode otimizar a E/S de gravação. No entanto, aumentar o espaço de refazer também significa tempos de recuperação mais longos quando o sistema perde energia ou trava por outros motivos.
3. Tamanho do buffer de log do InnoDB
Um tamanho maior de buffer de log do InnoDB significa menos E/S de disco para transações maiores. Sugere-se definir isso para 64M em todos os servidores.
4. Intervalo de liberação de log do InnoDB
A variável innodb_flush_log_at_trx_commit controla quando ocorre a liberação do buffer de registro para o disco. innodb_flush_log_at_trx_commit =1 (padrão) libera o buffer de registro para o disco a cada confirmação de transação. Essa é a opção mais segura, mas também a de menor desempenho.
innodb_flush_log_at_trx_commit =0 libera o buffer de registro para o disco a cada segundo, mas nada na confirmação da transação. Até um segundo (possivelmente mais devido ao agendamento do processo) pode ser perdido. Se houver alguma falha, o MySQL ou o servidor podem perder dados. Essa é a opção mais rápida, mas menos segura.
innodb_flush_log_at_trx_commit =2 grava o buffer de log no arquivo em cada confirmação, mas é liberado no disco a cada segundo. Se o cache de disco tiver um backup de bateria (por exemplo, um controlador de invasão de cache com bateria), esse geralmente é o melhor equilíbrio entre desempenho e segurança. Uma falha do MySQL não deve perder dados. Uma falha de servidor ou falta de energia pode perder até um segundo (possivelmente mais devido à programação do processo). Um cache com bateria reduz essa possibilidade.
Sugerimos usar a primeira opção por segurança.
5. Capacidade de E/S do InnoDB
innodb_io_capacity deve ser definido para aproximadamente o número máximo de IOPS que o armazenamento subjacente pode processar.
Por padrão, isso é definido como 1000. Recomendamos fazer um benchmarking do armazenamento para determinar se você pode aumentar ainda mais esse valor.
6. Tamanho do cache de thread
Monitore o valor de Threads_created. Se continuar aumentando em mais de alguns threads por minuto, aumente o valor de thread_cache_size.
O tamanho do cache de thread é definido como 200 na configuração padrão atual.
7. Cache de tabela e Cache de definição de tabela
As variáveis table_open_cache e table_defintion_cache controlam o número de tabelas e definições a serem mantidas abertas para todos os encadeamentos.
Monitore Open_tables, Open_table_defintitions, Opened_tables e Opened_table_definitions para determinar o melhor valor. A sugestão geral é definir table_open_cache (e posteriormente table_definition_cache) apenas alto o suficiente para reduzir a taxa de aumento do valor de status Opened_tables (e Opened_table_definitions).
Ambos table_open_cache e table_defintion_cache são definidos como 2048 na configuração padrão.
8. Cache de consulta
O cache de consulta é um gargalo bem conhecido que pode ser visto mesmo quando a simultaneidade é moderada. A melhor opção é desativá-lo desde o primeiro dia definindo query_cache_size =0 (o padrão no MariaDB 10) e usar outras maneiras de acelerar as consultas de leitura:ter uma boa indexação, adicionar réplicas para distribuir a carga de leitura ou usar um cache externo ( memcache ou redis, por exemplo). Se você já construiu seu aplicativo MariaDB com o cache de consulta ativado e nunca notou nenhum problema, o cache de consulta pode ser benéfico para você. Nesse caso, tenha cuidado se decidir desativá-lo.
9. Tabelas temporárias, tmp_table_size e max_heap_table_size
O MySQL usa o menor de max_heap_table_size e tmp_table_size para limitar o tamanho das tabelas temporárias na memória. Estas são por variáveis de cliente. Embora ter esse valor grande pode ajudar a reduzir o número de tabelas temporárias criadas no disco, também aumenta o risco de atingir a capacidade de memória do servidor, pois isso é por cliente. Geralmente, 32 milhões a 64 milhões é o valor sugerido para começar para ambas as variáveis e ajustar conforme necessário.
As tabelas temporárias costumam ser usadas para GROUP BY, ORDER BY, DISTINCT, UNION, subconsultas etc. Idealmente, o MySQL deve criá-las na memória, com o mínimo possível em disco.
É importante observar que as consultas que não usam junções de maneira adequada e a criação de grandes tabelas temporárias podem ser um motivo para um número maior de tabelas temporárias no disco. Outro motivo é que o mecanismo de armazenamento de memória usa colunas de comprimento fixo e assume o pior cenário. Se as colunas não forem dimensionadas corretamente (por exemplo, um VARCHAR(255) para uma string curta), isso influenciará o tamanho da tabela na memória e poderá fazer com que ela vá para o disco antes do que deveria. Além disso, as tabelas temporárias com blob e colunas de texto irão imediatamente para o disco, pois o mecanismo de armazenamento de memória não é compatível com elas.
Ambos estão atualmente configurados para 64M por padrão.
10. Nível de registro de aviso
Recomendamos definir o nível do registro de avisos como log_warnings =2. Isso registra informações sobre conexões interrompidas e erros de acesso negado.
11. Máximo de conexões
Se você encontrar o erro "Muitas conexões" com frequência, max_connections é muito baixo. Frequentemente, como o aplicativo não fecha as conexões com o banco de dados corretamente, você precisa de muito mais do que as 151 conexões padrão. A principal desvantagem de valores altos para max_connections (digamos, 1.000 ou mais) é que o servidor não responderá se precisar executar tantas transações ativas. Usar um pool de conexões no nível do aplicativo ou um pool de threads no nível MariaDB pode ajudar aqui.
12. Isolamento de transação
Investigue os níveis de isolamento de transações disponíveis e determine o melhor isolamento de transações para o caso de uso do seu servidor.
13. Formato de registro binário
Recomendamos usar o formato de registro binário ROW para replicação mestre-mestre.
14. Deslocamentos de incremento automático
Para ajudar a reduzir as chances de colisão entre dois mestres sendo gravados simultaneamente, os valores de deslocamento de incremento automático e incremento automático precisam ser ajustados de acordo.
15. Sincronizar Binlog
Por padrão, o sistema operacional lida com a liberação do log binário para o disco. No caso de uma falha do servidor, é possível perder transações do registro binário, fazendo com que a replicação fique fora de sincronia. Definir sync_binlog =1 faz com que o arquivo binlog seja liberado em cada confirmação.
Isso é mais lento, mas a opção mais segura.
16. Crash Safe(r) Slaves
Para ajudar a evitar erros de replicação após uma falha do escravo, habilite a recuperação do log de retransmissão e a sincronização do log de retransmissão e dos arquivos de informações do log de retransmissão para o disco.
17. Atualizações do Log Slave
Para ter replicação encadeada (master -> slave -> slave), log_slave_updates precisa ser ativado. Isso instrui um escravo a gravar transações replicadas em seu próprio log binário para que elas possam ser replicadas para escravos a partir dele.
18. Escravos somente leitura
Slaves devem ser somente leitura para evitar que dados sejam acidentalmente gravados neles.
Observação :Usuários com superprivilégios ainda podem escrever quando o servidor é somente leitura.
19. Tempo limite da rede escrava
A variável slave_net_timeout é o número de segundos que o escravo aguardará por um pacote do mestre antes de tentar se reconectar. O padrão é 3600 (1 hora). Isso significa que, se o link cair e não for detectado, pode levar até uma hora para o escravo se reconectar. Isso pode fazer com que o escravo subitamente fique até uma hora atrás do mestre.
Recomendamos definir slave_net_timeout para um valor mais razoável, como 30 ou 60.
20. Assista ao nosso webinar sobre como se preparar para a Black Friday e a Cyber Monday
Assista ao nosso webinar sob demanda – Preparação para a Black Friday e a Cyber Monday – para aprender os quatro princípios vitais da preparação do banco de dados: medidas de segurança para proteger seu banco de dados contra ataques maliciosos, ajuste de desempenho para garantir uma experiência de usuário tranquila, estratégias de alta disponibilidade para garantir que você não perca uma única venda e escalabilidade para se preparar tanto para o crescimento previsto quanto para picos inesperados.
