操作
機能 #69
未完了MySQLからPostgreSQLへのデータ移行計画
説明
#69: MySQLからPostgreSQLへのデータ移行計画¶
-
目的: 旧システム(MySQL)のデータ(特に
reference\riceshop\old_data\20251211.sql)を、将来的な「恵菜ファーム統合管理システム」の最終形を考慮しつつ、安全かつ正確にPostgreSQLへ移行するための計画を策定する。 -
作業手順:
-
移行元データ(
20251211.sql)の分析:- 提供されたMySQLダンプファイル
reference\riceshop\old_data\20251211.sqlの内容を詳細に分析し、テーブル構造、データ型、インデックス、外部キー制約、データエンコーディングなどを把握します。 - 特に、PostGISでの利用が想定される地理空間データや、移行後にデータ変換が必要となる可能性のある特殊なデータ型(例: BLOB, JSONフィールドなど)を特定します。
- 提供されたMySQLダンプファイル
-
移行先スキーマとのマッピング検討:
-
「恵菜ファーム統合管理システム」の最終形を考慮したPostgreSQL側のデータモデル(Djangoモデルおよび生成されるスキーマ)と、
20251211.sql内のMySQLスキーマとの間に存在する差異を洗い出します。 -
Meta.db_tableを使用してテーブル名を維持するアプローチ(提案チケット2で考慮)と、新しいDjangoモデルの命名規則に合わせたテーブル名への変更、どちらが今回のプロジェクト目標において適切か検討します。 - 各テーブルおよびカラム間のマッピングルールを定義し、データ型変換、値の調整、NULL許容性変更などの必要な変換処理を具体化します。
-
「恵菜ファーム統合管理システム」の最終形を考慮したPostgreSQL側のデータモデル(Djangoモデルおよび生成されるスキーマ)と、
-
データ移行戦略の検討と選定:
- 以下の方法を、分析結果と最終目標を考慮して比較検討し、最適な戦略を選定します。
- Djangoのdumpdata/loaddata: モデル定義に厳密に従うため、スキーマの変更が少ない場合に適していますが、大規模データや複雑な変換には不向きな場合があります。
-
SQL直接変換:
mysql2pgsqlなどのツールやカスタムスクリプトを用いて、20251211.sqlをPostgreSQL互換のSQLに変換しロードします。スキーマの差異が大きい場合や、特定のSQL構文調整が必要な場合に有効です。 - カスタムスクリプト(Pythonなど): MySQLからデータを読み込み、複雑な変換ロジック(例: PostGISデータへの変換、複数のカラム結合、データの正規化/非正規化)を適用した上でPostgreSQLに挿入します。最も柔軟性が高いですが、開発コストは高くなります。
-
外部ツール:
pgloaderなどの専用のデータ移行ツールは、多くのデータ型変換やスキーマ調整を自動化できる可能性があります。
- 以下の方法を、分析結果と最終目標を考慮して比較検討し、最適な戦略を選定します。
-
移行対象データの選定と順序付け:
-
20251211.sqlの中から、移行すべき必須データと、不要なデータを区別します。 - 外部キー制約や論理的な依存関係を考慮し、データ移行の順序を決定します。マスタデータからトランザクションデータ、依存性の高いデータから低いデータへの順序を確立します。
-
-
検証計画の策定:
- 移行後のデータが、移行元データと論理的に同等であり、かつ将来のシステムで正しく機能することを確認するための厳密な検証方法を策定します。
- 例: レコード数の一致、キー値の一致、主要な統計値(合計、平均など)の一致、特定の重要データのランダムサンプリング検証、アプリケーションレベルでの動作検証。
-
ロールバック計画の策定:
- データ移行が失敗または不正確であった場合に備え、旧システムを現状維持し、新しいPostgreSQLデータベースをクリーンな状態に戻すための手順を明確にします。
-
詳細な移行手順書の作成:
- 上記全ての検討結果を盛り込んだ、詳細なデータ移行手順書を作成します。これには、前準備、移行スクリプト/ツールの実行方法、検証手順、エラーハンドリング、ロールバック手順、および各ステップの責任者が含まれます。
-
移行元データ(
表示するデータがありません
操作