迁移注意事项

  • 24 分钟

在本地运行的业务系统的体系结构可以与在同一环境中运行的其他服务耦合。 理解想要迁移的系统与组织目前正在使用的其他应用程序和服务之间的关系非常重要。

在你的科技初创公司中，供应商数据库用于确保部件始终有库存，并且在制造过程中需要使用它们时能够及时到达。 库存控制器使用移动设备在货物到达时更新此数据库，而买家使用网站来监视库存水平，并确定最佳订购时间。 管理人员使用一组业务关键型报表来监视此过程和提高效率。 你想要确保所有这些用户不会因迁移到 Azure 而受到负面影响。

在这里，你将了解如何计划和执行数据库到云的平稳迁移。

调查依赖关系

在复杂的系统中，组件很少完全独立运行。 相反，它会调用其他进程和组件。 例如，数据库可能依赖于托管用户帐户的目录服务。 将数据库移入云中后，是否可以访问该目录服务？ 如果不可以，用户将如何登录？ 如果忽略此类依赖关系，可能会导致数据库完全失败。

若要缓解风险，请检查数据库是否依赖于如下服务：

  • 目录服务，如 Active Directory。
  • 安全主体的其他存储。
  • 其他数据库。
  • Web API 或其他网络服务。

另请记住，其他组件可能依赖于你的数据库。 如果不重新配置依赖的组件就移动数据库，会产生什么后果？ 例如，如果移动一个产品目录数据库，而面向公众的网站依赖它来决定向用户展示哪些产品，这样的移动是否会导致服务中断？

请检查是否有以下类型的组件依赖于你的数据库：

  • 网站和 Web API。
  • 客户端应用，例如移动应用和桌面软件。
  • 其他数据库。
  • 报表。
  • 数据仓库。

若要进行这些检查，请与每个数据库和系统组件所涉及的利益干系人、管理员和开发人员联系。 然后，请参阅文档，如果不确定自己是否理解系统的行为，可以考虑运行测试（如网络捕获）来观察行为。

准备回退

在任何迁移项目中，都应时刻做好失败的准备。 在将数据库迁移到云的项目中，最糟糕的情况是新数据库不可用，用户无法完成其作业。 通常，通过计划回滚到本地未修改的原始数据库，可以减轻可能对公司的盈利能力产生重大影响的风险。

对于回退计划，请考虑：

  • 如何确保回退到未被失败迁移影响的数据库？ 例如，强烈建议在开始迁移之前，执行完整的数据库备份。
  • 如果需要回退，可以接受数据库脱机多长时间？
  • 回退计划有多少预算？ 例如，能否负担得起将数据库复制到专用的回退服务器？ 如果能够，则可以在迁移前关闭此服务器。 若要回退，请启动此服务器。 你会立即获得不受迁移影响的数据库，且无需从备份还原该数据库。

脱机和联机迁移

若要迁移数据库，至少有两个选项：

注意

联机选项当前不适用于数据迁移服务中的 MySQL 数据库。

  • 停止系统，传输数据库，然后重新配置并重新启动系统以使用新的数据库。 这就是脱机迁移。
  • 在将数据库移到新位置时，使系统保持运行状态，并在迁移过程中将正在针对原始数据库执行的事务前滚到新数据库，然后将应用程序切换为连接到新数据库。 这就是联机迁移。

执行脱机迁移更简单，因为用户无法在迁移过程中更改数据。 但是，如果数据库繁忙或对组织的成功至关重要，则该迁移不可行。

脱机迁移

假设你的数据库在为一组分析人员提供支持，他们都处在同一时区，并都在正常工作时间段工作。 该团队通常不在周末工作。 在星期五的下午 6:00 到星期日上午 9:00 点之间，数据库通常不会使用。

在这种情况下，可以通过执行以下步骤，在周末进行脱机迁移：

  1. 在星期五晚上完成所有事务后，将数据库脱机。
  2. 完整备份或导出数据库。
  3. 关闭并保留本地服务器，以防需要回退。
  4. 在目标云系统上还原数据库。
  5. 将目标系统联机。
  6. 重新配置客户端以连接到云数据库。

在这种情况下，可以进行脱机迁移，因为有很长一段时间，服务中断对用户几乎没有影响。 在此期间，可以对数据库进行完整的备份和还原，因此不会错过任何更改。

联机迁移

现在，请考虑另一个支持销售应用的数据库。 销售人员遍布世界各地，而且周末也要工作。 没有一个低活跃度的时期，数据库始终处于繁忙状态，如果将数据库脱机很长一段时间，会影响到用户。 销售活动是业务关键型活动，因此服务中断会直接影响组织的盈利。

在此类情况下，请考虑执行联机迁移。 在联机迁移中，停机时间限制为切换到新数据库所需的时间。 使用 Azure 数据迁移服务之类的工具执行联机迁移。 联机迁移与脱机迁移有以下不同：

  • 在执行备份或导出之前，不会将原始数据库脱机。
  • 正在进行迁移时，更改将应用到旧数据库。
  • 迁移工具可确保在切换之前将这些更改复制到新数据库。 这通常是通过重新配置旧数据库以将更改复制到新数据库来实现的。

应用程序迁移

迁移数据库后，应如何（以及何时）切换到新系统，并更新应用程序以使用新数据库？ 你可能会：

  • 将应用程序逐个移动到新的数据库。
  • 移动部分用户。
  • 结合使用这两种方法。

这样做的目的是通过短期少量迁移应用程序，在出现问题时，可以轻松回滚。 无论采用的是脱机还是联机方式进行数据库迁移，都应该依然有一个位于原始源的工作配置。 理论上，可以快速切换回原始源。 但如果数据不断变化，则需要考虑这些变化是在哪里发生的。

  • 在脱机迁移中，源和目标相互独立。 用户和应用程序可能无法再看到一致的数据视图。 在事务系统中，这种情况可能是不可接受的。 在这种情况下，你需要在两个系统都保持活动状态时，在数据库之间保持某种形式的双向复制。 另外，如果应用程序的用途是生成每月或每周报表、生成销售预测或执行其他统计操作，则缺乏一致性可能并不是那么令人担心。 此类应用程序对数据进行“长线观察”，而不是依赖于最新的数据。 在后一种情况下，事务应用程序使用新数据库，而报表应用程序移动速度更慢。
  • 在联机迁移中，新数据库与旧数据库通常采用某种形式的复制来保持同步。 复制过程可能是异步的，因此可能会出现延迟。 但是，新数据库中的数据发生的更改不会传播回旧数据库，从而导致可能的冲突。 针对旧数据库运行的应用程序可能会对在新数据库中已被修改的数据进行修改，这种修改会引发冲突。 复制会盲目地覆盖新数据库中的更改，从而导致“丢失更新”。

测试方法

如果数据库在业务中扮演着关键角色，则失败的后果可能会很大。 为了增强你对不会发生这种情况的信心，请考虑对已迁移的数据库运行性能测试，以确保该数据库能够应对用户可能施加在其上的负载并迅速做出响应。 请记住，当需求远远高于正常值时，可能会出现活动高峰期。 必须确保已迁移的系统能够处理预期的工作负载。

在允许用户访问之前，始终对新数据库执行某种类型的回归测试。 这些测试将验证系统的行为和功能是否正确。

此外，还应考虑运行“浸泡测试”。 浸泡测试是一种负载测试，旨在查看系统整体在压力下的运行方式。 浸泡测试会对新数据库施加压力，并确定它在高需求下是否稳定。 浸泡测试将在很长的时间段内运行，以了解当高需求持续存在时会发生什么情况。

确定新系统稳定后，可以开始迁移用户。 但是，可能还需要添加其他保障措施来确保用户认为新系统是可接受的。 此时，你可以考虑“金丝雀测试”。 金丝雀测试以透明的方式将一小部分用户定向到新系统，但他们并不知道自己正在访问这个系统。 这是一种盲测形式，目的是能发现新系统中的任何问题。 监视这些用户的响应，并进行任何所需的调整。

维护并行系统

有多种原因导致你可能选择将旧的本地数据库与新的云数据库并行运行：

  • 测试周期。 正如上一主题所述，好的做法是先对迁移的数据库运行金丝雀测试以评估其功能、稳定性和容量，然后再使用它来支持用户。 如果新系统出现问题，并行维护本地系统可以快速将用户还原到旧系统。

  • 分阶段迁移。 为了减轻意外失败对生产的影响，一种方法是先将少量用户移动到新系统，并监视结果。 如果一切正常运行，随着对新数据库的信心逐渐增强，可以转移其他用户组。 可以按字母顺序、按部门、按位置或按角色移动用户，直到它们都位于新数据库上。

  • 逐段迁移。 另一种方法是按工作负载（而非按用户）来划分迁移。 例如，可以迁移支持人力资源的数据库表，然后再迁移支持销售的数据库表。

在所有这些情况下，旧的本地数据库与新的云数据库都会有一个并行运行的时段。 必须确保对旧数据库所做的更改也会应用于新数据库，反之亦然。 可以编写此同步脚本，或使用 Azure 数据迁移服务之类的工具。

如果决定维护并行数据库并同步更改，请问自己以下问题：

  • 冲突解决。 是否有可能在本地某一行发生更改的差不多同一时间，云中的同一行也在进行不同的更改？ 这会造成冲突，导致不清楚应该保留哪个更改。 你会如何解决此类冲突？

  • 网络流量。 在数据库之间同步更改时将生成多少网络流量？ 是否有足够的网络容量来处理这些流量？

  • 滞后时间。 如果有一个数据库发生更改，在该更改到达另一个数据库之前，可以接受多久的延迟（如果有）？ 例如，在产品目录中，在所有用户都能看到新产品之前可以等待长达一天的时间。 但如果数据库包含关键的事务信息（如货币汇率），那么即便不是即时同步，也应该更频繁地同步这些数据。

逐段迁移

逐段迁移是指将一个完整的系统划分为不同的工作负载，然后每次迁移一个工作负载。

多个数据库

复杂系统可能包含支持几个工作负载的多个数据库。 例如，人力资源可能会使用 StaffDB 数据库，而销售团队则可能拥有查询 ProductCatalogDB 数据库和 OrdersDB 数据库的移动应用。

当然，你可以选择一次性将整个数据库系统迁移到云中。 这种方法可能更简单，因为不必同时在本地和云中运行数据库。 不需要考虑这些数据库在迁移期间如何通信。 但是，失败风险会更高。 一个问题就可能会同时影响人力资源团队和销售团队。

请考虑通过执行逐段迁移（一次移动一个工作负载）来减轻大中型数据库系统的这些风险。 在此示例中，你可能会考虑首先迁移 StaffDB 数据库，因为与失败相关的问题会仅限于人力资源团队，而不会妨碍接订单。 通过解决 StaffDB 迁移时出现的任何问题，你将学到适用于其他工作负载迁移的经验。

接下来，可以考虑将产品目录工作负载迁移到云。 如果这样做，请考虑以下问题：

  • 如何确保新添加到目录中的产品可用于订单？
  • 是否需要将任何数据与仍保留在本地的 OrdersDB 数据库同步？
  • 新产品从产品目录到达 OrdersDB 数据库可接受的延迟是多久？

单一数据库逐段迁移

即使只有一个支持所有工作负载的单一数据库，仍然可以考虑进行逐段迁移。 例如，可以将数据库分为以下几个部分：

  • 支持 HR 操作的表。
  • 支持销售的表。
  • 支持分析和报告的表。

如果首先迁移 HR 操作表，则出现的任何问题仅影响 HR 人员。 销售和数据分析人员可以毫无中断地继续使用旧数据库。

在执行逐段迁移之前，必须完全理解数据库以及应用程序使用它们的方式。 例如，数据库中的某些表可能同时支持销售和报告。 这意味着不能完全划分工作负载。 必须在本地和云数据库之间同步这些表，直到所有工作负载都已迁移。

安全注意事项

你的数据库可能包含敏感数据（如产品详情、员工个人信息和支付详细信息），因此安全性始终是重中之重。 必须确定如何在迁移期间以及在新数据库中保护这些数据。

防火墙保护

在连接 Internet 的应用程序中，数据库服务器通常由至少两个防火墙提供保护。 第一个防火墙将 Internet 与前端服务器隔离（例如，如果这些服务器托管网站或 Web API）。 外部防火墙上只需打开 TCP 端口 80，但必须为所有源 IP 地址打开这个端口，被阻止的地址除外。

第二个防火墙将前端服务器与数据库服务器隔离开来。 建议将数据库服务发布到外界未知的专用端口号。 在第二个防火墙上，只为前端服务器的 IP 地址打开此端口号。 这种安排可防止恶意 Internet 用户与数据库服务器之间进行任何直接通信。

如果计划将数据库服务器迁移到 Azure 虚拟机，请使用具有网络安全组 (NSG) 的虚拟网络复制防火墙规则。 如果使用 Azure Database for MySQL、Azure Database for MariaDB 或 Azure Database for PostgreSQL，则可以使用 Azure 门户中服务器的“连接安全”页面创建防火墙规则来保护数据库。

身份验证和授权

在大多数数据库中，需要严格控制谁可以访问和修改哪些数据。 这种控制要求用户在连接到数据库时可以将其准确无误地识别出来。 此过程称为“身份验证”，通常通过用户名和密码来完成。 数据库系统（如 MySQL、MariaDB 和 PostgreSQL）提供自己的身份验证机制。 在将系统迁移到云时，必须确保继续安全地对用户进行身份验证。

注意

Azure Database for MySQL、Azure Database for MariaDB 和 Azure Database for PostgreSQL 服务可以模仿传统 MySQL、MariaDB 和 PostgreSQL 的身份验证。

如果知道用户是谁，则必须为他们分配权限以完成作业中的任务。 此过程称为“授权”。

对于数据库迁移项目，必须确保在云数据库中正确授权用户：

  1. 了解用户帐户在本地系统中的存储位置。 在 MySQL 中，用户帐户通常存储在 mysql 数据库的 user 表中，但可能会发生像与 Active Directory 中存储的用户帐户集成这样的情况。

  2. 获取所有用户帐户的列表。 例如，在 MySQL 中，可以使用以下命令：

    SELECT host, user FROM mysql.user;

  3. 对于每个用户帐户，请查明它们对数据库的访问权限。 例如，在 MySQL 中，可以为 dbadmin@on-premises-host 用户帐户使用以下命令：

    SHOW GRANTS FOR 'dbadmin'@'on-premises-host';

  4. 在云数据库中重新创建每个用户帐户。 例如，在 MySQL 中，可以使用以下命令创建一个新帐户：

    CREATE USER 'dbadmin'@'cloud-host'

  5. 向每个用户帐户授予云数据库中合适的访问权限级别。 例如，在 MySQL 中，可以使用此命令允许用户访问完整数据库：

    GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'

加密

通过网络发送数据时，这些数据可能会被所谓的“中间人”攻击截获。 为了防止出现这种情况，Azure Database for MySQL、Azure Database for MariaDB 和 Azure Database for PostgreSQL 均支持安全套接字层 (SSL) 加密通信。 默认情况下会强制实施 SSL，强烈建议不要更改此设置。

可能需要修改客户端应用程序的连接设置才能使用 SSL 加密。 与开发人员讨论本主题，以确定是否有必要进行更改。

监视和管理

在计划迁移数据库的过程中，需要考虑数据库管理员在迁移后如何继续执行其任务。

监视

本地数据库管理员习惯于定期监视以发现问题，例如硬件瓶颈或网络访问争用。 他们监视的目的是确保可以在工作效率受到影响之前解决所有问题。 可以预料，任何没有定期监视的数据库迟早会开始导致问题。

你应对云数据库采取完全相同的方法。 在 Azure 这样的 PaaS 系统中解决问题可能更容易，因为可以在不购买、设置和配置任何硬件的情况下添加资源。 不过，仍需要找出开发问题，因此监视在日常任务中是重中之重。

将数据库迁移到云中之前，请了解管理员当前使用的监视工具。 如果这些工具与你提议的基于云的解决方案兼容，可能只需要将它们重新连接到迁移的数据库即可。 如果不兼容，则必须研究替代方案。

请记住，Azure 包括一组性能监视工具，并收集各种性能计数器和日志数据。 通过配置 Azure Monitor，可以在 Azure 门户中使用面板和图表来显示此数据。 可以创建专门为管理员的需求而设计的自定义图形、表和报表。

Management

数据库管理员使用首选工具更改本地数据库的架构和内容。 如果在迁移后他们使用相同的工具，你可以继续受益于其专业知识。 首先评估现有工具集是否与提议的云托管数据库兼容。 许多工具都是兼容的，因为它们基于广泛采用的标准（例如 SQL），但是验证这种兼容性很重要。 如果在迁移后当前管理工具不起作用，请尝试与管理员一起确定替代方案。

Azure 包含多个可用于管理 MySQL、MariaDB 和 PostgreSQL 数据库的工具：

  • Azure 门户。 此网站提供了强大的工具，可用于配置、监视和管理数据库，以及可能在 Azure 云中创建的所有其他资源。

  • Azure PowerShell。 这是一种脚本执行环境和语言，拥有多种命令集。 使用 PowerShell（适用于 Windows 和 Linux 环境）可自动执行复杂的数据库管理任务。

  • Azure CLI。 这是 Azure 的命令行接口。 使用它可管理 Azure 中的服务和资源。 可以在 Windows 和 Linux shell 环境下使用 CLI，也可以在 Bash 脚本中使用。