RDBのトラブルの現場を追え！ ~ 様々な現場を見る ~ / rdb-troubleshooting2

RDBのトラブルの現場を追え！ 
~ 様々な現場を見る ~ 
builderscon tokyo 2019

View Slide

What is it? 
RDBMSの死はサービスの死 

View Slide

What is it? 
● DBが突然遅くなった… 
● コネクションが溢れてサービス停止… 
● INDEXを貼ろうとしたらエラー… 
現場の声 

View Slide

What is it? 
現場の悲鳴声のお届けします 

View Slide

あじぇんだ 
1. 自己紹介 
2. 初級編：スロークエリを追え！ 
3. 中級編：エラーログを追え！ 
4. 上級編：未知のエラーを追え！ 
5. 番外編：何もしてないのにDBが壊れた 
6. まとめ 

View Slide

View Slide

この話はこっちのスライドを見てください 
https://speakerdeck.com/soudai/rdb-troubleshooting

View Slide

あじぇんだ 
1. 自己紹介 
2. demo 1 
3. demo 2 
4. demo 3 
5. demo 4 
6. まとめ 

View Slide

View Slide

あじぇんだ 
1. 自己紹介 
2. スロークエリの現場 
3. 不正データの現場 
4. パフォーマンスチューニングの現場 
5. 突然DBが壊れた現場 
6. まとめ 

View Slide

自己紹介 
曽根壮大（34歳） 
株式会社オミカレ副社長 CTO 
 
そ　ね　　たけとも 
● 日本PostgreSQLユーザ会勉強会分科会担当 
● 3人の子供がいます（長女、次女、長男） 
● 技術的にはWeb/LL言語/RDBMSが好きです 
● コミュニティが好き

View Slide

婚活といえばオミカレ 
https://party-calendar.net/

View Slide

View Slide

本書きました 

View Slide

先週のそーだいさん 

View Slide

昨日のそーだいさん 

View Slide

あじぇんだ 
1. 自己紹介 
6. まとめ 

View Slide

スロークエリの現場 
サービスを殺すには刃物は要らぬ。 
スロークエリがあれば良い。 

View Slide

 
REPLACE INTO hoge(id, name)
SELECT id, name
FROM foo AS f
INNER JOIN bar AS b ON f.event_id = b.id
WHERE f.id in (
SELECT max(event_id)
FROM f
WHERE canceled_at IS NULL
GROP BY event_id, sheet_id
);

View Slide

もうおわかりですね？ 

View Slide

 
SELECT id, name
FROM foo AS f
WHERE f.id in (
FROM f
);

View Slide

 
SELECT id, name
FROM foo AS f
WHERE f.id in (
FROM f
);
REPLACE 構文はMySQLの独自構文 

View Slide

 
SELECT id, name
FROM foo AS f
WHERE f.id in (
FROM f
);
一般的なサブクエリ 

View Slide

つまり… 

View Slide

MySQL 5.5 相当以下だと死ぬ 

View Slide

簡単でしたね 

View Slide

 
UPDATE hoge
SET binary = ‘とてもでかい文字列’
WHERE id = 1;

View Slide

バイナリをDBに保存するな？ 
 

View Slide

バイナリをDBに保存するな？ 
↓ 
それはそう 

View Slide

これがPostgreSQLだったら？ 

View Slide

これがPostgreSQLだったら？ 
↓ 
更新はコスト 

View Slide

HOT(Heap Only Tuples)があるでしょ？ 

View Slide

HOT(Heap Only Tuples)があるでしょ？ 
↓ 
更新後のデータが同じファイルでは無い時はHOTは
利用できません！！！ 

View Slide

まぁPostgreSQLなのだから 
必要ならラージオブジェクトを使いましょう 

View Slide

まぁでかいデータをRDBMSに入れるな 
パスで良い 
（ファントムファイル？誤差です） 

View Slide

バルクインサート使ってます？ 

View Slide

バルクインサート使ってます？ 
↓ 
もっと早いのあります 

View Slide

MySQLならLOAD 
PostgreSQLならCOPY 
マジ便利なのでこれだけは覚えて 

View Slide

スロークエリは本当に様々ある 

View Slide

スロークエリは本当に様々ある 
↓ 
無知の豪腕と 
そもそもテーブル設計が悪いパターンがある 

View Slide

どちらに問題があるかを考えて 
適切に対応していくことが大事 

View Slide

スロークエリログを見て 
実行計画を見て 
TABLE設計を見直せば 
自然と道が見えてくるのじゃ 

View Slide

あじぇんだ 
1. 自己紹介 
6. まとめ 

View Slide

不正データの現場 
データは制約で守りましょう 

View Slide

完 

View Slide

…しかし制約でも守れないデータが！ 

View Slide

id user_id event_id seat_id reservation_at cancel_at
1 1 1 1 2019/08/19 09:10 null
2 1 2 1 2019/08/20 09:10 2019/08/21 09:10
3 1 2 4 2019/08/22 09:10 null
4 1 3 3 2019/08/23 09:10 null
︙ ︙ ︙ ︙ ︙ ︙

View Slide

1 1 1 1 2019/08/19 09:10 null
2 1 2 1 2019/08/20 09:10 2019/08/21 09:10
3 1 2 4 2019/08/22 09:10 null
4 1 3 3 2019/08/23 09:10 null
︙ ︙ ︙ ︙ ︙ ︙
予約日時は必ず今よりも後 

View Slide

1 1 1 1 2019/08/19 09:10 null
2 1 2 1 2019/08/20 09:10 2019/08/21 09:10
3 1 2 4 2019/08/22 09:10 null
4 1 3 3 2019/08/23 09:10 null
︙ ︙ ︙ ︙ ︙ ︙
キャンセル日時は必ず予約日時よりも後 

View Slide

素直にcheck制約で設定すると 
reservation_at > now() 
cancel_at > reservation_at 

View Slide

これで安心！とはならない… 

View Slide

過去のデータ、リストア出来ません！！！ 
（テストでも困るし、リストアで困る） 

View Slide

なので最初に遅延制約をつけましょう 
(DEFERRABLE INITIALLY DEFERRED) 
※PostgreSQLの場合 

View Slide

1 1 2 1 2019/08/19 09:10 null
2 1 2 1 2019/08/20 09:10 2019/08/21 09:10
3 1 2 1 2019/08/22 09:10 null
4 1 3 3 2019/08/23 09:10 null
︙ ︙ ︙ ︙ ︙ ︙

View Slide

キャンセルされて無いのに 
同じ席を予約されてはいけない 

View Slide

cancel_atが無い時は 
event_it+seat_idは組み合せユニーク 
 

View Slide

それPostgreSQLなら出来るよ 
(UNIQUE制約にWHERE句を付けれる) 

View Slide

 
CREATE UNIQUE INDEX
event_seat_idx
ON reservation (event_id,seat_id)
WHERE cancel_at IS NULL;

View Slide

完 

View Slide

とはならない！ 

View Slide

レコードの連続性の正当性 

View Slide

そもそも 

View Slide

キャンセルされて無いのに 
同じ席を予約されてはいけない 

View Slide

1 1 2 1 2019/08/19 09:10 null
2 1 2 1 2019/08/20 09:10 2019/08/21 09:10
3 1 2 1 2019/08/22 09:10 null
4 1 3 3 2019/08/23 09:10 null
︙ ︙ ︙ ︙ ︙ ︙

View Slide

1 1 2 1 2019/08/19 09:10 null
2 1 2 1 2019/08/20 09:10 2019/08/21 09:10
3 1 2 1 2019/08/22 09:10 null
4 1 3 3 2019/08/23 09:10 null
︙ ︙ ︙ ︙ ︙ ︙
キャンセルされてから、次のデータが正しい 

View Slide

1 1 2 1 2019/08/19 09:10 null
2 1 2 1 2019/08/20 09:10 2019/08/21 09:10
3 1 2 1 2019/08/22 09:10 null
4 1 3 3 2019/08/23 09:10 null
︙ ︙ ︙ ︙ ︙ ︙
キャンセルされてなかったのに次のレコードが入ってる 

View Slide

実際の運用上、起こり得ないですよね 

View Slide

これの制約を書くのは大変なので割愛します 

View Slide

そもそもこんなデータ入らないでしょ？ 

View Slide

テストデータとかバグとか 
ヒューマンエラーとかで入るんですよね 

View Slide

データはINSERTやUPDATEに成功しても 
それが正しいのは判断は難しい 

View Slide

制約でデータを守る 
テストで振る舞いを守る 
モニタリングでサービスを守る 

View Slide

適切な制約に 
適切なデータは宿る 

View Slide

正しさを常に求めていきましょう 

View Slide

あじぇんだ 
1. 自己紹介 
6. まとめ 

View Slide

パフォーマンスチューニングの現場 
そもそもさっきのreservationテーブル 
ロックが激しくて現実では厳しい 
（主にISUCON8） 

View Slide

seatテーブルには席の一覧がある 

View Slide

 
SELECT
*
FROM seat
ORDER BY RAND()
LIMIT 1;

View Slide

空席考慮してないでしょ！ 
(考慮したSQL、途端に長くなるので割愛) 

View Slide

再掲 
1 1 1 1 2019/08/19 09:10 null
2 1 2 1 2019/08/20 09:10 2019/08/21 09:10
3 1 2 4 2019/08/22 09:10 null
4 1 3 3 2019/08/23 09:10 null
︙ ︙ ︙ ︙ ︙ ︙

View Slide

飲み友達に聞きました 

View Slide

InnoDBを使いこなす 
ならこうやで！ 
(プライバシー保護のため加工されています) 

View Slide

remainsテーブルの例 
id event_id seat_id reservation_at
1 1 11049 null
2 1 5467 null
3 1 3333 null
4 1 14 null
︙ ︙ ︙ ︙

View Slide

1 1 11049 null
2 1 5467 null
3 1 3333 null
4 1 14 null
︙ ︙ ︙ ︙
InnoDBはクラスタインデックスなので 
event_idのINDEXを利用した時 
暗黙的にPKでソートされえる 

View Slide

1 1 11049 null
2 1 5467 null
3 1 3333 null
4 1 14 null
︙ ︙ ︙ ︙
つまり先頭からとってランダム！ 

View Slide

 
mysql> SELECT * FROM remains WHERE event_id = 1;
+----+----------+---------+-------------+
| id | event_id | seat_id | reserved_at |
+----+----------+---------+-------------+
| 1 | 1 | 29 | NULL |
| 2 | 1 | 59 | NULL |
| 3 | 1 | 10029 | NULL |
| 4 | 1 | 2009 | NULL |
| 5 | 1 | 2345 | NULL |
| 6 | 1 | 8756 | NULL |
+----+----------+---------+-------------+
6 rows in set (0.00 sec)

View Slide

https://soudai.hatenablog.com/entry/2018/05/01/204442

View Slide

集合論から外れず 
しかしRDBMSの特性を活かした設計をする 

View Slide

あじぇんだ 
1. 自己紹介 
6. まとめ 

View Slide

突然DBが壊れた現場 
稀によくある 

View Slide

まず壊れた種類を考える 

View Slide

壊れたとは何が？ 
1. 突然パフォーマンスが悪化した 
2. データの不整合が発生している 
3. データベースが応答を返さない 
4. コネクションが溢れている 
5. 間違えてDROP TABLEしちゃった（バルス） 
...etc 

View Slide

壊れたを知るために 
モニタリングが大事ｓ 

View Slide


View Slide

データベースは突然遅くなる 

View Slide

データベースは突然遅くなる 
1. データが増えて、tmp落ち 
2. CPUがサチってDisk ioに余力がない 
3. データ傾向が変わって実行計画が変わった 
4. そもそも意図した実行計画を使ってくれない 
5. 1つの小さな遅延がロックによって顕在化 
...etc 

View Slide

データはカジュアルに壊れる 

View Slide

データはカジュアルに壊れる 
1. バグやヒューマンエラーでデータは壊れる 
2. 予想外のデータはいつでも入る 
3. データファイルがDisk障害で死ぬことも 
4. レプリケーションでも場合によっては壊れる 
5. そもそもDROPの前では無力 
...etc 

View Slide

ヒューマンエラーやバグからは 
制約で守る 

View Slide

バックアップとログは大事 

View Slide


View Slide

 
？？？「エラーログで調べると 
自分のblogしか出てこないんですけど」 
 

View Slide

 
？？？「わかるぅ〜〜〜」 
(CV:そーだい) 

View Slide

未知の問題を解決することが 
エンジニアの腕の見せ所 

View Slide

 
？？？「わかるぅ〜〜〜」 
(CV:そーだい) 

View Slide

日本語コミュニティのSlackを活用する 
↓ 
mysql-casualとpostgresql-jp 

View Slide

あじぇんだ 
1. 自己紹介 
6. まとめ 

View Slide

まとめ 
今日、学びはありましたか？ 

View Slide

まとめ 
今日、学びはありましたか？ 
↓ 
DBAの仕事のほんの一部です 

View Slide

まとめ 
でもそのDBAの仕事を 
みんなが出来るようにするのが 
DBREの仕事です 

View Slide

まとめ 
仕組みで課題を解決する 

View Slide

まとめ 
技術で課題を解決する 

View Slide

まとめ 
理想への一歩目を踏み出すのは 
自分自身 

View Slide

まとめ 
ご清聴ありがとうございました 

View Slide

RDBのトラブルの現場を追え！ ~ 様々な現場を見る ~ / rdb-troubleshooting2

RDBのトラブルの現場を追え！ ~ 様々な現場を見る ~ / rdb-troubleshooting2

soudai sone

More Decks by soudai sone

Other Decks in Technology

Featured

Transcript