[MySQL] 大容量データベースの移動（２）

ということで、２のサーバーそれぞれのデータベースを実際に移転する。

海外サーバー → 海外サーバー

# ちなみに、前者が廉価でヘタレ、後者が高価（？）で評価が高い。これまで様子を見ていると、どうやら”安かろう～”がそのまま出ているように感じてしまう 機会が何度かあった。前者はSSH アクセスができないし、mysqldunp へのアクセスも（プログラム経由でも）できない。せめて同期くらいしてくれればなぁ・・・。

バックアップ

# 今回のソース側サーバーは、SSH は使用できないが、phpMyAdmin とcPanel は利用できる。またおそらく本来は同期やリモート接続できるはずだが、通信系がダメダメでできない。おまけにこちらのIP アドレスをブロックする始末だ・・。
#唯一の救いは、大容量のファイルであっても、Kill されずに受信できていることだ。しっかり転送量カウントされているとは思うが。

データベース上のサイズは 500M超で、入手した gallery_gallery.sql.gz が272M 程度。念のため転送前に解凍して調べてみると、出てきたgallery_gallery.sql ファイルは1.18G だった。いいのかな・・？

レストア

# gunzip gallery_gallery.sql.gz
# ls -lh
-rw-r--r--  1 gallery gallery 1.2G Aug 20 12:57 gallery_gallery.sql
# mysql -u gallery_gallery -p gallery_gallery < gallery_gallery.sql

・・・ふぅ。phpMySQL でデータを確認したら問題は無いようだ。一安心。

# 移転先でSSH が使えなかったらどうしただろうか（怖）

coreserver → さくらインターネット

バックアップ

coreserver でバックアップを取る。こちらのデータベースは圧縮すれば効果があるので圧縮する。

# データベースをdump する

$ mysqldump -u blog_pc -p blog_pc > blog_pc.sql
 $ ls -lh
-rw-r--r--   1 blog hpusers 173M 2011-08-21 00:43 blog_pc.sql

# 圧縮する場合

$ gzip blog_pc.sql
$ ls -lh
-rw-r--r--  1 blog hpusers 36M 2011-08-21 02:36 blog_pc.sql.gz

# FTP 転送後に削除する場合

$ rm blog_pc.sql.gz

リストア

そしてさくらインターネットにFTP転送し、SSH でMySQL に流しこむ。

# リソース管理の厳しいさくらインターネットのFTPの転送速度は、下手すれば海外サーバーと同等かそれより遅い・・

# 圧縮している場合は解凍する

%ls -lh
-rw----r--   1 blog users    35M Aug 21 02:36 blog_pc.sql.gz
%gunzip blog_pc.sql.gz

# データベースに流しこむ

%ls -lh
 -rw----r--   1 blog users   173M Aug 21 02:36 blog_pc.sql

% mysql -h mysql***.db.sakura.ne.jp -u blog -p blog < blog_pc.sql

# 確認後に削除する場合

% rm blog_pc.sql

確認

レコード数がほぼ一致した。ほぼ、というのは欠損があったのではなく、実稼働中なので完全に一致しないから。今回はテストだが、実際に移動する場合は矛盾などが生じないようにアクセスを自分だけにしておくほうが良いだろう。