RDS for PostgreSQL 迁移到 Aurora PostgreSQL

为什么迁移？

1.Aurora PG的性能是PG的3倍（我没验证，估计得看workload

2.Aurora PG的存储计算分离，使得扩展、故障转移变得更快更方便，同时存储的性能得到了很大的提升

3.存储弹性分配，可以有效解决RDS实例分配了大存储无法缩容的问题（是的，它可以自动扩容，无法缩容

如何迁移？

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Migrating.html

参考文档，我们可以看到官方提供了四种迁移选项，

1.使用快照迁移；顾名思义，就是通过创建RDS for PostgreSQL的快照，还原出一个Aurora PG，但是可以想到的是，这种迁移方式需要合适的窗口期——原RDS的备份需要时间，新Aurora PG从备份还原也需要时间；

2.使用Aurora只读副本迁移；这种方法不会影响当前的生产环境，只需要在同步完成后，找到一个合适的维护期，以分钟级的窗口就能完成迁移，这也是本文将要使用的方法；

3.从S3导入；这个可以遇见与第一种方法一样，需要较久的窗口才能完成迁移；

4.使用DMS做异构迁移；更多是异构数据库的场景，需要对齐前后的表结构及业务逻辑。

使用Aurora只读副本迁移

1.文档中给出了最简单的一种方式，即通过在控制台中点击创建Aurora只读副本，便可以开始这个过程，如下图

但是当你打开亚马逊云科技中国区域控制台时，你会发现这样

这里并没有创建Aurora只读副本的选项，而且在我们使用亚马逊云科技中国区域的这几年内，也都没有这个选项，通过咨询亚马逊云科技负责数据库的产品经理，确认以上功能可以通过CLI实现。

以下是示例环境，RDS for PostgreSQL版本为10.12，使用Multi-AZ多可用区部署，存储分配2000GiB（实际占用450GiB左右），未开启KMS静态加密，配置使用了db.m5.large，如下图

2.使用CLI创建Aurora只读副本

需要注意的是，如果当前的RDS for PostgreSQL已经存在跨Region只读副本时，是无法再为其创建Aurora只读副本。

先创建Aurora集群，以下参数是必须的

aws rds create-db-cluster \
  --db-cluster-identifier rds-for-pg-migrate-to-aurora --engine aurora-postgresql \
  --db-subnet-group-name xxxxxx-prd-rds \
  --vpc-security-group-ids sg-xxxxxx \
  --replication-source-identifier arn:aws-cn:rds:cn-northwest-1:xxxxxx:db:rds-for-pg-demo

得到一个报错

An error occurred (InvalidParameterCombination) when calling the CreateDBCluster operation: Cannot upgrade from postgres 10.12 to aurora-postgresql 11.9.Specify a current active database version, the latest active minor version for postgres 10 is 10.15.

我们可以列出宁夏区域所支持的Aurora PG版本列表，

$ aws rds describe-db-engine-versions --engine aurora-postgresql --query '*[].[EngineVersion]' --output text | grep 10.
10.11
10.12
10.13
10.14
10.16

可见我们可以指定以上版本来创建Aurora集群，我们这里选择10.16直接升级小版本（不选择10.12的原因将在之后的步骤中列出来）

执行以下命令

aws rds create-db-cluster \
  --db-cluster-identifier rds-for-pg-migrate-to-aurora --engine aurora-postgresql \
  --db-subnet-group-name xxxxxx-prd-rds \
  --vpc-security-group-ids sg-xxxxxx \
  --replication-source-identifier arn:aws-cn:rds:cn-northwest-1:xxxxxx:db:rds-for-pg-demo \
  --engine-version 10.16

这时我们可以看到正常的参数返回如下

{
    "DBCluster": {
        "AllocatedStorage": 1,
        "AvailabilityZones": [
            "cn-northwest-1c",
            "cn-northwest-1a",
            "cn-northwest-1b"
        ],
        ...
}

回到控制台中，我们也可以看到一个Aurora集群被立刻创建了

值得注意的是，它很快就是Available的状态，当然他只是一个没有任何数据库实例的集群。

3.创建Aurora集群的主实例。

第二步只创建了Aurora集群，因为我们使用CLI的缘故，并不会自动创建该集群的主实例，故我们依然需要使用CLI来创建第一个数据库实例

$ aws rds create-db-instance \
    --db-cluster-identifier rds-for-pg-migrate-to-aurora \
    --db-instance-class db.r5.large \
    --db-instance-identifier aurora-demo \
    --engine aurora-postgresql

这里需要注意的是，instance-class必须指定当前版本所支持的实例类型，比如说我们原有的10.12在Aurora下则只有r4系列的实例，并不提供r5，所以我们在创建Aurora集群时，要注意小版本的差异（如果你的版本比较新，则更新的小版本也有提供Graviton 2系列的实例）。

可以得到如下返回

{
    "DBInstance": {
        "DBInstanceIdentifier": "aurora-demo",
        "DBInstanceClass": "db.r5.large",
        "Engine": "aurora-postgresql",
        "DBInstanceStatus": "creating",
...
}

这时我们便可以回到控制台查看实例创建的过程

首先它会对原实例进行一次快照（这次快照免费），然后通过快照还原Aurora实例，之后会开始持续复制以追上还原过程中的增量并且保持同步。

Aurora只读副本的创建时间，和数据量有关，首先有一个准备迁移的过程，之后会开始迁移，由于Aurora存储和计算分离，存储的部分有非常高的性能，所以在准备迁移检查结束后，实际写入数据是非常快的。

你可以在Aurora实例的监控页面查看当前的一些性能指标，以了解创建进度

可以看到数据库实例以极高的IO在填充。

以本例450GiB左右数据为例，大约使用了十五分钟做准备，之后使用了大约45分钟完成迁移，这个过程中原数据库状态一直是可用的，不会影响用户的使用（并且原数据库本身是多可用区部署，所以其快照阶段也不会影响主实例的IO）

最终我们看到Aurora集群及实例也处于了可用状态，如下图

这时，准备工作就完成了，我们便可以发出一个维护公告，我们将在指定的窗口期切换数据库的Endpoint。

这时我们也可以就一些集群参数和配置做一些调整，比如开启Performance Insights.

4.挂维护页面，停应用，检查数据库当前连接。

关于应用的部分就不再赘述了，当应用停止后，我们登录原PG，可以使用以下命令查询当前的连接情况。

SELECT * FROM pg_stat_activity;

建议确认没有应用连接后，等待约1分钟，再进行下一步操作。

5.提升Aurora集群。

选中Aurora集群后，点击Promote，如下图

点击后，复制会中断，虽然提示会在几分钟后完成提升，但是实际上通常会在几十秒内完成，事件中也会有Promote事件，不过事件出现的时间相对滞后。

6.更改应用中数据库的Endpoint，重新部署（或者重新启动），这样迁移就完成了，我们需要观察一段时间，看看数据库的运行情况，原有的数据库此时可以先停止，等一段时间后确认Aurora集群工作正常，便可以删除了。