AIがすごすぎて記事を書くモチベがない😂
誰がこんな時代が来ることを予想したでしょうか…
人間のための記事を書こう
弊社には「ヒヤリハット」をどこか人目に付くところに登録しようという文化があります。作業をしていてヒヤッとしたり( ﾟдﾟ)ﾊｯ!としたりした時、他の人も危ないから気を付けてね～という注意喚起をするものです。
ということで、モチベこそないですが書いていきたいと思います。😊😊
結局人間が作業をしている場所には、まだ人間のための記事が必要だと信じて…
最近やらかしたこと
EC2コンソールでサーバを削除しました。
やりました🫠開発機ですが…
（ヒヤリハットじゃなくて完全にやっちゃってて草）
流れ
当日はかなり遅くまで残業してて、前日の寝不足もあってかなり眠かったです。😴
な～んかサーバの調子悪いな、開発機だし別にいいや、一旦再起動しよ…
で、EC2のコンソールを開いて、インスタンスを終了っと…
あっ…（現場猫がデーモンコアの青い光を見つめる図）
その後
はいそうです、停止 を選ばないといけないですね。🤗なんて古典的なんだ…
ほんと「終了」と「停止」で分かりにくいんですよね。いやもう今まで何人の日本人がこれやってるんだよって話ですけどね。
先人に学ばない。なぜなら人間だから…
（最近は終了カッコ削除となっており、寝ぼけてなければ削除しないかとは思います）
インスタンスを終了するとですね、プルダウンからインスタンス開始を押そうとしても、グレーの文字が黒になりません。いやだって消滅してるんだもん。無を開始することはできません。 ふふ、そっかぁ…。スナップショット？あるわけないじゃないですか～これ開発機なんですよ。😂
でもそのサーバ、あれとあれとあれを入れて、それとこれを編集して、なにそれをやってる途中ですよね。その稼働、何時間分だよ…？てかこの開発機、明日あれを検証するつもりだったし、打合せで部長にデモしないといけないんじゃなかったっけ…？🤔
一気に目が覚めてそこから復旧作業です。一応断片的に殴り書きした構築手順があったのと、数週間前に優秀な同僚が念のため作成してくれたそこそこ新しめのデータが突っ込んであるリポジトリがありました。神か…！？助かりました。助かったのですが…帰るのは夜中のhoge時でした。とりあえず直って良かったね。😊
対策
ちゃんと寝る
まず寝不足はやめましょう。睡眠の重要性。
終了保護つける
終了保護をつけましょう。こんな2クリックで終わること何故やらんのだ。
AWS Backup設定する
イメージバックアップを取っとくのが一番確実です。
クラメソさんの記事を確認しよう
最近やらかしたこと2
まだあんの？🤣
テーブルのデータを削除しました。
これもやりました。🫠開発機のデータですが…
（もう今年は仕事しない方がいいかもね）
流れ
僕：いやぁ最近AI便利っすよね～🤗
「テーブルのデータを別のDBから持ってこないといけないんですけど、環境が別なのでどうやったら楽ですかね。対象テーブルはこれで、where句がこの条件」っと…
Claudeきゅん：where句のオプションを付けてテーブルダンプのファイルを作って、それをダウンロードして移行先の環境にもっていくといいよ。コマンドはこんなかんじ👍
移行先では、SOURCE句を使えば入れれるよ。SQLはこれね！よろよろ～
僕：おｋ～👌
僕：よし終わった。じゃあ元々やりたかった作業を始めるぞ。まずこのテーブルのデータ数を確認して…
count( * ) : 20 （とても少ない数字）
僕：ん？
count( * ) : 20 （とても少ない数字）
僕：？☺️
なにが起きたか
mysqlのテーブルダンプのファイルは特に明示的に回避オプションを入れない場合、DROP TABLE句を含みます。つまり今回とったダンプファイルの中身はこうです。🤗
- テーブルをドロップして再作成する
- where句で取ってきたレコードをINSERTする。
大体こんな感じ
DROP TABLE IF EXISTS `reino_table`;
CREATE TABLE `reino_table` (
云々
);
--
-- Dumping data for table `reino_table`
--
-- WHERE: nanntoka='kantoka'
LOCK TABLES `reino_table` WRITE;
INSERT INTO ... ここにデータ群
UNLOCK TABLES;
ただしくは、 --skip-add-drop-table を付けてダンプする必要がありました。
これでダンプすると、最初のDROPとCREATEはやらないものを作れます。
云々
LOCK TABLES `reino_table` WRITE;
INSERT INTO ... ここにデータ群
UNLOCK TABLES;
AIのいうことはちゃんと精査してから慎重に実行しろってあれほど言ったのにね。
先人に学ばない。なぜなら人間だから…🙄
で、結局where句以外のテーブル内ほぼ全データを消失しました。 すごいことしてる。睡眠はとってたしなんならその日は少し寝坊したぐらいでしたが、いい感じに目が覚めました。開発環境なんだけどわりと重要なテストデータが入っててユーザテストの期間中だったよね、割とまずくね？😆
幸い作業前に一部のテーブルは手なりでバックアップを取っていたのと、足りてなかった分はスナップショットがあったのでそいつを急いで立ち上げてデータを移動… とはいえスナップショットから立ち上げは10分くらいかかりますし、また余計な手順を用意して余計な時間を消費して、今日やりたかった作業は明日に延期と…😂
対策
疑え
まずAIは割と無責任なのでお前がどうなろうと知ったこっちゃないので気をつけろ
作業前にバックアップ
データベース触るときはいつもそう。
スナップショットでもダンプでもよい。一切の例外なくやろう
Backup設定する
今回は設定しておいてよかったね。お前死んでたぞ
まぁAuroraの場合作成時にデフォで設定するので安心かもです。念のため確認しよう
ちなみにAWSBackupでもとれるそう。アイレットさんの記事
おわりに
人間ってのは能力に限界があるなぁ…
人間をやめるしかない😆