本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 迁移波次、服务器和数据库
<a name="considerations"></a>

迁移项目从以下未解决的问题列表开始，这些问题在上一节描述的三种场景中很常见：
+ 我们如何建立迁移波次？
+ 我们如何在每个波次中对服务器进行分组？
+ 数据库服务器应该先于应用程序服务器迁移，还是随应用程序服务器一起迁移？
+ 我们应该使用哪种工具进行数据库迁移？

但是，要解决这些问题，我们需要先澄清一些定义。本指南的这一部分重点介绍*数据库*一词及其在迁移浪潮背景下的含义。这个定义很重要，因为对该术语的理解可能会改变特定迁移浪潮的整体迁移方法，甚至可以通过在不同浪潮之间转移服务器来改变迁移浪潮。

*数据库*一词是指运行 DBMS 软件的服务器，还是逻辑数据库入口点？ 它是指同一服务器上的几个数据库中的一个，还是指一个服务器集群中的一个？ 根据上下文，数据库可以指任一选项。数据库管理员 (DBAs) 通常考虑逻辑数据库，而不是物理服务器。但是，在迁移（尤其是大规模迁 lift-and-shift移）的背景下，数据库通常对应于一台物理服务器或一组服务器。

数据库的迁移必须与其使用的应用程序保持一致并与之相关联，因为逻辑数据库始终是应用程序及其依赖项的一部分。但是，该逻辑数据库的物理位置可能会有所不同。例如，它可能位于：
+ 一台独立的物理服务器，不存在任何其他数据库。
+ 与其他逻辑数据库托管在一起的独立物理服务器。
+ 物理服务器群集，可以作为单个逻辑数据库，也可以作为为其他应用程序提供服务的更大数据库集的一部分。

如果应用程序和数据库服务器之间没有明确的依赖关系，则为迁移浪潮创建 one-to-one依赖关系映射会很复杂，尤其是当来自不同应用程序的多个逻辑数据库托管在同一台物理服务器上时。此类数据库系统需要采用[重构平台](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html#replatform)的方法，这种方法涉及数据库的分解或整合，这会使大规模迁移工作复杂化。 lift-and-shift 

这就是数据库迁移工具（例如数据库引擎供应商或第三方提供的本机工具）可以提供帮助的地方。这些工具在逻辑数据库级别上工作，而不是块级复制方法 AWS Application Migration Service，并且可以在物理服务器和位置之间在逻辑级别上移动数据或数据库。这些本机数据库迁移工具可以帮助您将逻辑数据库整合到单个物理服务器上。他们也可以反其道而行之：他们可以在不同的物理数据库服务器之间分解逻辑数据库，使它们与不同的应用程序保持一致，并将它们分布在不同的迁移浪潮中。