The Ultimate Guide to Data Migration in Mendix

Mendix Cloudで Mendix アプリケーションを実行すると、データのバックアップと復元が簡単になります。それが、Mendix プラットフォームでの開発が好まれる理由です。完全に自動化された CI/CD、バックアップおよび復元オプションによるログ記録を備えた、セルフサービスのワンクリック デプロイを提供するフル マネージド サービスです。

ただし、Azure、AWS、Raspberry Pi でさえ、アプリケーションをセルフホストすることを決定する時が来るかもしれません!　Mendix は、Linux および Windows 上の従来の VM ベースの環境から、Kubernetes や Docker を使用した新しいコンテナ化アプローチまで、多数の展開オプションをサポートしています。しかし、ある環境から別の環境にアプリ データを移行するにはどうすればよいでしょうか。それが、この投稿でお見せするものです。

この投稿では、ソース環境とターゲット環境について言及します。ソースは現在実行中の環境 (移動したい環境) であり、ターゲットはデータを移行したい新しいセルフホスト環境です。

Developer portal - apps view

定義

始める前に、Mendix によってデータがどのように管理および保存されるかを明確に理解することが重要です。Mendix は、データをデータベースとファイル ストレージの 2 つに分離します。

データベース

データベースは Studio Pro で作成されたドメイン モデルを反映し、期待されるすべての情報を保存します。

  • エンティティはデータベース テーブルにマップされます
  • 属性はテーブル内の列にマップされます
  • コミットされたオブジェクトは、それらのテーブル内の行にマップされます

Mendix Cloud では、これは AWS Postgres データベースです。

ファイルストレージ

一方、ファイルは個別に保存されます。ファイルに関するメタデータ (ファイル名、サイズ、UUID) はデータベースに保存されますが、バイナリ ファイルのコンテンツ自体は保存されません。バイナリ コンテンツはfile storageとして保存されます。FileDocument データベース テーブル内の UUID は、バイナリ コンテンツのファイル名に 1 対 1 でマップされます。Mendix Cloud では、これは AWS S3 でオブジェクト ストレージとしてホストされます。

はじめに

このチュートリアルの範囲は、ライブ環境のデータとファイルの移行です。ターゲット環境がセットアップされ、Mendix アプリケーションがデプロイされ、データベースとファイル ストレージが (空ではありますが) 構成され、機能していることを前提としています。

Mendix アプリケーションをデプロイする方法の詳細については、このガイドを参照してください。

実際の運用アプリで移行を行う前に、次のチェックリストを確認することをお勧めします。

  • ソース環境とターゲット環境はまったく同じバージョンの Mendix アプリ (.mda) を実行していますか? (同じバージョンを実行しないと、データが失われる可能性があります)
  • 移行期間がスケジュールされ、通知されていますか? (ライブ アプリケーションの移行には、通常は時間外のダウンタイムが必要です。移行を計画し、アプリにアクセスできなくなる時期をユーザーに通知します。)
  • スナップショットの日付は合意され、ユーザーに通知されていますか? (移行では、特定の時点でデータのバックアップ スナップショットを作成する必要があります。それ以降の変更は移行されません。移行の時間になったら、ライブ環境を停止し、データのスナップショットを作成して開始します。)
  • 実際に復元プロセスを実行する前に、廃棄環境で復元プロセスを練習して、手順に慣れていることを確認してください。
  • 実際の移行中に参照できる実践中の手順を文書化する手順書を作成します。

手順書には、次のものも含めることができます。

  • スモーク テスト: 移行後にテスト ケースを実行して、成功を確認します。(アプリケーションに期待されるデータが含まれていることを検証するテストと、データベースとファイル ストレージの両方が移行され、同期されていることを確認します。)
  • DNS レコードとロード バランサーを更新して、ユーザーを新しいターゲット環境にリダイレクトする手順。
  • 移行が失敗した場合、または割り当てられた移行ウィンドウが経過した場合の最悪のシナリオの計画。
  • さまざまなシナリオが発生した場合のユーザー、利害関係者などへのコミュニケーション。

    移行

    Mendix は膨大な数のデータベース、ファイル ストレージ、および展開タイプをサポートしているため、移行する方法も同様にいくつかあります。カスタム ランタイム設定を使用して、最も用途の広い移行アプローチを示します。

    この例では、Mendix Cloud で実行されているアプリを、Azure Kubernetes Service (AKS) で実行されている新しい自己ホスト環境に移行します。ファイル ストレージ用に Azure SQL Database と Azure Blob Storage を実行します。

    Mendix の移行には 2 つの部分が必要です。最初にデータベースの移行、次にファイル ストレージの移行です。

    カスタム ランタイム設定

    Mendix ランタイムには、カスタム ランタイム設定による移行機能が組み込まれています。これらの設定により、ソース データベースからターゲット データベースにデータが転送されます。また、データベースを変換します。したがって、ソース データベースが PostgresSQL でターゲットが MSSQL の場合、ランタイムがこれを処理します。

    Custom-runtime-settings

    データベースの移行で最もよく使用されるカスタム設定は次のとおりです。

    • SourceDatabaseType (HSQLDB、MYSQL、ORACLE、POSTGRESQL、SQLSERVER)
    • ソースデータベースホスト
    • ソースデータベース名
    • ソースデータベースのユーザー名
    • ソースデータベースパスワード
    Custom Runtime Settings example in Windows Service Console
    Windows サービス コンソールでのカスタム ランタイム設定の例

    Custom Runtime Settings example in Mendix for Private Cloud (Mx4PC) Connected

    Mendix for Private Cloud (Mx4PC) Connected のカスタム ランタイム設定の例

    新しいターゲット環境は Azure で実行されています。したがって、Mx Cloud 上のソース データベースを指定して、上記のようにカスタム ランタイム設定を構成する必要があるだけですよね?

    はい。ただし、Mendix Cloud ではデータベースへの直接アクセスは許可されていません。

    したがって、独自の一時 PostgresSQL データベースを作成し、Mx Cloud バックアップをそこに復元してから、この一時データベースをカスタム ランタイム設定のソースとして使用する必要があります。

    ターゲット データベースも PostGresSQL である場合、変換、カスタム ランタイム設定、または一時データベースは必要ありません。PostgreSQL 復元機能を使用して、Mendix Cloud バックアップをターゲット データベースに直接復元するだけです。

    ターゲット データベースとファイル ストレージが空であることを検証する

    移行を実行する前に、ターゲット ファイル ストレージとデータベースを空にする必要があります。

    おそらく、ターゲットの Mendix アプリケーションを起動し、テストを実行してその動作を確認しましたが、それによって誤ってデータを作成してしまったのではないでしょうか。これは、移行の前に削除する必要があります。

    Azure ブログ ストレージ (ターゲット)

    An empty Azure blog storage container

    空の Azure ブログ ストレージ コンテナ

    Azure SQL Server (ターゲット)

    An Azure SQL Database with tables created

    テーブルが作成された Azure SQL データベース

    ターゲット データベースが空ではありません。これには、移行を機能させるために削除する必要があるアプリケーション テーブルが含まれています。

    ブラウザを離れることなく、すべてのテーブルを削除するために必要な SQL コマンドを書き出す簡単なExcel 関数を作成しました。

    代替手段は、数回クリックするだけでテーブルを削除できる視覚的な GUI を備えたSQL Server Management Studio (SSMS)でした。

     

    SQL to drop all tables in my database

    データベース内のすべてのテーブルを削除する SQL

    これらのコマンドを実行した後、データベースは空です。

    An empty Azure SQL Database

    空の Azure SQL データベース

    スナップショットを撮る 📸

    本番データの最終バックアップを取り、移行を開始する時が来ました。Mendix Cloud はセルフサービスであるため、これを実行するのは簡単です。

    Mendix Developer Portal Backups Page

    Mendix 開発者ポータルのバックアップ ページ

    Mendix Cloud開発者ポータルから:

    1. Backups > Production > Create Backup (Mendix はデータのスナップショットを作成します)
    2. [バックアップのダウンロード] > [完全なスナップショット] を選択します(アプリケーションのサイズによっては、数分から数時間かかる場合があります)。

    完全なスナップショットには圧縮された *.tar.gz アーカイブが含まれており、これは Windows で 7-zip を使用して抽出できます。

    フォルダ構造は次のとおりです。

    • db – postgres データベースのバックアップ
    • tree – ファイルストレージ

    Backup-folder-structure

    一時 PostgresSQL データベース

    PostgresSQL DB を作成します。これは、私たちが制御し、接続の詳細を持つデータベースを取得するための一時的な解決策です。

    私のターゲット環境は Azure にあるため、Azure Postgres データベース サーバーを作成します。

    注: ターゲット環境では、データを移行するために一時データベースへのネットワーク接続が必要です。

    一時 PostGresSQL DB がソース データベースと同じバージョンであることを確認します (Mx 開発者ポータルの環境の詳細ページにあります)。

    Environment-details-page-on-Mendix-developer-portal

    復元を実行するには、新しく作成した一時データベースとやり取りできる必要があります。シンプルな GUI インターフェイスを提供するので、pgAdmin 4 をインストールします。

    ローカル マシンに Postgres をダウンロードしてインストールする

    ( PostgreSQL: ダウンロード) pgAdmin と PostgreSQL サーバーが選択されていることを確認します (復元機能に必要)。

    Download-page-for-Postgres-showing-pgAdmin-and-PostgreSQL-server-are-selected

    pgAdmin の初回起動時にマスター パスワードを設定する

    Set master password on first time start of pgAdmin

    接続の詳細を使用して、Azure PostgresSQL サーバーに接続しますConnect to Azure PostgresSQL server

    一時データベースを作成する

    Create-a-temporary-database-in-PostgreSQL

    バックアップを復元する

    PostGresSQL への復元は簡単です。
    「所有者を保存しない」が true に設定されていることを確認して、バックアップ ファイル「db.backup」を選択するだけです。
    詳細については、こちらをご覧ください。

    pgAdmin-menu-showing-selecting-backup-file

    Temp-Migration-DB-restore-options-menu

    一時データベースの復元を検証する

    データはここにあります。一時データベースへの復元は成功しました。

    Validate-the-TempDB-restore

    これで、私たちが管理するデータベースに生産データがあり、接続の詳細が得られました!

    データベースを移行する

    したがって、Postgres から Postgres への移行は非常に簡単です。ターゲット データベースが PostgresSQL の場合は、上記の手順に従ってターゲット データベースに直接アクセスできます。

    私にとっては、変換して MS SQL Server (Azure SQL) に移行する必要があります。幸いなことに、カスタム ランタイム設定を介してこれを行うことができます。

    ターゲット アプリケーションが停止していることを確認する

    Ensure-target-app-has-stopped

    カスタム ランタイム変数の設定

    Set-custom-runtime-values

    ターゲット環境を開始し、データベースの復元が機能したことを検証します

    Start target application

    Validate-the-database-restoration-has-worked

    データは正常に移行されました。

    ファイル ドキュメントは表示されますが、ダウンロードはされません。これは、メタデータを含むデータベースを復元したものの、ファイル ストレージをまだ移行していないためです。

    ファイル ストレージを移行する

    これは、2 つの移行のうち最も単純なものです。スナップショット内のファイルをターゲット ファイル ストレージ (私の場合は Azure Blob Storage) にアップロードするだけです。

    フォルダー構造をフラット化する (必要な場合)

    Mendix での Azure Blob Storage のサポートでは、すべてのオブジェクトが 1 つのフォルダーで利用できることが想定されています。したがって、ルート ディレクトリ内にすべてのファイルをフラット化して格納する必要があります。私は Windows ユーザーなので、単純なPowerShell スクリプトを使用してこれを行います。

    Get-ChildItem -Path SOURCE -Recurse -File | Move-Item -Destination DEST

    Using-a-PowerShell-script-to-flatten-folder-structure-in-Windows

    ファイルを Azure Blob Storage コンテナーにアップロードする

    数千のファイルが 100 GB 以上になる大規模な移行の場合は、 Azure CLIまたはAzure Storage Explorerを使用することをお勧めします。

    私のシナリオではファイルが 2 つしかないので、Azure Web ポータルを使用します。

    Upload-files-to-Azure-Blog-Storage-Container

    Smoke Test
    アプリケーションを再度実行すると、データとファイル コンテンツの両方に完全にアクセスできるようになりました。

    Run a smoke test on the application

    データの移行は成功しました。

    要約

    実際の運用データを処理する場合は、移行後にクリーンアップ アクティビティを実行して、このデータが安全に保たれるようにすることが重要です。これには次のものが含まれます。

    • 本番バックアップのローカル ダウンロードの削除
    • 一時データベースの破棄
    • ターゲット環境でのカスタム ランタイム設定の削除

    結びの言葉

    潜在的な移行の組み合わせ、セットアップ、インフラストラクチャの設計は多数あり、1 回の投稿ですべてをカバーすることは不可能です。特に、同じ手法を使用して独自のデータ移行シナリオに適応できる複雑なシナリオについて説明しました。

    代替アプローチ

    • PG データベースを使用して、Mx4PC から Mx4PC へ、または Mendix Cloud から Mx4PC へ移行しますか? 新しいプライベート クラウド データ移行ツールを利用できます(執筆時点では現在プレビュー中です)。
    • 要塞ホストが必要な場合は、Postgres のローカル インストールで Windows VM を立ち上げ、Mendix Service Console を使用してデータベースをターゲットに移行できます。

    Go migrate it!