禍つSQL
- 1. 禍つSQL
- 2. OSS開発者: CPython, mysqlclient-python, go-sql-driver/mysql, msgpack-python ISUCON6優勝、8予選落ち、9決勝fail 稲田 直哉 Twitter: @methane Github: methane Kラボラトリー
- 4. 4 MySQL のエキスパートではないです。 解説に間違いがあったらごめんなさい。 利用している MySQL は Aurora の MySQL 5.7 です。 まえおき
- 5. 5 序章
- 7. 7 partyテーブル (抜粋) column type 備考 id bigint primary key member_counter int メンバー数
- 8. 8 party_memberテーブル (抜粋) column type 備考 party_id bigint party.id player_id int メンバーのユーザーID (party_id, player_id) の複合PK player_id は unique key
- 9. 9 1. party と party_member をロック (SELECT ... FOR UPDATE) 2. 新しい party_member を INSERT 3. party.member_counter を UPDATE 4. COMMIT パーティー参加
- 11. 11 第一章 パーティーチャット
- 12. 12 1. party と party_member をロック (SELECT ... FOR UPDATE) 2. 新しい party_member を INSERT 3. party.member_counter を UPDATE 4. パーティーチャットに参加 5. COMMIT パーティー参加
- 14. 14 結果
- 15. 15 解決...？ ● innodb_lock_wait_timeout は 50sec ● チャットサービスのAPIは遅くても1秒程度 ● 名前解決等に時間がかかってた形跡もなし 本当にこれがタイムアウトの原因だったのか？
- 16. 16 報告
- 17. 17 第二章 招待デッドロック
- 19. 19 招待
- 20. 20 ● パーティー作成時に、ギルドメンバーやフォローしているユーザーに 招待を送っていた。 ● 相互招待を避けるために招待対象全員のユーザーをロックしていた。 ● 相互フォロワーやギルドメンバーが同時にパーティーを作るとデッド ロックする。 ○ 巻き添えで他のフォロワーやギルドメンバーもロックされタイム アウト大量発生。 招待
- 23. 23 緊急デプロイ
- 24. 24 解決
- 25. 25 翌週 2019-05-12 13:10:21 0x2b3f75a197002019-05-12 13:10:21 0x2b3f75a19700 *** (1) TRANSACTION: TRANSACTION 2056616651, ACTIVE 0 sec inserting mysql tables in use 1, locked 1 LOCK WAIT 6 lock struct(s), heap size 1136, 4 row lock(s) MySQL thread id 151527458, OS thread handle 47340841101056, query id 7830734758 10.0.3.60 user update INSERT INTO party_member (party_id, player_id, job_no, alive_updated, created) VALUES (...) *** (1) WAITING FOR THIS LOCK TO BE GRANTED: ...
- 27. 27 ギャップロック(1) party_id player_id 1 10 1 20 2 11 3 12 party_id=2 を SELECT FOR UPDATE すると、 party_id=2 のレコードを追加できないように前後の ギャップもロックする。 結果 party_id=1 や party_id=3 のレコードも player_id 次第で insert がロック待ちになる。 party_member
- 28. 28 ギャップロック(2) party_id player_id 1 10 1 20 2 11 3 12 party_id=1 と party_id=2 に同時に参加しようとする と、両方ともロックは成功する。 ギャップロックは insert ロックと競合するが、ギャップ ロック同士は競合しない。 party_member
- 29. 29 デッドロック party_id player_id 1 10 1 20 2 11 3 12 (1, 25) も (2, 5) も insert できずデッドロックになる この場合片方のトランザクションが成功しもう片方は Deadlock found エラーになる。 party_member
- 30. 30 リトライする →不安、面倒 party ロックをしているから party_member での排他制御は いらないはず。 →party_member をロックなしの select にする。 解決策？
- 32. 32 MySQL のデフォルトのトランザクション分離レベル トランザクション中は同じクエリは同じ結果を返す トランザクションの最初のクエリを実行した時のバージョン を記憶し、SELECTはそのバージョンの結果を返す。 ※SELECT * ... FOR UPDATE は最新の情報を返す そのトランザクションがINSERTやUPDATEした行を SELECTしたときも最新の情報を返す Repeatable Read
- 33. 33 1. BEGIN 2. SELECT * FROM party WHERE id=? 3. バリデーション等 4. SELECT * FROM party WHERE id=? FOR UPDATE 5. INSERT INTO party_member ... 6. SELECT * FROM party_member WHERE party_id=? 7. UPDATE party SET member_count=? 8. COMMIT パーティー参加
- 34. 34 ● party をロックする前にクエリを実行していた ● SELECT * FROM party_member はロック前のバージョン になる ● 同じ party に同時に参加しようとすると、 SELECT * FROM party_member が1つ少ない行を返す ○ member_counter に1つ少ない値をSETしてしまう！！ ロストアップデート
- 35. 35 /* 3人目 */ BEGIN ... SELECT party ... FOR UPDATE INSERT party_member SELECT party_member ... (3人) UPDATE party SET member_counter=3 COMMIT ロストアップデート /* 4人目 */ BEGIN ... SELECT party ... FOR UPDATE (ロック待ち) . . . INSERT party_member SELECT party_member ... (3人!!) UPDATE party SET member_counter=3 COMMIT
- 36. 36 ● BEGIN 直後に SELECT party ... FOR UPDATE する ○ 今は良いけどあとでエンバグしそう🙄 ● member_counter = member_counter+1 ○ SELECT party_member が減らせる👍 ○ いろんな箇所で触っているので保留 解決案(1)
- 37. 37 ● READ COMMITTED にする? ○ SELECT が最新情報を返す👍 ○ ギャップロックいらない👍 ○ でも副作用がこわいので保留🤔 ● Redisで作り直す！ ○ パーティー機能を大幅強化したい ■ Redisにした方が簡単そう 解決案(2)
- 38. 38 終章
- 39. 39 ● ロック中に外部API呼び出しするのは避けよう ● ロック中に他のロックをするのに気をつけよう ● ギャップロックこわい、ロストアップデートこわい ○ とにかく試そう ● READ COMMITTED や Redis も検討しよう まとめ