在这篇文章中，我将提到 来源 和 目标 环境。 来源 是当前正在运行的环境（我们想要脱离的环境），以及 目标 这是我们想要迁移数据的全新自托管环境。

借口

在开始之前，我们首先要清楚了解数据是如何管理和存储的 Mendix. Mendix 将数据分为两部分：数据库和文件存储。

数据库

数据库反映了在 Studio Pro 中创建的域模型并存储了您期望的所有信息。

• 实体映射到数据库表
• 属性映射到表中的列
• 已提交的对象映射到这些表中的行

In Mendix 云这是一个 AWS Postgres 数据库。

文件存储

另一方面，文件是单独存储的。有关文件的元数据（文件名、大小、UUID）存储在数据库中，但二进制文件内容本身并不存储在数据库中——二进制内容存储为 文件存储。FileDocument 数据库表中的 UUID 与二进制内容的文件名一一对应。在 Mendix 云它作为对象存储托管在 AWS S3 上。

简介

本教程的范围是实时环境的数据和文件迁移。它假设目标环境已设置， Mendix 应用程序已部署，并且数据库和文件存储已配置（尽管为空）且正常运行。

有关如何部署 Mendix 应用程序，你可以 看看这个指南.

在对实际生产应用程序进行任何迁移之前，最好先查看以下清单：

• 源环境和目标环境是否运行完全相同版本的 Mendix 应用程序（.mda）？ （不运行相同版本可能会导致数据丢失）
• 迁移窗口是否已安排并传达？ （实时应用程序的迁移需要停机，通常是非工作时间。规划迁移并在应用程序无法访问时通知用户。）
• 快照日期是否已商定并传达给用户？ （迁移需要在特定时间点对数据进行备份快照。任何后续更改都不会被迁移。迁移时，请停止实时环境，拍摄数据快照，然后开始。）
• 在实际执行恢复过程之前，先在一次性环境中练习一下恢复过程，以确保您熟悉这些步骤。
• 创建一个运行手册来记录实践过程中的步骤，可以在实际迁移期间参考。

该运行手册还可以包括：

• 冒烟测试：迁移后运行测试用例以确认成功。 （测试以验证应用程序是否包含预期数据，并确认数据库和文件存储均已迁移且同步。）
• 更新 DNS 记录和负载均衡器以将用户重定向到新的目标环境的步骤。
• 如果迁移失败或分配的迁移窗口已过期，则制定最坏情况计划。
• 在不同情况下与用户、利益相关者等进行沟通。

移民

As Mendix 支持各种各样的 数据库、文件存储和部署类型，迁移方法同样多种多样。我将演示最通用的迁移方法，即使用自定义运行时设置。

在此示例中，我将迁移运行在 Mendix 将云迁移到我在 Azure Kubernetes 服务 (AKS) 中运行的新自托管环境。它运行 Azure SQL 数据库和 Azure Blob 存储以进行文件存储。

A Mendix 迁移需要两部分：首先是数据库的迁移，然后是文件存储的迁移。

自定义运行时设置

这个 Mendix 运行时具有内置的迁移功能，通过 自定义运行时设置。这些设置将数据从源数据库传输到目标数据库。它还会转换数据库。因此，如果源数据库是 PostgresSQL，而我们的目标是 MSSQL，则运行时将为我们处理此问题。

数据库迁移最常用的自定义设置是：

• 源数据库类型（HSQLDB、MYSQL、ORACLE、POSTGRESQL、SQLSERVER）
• 源数据库主机
• 源数据库名称
• 源数据库用户名
• 源数据库密码

我们的新目标环境正在 Azure 中运行。因此，我们只需要像上面一样配置自定义运行时设置，指向 Mx Cloud 上的源数据库，对吗？

是的，但是 Mendix 云不允许直接访问数据库。

因此，我们需要创建我们自己的临时 PostgresSQL 数据库，将 Mx Cloud 备份恢复到该数据库，然后在自定义运行时设置中使用该临时数据库作为我们的源。

如果您的目标数据库也是 PostGresSQL，则无需转换、自定义运行时设置或临时数据库。只需恢复 Mendix 使用云直接备份到目标数据库 PostgreSQL 恢复功能。

验证目标数据库和文件存储是否为空

执行迁移之前，目标文件存储和数据库需要为空。

也许你已经开始你的目标 Mendix 应用程序，运行测试以确认其正常运行，并因此无意中创建了数据。需要在迁移之前将其删除。

Azure 博客存储（目标）

Azure SQL Server（目标）

我的目标数据库不为空。它包含需要删除才能使迁移正常工作的应用程序表。

我快速写了一篇 Excel功能 写出必要的 SQL 命令来删除所有表，而无需离开浏览器。

另一种选择可能是 SQL Server 管理工作室 (SSMS) 它具有可视化的 GUI，只需单击几下即可删除表格。

运行这些命令后，我的数据库是空的。

拍摄快照📸

现在是时候对我们的生产数据进行最终备份并开始迁移了。 Mendix 云是自助服务的，因此很容易操作。

来自 Mendix 云开发者门户：

1. 备份 > 生产 > 创建备份 (Mendix 创建数据快照）
2. 下载备份 > 完整快照 （根据应用程序的大小，这可能需要几分钟到几个小时。）

完整快照包含压缩的 *.tar.gz 档案，可在 Windows 上使用 7-zip 提取。

文件夹结构如下：

• db – postgres 数据库备份
• 树 – 文件存储

临时 PostgresSQL 数据库

创建 PostgresSQL DB。这是一个临时解决方案，用于获取我们控制并拥有连接详细信息的数据库。

由于我的目标环境在 Azure 中，因此我将创建一个 Azure Postgres 数据库服务器。

注意：目标环境需要与临时数据库建立网络连接才能迁移数据。

确保临时 PostGresSQL DB 与源数据库（可在 Mx 开发人员门户的环境详细信息页面中找到）是同一版本。

要执行恢复，我们需要能够与新创建的临时数据库进行交互。我将安装 pgAdmin 4，因为它提供了一个简单的 GUI 界面：

在本地机器上下载并安装 Postgres

(PostgreSQL：下载）确保选择了 pgAdmin 和 PostgreSQL Server（恢复功能所需）。

首次启动 pgAdmin 时设置主密码

使用连接详细信息连接到我们的 Azure PostgresSQL 服务器

创建临时数据库

恢复备份

恢复到 PostGresSQL 很简单。
只需选择您的备份文件“db.backup”，确保“不保存所有者”设置为 true。
更多详细信息可以在这里找到。

验证临时数据库还原

我们的数据在这里，恢复到我们的临时数据库已成功。

我们现在在我们控制的数据库中拥有生产数据和连接详细信息！

迁移数据库

因此，Postgres 到 Postgres 的迁移非常简单。如果您的目标数据库是 PostgresSQL，您可以直接按照上述步骤进入目标数据库.

对我来说，我需要转换并迁移到 MS SQL Server (Azure SQL)。幸运的是，我们可以通过自定义运行时设置来做到这一点。

确保目标应用程序已停止

设置自定义运行时变量

启动目标环境并验证数据库恢复是否有效

数据已迁移成功。

但是，文件文档显示出来但没有下载。这是因为我们已经恢复了包含元数据的数据库，但尚未迁移文件存储。

迁移文件存储

这是两次迁移中最简单的一次。我们只需将快照中的文件上传到目标文件存储，在我的情况下是 Azure Blob Storage。

扁平文件夹结构（如果需要）

Azure Blob 存储支持 Mendix 期望所有对象都位于一个文件夹中。因此，我需要将所有文件平铺并存储在根目录中。由于我是 Windows 用户，我将使用一个简单的 PowerShell脚本 去做这个。

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

将文件上传到 Azure Blob 存储容器

对于更大规模的迁移，数千个文件总计 100gb 以上，您可能更愿意使用 Azure CLI or Azure 存储资源管理器.

在我的场景中我只有两个文件，所以我将使用 Azure Web 门户。

烟雾测试
再次运行该应用程序，我现在可以完全访问我的数据和文件内容！

数据迁移成功。

包起来

处理实际生产数据时，迁移后进行清理活动很重要，以确保数据安全。这可能包括：

• 删除生产备份的本地下载
• 销毁所有临时数据库
• 删除目标环境上的自定义运行时设置

闭幕词

有许多潜在的迁移组合、设置和基础架构设计，我不可能在一篇文章中全部介绍。我专门介绍了一个复杂的场景，您可以使用相同的技术将其应用于您自己的数据迁移场景。

替代方法

• 在 Mx4PC 和 Mx4PC 之间迁移或 Mendix 使用 PG 数据库将云连接到 Mx4PC？您可以使用新的 私有云数据迁移工具 （撰写本文时目前处于预览状态）。
• 需要堡垒主机，您可以启动一个本地安装了 Postgres 的 Windows VM，然后使用 Mendix 服务控制台 将数据库迁移到目标。

去迁移吧！