別サーバーからのデータベース移行
Millida VDSへのデータベース移行手順を説明します。準備、ネットワーク経由でのダンプ転送、整合性の確認、ダウンタイムを最小限にしたアプリケーションの切り替えを扱います。
更新日 2026年8月23日
データベースの移行はコマンドで失敗するのではなく、手順の順序で失敗します。ドメインを先に切り替えてから、データの半分しか移行できていなかったことに気づくケースが典型です。以下に、それを防ぐ手順を示します。
準備
新しいマシンに、同じかそれより新しいバージョンのデータベースサーバーをインストールします — PostgreSQL または MySQL です。ダウングレードはサポートされていません。
psql --version
mysql --version
df -h /
データベースサイズの約2.5倍の空き容量が必要です。ダンプ、展開後のデータ、そして多少の余裕分です。VDS-1 では合計40 GBになるため、事前に計画しておいてください。
古いサーバーと同じエンコーディングでユーザーと空のデータベースを作成します。
データの移行
最も簡単な方法は、中間ファイルを介さず SSH 経由でダンプする方法です。
ssh root@OLD 'pg_dump -Fc -U shop shop' > /srv/shop.dump
pg_restore -U postgres -d shop --no-owner --role=shop /srv/shop.dump
MySQL の場合:
ssh root@OLD 'mysqldump --single-transaction --routines --events -u root shop' \
| mysql -u root shop
ロールとユーザーはデータベースのダンプには含まれません — 別途エクスポートします。pg_dumpall --roles-only を使うか、手動で作成します — ユーザーと権限 を参照してください。
帯域幅は最大500 Mbps なので、20 GB のデータベースは数分で移行できます。ボトルネックになるのは通常ディスクへの書き込みで、これはティアによって制限されます。
切り替え前の確認
「サイトが開いた」だけでなく、数値を確認します。
SELECT relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 20;
SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema='shop';
主要なテーブルの行数を古いサーバーと比較し、シーケンスがリセットされていないこと（SELECT last_value FROM users_id_seq;）を確認し、テストモードで新しいデータベースに対してアプリケーションを実行します。
切り替え
- 古いサーバーでメンテナンスモードを有効にするか、アプリケーションを停止します。
- 準備中に行われた変更の最終ダンプを取得します。
- 新しいマシンでそれを復元します。
- アプリケーションの接続文字列を切り替え、サービスを再起動します。
- データを削除せずに、古いサーバーをさらに1週間稼働させておきます。
5番目の手順を飛ばさないでください。3日後にテーブルが欠けていることに気づくのはよくあることです。
よくある間違い
| 症状 | 原因 |
|---|---|
復元時に role does not exist | ロールが移行されていない — --no-owner と手動でのロール作成を併用してください |
| 文字化け | エンコーディングの不一致: utf8mb4 または UTF8 のデータベースに復元してください |
| シーケンスが1から始まる | ダンプに setval が含まれず、データのみだった |
| 復元に数時間かかる | インデックスがその場で構築されている。大規模なデータベースでは pg_restore -j 4 を使用してください |
| 途中で容量が不足した | データと並行してダンプのサイズが考慮されていなかった |
移行前に、新しいデータベースが
127.0.0.1のみで待ち受けていることを確認してください。「移行期間中だけ」という理由で公開する必要はありません — 転送は SSH 経由で行われます。リモートアクセス を参照してください。