Una actualización rutinaria de MySQL en AWS RDS desencadenó un problema de corrupción de datos silenciosa al promover una réplica verde. Después de actualizar la réplica y verificar su funcionalidad, el autor cambió el tráfico. Una hora después, surgió un error crítico: una tabla (tabla X) tenía sus IDs de auto-incremento asignados en un orden diferente en la réplica frente al origen. La fila que anteriormente tenía el ID 1 ahora tenía el ID 26.

La causa raíz se remonta a una migración anterior que agregó una clave primaria AUTO_INCREMENT a la tabla X mediante `ALTER TABLE X ADD COLUMN id INT NOT NULL AUTO_INCREMENT PRIMARY KEY`. Seis tablas relacionadas se actualizaron para referenciar este nuevo ID utilizando sentencias UPDATE basadas en JOIN. Sin embargo, la documentación de MySQL advierte que agregar columnas AUTO_INCREMENT a tablas replicadas puede producir un orden de filas diferente en el origen y la réplica, dependiendo del motor de almacenamiento y el orden de procesamiento.

La discrepancia se manifestó debido al formato de binlog de la base de datos de origen `binlog_format=MIXED`. Cinco tablas replicaron sus sentencias UPDATE en modo STATEMENT, lo que hizo que la réplica volviera a ejecutar el JOIN contra sus valores de ID locales (diferentes), mapeando correctamente las referencias. Pero la sexta tabla, que también tenía una columna AUTO_INCREMENT, se consideró insegura para la replicación basada en sentencias y se registró en modo ROW. La réplica aplicó cambios de fila sin procesar desde el origen, copiando los valores `x_id` generados en el origen que ahora apuntaban a filas incorrectas en la réplica.

Esta sutil interacción entre el orden de asignación de AUTO_INCREMENT, el registro binario MIXED y la detección de sentencias inseguras provocó un fallo silencioso de integridad referencial. El autor advierte que estos problemas son fáciles de pasar por alto durante las actualizaciones, pero pueden corromper los datos rápidamente.

Entidades clave: Empresas: AWS, MySQL