デッドロックが起きたら、どう調べてどう防ぎますか

どうして起きるか

在庫を 2 つ持つ注文を考えます。

1. 注文 A のトランザクションが、商品 1 の行をロックする
2. 注文 B のトランザクションが、商品 2 の行をロックする
3. A が商品 2 をロックしようとして、B を待つ
4. B が商品 1 をロックしようとして、A を待つ

A は B を、B は A を待っているので、どちらも永遠に進めません。PostgreSQL や MySQL (InnoDB) は、この待ち合いの輪を見つけると、片方のトランザクションをエラーで取り消し、もう片方を進めます。

ただのロックの待ちは、相手が終われば進めます。デッドロックは、待っていても決して終わらない点が違います。

どう調べるか

DB はデッドロックの中身を記録します。PostgreSQL では起きるたびにサーバーの記録に出て、MySQL では SHOW ENGINE INNODB STATUS の結果に直近の 1 件が出ます。そこから次を読み取ります。

• ぶつかった 2 つのトランザクションが、それぞれ流していた SQL
• それぞれが、どの表のどの行 (どのインデックス) のロックを持ち、何を待っていたか

次に、その SQL を流しているアプリのコードを探し、ロックを取る順番が呼び出しによって入れ替わる所を見つけます。起きた回数と時間帯も監視で見て、特定の処理や時間に偏っていないかを確かめます。

どう防ぐか

• ロックを取る順番をそろえる上の例なら、どの注文も商品の id の小さい順に更新すれば、輪ができません。いちばん効く手です
• トランザクションを短くする 中で外の API を呼んだり、利用者の入力を待ったりしません。ロックを持つ時間が短いほど、ぶつかる機会が減ります
• ロックする行を減らす条件に合うインデックスが無いと、DB は多くの行を読んでロックすることがあります。更新の条件に合うインデックスを用意します
• 最初にまとめてロックする後で更新する行を、トランザクションの初めに順番どおり SELECT ... FOR UPDATE でロックしておく手もあります

-- どの注文も商品の id の小さい順にロックする
BEGIN;
SELECT id, stock FROM products
WHERE id IN (1, 2)
ORDER BY id
FOR UPDATE;
UPDATE products SET stock = stock - 1 WHERE id = 1;
UPDATE products SET stock = stock - 1 WHERE id = 2;
COMMIT;

やり直しの作り

順番をそろえても、別の処理の組み合わせで起こることはあります。だから、デッドロックのエラーを受けたら、トランザクションを初めからやり直す作りにします。途中の SQL だけをやり直すのではなく、トランザクションごとです。回数に上限を付け、何度も起きるなら記録に残して原因を探します。やり直しても困らないように、外へのメールや通知はトランザクションが確定した後に送ります。

トレードオフ

ロックの順番をそろえるには、コードのあちこちの更新の順を決まりとして守る必要があり、レビューで見る物が増えます。最初にまとめてロックすると、ロックを持つ時間が延び、同時に動ける数は減ります。起きる頻度と、起きたときの害の大きさを見て、どこまで手を入れるかを決めます。

話す例は架空の例で構いません。「複数の商品を買う処理で、カートの順に在庫を減らしていたためデッドロックが出ていたので、id の順に並べてから減らすようにした」のように話せると伝わります。