PostgreSQLからMySQLへの移行は、データをコピーして終わる作業ではありません。テーブルと行データに加え、データ型、既定値、インデックス、制約、ビュー、トリガー、ストアド処理、アプリケーション側のSQLを確認する必要があります。
MySQL Workbenchの公式マニュアルはPostgreSQLを移行元として扱えますが、自動変換の中心はテーブルとデータです。ビュー、ストアドプロシージャ、トリガーなどは手動での確認と書き換えが前提になります。
この記事では、小規模から中規模のシステムで、検証環境を用意して段階的に移行する流れを説明します。停止時間をほとんど取れないシステムや更新量の多いシステムでは、継続同期と切り替え方式を別途設計してください。
最初に押さえたい移行範囲
データベース移行とは、表の中身だけでなく、データを正しく保存して検索するための構造と、データベースを利用するアプリケーションの動作を移す作業です。ツールが完了と表示しても、業務機能が同じ結果を返すとは限りません。
| 対象 | Workbenchでの扱い | 担当者が確認すること |
|---|---|---|
| テーブルと行データ | 変換とコピーの対象 | 件数、NULL、文字、数値、日時、主キーの一致 |
| データ型と既定値 | 既定の規則で自動マッピング | 桁数、精度、値の意味、アプリケーションとの整合 |
| インデックスと外部キー | 変換候補を生成 | 生成SQL、制約、検索性能 |
| ビュー、ストアド処理、トリガー | 自動変換の対象外 | MySQL向けの再実装とテスト |
| アプリケーションのSQL | 対象外 | SQL方言、関数、型の扱い、接続設定 |
製品選定そのものを見直している場合は、先にMySQLとPostgreSQLの違いを整理し、移行の目的が運用要件と一致しているかを確認してください。
移行前に決めること
移行の目的と完了条件
最初に、なぜMySQLへ移すのかを明文化します。運用基盤の統一、保守体制の変更、アプリケーション要件への対応など、目的によって許容できる停止時間と改修範囲が変わるためです。
完了条件には、対象テーブルのコピーだけでなく、主要画面、バッチ処理、帳票、外部連携が期待どおり動くことを含めます。件数一致だけを完了条件にすると、型変換やSQLの違いによる不具合を見落とします。
対象オブジェクトの棚卸し
スキーマごとに、テーブル、列、主キー、外部キー、インデックス、ビュー、トリガー、関数、シーケンス、拡張機能を一覧にします。アプリケーション側では、生SQL、ORMの設定、接続先、バッチ、レポート、外部連携を洗い出します。
棚卸し表には「自動変換」「手動変換」「移行しない」のいずれかを付けます。判断が未確定の項目を残したまま本番コピーへ進まないことが、手戻りを減らします。
バックアップと復元手順
移行前には、PostgreSQLへ戻すためのバックアップを取得します。次の例は、カスタム形式のアーカイブを作成するコマンドです。
pg_dump -U ユーザー名 -Fc -f backup_file.dump データベース名-Fcで作るファイルはpg_restoreでPostgreSQLへ復元するためのものであり、MySQLへ直接読み込むファイルではありません。PostgreSQLのpg_dump公式資料を確認し、隔離した環境で復元できるところまで試しておきます。
切り替えとロールバック
本番切り替えでは、書き込みを止める時点、最終データを移す方法、接続先を変更する順序、動作確認の担当者を決めます。ロールバック条件も数値や具体的な症状で定め、旧環境へ戻す判断を先送りしないようにします。
MySQL Workbenchで移行する手順
1．検証環境と接続権限を用意する
本番環境を直接の練習場所にせず、PostgreSQLのコピーと空のMySQLデータベースを用意します。移行に使うアカウントには必要な範囲の読み取り権限と作成権限を与え、作業後に無効化できるようにします。
2．PostgreSQL用ODBCドライバーを準備する
MySQL Workbench Migration Wizardは、MySQL以外の移行元へODBCで接続します。PostgreSQLではpsqlODBCを使用するため、Workbenchを動かす環境に対応するドライバーを導入します。詳しい前提はMigration Wizardのインストール要件で確認できます。
3．移行ウィザードで接続先を設定する
MySQL Workbenchの「Database」から「Migrate」を開き、移行元にPostgreSQL、移行先にMySQLを指定します。両方の接続テストが成功したら、移行するスキーマを選びます。
接続文字列や設定ファイルへ認証情報を残す場合は、リポジトリへ登録せず、閲覧権限と保存期間を制限してください。
4．変換結果と生成SQLを確認する
Workbenchが移行元の構造を読み取り、MySQL向けのオブジェクトとCREATE文を生成します。「Migration Problems」と列のマッピングを確認し、警告を一件ずつ処理します。警告がない場合も、型、既定値、主キー、外部キー、インデックスを棚卸し表と照合します。
5．MySQLへスキーマとデータを作成する
生成SQLを検証環境へ適用し、テーブル作成に失敗した箇所を修正します。その後にデータ転送を実行し、移行レポートとログを保存します。再実行する場合は、対象テーブルに残ったデータをどう扱うかを確認してから進めます。
6．手動対象を実装する
ビュー、ストアドプロシージャ、関数、トリガーは、PostgreSQL側の定義をそのまま実行せず、MySQL向けに書き換えます。アプリケーションのSQLも、PostgreSQL固有の関数、演算子、型に依存していないかを調べ、テストで結果を比較します。
データ型は自動変換後に再設計する
WorkbenchのPostgreSQL型マッピングには、次のような初期変換が示されています。これは変換開始時の規則であり、個々のシステムに最適な設計を保証するものではありません。
| PostgreSQL | Workbenchの初期マッピング | レビュー項目 |
|---|---|---|
SERIAL、BIGSERIAL |
INT、BIGINTとAUTO_INCREMENT |
採番開始値、既存ID、アプリケーションの採番処理 |
BOOLEAN |
TINYINT(1) |
入力値、ORMの型変換、検索条件 |
NUMERIC |
DECIMAL |
精度と小数桁、最大値、丸め処理 |
TIMESTAMP |
DATETIME |
保存形式、タイムゾーンの扱い、表示結果 |
BYTEA |
LONGBLOB |
データサイズ、読み書き、バックアップ時間 |
UUID |
VARCHAR(36) |
形式、索引、比較処理 |
JSON、ARRAY |
LONGTEXT |
妥当性検証、検索方法、アプリケーションの変換処理 |
たとえば、移行元で配列型を検索条件に使っている場合、文字列としてコピーできても同じ検索はできません。保存できるかではなく、業務処理が同じ意味で動くかを基準に変換先を決めます。
pgloaderをこの方向の移行に使わない
元の記事で紹介されていたpgloaderは、PostgreSQLからMySQLへの移行先としては使えません。pgloaderの公式資料は、各種データソースからPostgreSQLプロトコルの移行先へデータをロードするツールとして説明しています。
したがって、PostgreSQLを移行元、MySQLを移行先にした設定例は削除しました。逆方向を検討している場合は、別記事のMySQLからPostgreSQLへの移行手順を参照してください。
移行後の検証チェックリスト
検証は「構造」「データ」「アプリケーション」「運用」の順に進めると、問題の場所を切り分けやすくなります。
構造とデータ
- 対象テーブル、列、主キー、外部キー、インデックスが揃っている
- テーブルごとの件数が移行元と一致している
- NULL件数、最小値、最大値、合計値など、業務上意味のある集計結果が一致している
- 日本語、絵文字、改行を含む文字列が欠けたり文字化けしたりしていない
- 日時、真偽値、小数、バイナリ、UUID、JSON、配列由来の値を重点的に確認した
アプリケーションと性能
- 登録、参照、更新、削除の主要操作が成功する
- 認証、検索、一覧、集計、帳票、バッチ、外部連携の結果が一致する
- エラー時にトランザクションが期待どおり処理される
- 代表的な検索について実行計画と応答時間を確認した
- 監視、バックアップ、障害対応の手順をMySQL向けに更新した
本番切り替え
- 利用者へ影響時間を周知し、PostgreSQLへの書き込みを止めます。
- 最終データをMySQLへ反映し、件数と主要な集計値を再確認します。
- アプリケーションの接続先をMySQLへ変更し、主要機能を短時間で確認します。
- 事前に定めた完了条件を満たさない場合は、ロールバック手順を実行します。
- 切り替え後もログ、エラー率、処理時間を監視し、旧環境は保持期限まで変更せず保管します。
安全な移行は検証可能な計画から始まる
MySQL Workbenchは、PostgreSQLのテーブル構造とデータをMySQLへ移す出発点になります。しかし、データ型の意味、コードオブジェクト、アプリケーションのSQL、切り替え後の運用まで自動で保証するものではありません。
本番作業の前に、棚卸し、バックアップの復元試験、検証環境での移行、業務機能の比較、ロールバック判断を一度通しておきます。手順を再現でき、結果を比較できる状態が、本番移行へ進む条件です。
この記事に関連する株式会社greedenの取り組み
Webシステムのデータベース移行では、型変換、アプリ改修、切替後の検証を一つの計画にまとめる必要があります。株式会社greedenは、要件整理から設計、実装、テスト、データ移行、保守運用まで一気通貫で支援します。