SELECT文で本番環境を落としたお話 - Qiita

結果はすぐに帰ってきました。確か2行程度だったと思います。 続けてさらに SQL を実行しようとしました。しかし、ここで同僚から「ソースコードでわからないところがあるんですが…」と声をかけられました。 こちらは急ぎの作業ではなかったので、ターミナルをそのままにして同僚の質問に回答することにしました。 そして約10分後…。 $\huge{「システムがダウンしてるー！」}$ 本番障害となりました。 何が悪かったのか **「トランザクションをかけて SELECT 文を打ったお前が悪い」**ということになりました。 何が起きていたのか ログからシステムの動きを確認したところ、あるスレッドで user_setting テーブルをロックしようとしていたことが分かりました。具体的には、以下の SQL が発行されていました。 この SQL には、ロックモードの指定がありません。この場合、PostgreSQ

[everybodyelse]

select * from tableみたいなクエリを数千万件あるデーターベースで発行して、メモリ過多で死亡的な話かと思ったら違った。

[kkobayashi]

この手のエントリーでやらかした事そのものを叩くのは良くないのでは・・・やらかしは気軽に共有していこう

[takc923]

SELECT文がミスっててでかいテーブルでレコード全走査してワークロードが上がって他のクエリに影響して最終的に落ちた、とかそう言う話かと思ったら違った

[n314]

いやこれselectは悪くなくない？手動でSQL実行する環境なら、update後に目grepで確認してる間はコミットもロールバックもできないよね。

[w1234567]

lock tableなんて使うシステム作る奴がゴミだって印象しか受けないんだが

[kathew]

BEGINとROLLBACKをあらかじめセットで書いたとしてもSELECTの内容次第では数百ミリ秒～数秒ロックしてしまうこともあるし、やっぱりトランザクションを張る時はロックの粒度を気にするのが一番良さそうだ

[te2u]

”LOCK TABLE user_setting;” これを対応しない限り、その本番環境は潜在的に同様の問題を抱え続けることになるのでは。この件はむしろ、その問題を明らかにしたわけで、そのとばっちりを食らったかのように感じる。

[KentarouTakeda]

これはどちらかというとロック取る側の問題の方が大きい。ACCESS EXCLUVE必須なケースなんてそう無いし、ましてやユーザーアクセスが契機でそれを取るような実装だとやらかしが無かったとしても落ちるときは落ちる。

[chiheisen]

はてブのコメントに、トランザクションかけてても ALTER TABLE や TRUNCATE を実行してしまったら意味ないだろうという意見があるのですが、PostgreSQL はどちらもトランザクションかけていればロールバックできますよ…。

[t-murachi]

色々ひどい。解決手段が人為的になってる。READ ONLYの (変更権限のない) ユーザー作るのがまず先決やろ。「気をつける」が解決手段の現場で胃潰瘍になるなっちゅー方が無理な話や(´・ω・`)

[progrhyme]

あかん

[terafuri]

地の文にBEGINが一ヶ所もないので「！！？！？？」ってなる！優勝！！

[numtostring]

やらかしたのはDB設計したやつじゃん。

[ikosin]

やらかしへの対策が他の現場に導入されて新たなやらかしの火種になった感じ

[JULY]

投入した SQL を見て、ちょっと間をおいて気がついたけど、このパターンは初めて聞いた。DB の側に立つと「この人がトランザクション初めて、いつまで経っても終わらないんだけど」だからなぁ。

[Soraneko]

"その際、万が一コピペをミスって更新系の SQL を実行してしまったら怖いので、念のためトランザクションをかけて" この時点でこわい、ちゃんとReadOnlyなユーザを作りませう

[ch1248]

知見だ。

[hiroki0251]

PostgreSQL

[kouhii]

「お前が悪いという『ことになりました』」から察してあげるべき案件だろうに。タイトル詐欺気味なのは否定しない

[altar]

この記事叩きつつ心理的安全性の記事が有益とか言ってるのだとしたらたしかに矛盾してるな。

[tekimen]

貴重な知見をありがとうございます。

[healthyprog]

これはいい教訓。いつも思うけど、なぜこの手の失敗に罵声を浴びせる人がいるのか理解できない。

[otation]

気軽に本番環境にSQL流せる職場なら、体調崩すほど責任感じる必要はなさそうだけど

[threetea0407]

replicationがないとこういうことが起こるんやなあ

[nippondanji]

なんでテーブルロックしてるんだろうというのが疑問なんだけど、テーブル名といい、もしかしてEAVになっててアプリ側で全部の設定の整合性をチェックするようになってたりするのかな。

[Hamukoro]

ブコメで言われてるようにSELECTしかできないユーザーをこさえるのが最適解なのはわかるんだけど、トランザクションより声出し指差し確認のほうが安全ってのを受け入れたくなくてもにょる。

[arearekorekore]

こわい

[miquniqu]

程度によらず目的のためにおかしな手段を考案する人がいるっていう気づきを得た。おかしな手段を実行に移す前に食い止める方法を考えたほうがいいような。まずは上長に斜めのはんこ押してもらおう。（適当

[foostan]

read onlyなユーザーはいなかったのかな？

[namisk]

オンラインの処理だと　lock table とかかけるの何様だよって感じだよね。

[love0hate]

readだけならサービス投入してないレプリカ上でするべき

[tis8347]

BEGIN... BEGIN!?

[Wafer]

対策はまあ悪くないとしてタイトル詐欺なのは問題の本質を著者が実はわかってないという疑惑を生んでいる。従って古のはてなのしきたりにのっとり罵詈雑言が浴びせかけられることになる

[stp7]

SELECT文を実行しただけだから安心と思ってしまったのが原因なのでSELECTが原因と言いたくなるのはわかる。根本的な原因としてはLOCK TABLEが悪い。スロークエリ発行されたら終わり。

[torish]

個人情報ないからってもいきなり本番系アクセス、トランザクションかけるって怖いな。せめてリードオンリーにしたらよかったのに

[ghostbass]

begin transaction; ... -- rollback とかをコンソールなりGUIツールで実行している人たちを知ってるが… まあ気を付けよう。

[koogawa]

ブコメ荒れてるけど、こういう失敗を共有してくれるだけで素晴らしいじゃない！

[rAdio]

BEGIN……恋しくて、泣き出した、日々などもう、忘れたの。今さらは、戻れない、キズつけあった日々が長すぎたの。 / I replicate. Do you replicate. してるわけもなく笑った頃。Wow Wow...

[paradisemaker]

「ちょっとした調査」のために本番環境で個人が SQL 流すってのがどうかと思う