应用程序迁移

  • 8 分钟

将数据库从本地迁移到 Azure 后，需要更新现有应用程序，以便他们可以在其新位置访问 PostgreSQL。

原始本地服务器和数据库将包含定义与用户关联的特权、他们可以执行的作以及他们执行这些作的对象的角色。 Azure Database for PostgreSQL 使用与在本地运行的 PostgreSQL 相同的身份验证和授权机制。

在本单元中，你将了解应用程序连接到新迁移的 Azure Database for PostgreSQL 所需的更新。

手动创建用户角色

使用 Azure 数据库迁移服务将 PostgreSQL 数据库传输到 Azure Database for PostgreSQL 时，不会复制角色和角色分配。 必须为目标数据库中表的管理员和用户手动重新创建必要的角色和用户帐户。 可以使用 psql 或 pgAdmin 实用工具执行这些任务。 运行 CREATE ROLE 命令。 使用 GRANT 命令将必要的特权分配给角色。 例如：

CREATE ROLE myuseraccount WITH LOGIN NOSUPERUSER CREATEDB PASSWORD 'mY!P@ss0rd';
GRANT ALL PRIVILEGES ON DATABASE mydatabase TO myuseraccount;

注释

还可以使用 bash 提示符中的 createuser 命令来创建 PostgreSQL 角色。

若要查看本地数据库中的现有角色，请运行以下 SQL 语句：

SELECT rolname
FROM pg_roles;

可以使用 psql 实用工具中的 \du 命令显示分配给角色的权限。

                              List of roles
   Role name   |               Attributes                                   | Member of
---------------+------------------------------------------------------------+-----------
 azureuser     | Superuser, Create DB                                       | {}
 myuseraccount | Create DB                                                  | {}
 postgres      | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

注释

请注意，Azure Database for PostgreSQL 会添加自己的某些角色。 这些角色包括 azure_pg_admin、azure_superuser以及创建服务时指定的管理员用户。 使用管理帐户登录，但其他两个角色保留供 Azure 使用-不应尝试使用它们。

重新配置应用程序

将应用程序配置为连接到 Azure Database for PostgreSQL 的过程非常简单。 但是，确定迁移应用程序的策略更为重要。

重新配置 PostgreSQL 应用程序时的注意事项

在企业环境中，可能有许多应用程序针对同一 PostgreSQL 数据库运行。 可能有大量用户运行这些应用程序。 你希望确信，从现有系统切换到 Azure Database for PostgreSQL 时，系统仍将有效，用户可以继续执行其作业，并且业务关键型作仍可正常运行。 模块 1，第 2 课，迁移注意事项，一般讨论了许多问题。 将 PostgreSQL 数据库迁移到 Azure 时，需要注意一些具体说明：

  • 如果要执行脱机迁移，则原始 PostgreSQL 数据库中的数据以及 Azure 上运行的新数据库在旧数据库仍在使用时可能会开始快速分流。 当系统完全退出作一段时间，然后将所有应用程序切换到新系统，然后重新启动之前，脱机迁移是合适的。 对于业务关键型系统，这种方法可能是不可能的。 如果要迁移到在 Azure 虚拟机上运行的 PostgreSQL，请在本地系统与 Azure 中运行的复制之间配置 PostgreSQL 复制。 本机 PostgreSQL 复制仅以一个方向运行，但第三方解决方案支持 PostgreSQL 服务器之间的双向复制（这些解决方案不适用于 Azure Database for PostgreSQL）。
  • 如果要执行联机迁移，Azure Database for PostgreSQL 服务会设置从本地数据库到在 Azure 中运行的数据库的复制。 初始数据传输后，复制可确保本地数据库中所做的任何更改都复制到 Azure 中的数据库，但不会以另一种方式进行复制。

在这两种情况下，都应确保不会通过意外覆盖丢失实时数据。 例如，在联机方案中，连接到 Azure Database for PostgreSQL 中运行的数据库的应用程序可能会让仍在使用本地数据库的应用程序盲目覆盖其更改。 考虑到这一点，应考虑以下方法：

  • 根据应用程序的工作负荷类型迁移应用程序。 访问数据以供读取的应用程序只能安全地移动到 Azure Database for PostgreSQL 中运行的数据库，并会看到仍在使用本地数据库的应用程序所做的所有更改。 如果只读应用程序不需要完全 up-to日期数据，还可以采用相反的策略。
  • 根据用户的工作负荷类型迁移用户。 此策略类似于上一个策略，只是你可能有用户只生成报表，而另一些用户则修改数据。 你可能已将同一应用程序配置为根据用户要求连接到相应的数据库。
  • 根据所使用的数据集迁移应用程序。 如果不同的应用程序使用不同的数据子集，则你可能能够独立迁移这些应用程序。

重新配置应用程序

若要重新配置应用程序，请将其指向新数据库。 大多数编写良好的应用程序将隔离连接逻辑，这应该是需要更改的代码的唯一部分。 在许多情况下，连接信息可能存储为配置信息 ，只需更新该信息。

可以在 Azure 门户中的 连接字符串 页上找到 Azure Database for PostgreSQL 服务的连接信息。 Azure 提供了许多常见编程语言和框架的信息。

显示 Azure 门户中 Azure Database for PostgreSQL 项的连接字符串页的图像

打开网络端口

如本模块第 1 课中所述，Azure Database for PostgreSQL 是一种在防火墙后运行的受保护服务。 客户端无法连接，除非服务识别其 IP 地址。 对于运行需要连接到数据库的应用程序的客户端，必须添加 IP 地址或地址块范围。

测试和验证应用程序

将应用程序和用户切换到新数据库之前，请务必确保已正确配置所有内容。

首先，“干运行”应用程序并连接每个角色，以确保正确的功能可用。

接下来，执行“浸泡测试”来模拟一段时间内同时运行代表性工作负荷的典型用户数。 监视系统，并验证是否已为 Azure Database for PostgreSQL 服务分配足够的资源。

此时，你可以开始向用户推出系统。 实施某种形式的“Canary 测试”可能很有帮助，其中一小部分用户不会意识到。 这让你对用户拥有新数据库的体验是相同、更好还是更差，这提供了一个不偏不开的观点。