Day22 前半のゴール
「“もしDBが飛んでも戻せる”状態を、自分で作れるイメージを持つ」
ここからは「パフォーマンスと設計」だけでなく、「守り」の話に入ります。
テーマはバックアップ――mysqldump とリストアです。
前半のゴールはこうです。
バックアップがなぜ必須なのかを“他人に説明できるレベル”で理解する
mysqldump が何をしているツールなのか、ざっくりイメージできる
小さなサンプルDBを「dump → 消す → 復元する」という流れを頭の中でトレースできる
ここまで行けば、後半で「実務的なオプション設定」や「運用の考え方」に進むとき、話がスッと入ります。
そもそもバックアップとは何か
「“過去の状態を丸ごと保存しておく保険”」
バックアップは、一言で言うとこうです。
DBの中身を、ある時点の状態で丸ごと保存しておくこと
なぜ必要かは、少し想像すれば分かります。
誤ってテーブルを DROP した
DELETE 文を WHERE なしで流してしまった
ディスク障害でデータファイルが壊れた
アプリのバグで大量のデータが書き換わった
こういうとき、「ごめんなさい」だけでは済みません。
「じゃあ、昨日の状態に戻そう」ができるかどうかが、
システムとしての“生存力”を決めます。
バックアップは、パフォーマンスチューニングより地味に見えますが、
実務では「これがないと話にならない」レベルの基礎体力です。
mysqldump とは何をするツールか
「“SQLで書き出して、SQLで戻せるようにする”」
MySQL には、標準で mysqldump というコマンドラインツールが付いています。
役割はシンプルで、
指定したDB（やテーブル）の中身を、SQL文の形で書き出す
というものです。
イメージとしては、
テーブル定義（CREATE TABLE …）
テーブルの中身（INSERT INTO …）
を、全部テキストファイルに吐き出してくれるツールです。
そのテキストファイルを、あとで MySQL に流し込めば、
同じテーブル・同じデータを再現できます。
つまり、
mysqldump で「SQLスクリプトとして保存」
→ そのSQLを流して「元の状態を再現」
という流れです。
ここが分かると、
「バックアップ＝DBファイルをコピーする」だけではない
「バックアップ＝再現可能なSQLを残す」というやり方もある
という感覚が掴めます。
まずは超シンプルな例で流れを掴む
「小さなDBを dump → 削除 → 復元、を頭の中でシミュレーションする」
具体的なイメージを持つために、
小さなサンプルDBを使って、mysqldump → リストアの流れを追ってみます。
サンプルDBを用意する
例えば、こんなDBとテーブルがあるとします。
CREATE DATABASE sample_app;
USE sample_app;
CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(50) NOT NULL
);
INSERT INTO users (name) VALUES
('Alice'),
('Bob'),
('Charlie');
この時点で、sample_app.users には3件のデータが入っています。
mysqldump でバックアップを取るイメージ
ここで、mysqldump を使って sample_app 全体をバックアップします。
コマンドのイメージはこうです。
mysqldump -u root -p sample_app > sample_app.sql
これで、カレントディレクトリに sample_app.sql というファイルができます。
中身を開くと、ざっくりこんな感じのSQLが並んでいます。
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `sample_app` /*!40100 DEFAULT CHARACTER SET utf8mb4 */;
USE `sample_app`;
CREATE TABLE `users` (
`id` int NOT NULL AUTO_INCREMENT,
`name` varchar(50) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;
INSERT INTO `users` VALUES
(1,'Alice'),
(2,'Bob'),
(3,'Charlie');
つまり、
このファイルを MySQL に流せば、
sample_app というDBと、その中の users テーブルと、そのデータ3件が再現できる
という状態になっています。
ここまでが「バックアップを取る」側のイメージです。
リストアとは何か
「“dumpされたSQLをもう一度流して、元の状態を作り直す”」
リストア（復元）は、mysqldump が吐き出したSQLを、
もう一度 MySQL に流し込むことです。
イメージとしては、
バックアップファイル（sample_app.sql）を
mysql コマンドに食わせて実行する
という感じです。
あえてDBを消してから復元してみるイメージ
流れをはっきりさせるために、
一度 sample_app を消してから復元する、というシナリオで考えます。
まず、DBを削除します。
DROP DATABASE sample_app;
この時点で、users テーブルもデータも、全部消えています。
ここから、バックアップファイルを使って復元します。
コマンドのイメージはこうです。
mysql -u root -p < sample_app.sql
すると、sample_app.sql の中に書かれている、
CREATE DATABASE …
USE sample_app;
CREATE TABLE users …
INSERT INTO users …
といったSQLが順番に実行され、
結果として、元と同じ sample_app DB が再現されます。
復元後に、
SELECT * FROM sample_app.users;
と叩けば、また Alice / Bob / Charlie の3件が見えるはず、というイメージです。
ここで大事なのは、
mysqldump の出力は「人間が読めるテキスト」であり
それをそのまま mysql に流せば「元の状態を再構築できる」
という構造を理解することです。
「バックアップがある」と「戻せる」は別物
「“取ったつもり”バックアップが一番危ない」
ここで、実務的にめちゃくちゃ重要なポイントを一つ挟みます。
バックアップファイルがある
＝ 安心
ではありません。
本当に大事なのは、
そのバックアップから、実際に復元できることを確認しているか
です。
例えば、
mysqldump のコマンドが間違っていて、一部のテーブルが含まれていなかった
権限の問題で、特定のテーブルだけダンプできていなかった
文字コードや設定の違いで、復元時にエラーが出る
こういうことは普通に起こります。
なので、現場ではよく、
定期的に「バックアップからテスト環境にリストアしてみる」
ということをやります。
Day22 前半の段階では、
バックアップは「取る」だけでなく「戻せるか検証する」までがセット
という意識だけ、しっかり持っておいてください。
Day22 前半のまとめ
バックアップは「DBの状態をある時点で丸ごと保存しておく保険」であり、mysqldump はそのために「テーブル定義（CREATE TABLE）とデータ（INSERT）を1本のSQLファイルとして書き出す」ツールで、mysqldump -u ユーザー -p データベース名 > dump.sql のように実行すると、そのDBを再現するためのSQLスクリプトが手に入る。
リストア（復元）は、そのSQLファイルを mysql -u ユーザー -p < dump.sql のように MySQL に流し込むことで、DROP して消えてしまったDBやテーブルを「dump取得時点の状態」に戻す操作であり、サンプルDB（sample_app.users に3件のデータ）を dump → DROP DATABASE → mysqlで流し込み → SELECTして元通り、という流れを頭の中でシミュレーションできれば、mysqldump／リストアの基本構造は掴めている。
そして何より重要なのは、「バックアップファイルがある＝安全」ではなく、「そのバックアップから実際に復元できることを確認して初めて安全と言える」という点であり、Day22 後半では、実務で使うときのオプション（ロックの扱い・特定DB／テーブルだけのdump・大規模DBでの注意点）や、バックアップ運用の考え方をもう一段深く整理していく。