Uma atualização rotineira do MySQL na AWS RDS desencadeou um problema silencioso de corrupção de dados ao promover uma réplica verde. Após atualizar a réplica e verificar sua funcionalidade, o autor mudou o tráfego. Uma hora depois, surgiu um bug crítico: uma tabela (tabela X) tinha seus IDs de auto-incremento atribuídos em uma ordem diferente na réplica em comparação com a fonte. A linha que anteriormente detinha o ID 1 agora detinha o ID 26.

A causa raiz remonta a uma migração anterior que adicionou uma chave primária AUTO_INCREMENT à tabela X por meio de `ALTER TABLE X ADD COLUMN id INT NOT NULL AUTO_INCREMENT PRIMARY KEY`. Seis tabelas relacionadas foram atualizadas para referenciar esse novo ID usando instruções UPDATE baseadas em JOIN. No entanto, a documentação do MySQL alerta que a adição de colunas AUTO_INCREMENT em tabelas replicadas pode resultar em uma ordem de linhas diferente na fonte e na réplica, dependendo do mecanismo de armazenamento e da ordem de processamento.

A discrepância se manifestou devido ao formato de binlog do banco de dados de origem `binlog_format=MIXED`. Cinco tabelas replicaram suas instruções UPDATE no modo STATEMENT, fazendo com que a réplica executasse novamente o JOIN em relação aos seus valores de ID locais (diferentes) — mapeando corretamente as referências. Mas a sexta tabela, que também tinha uma coluna AUTO_INCREMENT, foi considerada insegura para replicação baseada em instruções e foi registrada no modo ROW. A réplica aplicou alterações de linha brutas da fonte, copiando os valores `x_id` gerados pela fonte que agora apontavam para linhas incorretas na réplica.

Esta interação sutil entre a ordem de atribuição de AUTO_INCREMENT, o log binário MIXED e a detecção de instruções inseguras causou uma falha silenciosa de integridade referencial. O autor alerta que esses problemas são fáceis de serem ignorados durante atualizações, mas podem corromper os dados rapidamente.

Entidades-chave: Empresas: AWS, MySQL