MySQL aguenta aplicações críticas e escaláveis? O que diz a prática

Existe um preconceito antigo de que MySQL é "banco de blog". Quem diz isso nunca olhou a infraestrutura do Facebook, do Booking, do Shopify ou de metade dos bancos digitais brasileiros. MySQL aguenta missão crítica — desde que você monte a arquitetura para isso. Sozinho, um servidor solto não é crítico em lugar nenhum, com nenhum produto.

Comece pelos números, não pela tecnologia

Antes de escolher topologia, escreva dois números no papel:

• RPO — quanto dado o negócio aceita perder num desastre (zero? 5 segundos? 1 hora?).
• RTO — quanto tempo pode ficar fora do ar (30 segundos? 15 minutos?).

RPO zero custa caro e exige replicação síncrona. RPO de 5 minutos roda com replicação assíncrona e backup. Quem define esses números é o negócio; quem paga a conta da arquitetura também.

As topologias, do mais simples ao mais robusto

Topologia	RPO típico	Failover	Complexidade
Primário + réplica assíncrona	segundos a minutos	manual	baixa
Semi-síncrona (1 réplica confirma)	próximo de zero	manual ou orquestrado	média
InnoDB Cluster (Group Replication + MySQL Router)	zero	automático	média-alta
Galera / MariaDB Cluster	zero	automático, multi-master	alta
Aurora MySQL / cloud gerenciada	próximo de zero	automático	baixa (custo alto)

Replicação semi-síncrona na prática

É o melhor custo-benefício para quem quer durabilidade sem entrar em cluster completo. O commit no primário só retorna depois que ao menos uma réplica confirmou o recebimento do log:

-- No primário (MySQL 8.4)
INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
SET GLOBAL rpl_semi_sync_source_enabled = 1;
SET GLOBAL rpl_semi_sync_source_timeout = 1000;   -- ms antes de cair para assíncrono

-- Na réplica
INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';
SET GLOBAL rpl_semi_sync_replica_enabled = 1;

E a configuração de durabilidade que eu não abro mão em ambiente crítico:

innodb_flush_log_at_trx_commit = 1
sync_binlog                    = 1
gtid_mode                      = ON
enforce_gtid_consistency       = ON
binlog_expire_logs_seconds     = 604800

GTID é inegociável: sem ele, promover uma réplica depois de uma queda vira arqueologia de posição de binlog às três da manhã. Já fiz. Não recomendo.

Monitorar o atraso de réplica

SHOW REPLICA STATUS\G
-- Olhe: Seconds_Behind_Source, Replica_SQL_Running, Last_SQL_Error

-- Visão precisa em MySQL 8:
SELECT channel_name,
       service_state,
       last_applied_transaction_end_apply_timestamp
FROM performance_schema.replication_applier_status_by_worker;

Réplica atrasando em carga de escrita pesada? Aumente o paralelismo de aplicação: replica_parallel_workers = 8 com replica_parallel_type = LOGICAL_CLOCK e replica_preserve_commit_order = ON.

Escalar leitura e escrita

• Leitura: réplicas + roteamento na aplicação ou via MySQL Router/ProxySQL. Cuidado com leitura obsoleta — transação que lê o que acabou de escrever tem que ir no primário.
• Escrita: primeiro tuning e índice, depois separar domínios em instâncias, e só então sharding, como descrevi em MySQL com grandes volumes de dados.
• Conexões: use pool. Milhares de conexões ociosas batendo direto no banco é receita de incidente.

Backup só existe se for restaurado

Dump lógico com mysqldump serve para bases pequenas. Acima de algumas dezenas de GB, use backup físico (Percona XtraBackup ou MySQL Enterprise Backup) e guarde os binlogs para point-in-time recovery.

xtrabackup --backup --target-dir=/backup/full --user=bkp --password=***
xtrabackup --prepare --target-dir=/backup/full

A regra que eu repito em todo treinamento: backup não testado é arquivo de estimação. Agende um restore de verdade a cada trimestre e cronometre. Esse tempo é o seu RTO real — não o que está no slide.

Checklist de produção crítica

1. GTID ligado e replicação semi-síncrona no mínimo.
2. Failover orquestrado e testado (InnoDB Cluster, Orchestrator ou serviço gerenciado).
3. Backup físico diário + binlogs + restore testado com cronômetro.
4. Monitoramento de atraso de réplica, hit ratio do buffer pool e locks.
5. Réplica dedicada a relatórios, fora do caminho do OLTP.
6. Runbook escrito de failover — a pessoa de plantão não vai improvisar bem às 3h.

Com isso no lugar, MySQL entrega quatro noves sem drama. Sem isso, nenhum banco do mundo entrega — nem os caros.

Para o quadro completo, volte ao guia definitivo de MySQL. Se a sua dúvida é de escolha de produto, veja MySQL ou MariaDB e MySQL ou PostgreSQL.

---

Sobre o autor: Alexandre Almeida atua com bancos de dados há mais de 25 anos, foi instrutor oficial de MySQL e Oracle para mais de 1.000 alunos e é autor de Aprendendo MySQL: Prática, Teoria e Laboratórios. Quer montar replicação e failover num laboratório seu? Veja os treinamentos.

Fontes: MySQL 8.4 Reference Manual (Replication, Group Replication, InnoDB Cluster), documentação do Percona XtraBackup e experiência em ambientes de produção 24x7.