最近やらかした系の投稿ばっかりだな・・・
まあ失敗から学ぶのが人間さ！！
ということで、今回のお話は・・・

むかーしむかしのお話じゃ。

むかーしむかし、hogeというDBと、hoge_stgというDBありました。
tentatsuどんは、hoge_stgに、hogeを上書きしましたとさ。
するとどうでしょう、本番で稼働していたDBはhoge_stgだったということです。

mysqldump -h dokoka_server -u user -p hoge > hoge.dump
mysql -h dokoka_server -u user -p hoge hoge_stg < hoge.dump

しかも、hogeはhoge_stgとは全く関係ないデータが入っておりましたとさ。
めでたくない、めでたくない。

これからが本当の地獄だ・・・

悪あがき１、過去のdumpをとにかく探す。

探そう。とにかく探そう。
参考）10M以上のファイルを探す

find /home/ec2-user -size +10M -print

今回はたまたま、これで1ヶ月前のダンプが出てきたので残り１ヶ月を埋める作業が始まりました。

今回書きたかったことがここからです。

たまたまmaster-slave構成にしていたのでバイナリログが残っていました。
さらにポータルサイトのWordPressだったので登録、更新が少なかったことも幸いして、
いくつかの記事を復旧させるだけのお仕事になりました。

レプリケーションでmaster-slave構成にしていたため、更新のバイナリファイルがあり
それを使って普及する・・・という手段を取りました。

バイナリファイルを探す

ls -l /var/lib/mysql
-rw-rw---- 1 mysql mysql 538546587  4月 12 04:49 mysqld-bin.000001

あった！！！
ただし、中身は人間には読むことの出来ないバイナリ文字の世界。

ここで人間の読める形にするために、mysqlbinlogというコマンドが活躍。
--no-defaults無しでやると、エラーが出るので注意。
(mysqlbinlog: unknown variable 'default-character-set=utf8mb4' みたいな。)

mysqlbinlog  --no-defaults mysqld-bin.000001 > ~/mysql_bin.log
grep 11587, mysql_bin.log > mysql_bin_tmp.log  # 記事ID11587を復旧したい

あとは中を見ると関連する記事の登録、更新SQLが入っているはずなのでそれを見て復旧しましょう。
無かった場合は、他のバイナリログに含まれているかもしれないので諦めずに漁りまくりましょう。

よい子のみんなは、DBバックアップをちゃんとやろうね。
https://qiita.com/tentatsu/items/2b163af4a1ac1c897891