データ移行の究極ガイド Mendix
実行中のデータのバックアップと復元は簡単です Mendix のアプリケーション Mendix クラウド。それが私がクラウドで開発するのが好きな理由です Mendix プラットフォームです。完全に自動化された CI/CD、ログ記録、バックアップおよび復元オプションを備えたセルフサービス ワンクリック デプロイメントを提供する、完全に管理されたサービスです。
ただし、Azure、AWS、さらには Raspberry Pi 上でアプリケーションを自己ホストすることを決定するときが来るかもしれません。 Mendix Linux および Windows 上の従来の VM ベースの環境から、Kubernetes や Docker を使用した新しいコンテナ化アプローチまで、さまざまなデプロイメント オプションをサポートしています。しかし、アプリ データをある環境から別の環境に移行するにはどうすればよいでしょうか。この記事では、その方法を説明します。
この投稿では、 ソース および ターゲット 環境。 ソース 現在実行中の環境（私たちが移行したい環境）であり、 ターゲット データを移行したい新しいセルフホスト環境です。
口実
始める前に、データがどのように管理され、保存されるかを明確に理解することが重要です。 Mendix. Mendix データをデータベースとファイル ストレージの 2 つに分離します。
データベース
データベースは Studio Pro で作成されたドメイン モデルを反映し、必要なすべての情報を保存します。
- エンティティはデータベーステーブルにマップされます
- 属性はテーブル内の列にマップされます
- コミットされたオブジェクトはそれらのテーブル内の行にマップされます
In Mendix クラウドは AWS Postgres データベースです。
ファイルストレージ
一方、ファイルは別々に保存されます。ファイルに関するメタデータ（ファイル名、サイズ、UUID）はデータベースに保存されますが、バイナリファイルの内容自体は保存されません。バイナリコンテンツは次のように保存されます。 ファイルストレージFileDocumentデータベーステーブル内のUUIDは、バイナリコンテンツのファイル名に1対1でマップされます。 Mendix クラウドは AWS S3 上のオブジェクト ストレージとしてホストされます。
イントロ
このチュートリアルの目的は、ライブ環境のデータとファイルの移行です。ターゲット環境がセットアップされ、 Mendix アプリケーションがデプロイされ、データベースとファイル ストレージが構成され (空ではありますが) 動作しています。
導入方法の詳細については、 Mendix アプリケーション、あなたはすることができます このガイドをチェックしてください.
実際の運用アプリで移行を実行する前に、次のチェックリストを確認することをお勧めします。
- ソース環境とターゲット環境では、 Mendix アプリ (.mda)? (同じバージョンを実行しないとデータが失われる可能性があります)
- 移行期間がスケジュールされ、通知されていますか? (ライブ アプリケーションの移行には、通常は営業時間外のダウンタイムが必要です。移行を計画し、アプリがアクセスできなくなる時間をユーザーに通知します。)
- スナップショットの日付は合意され、ユーザーに伝えられていますか? (移行には、特定の時点でのデータのバックアップ スナップショットを作成する必要があります。それ以降の変更は移行されません。移行するときは、ライブ環境を停止し、データのスナップショットを作成して開始します。)
- 実際に実行する前に、使い捨ての環境で復元プロセスを練習して、手順に慣れておくようにしてください。
- 実際の移行時に参照できるように、練習中の手順を文書化したランブックを作成します。
ランブックには次の内容も含まれる場合があります。
- スモーク テスト: 移行後に成功を確認するためにテスト ケースを実行します。 (アプリケーションに期待されるデータが含まれていることを検証し、データベースとファイル ストレージの両方が移行され、同期されていることを確認するテストです。)
- DNS レコードとロード バランサーを更新して、ユーザーを新しいターゲット環境にリダイレクトする手順。
- 移行が失敗した場合、または割り当てられた移行期間が経過した場合の最悪のシナリオの計画。
- さまざまなシナリオが発生した場合のユーザー、利害関係者などへのコミュニケーション。
移行
As Mendix 幅広い範囲をサポート データベース、ファイル ストレージ、展開の種類に応じて、移行方法もいくつかあります。ここでは、カスタム ランタイム設定を使用した最も汎用性の高い移行方法を紹介します。
この例では、 Mendix Azure Kubernetes Service (AKS) で実行されている新しいセルフホスト環境へのクラウド。ファイル ストレージ用に Azure SQL Database と Azure Blob Storage を実行します。
A Mendix 移行には 2 つの部分が必要です。最初にデータベースの移行、次にファイル ストレージの移行です。
カスタムランタイム設定
当学校区の Mendix ランタイムには、 カスタムランタイム設定これらの設定は、ソース データベースからターゲット データベースにデータを転送します。また、データベースの変換も行います。したがって、ソース データベースが PostgresSQL で、ターゲットが MSSQL の場合、ランタイムがこれを処理します。
データベース移行で最もよく使用されるカスタム設定は次のとおりです。
- ソースデータベースタイプ (HSQLDB、MYSQL、ORACLE、POSTGRESQL、SQLSERVER)
- ソースデータベースホスト
- ソースデータベース名
- ソースデータベースユーザー名
- ソースデータベースパスワード
新しいターゲット環境は Azure で実行されています。したがって、上記のようにカスタム ランタイム設定を構成して、Mx Cloud 上のソース データベースを指定するだけでよいのでしょうか?
はい、しかし、 Mendix クラウドではデータベースへの直接アクセスは許可されません。
したがって、独自の一時的な PostgresSQL データベースを作成し、そこに Mx Cloud バックアップを復元して、この一時データベースをカスタム ランタイム設定のソースとして使用する必要があります。
ターゲットデータベースもPostGresSQLの場合、変換やカスタムランタイム設定、一時データベースは必要ありません。 Mendix クラウドバックアップをターゲットデータベースに直接使用する PostgreSQL の復元機能。
ターゲットデータベースとファイルストレージが空であることを確認する
移行を実行する前に、ターゲット ファイル ストレージとデータベースを空にする必要があります。
おそらくあなたは目標を開始した Mendix アプリケーションが動作していることを確認するためにテストを実行しましたが、その際に誤ってデータが作成されました。これは移行前に削除する必要があります。
Azure ブログ ストレージ (ターゲット)
Azure SQL Server (ターゲット)
ターゲット データベースは空ではありません。移行を機能させるために削除する必要があるアプリケーション テーブルが含まれています。
私は簡単に書いた エクセル機能 ブラウザを終了せずに、すべてのテーブルを削除するために必要な SQL コマンドを記述します。
代替案としては SQL Server Management Studio（SSMS） 数回のクリックでテーブルを削除できるビジュアル GUI を備えています。
これらのコマンドを実行すると、データベースは空になります。
スナップショットを撮る 📸
実稼働データの最終バックアップを取り、移行を開始します。 Mendix クラウドはセルフサービスなので、簡単に実行できます。
ノーザンダイバー社の Mendix クラウド開発者ポータル:
- バックアップ > プロダクション > バックアップの作成 (Mendix データのスナップショットを作成します）
- バックアップをダウンロード > フルスナップショット (アプリケーションのサイズに応じて、数分から数時間かかる場合があります。)
完全なスナップショットには圧縮された *.tar.gz アーカイブが含まれており、Windows では 7-zip を使用して抽出できます。
フォルダ構造は次のとおりです。
- db – postgres データベースのバックアップ
- ツリー – ファイルストレージ
一時的な PostgresSQL データベース
PostgresSQL DB を作成します。これは、私たちが制御し、接続の詳細を持つデータベースを取得するための一時的なソリューションです。
ターゲット環境は Azure にあるため、Azure Postgres データベース サーバーを作成します。
注: データを移行するには、ターゲット環境で一時データベースへのネットワーク接続が必要です。
一時 PostGresSQL DB がソース データベースと同じバージョンであることを確認します (Mx 開発者ポータルの環境詳細ページにあります)。
復元を実行するには、新しく作成した一時データベースを操作できる必要があります。シンプルな GUI インターフェイスを提供する pgAdmin 4 をインストールします。
ローカルマシンにPostgresをダウンロードしてインストールします
(PostgreSQL: ダウンロード) pgAdmin と PostgreSQL サーバーが選択されていることを確認します (復元機能に必要)。
pgAdmin の初回起動時にマスターパスワードを設定する
接続詳細を使用してAzure PostgresSQLサーバーに接続します
一時データベースを作成する
バックアップを復元する
PostGresSQL への復元は簡単です。
バックアップ ファイル「db.backup」を選択し、「所有者を保存しない」が true に設定されていることを確認します。
詳細については、こちらをご覧ください。
一時データベースの復元を検証する
データはここにあり、一時データベースへの復元は成功しました。
これで、私たちが管理するデータベースに生産データが格納され、接続の詳細も取得できました。
データベースの移行
したがって、PostgresからPostgresへの移行は非常に簡単です。ターゲットデータベースがPostgresSQLの場合は、上記の手順をターゲットデータベースに直接実行できます。.
私の場合、MS SQL Server (Azure SQL) に変換して移行する必要があります。幸いなことに、カスタム ランタイム設定を使用してこれを実行できます。
ターゲットアプリケーションが停止していることを確認する
カスタムランタイム変数を設定する
ターゲット環境を起動し、データベースの復元が機能したことを確認します。
データは正常に移行されました。
しかし、待ってください。ファイル ドキュメントは表示されますが、ダウンロードされません。これは、メタデータを含むデータベースは復元しましたが、ファイル ストレージがまだ移行されていないためです。
ファイルストレージの移行
これは 2 つの移行の中で最も簡単です。スナップショット内のファイルをターゲット ファイル ストレージ (私の場合は Azure Blob Storage) にアップロードするだけです。
フォルダ構造をフラット化する（必要な場合）
Azure Blob Storageのサポート Mendix すべてのオブジェクトが1つのフォルダで利用できることが期待されています。したがって、すべてのファイルをフラット化してルートディレクトリ内に保存する必要があります。私はWindowsユーザーなので、単純な PowerShellスクリプト これをする。
Get-ChildItem -Path SOURCE -Recurse -File | Move-Item -Destination DEST
Azure Blob Storage コンテナーにファイルをアップロードする
100GBを超える数千のファイルを含む大規模な移行の場合は、 AzureCLI or Azure ストレージ エクスプローラー.
私のシナリオではファイルは 2 つしかないため、Azure Web ポータルを使用します。
スモークテスト
アプリケーションを再度実行すると、データとファイルの内容の両方に完全にアクセスできるようになりました。
データ移行は成功しました。
要約
実際の運用データを扱う場合、移行後にクリーンアップ アクティビティを実行して、このデータが安全であることを保証することが重要です。これには次のものが含まれます。
- 本番環境バックアップのローカルダウンロードを削除する
- 一時データベースの破棄
- ターゲット環境のカスタムランタイム設定を削除する
閉じた言葉
移行の組み合わせ、セットアップ、インフラストラクチャ設計は数多くあり、すべてを 1 つの投稿でカバーすることは不可能です。ここでは、同じ手法を使用して独自のデータ移行シナリオに適応できる複雑なシナリオについて具体的に説明しました。
代替アプローチ
- Mx4PCからMx4PCへの移行または Mendix PGデータベースを備えたMx4PCにクラウドを接続できますか？新しい プライベートクラウドデータ移行ツール (執筆時点ではプレビュー段階です)。
- 要塞ホストが必要な場合は、PostgresのローカルインストールでWindows VMを立ち上げ、 Mendix サービス コンソール データベースをターゲットに移行します。
移行しましょう!