気に入った記事をブックマーク
- 気に入った記事を保存できます
保存した記事の一覧は、はてなブックマークで確認・編集ができます
- 記事を読んだ感想やメモを書き残せます
- 非公開でブックマークすることもできます
エントリーの編集
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
176 usersがブックマーク
74
74
本番でTableを1つDeleteしてしまいON DELETE CASCADEでさらに4つTable dataが消えた話 - Qiita
176 users
qiita.com/nobu0605
qiita.com/nobu0605
記事へのコメント74件
- 注目コメント
- 新着コメント
versatile
「selectと間違えてdeleteを実行」？ table って drop じゃなくて delete でもきえるのかって思ったけど、 table じゃなくて record を消したのか。
B-108
「気軽に本番触れるとか実行前のレビュー無しとかアホ、そんな怖い仕事できない」って人は信じがたい事しれないけど、金無、時間無、素人SEのプロジェクトなんか世の中にはゴロゴロ存在して皆ギリギリで動いてる。
moto_motosaka
ちょちょっとまって、トランザクションは有効になってないの？即時コミット？🤯 根本的に何が問題だったのかの視点がずれすぎてて、なぜその対策になるのか理解できないしdeleteじゃなくupdateならどうすんの？
otchy210
やたらツッコミ所が多いのはさておき、やんごとなき理由で直接 DELETE 文書かなきゃいけない時は、必ずまず SELECT 文を書いて確認してから SELECT 句を DELETE 句に置き換えるな。
korilog
別に各自で編集権限もっててもいいんだけど、閲覧権限のみのアカウント（あるいはRedashとか）と2つ経路を持っといて、基本的には閲覧のみの方使う、みたいなやり方が多いかな。あと編集権限はコマンド全部PRに書く
yodelx
CASCADEは別に悪くないし、スキーマの問題じゃないよね。誤操作が通ってしまったことが問題。対策としては、コメント指摘にある通り“オートコミットを無効化するか、 実行前には、必ず start transaction を実行する”
napsucks
再発防止策‥監督者を同席させてエンター押す前にダブルチェック、事前手順書の整備と上長レビュ、手順逸脱の禁止、事前にクローンした同型ステージング環境で手順リハーサルだろうな。東証でこれやったら殺される。
jiro68
select と delete 間違えるのはありえない(構文が違う)。こんな素人に本番DBを触らせる時点で終わっているが、この人が悪いと言うより、このレベル人にそういう事をさせる組織としての問題だと思う。
otchy210
やたらツッコミ所が多いのはさておき、やんごとなき理由で直接 DELETE 文書かなきゃいけない時は、必ずまず SELECT 文を書いて確認してから SELECT 句を DELETE 句に置き換えるな。
scorelessdraw
初めの文から焦げ臭いにおいを発していて、直ぐに発火している。というわけで、再発防止策がそこじゃない気がするが、とりあえずグッドラック！得られた知見を役立てられる会社だといいね！
oakbow
環境によってはwhere区のないdeleteやupdateは実行できない制限があるけど、MySQL Workbenchにはないっけ？まあリードレプリカ作って本番へのCRUDできるのはアプリケーションだけにしとくべきだよね
nankichi
“ミーティング中にデータの調査が必要になり、話しながら本番DBを見て DELETEを実行してしまった”これだよ。このシーンこそがクリティカルポイント。ヒトに権限付与するのではなく、複数roll発行して使い分けるべき
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
いまの話題をアプリでチェック！
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
本番でTableを1つDeleteしてしまいON DELETE CASCADEでさらに4つTable dataが消えた話 - Qiita
起きた事 本番環境のデータ調査の依頼を受けた。その調査を受ける前に、それとは別で不要データを本番DB...
起きた事 本番環境のデータ調査の依頼を受けた。その調査を受ける前に、それとは別で不要データを本番DBから削除する作業をMySQL Workbenchで行っていた。 本番DBで、データ調査を行う際にMySQL WorkbenchでSQLのselectと間違えてdeleteを実行してしまい、Tableを1つ丸ごとDeleteしてしまった。 ON DELETE CASCADEが親テーブルに設定されてしまっていたため、さらに4つのTable dataが芋づる式に消えてしまった。 ON DELETE CASCADEの説明としては、この記事がわかりやすかったです。 https://www.dbonline.jp/mysql/table/index11.html テーブルの構成(テーブル名などは例として挙げていて、実際のものとは多少異なります) 正しい設定 usersテーブルでuserを削除した時に、そ
ブックマークしたユーザー
すべてのユーザーの
詳細を表示します
詳細を表示します
qiita.com/nobu0605
qiita.com/nobu0605
qiita.com/nobu0605
qiita.com/nobu0605
note.com/waravim
tomoyukiarasuna.com
anond.hatelabo.jp
www.k-taimiler.com
www.janog.gr.jp
levtech.jp
journal.ntt.co.jp
pc.watch.impress.co.jp
smhn.info
www.itmedia.co.jp
blogs.jpcert.or.jp
github.com/pythops
ayamevip.com
www.nikkei.com
ccsdschools.instructure.com
ccsdschools.instructure.com
2020/12/03 リンク