La actualización de bases de datos MySQL puede generar inconsistencias silenciosas si no se consideran las implicaciones de la replicación con columnas AUTO_INCREMENT. Un caso documentado muestra cómo una migración aparentemente segura resultó en referencias cruzadas incorrectas tras el cambio a una réplica, debido a diferencias en la asignación de identificadores entre el origen y la réplica.
El problema surge al añadir una nueva clave primaria autoincremental mediante ALTER TABLE. Según la documentación oficial, esta operación no garantiza que los IDs se asignen en el mismo orden en el servidor origen y en la réplica, ya que depende del motor de almacenamiento y del orden de procesamiento de las filas. En el incidente descrito, cinco tablas relacionadas mantuvieron referencias correctas, pero una sexta quedó desincronizada.
La causa raíz reside en el formato del registro binario (binlog) configurado en modo MIXED. Para la mayoría de las actualizaciones, MySQL utilizó el modo STATEMENT, ejecutando la sentencia SQL en la réplica y resolviendo los IDs locales correctamente. Sin embargo, para la tabla problemática, que contenía una columna AUTO_INCREMENT, MySQL conmutó automáticamente al modo ROW por considerarlo inseguro para la replicación basada en sentencias. En este modo, se copian directamente los valores de fila generados en el origen, ignorando los IDs locales de la réplica.
Este comportamiento técnico subraya la necesidad de auditar cuidadosamente las configuraciones de binlog y las migraciones que involucran autoincrementos en entornos replicados. La lección clave es que las características de conveniencia como AUTO_INCREMENT pueden introducir riesgos sutiles de integridad de datos si no se comprenden sus interacciones con los mecanismos de replicación.