MySQL升级陷阱:AUTO_INCREMENT引发的数据错乱

A safe MySQL upgrade that wasn't so safe

我收到数据库版本过期的通知,为了避开AWS的额外支持费,我决定升级。我按惯例先升级了绿色的副本,确认无误后切换流量,本以为一切顺利。然而一小时后,奇怪的Bug报告接踵而至。检查发现,某张表的主键ID顺序在源库和副本上完全不一致,导致关联表中的外键指向了错误的行。原来,在MIXED模式下,MySQL对包含AUTO_INCREMENT列的更新操作,在源库使用STATEMENT模式,却在副本上切换到了ROW模式。这种复制机制的微妙差异,让原本安全的升级演变成了一场数据灾难。

这类问题最可怕的地方在于,它既出乎意料又极易被忽视,却能在生产环境中迅速演变成一场灾难,让你事后只能困惑不已。
  1. Insimwytim

    这事儿挺有意思(当然不是那种好玩的意思)。

    既然升级是通过 AWS RDS 半自动完成的,AWS 要不要为此负责?除非迁移说明里明确警告过这种用法,否则我觉得他们应该负责。

  2. 190n

    我不明白为什么这个问题只在升级后出现,而不是在迁移添加列之后立刻出现?

  3. krautburglar

    在我看来,在副本间混用 binlog 格式属于用户操作失误。

同日更多故事

2026-08-29