Defina o valor correto para max_allowed_packet. |
Em configurações de replicação em que transações grandes ou binlogs excedem o limite, a violação do tamanho do max_allowed_packet pode fazer com que a réplica entre em um estado de cópia com falha e causar o risco de bloqueio
do primário. O uso de colunas BLOB ou VARTEXT para armazenar o conteúdo de arquivos em colunas MySQL pode causar problemas com a replicação e a restauração de backups. Recomenda-se que você configure o max_allowed_packet com o valor máximo
se carregar dados de comprimentos variados em qualquer coluna. Além disso, não use várias colunas LONGBLOB largas em uma tabela específica, pois isso pode levar a situações em que o tamanho da linha excede o máximo permitido, e as restaurações
usando point-in-time podem não funcionar. |
| Implementar chaves primárias em tabelas com grande número de linhas. |
A adição de uma chave primária a qualquer tabela com mais de 5K linhas otimizará muito a replicação e evitará atrasos excessivos. Recomenda-se definir uma chave primária para qualquer tabela na qual operações DELETE ou UPDATE de mais de
5K linhas sejam executadas em instruções únicas. Se não for possível adicionar uma chave primária, DELETE em lotes de < 5K linhas, com confirmações por lote. |
| Prefira DROP TABLE e TRUNCATE TABLE em vez de DELETE de toda a tabela quando possível. |
A replicação registra cada exclusão de linha, o que pode tornar o processo significativamente mais lento. Recomenda-se a divisão das exclusões e atualizações em blocos. Lembre-se de que DROP, CREATE e TRUNCATE são instruções DDL e não são
concluídas durante um backup, mas aguardam até que a operação de backup seja concluída. As entradas de registro mostram mensagens de aviso para o tempo durante o backup em que essas instruções serão bloqueadas. Você pode estimar o tempo
de backup inspecionando o painel de discos usados do painel de monitoramento. Como regra geral, o backup de 500 GB de dados leva aproximadamente 90 minutos. |
| Minimize as operações de várias linhas de instrução única, como UPDATE JOIN ou DELETE, usando cláusulas de intervalo WHERE para minimizar a contagem de linhas tocadas. |
Essa prática pode melhorar o desempenho da consulta e reduzir a contenção de bloqueios. |
| Use o pooling de conexões no final do aplicativo. |
O pooling reutiliza as conexões, evitando o limite máximo de conexões. Certifique-se de que o tamanho do pool esteja bem abaixo do tamanho do banco de dados max_connections. Implemente a lógica de repetição e capture exceções
para lidar com a exaustão do pool ou com falhas de conexão. |
| Reduza o raio de explosão usando uma instância dedicada ICD-MySQL por aplicativo de produção. |
A separação de aplicativos reduz o volume por instância de serviço, minimizando os problemas causados pela agregação da demanda de muitos aplicativos. |
| Implante uma réplica de leitura MySQL por instância MySQL. |
As réplicas de leitura oferecem a capacidade de suportar o tráfego de leitura da instância principal, reduzindo a carga de trabalho geral e aumentando a confiabilidade. |
| Hospedagem do MySQL em uma instância dedicada |
Para ambientes de produção, especialmente aqueles que prevêem crescimento, aumento do tráfego ou que exigem alta confiabilidade e desempenho, recomendamos fortemente hospedar o MySQL em uma instância dedicada. Isso garante melhor isolamento
de recursos, escalabilidade e estabilidade geral do sistema. |