テクニカルアーティストのためのデータベース入門 (3) データ保全

チーム内に土下座行脚をしたくなければ、まずはデータの守り方を覚える必要がある。

基本的には、「1日1回の丸ごとバックアップ」と「毎操作のバックアップ」の2種類でカバーできる。1日単位での記録は「丸ごと」で、それより小さい単位では「毎操作」で、データを保存しておく。

「操作」というと違和感があるかもしれないけど、DBは基本的にクエリ（SQL）を使ってデータの書き込みをするので、クエリごと保存してしまおうという発想。人によっては、通信対戦ゲームでいうところの「キー同期方式」という言い方でピンとくるかもしれない。

「スナップショット」と呼ばれる、「その時点でDB内に存在するすべてのデータ」をまとめたもの。MySQLでのコマンドは以下のとおり。

mysqldump -u[user_name] -p -h[host_name] --lock-all-tables database_name  > filename

これを、*nix なら cron、Windows ならタスクスケジューラに登録しておく。例えば毎日深夜3時あたりに自動実行すればいい。
溜まったデータは、定期的に別のHDDにコピーしておこう。

バックアップファイルからDBにデータを流し込むにはこのコマンド。

mysql -u[user_name] -p -h[host_name] database_name < filename

スナップショットの基本的な用途は当然日々のバックアップということになるのだけど、もうひとつ、他のサーバにデータをコピーするときにも使うことができる。例えば、

などなど。

特に「壊れてもいいテストDB」に関しては、ある程度真面目にDBをさわりだすと、必ずといっていいほど必要になってくる。片方向レプリケーションはとても便利。

「クエリログ」と呼ばれる、「DBに対するすべての操作を記録したデータ」をまとめたもの。MySQLの場合は設定ファイルでON/OFFを切り替える。デフォルトはOFFなので、新規セットアップ時には注意したい。油断すると結構忘れる。

え？なに？サーバのセットアップは自動化しておくべき？まったくその通り、でもそれは後でいい。慣れないサーバ構築中に頑張ってChefやAnsibleの使い方をぐぐりながら悩むよりも、まずはアーティストと雑談でもしながらメタデータの構成を試行錯誤する。

「データが消えるのが怖いなら消さなきゃいいじゃない！」という発想。
これに関してはとてもいい記事があるので、ぜひこちらを。
qiita.com

個人的には、「ちゃんとバックアップとってれば別に間違って消しちゃってもいいんじゃないかな？」くらいのゆるい立ち位置。よほどややこしい状況でもない限り「ミスったときに急いでバックアップから復旧する」ことができれば十分だと思う。