本番でTableを1つDeleteしてしまいON DELETE CASCADEでさらに4つTable dataが消えた話 - Qiita

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

[gowithyou]

「Tableを1つDelete」という表現はおかしいな、Table自体を削除するならDropでしょ。正しくは「Tableの全データをDelete」じゃないかな。「Table data」という表現も出てくるし文章は正確に

[sirobu]

こう言う事例を読むと「本番テーブル操作は手順書を書いて検証環境でリハーサルしてから」「コマンドは手順書Excelからコピペで」っていうSIer仕草が理にかなってる気がする

[versatile]

「selectと間違えてdeleteを実行」？ table って drop じゃなくて delete でもきえるのかって思ったけど、 table じゃなくて record を消したのか。

[B-108]

「気軽に本番触れるとか実行前のレビュー無しとかアホ、そんな怖い仕事できない」って人は信じがたい事しれないけど、金無、時間無、素人SEのプロジェクトなんか世の中にはゴロゴロ存在して皆ギリギリで動いてる。

[moto_motosaka]

ちょちょっとまって、トランザクションは有効になってないの？即時コミット？🤯　根本的に何が問題だったのかの視点がずれすぎてて、なぜその対策になるのか理解できないしdeleteじゃなくupdateならどうすんの？

[Error401]

ON DELETE CASCADEを取り除いたというのが、さらなるやらかしの可能性が･･･ (Qiitaにコメントしました）

[rryu]

本番環境での削除作業と同時に別のことをやるのは死亡フラグすぎるが、親と子の双方向のON DELETE CASCADEが設定されていてどれかを消すと全滅という罠も致死性すぎる…

[otchy210]

やたらツッコミ所が多いのはさておき、やんごとなき理由で直接 DELETE 文書かなきゃいけない時は、必ずまず SELECT 文を書いて確認してから SELECT 句を DELETE 句に置き換えるな。

[NOV1975]

ええと、そもそもなぜ「親」テーブルに子テーブルの項目の外部キー制約があるんだ？設計がおかしくないか？

[korilog]

別に各自で編集権限もっててもいいんだけど、閲覧権限のみのアカウント（あるいはRedashとか）と2つ経路を持っといて、基本的には閲覧のみの方使う、みたいなやり方が多いかな。あと編集権限はコマンド全部PRに書く

[yodelx]

CASCADEは別に悪くないし、スキーマの問題じゃないよね。誤操作が通ってしまったことが問題。対策としては、コメント指摘にある通り“オートコミットを無効化するか、 実行前には、必ず start transaction を実行する”

[koogawa]

あって良かった、バックアップ😂

[helldeath]

おー、CASCADE設定で親テーブルデータも削除、そして親テーブルからつながる小テーブルデータも削除か。一蓮托生みたいなDB設定やな。

[hintoku]

リードレプリカしないと怖くないかな…

[yuzuk45]

トランザクション？

[odakaho]

DDLなら仕方ないけど、マスタで調査すんなっていう。適当なスレーブ生やして調査はそっちでが普通でしょうね。

[napsucks]

再発防止策：監督者を同席させてエンター押す前にダブルチェック、事前手順書の整備と上長レビュ、手順逸脱の禁止、事前にクローンした同型ステージング環境で手順リハーサルだろうな。東証でこれやったら殺される。

[hnt4]

MySQL Workbenchを本番で使う人初めて見た

[proverb]

本番でやらかさなかった者だけが石を投げよ（このアドベントカレンダー全部に同じブコメ付けられそう）／とはいえデータ吹き飛ばし系のやらかしは怖いよね。バックアップが無ければ即死だし。

[jiro68]

select と delete 間違えるのはありえない(構文が違う)。こんな素人に本番DBを触らせる時点で終わっているが、この人が悪いと言うより、このレベル人にそういう事をさせる組織としての問題だと思う。

[lotus-sutra]

“selectと間違えてdeleteを実行してしまい”って書いてあるのをちゃんと読んでないコメントが散見されこの筆者のスキルと同時にブクマカの読解力についても不安になってくる

[rkosaka]

内容以前に単語が曖昧で不安になる

[diveintounlimit]

いやー何か色々ツッコミどころたくさんなエントリーだなー

[morimarii]

気が緩んでいたとかそういう問題ではない／今年のは作業ミスとかそれ以前にいろいろおかしいし再発防止も違うそうじゃない感が

[baronhorse]

本番データ削除は一度くらいはやっといた方がいいね

[onesplat]

まずサービス用のDBにクエリを打つな

[findup]

未経験から三ヶ月で、系の人なのかなあ…。

[YukeSkywalker]

胃がキュッてなる/現職でもDBにupdateする時は、それ用のアカウント使って、作業手順書作ってレビューしてもらって、その上でコマンドはコピペするよ……

[dkkoma]

養殖では生み出せないこの感じがすき

[kumoha683]

ロールバックとかできないの？

[yamadadadada2]

この対応の是非はともかく、同僚の優しさに全俺が泣いた

[taruhachi]

ON DELETE CASCADEを双方向に張って握り合ってたという事が全ての原因かな。むしろそんな設定ができるんだ。

[tA9]

直接触るのをやめないとまた誰かがやらかす

[scorelessdraw]

初めの文から焦げ臭いにおいを発していて、直ぐに発火している。というわけで、再発防止策がそこじゃない気がするが、とりあえずグッドラック！得られた知見を役立てられる会社だといいね！

[oakbow]

環境によってはwhere区のないdeleteやupdateは実行できない制限があるけど、MySQL Workbenchにはないっけ？まあリードレプリカ作って本番へのCRUDできるのはアプリケーションだけにしとくべきだよね

[tettekete37564]

用語のおかしさからこのレベルの人に更新削除系任しちゃダメでしょ的な。というか作業ログ残したいから GUI からはやらんし開発環境で SQL 文の動作テストしてから流す。

[lont_in]

ステージング環境ないの

[nankichi]

“ミーティング中にデータの調査が必要になり、話しながら本番DBを見て DELETEを実行してしまった”これだよ。このシーンこそがクリティカルポイント。ヒトに権限付与するのではなく、複数roll発行して使い分けるべき