blog.elis.cc
11時間前
A safe MySQL upgrade that wasn't so safe
MySQLレプリケーション環境でAUTO_INCREMENT列を追加するマイグレーションを実施したところ、ソースとレプリカでIDの割り当て順序が異なる事態が発生。binlog_formatがMIXEDだったため、5つの関連テーブルはSTATEMENT形式で正しくレプリカ側のIDを参照できたが、AUTO_INCREMENT関連の操作はMySQLがROW形式に自動切り替えするため、1つのテーブルだけソース側のIDがそのままコピーされ、レプリカ上では全く別の行を指す不整合が発生した
MySQLレプリケーション環境でAUTO_INCREMENT列を追加するマイグレーションを実施したところ、ソースとレプリカでIDの割り当て順序が異なる事態が発生。binlog_formatがMIXEDだったため、5つの関連テーブルはSTATEMENT形式で正しくレプリカ側のIDを参照できたが、AUTO_INCREMENT関連の操作はMySQLがROW形式に自動切り替えするため、1つのテーブルだけソース側のIDがそのままコピーされ、レプリカ上では全く別の行を指す不整合が発生した
dev.classmethod.jp
2日前
【MySQL】SELECT MAX(id) FOR UPDATEでID採番すると同時実行でデッドロックする理由を調べてみた
MySQL 8.4でSELECT MAX(id) FOR UPDATEによるID採番を並列実行するとデッドロックが発生する事象を検証。原因はレコードロックとギャップロック（末尾supremumへのロック）の取得順序がセッション間で交差するため。対策としてAUTO_INCREMENT、シーケンステーブル、GET_LOCKによるアドバイザリーロック、UUID採番の4方式を比較し、AUTO_INCREMENTかMySQL公式シーケンスパターンを推奨している。
MySQL 8.4でSELECT MAX(id) FOR UPDATEによるID採番を並列実行するとデッドロックが発生する事象を検証。原因はレコードロックとギャップロック（末尾supremumへのロック）の取得順序がセッション間で交差するため。対策としてAUTO_INCREMENT、シーケンステーブル、GET_LOCKによるアドバイザリーロック、UUID採番の4方式を比較し、AUTO_INCREMENTかMySQL公式シーケンスパターンを推奨している。
www.percona.com
3日前
Performance Progression of Percona Server for MySQL 8.4
Percona Server for MySQL 8.4系の3バージョン（8.4.8-8、8.4.10-10、8.4.11-11）についてsysbench OLTP Read-Writeベンチマークで性能推移を検証。8.4.11-11はInnoDB LRUページフラッシュ最適化により、スレッド数が物理コア数を超える高並行・I/Oバウンド環境で他バージョンを大きく上回るTPSを達成。8.4.10-10はPGO導入により8.4.8-8より高性能。ただしデータが完全にバッファに収まる環境では8.4.10-10がわずかに優位。
Percona Server for MySQL 8.4系の3バージョン（8.4.8-8、8.4.10-10、8.4.11-11）についてsysbench OLTP Read-Writeベンチマークで性能推移を検証。8.4.11-11はInnoDB LRUページフラッシュ最適化により、スレッド数が物理コア数を超える高並行・I/Oバウンド環境で他バージョンを大きく上回るTPSを達成。8.4.10-10はPGO導入により8.4.8-8より高性能。ただしデータが完全にバッファに収まる環境では8.4.10-10がわずかに優位。