分析工具选择和迁移模型的决策条件

现在，我们探索了迁移方法和工具选项的选项，接下来可以探索需要考虑的决策条件，以执行迁移到 Azure Database for PostgreSQL 灵活服务器。 帮助我们做出选择的三个主要条件是停机时间、源数据库位置和可自定义性。

停机时间

停机时间是迁移活动的关键方面，利益干系人可以接受的持续时间有助于我们决定是否必须执行脱机或联机迁移活动。

通常，迁移活动提前进行规划，以确保为活动完成适当的更改控制和关联的治理。 此计划允许与关键利益干系人进行对话，以了解系统脱机的时间。 在这种情况下，建议了解不同选项所需的时间，以便确定估计的最短和最长停机时间。

确定执行应用程序切换所需的最短停机时间是关键。 归根结底，即使是联机（或最短停机时间）迁移活动，在这段时间里，系统也必须脱机。 应用程序的复杂性将决定此时间刻度。 对于相对简单的应用程序，此过程可能是停止服务、更新配置文件、重新打开配置文件的情况。 在更复杂的环境中，如果存在多个服务器和应用程序层，此过程可能需要更长的时间。

了解联机或脱机迁移活动所需的持续时间是与停机时间相关的下一个重要元素。 如果是脱机迁移，停机时间是从源提取、传输和加载数据到目标，然后进行验证和校验所花费的时间。 然后，此停机时间将夹在关闭应用/工作负荷所需的时间与重新打开应用/工作负荷所需的时间之间。

如果是停机时间最少的联机迁移，停机时间是指应用程序关闭后，将最终更改从源同步到目标所需的时间。 在重新配置和启用应用程序/工作负载之前，除了停机时间，还需要进行验证和确认活动。

获得此信息后，可以查看迁移的技术元素，以帮助确定可行的选项。

源数据库位置

要迁移的数据库的源位置会产生影响，因为可能存在对任何给定配置的限制。

本地或非 Azure 源

对于本地数据库或非 Azure 位置数据库，密钥约束通常是源与目标之间的网络连接。 此处要考虑的三点是带宽、延迟和数据量。 了解这些要点后，我们可以就哪种类型的迁移可行做出明智的决定。

如果我们有大量数据要迁移，并且带宽的比例较小，那么简单的转储和还原可能不可行。 而如果我们有大量数据和大量的带宽，那么就不那么担心了。

同样，如果是要进行数据同步的联机迁移，则延迟是关键因素之一。 如果延迟较高，则可能会对系统性能产生负面影响，因为同步过程需要很长时间才能完成。

从其他云提供商迁移时还要考虑的一个重要因素是它们是否对数据出口收费。 如果是这样，那么能够最大程度地减少传输的数据的物理占用量可能是一个考虑因素。 在这种情况下，压缩技术对用于同步的转储或数据流非常重要。

其他基于 Azure 的服务

在某些情况下，需要从其他基于 Azure 的服务迁移到 Azure Database for PostgreSQL 灵活服务器。 这些源数据库可以位于 Azure VM、容器或 Azure Database for PostgreSQL 单一服务器中。 如果是这样，则需要考虑一组不同的注意事项，但同时，为这些方案从 Azure 服务中的优化中获益的机会有很多。

可自定义性

最后需要考虑的方面是需要或期望的自定义程度。 这种考量可能需要修改源数据库结构以支持数据复制，或者，这也可能意味着通过脚本自动化实现的难易程度。

一个很好的示例是通过pg_dump和pg_restore自动执行数据库脱机迁移，但同时包括转储文件的压缩和解压缩。

决策

现在，我们经历了收集所有这些信息的过程，我们可以与利益干系人合作，确定给定方案的最佳选项。 在决定采用哪种方法和技术时，不仅要与业务利益干系人合作，而且还要与技术利益干系人合作，这一点很重要。 此协作有助于避免由于人员、资源或技术限制造成的情况，即业务要求迁移停机时间最短，而技术团队无法实现。

这里的关键是管理期望，并有一个开放和诚实的对话。 另外，还需确保业务部门对不在数据库迁移技术团队职责范围内的验证任务拥有所有权。 此验证可以涉及数据一致性和验证检查，以及用户体验测试。