AWS RDS での MySQL の定期的なアップグレードが、グリーン レプリカの昇格時にサイレントなデータ破損を引き起こしました。レプリカのアップグレードと機能の確認後、著者はトラフィックを切り替えました。1 時間後、重大なバグが発生しました：1 つのテーブル（テーブル X）のオートインクリメント ID が、ソースとレプリカで異なる順序で割り当てられていました。以前は ID 1 を保持していた行が、今では ID 26 を保持しています。

根本的な原因は、以前の移行にさかのぼります。その移行では、`ALTER TABLE X ADD COLUMN id INT NOT NULL AUTO_INCREMENT PRIMARY KEY` を使用してテーブル X に AUTO_INCREMENT プライマリ キーが追加されました。6 つの関連テーブルが、この新しい ID を参照するように JOIN ベースの UPDATE ステートメントで更新されました。ただし、MySQL のドキュメントでは、レプリケートされたテーブルに AUTO_INCREMENT 列を追加すると、ストレージ エンジンと処理の順序によって、ソースとレプリカ間で行の順序が異なる可能性があると警告しています。

この不一致は、ソース データベースの `binlog_format=MIXED` によって現れました。5 つのテーブルが、STATEMENT モードで UPDATE ステートメントをレプリケートし、これによりレプリカは、ローカルの（異なる）ID 値に対して JOIN を再実行しました — 参照を正しくマッピングしました。しかし、AUTO_INCREMENT 列も持っていた 6 番目のテーブルは、ステートメントベースのレプリケーションに対して安全でないと判断され、ROW モードでログ記録されました。レプリカは、ソースからの生の行変更を適用し、ソースによって生成された `x_id` 値をコピーしました。これらの値は now 、レプリカ上の間違った行を指しています。

AUTO_INCREMENT の割り当て順序、MIXED バイナリ ロギング、および安全でないステートメントの検出の間のこの微妙な相互作用が、サイレントな参照整合性の障害を引き起こしました。著者は、このような問題はアップグレード中に見逃されやすいが、データを急速に破損させる可能性があると警告しています。

主要なエンティティ: 企業: AWS, MySQL