AWS-将PostgreSQL独立实例迁移到Aurora（Amazon RDS）

 

在启动时工作需要快速更改。你开始了一个带有概念验证的新功能，然后是你希望它留下来的成功，并且必须让它保持稳定。对于我们在Storyline上已经有一年左右的独立PostgreSQL实例，情况并非如此。我们刚刚成长，不得不改变我们的基础设施。我们希望我们的数据库易于在云中扩展，可复制，容错，并且所有这些都没有任何管理上的麻烦。换句话说，我们需要迁移到Amazon Relational Database Service（RDS），此外，我们希望它是Aurora：为云构建的兼容PostgreSQL的关系数据库，它将高端商业数据库的性能和可用性与简单性相结合和开源数据库的成本效益。
拯救AWS数据库迁移服务（DMS）！我们独立的PostgreSQL服务器的复制配置是唯一需要做的事情......

                        It turned out to be a bit more complicated…

迁移背后的想法很简单：在RDS中创建Aurora集群，在DMS中创建数据库源和目标端点，以及启动数据库迁移任务。数据迁移任务将迁移源数据库中的所有数据，并将正在进行的更改复制到目标端点。您所要做的就是将Web服务器指向新的Aurora集群，并在源和目标端点完全同步后热重新加载Web服务器。然而，魔鬼在细节。
我花了大约一天的时间才找到正确的迁移路径。在我无休止地重试我们找出错误的时候，我们的登台服务器有几个上下循环。让我分享一下我的经验，而DMS将另外一百万行迁移到Aurora。

这是成功迁移的最重要部分：
1. 必须正确配置源数据库服务器才能进行复制
2. DMS不会将您的架构一对一地迁移，只留下所有索引，列默认值，存储过程等
3. 迁移后必须修复自动增量索引

令我困扰的另一件事是AWS VPC安全组。为简单起见，我0.0.0.0/0在迁移完成后立即设置了一个安全组，其入站和出站规则已更新为更安全的掩码。

VPC security group have gotten very loose

＃1让我们从源数据库配置开始
首先要做的事情是：源数据库必须接受远程连接并配置为即将进行的复制任务。我创建了一个repuser以超级用户角色和复制权限命名的新数据库用户：
sudo -u postgres createuser -U postgres repuser -P --replication --superuser

一旦做到这一点，你可以通过检查新的用户角色\du在PSQL控制台。
要允许该用户进行远程连接和复制，请将这两行添加到pg_hba.conf的最后sudo vi /etc/postgresql/9.5/main/pg_hba.conf：
# Amazon DMS to Aurora
host mydb_prod repuser 0.0.0.0/0 md5 # mydb_prod - source database
host replication repuser 0.0.0.0/0 md5

对于复制配置，在postgresql.conf中 设置以下参数和值sudo vi /etc/postgresql/9.5/main/posgresql.conf：
wal_level = logical
max_replication_slots = 5
max_wal_senders = 5
wal_sender_timeout = 0

...现在到Aurora集群的AWS控制台
好。我的源数据库（旧的生产数据库）已经建立并准备好让DMS将其数据和负载加载到Aurora云。让我们直接跳转到RDS部分并根据需要创建Aurora或集群的实例。没有什么好看的，只要按照说明操作。为完整性添加一些屏幕截图：

Amazon Aurora Engine

DB instance details with Multi A-Z deployment

这里有一个注释 - 此时我没有创建数据库，因为我稍后会手动加载我的模式。但这取决于你。您可以随时创建或删除数据库。
存储RDS用户名和密码以供以后参考，一旦您的RDS实例或群集准备就绪，请获取实例或群集的端点URL。应该像“rds-aurora-prod.kdfoe7d9ww9do.us-east-2.rds.amazonaws.com”。我们将需要它用于DMS目标端点。
... DMS中的复制实例，源和目标端点
好的！现在到AWS的DMS部分。这就是工作的目的地。这里要创建四个项目：
1. Replication instance - 云计算能力，用于处理数据迁移和持续复制。
2. Source endpoint - 源数据库的连接设置（这是我的生产数据库连接）
3. Target endpoint - 目标数据库的连接设置（这是我新创建的Aurora集群）
4. Task - 编制端点和复制实例以完成工作的过程

复制实例。通过dms.t2.medium实例迁移的15Gbs数据的经验是5小时。做出明智的选择…

dms.t2.medium took about 5 hours to migrate 15Gbs of data

Source endpoint 利用我们在第1部分中为“repuser”执行的配置。稍后您可以测试您的连接，以确保没有错误潜入。

Source endpoint reply on configuration of repuser in #1

Target endpoint 就像检查“选择RDS实例”复选框一样简单，并从下拉列表中选择新创建的极光RDS实例。

Target endpoint is simple: check Select RDS instance and choose RDS instance from drop down

DMS Task,是所有工作发生的地方。它负责将数据从源端点迁移到目标端点，缓存在初始数据传输期间可能发生的所有更改，并将缓存和持续更改应用于目标数据库。

DMS task is the heart of data migration

＃2 DMS不会将您的架构1转换为1，也不会转移索引！
在另一次“成功”迁移之后，我注意到Aurora中的列默认值与我在原始数据库中的列默认值不匹配。更重要的是，我的序列和指数都消失了！在这里我的解决方案 - 在任务设置中：
取消选中“在创建时启动任务”
设置“目标表准备模式”，以截断
设置“后，满负荷完整性停止任务”，以应用缓存更改之前停止。
（我将在启动DMS任务之前手动加载模式）

Target table preparation mode = Truncate AND Stop task after full load completeness = Stop Before

在这里，您需要自己动手，并使用您之前获得的凭据和端点在Aurora中创建架构。在Storyline，我们在后端运行Ruby on Rails，如果你也这样做，你可能想要接下来的3个步骤：
1. 使用Aurora端点和凭据更改config / database.yml
2. 运行bin/rails db:create - 在Aurora上创建数据库
3. 擦除bin/rails db:schema:load - 将索引加载到Aurora的模式

恕我直言：大多数框架我们的日子都有一些持久层包装器，特别是数据库。您应该能够使用他们提供的工具轻松切换数据库端点并加载架构或朗姆酒迁移。

由于我们已将DMS任务“目标准备模式”设置为Truncate，因此在DMS迁移后模式将保持不变，并且所有索引都将存在。但是，自动增量序列将被破坏，我将在“满载完成”动量后修复它。记住“完全加载完成后停止任务” = 在应用缓存更改之前停止？
＃3修复损坏的自动增量序列
大约5个小时后，我开始使用DMS任务将生产数据库迁移到Aurora，“完全加载”步骤已经完成，现在整个过程暂停，等待我修复自动增量索引。这是复制或重新创建数据库时的常见问题。

创建一个文件reset-seq.sql，其内容为：
SELECT 'SELECT SETVAL(' ||
       quote_literal(quote_ident(PGT.schemaname) || '.' || quote_ident(S.relname)) ||
       ', COALESCE(MAX(' ||quote_ident(C.attname)|| '), 1) ) FROM ' ||
       quote_ident(PGT.schemaname)|| '.'||quote_ident(T.relname)|| ';'
FROM pg_class AS S,
     pg_depend AS D,
     pg_class AS T,
     pg_attribute AS C,
     pg_tables AS PGT
WHERE S.relkind = 'S'
    AND S.oid = D.objid
    AND D.refobjid = T.oid
    AND D.refobjid = C.attrelid
    AND D.refobjsubid = C.attnum
    AND T.relname = PGT.tablename
ORDER BY S.relname;

使用以下命令在reset-seq.sql中执行查询：
psql -hAURORA_ENPOINT -UAURORA_USER -Atq -f reset-seq.sql -o temp.sql -dDATABASE_NAME

因此，temp.sql文件将包含索引重置查询。执行它：
psql -f temp.sql -hAURORA_ENPOINT -UAURORA_USER -dDATABASE_NAME

安全删除临时文件 rm temp.sql
此时，我的数据库已经准备好所有索引并且正常工作，我可以安全地恢复DMS迁移过程，这将应用缓存的更改以及正在运行的持续更改复制。

FINAL：更新Web服务器端点和热重启Web服务器
等待DMS任务完全同步。同步后，将Web服务器的config或ENV变量更新为指向Aurora RDS，然后热重启Web服务器。

如何知道Aurora何时与旧的生产数据库同步？Aurora不支持pg_last_xact_reply_timestamp()与复制相关的其他功能。AFAIK是了解主服务器和服务器之间延迟的唯一方法是Cloud Watch Metrics。您将寻找CDCLatencyTarget：

CDCLatencyTarget

而已。现在，您可以安全地关闭旧的生产PostgreSQL独立实例，并享受云中数据库的奢华。

这些命令在我去奥罗拉的旅途中非常有用。也可能对你有好处。
SELECT * FROM pg_replication_slots; # List replication slots

SELECT pg_drop_replication_slot('slot name'); # Close replication slot (they are not cleaned up automatically

pg_dump -hHOST_URL -UDATABASE_USER -dDATABASE_SCHEMA -F c -b -v -f production.dump

pg_restore -hHOST_URL --clean --no-acl --no-owner -dLOCAL_DATABASE_SCHEMA -v production.dump

 

转自：https://medium.com/@paveltyk/migrating-postgresql-standalone-instance-to-aurora-amazon-rds-3c038cfd2517

参考：

aws DMS : https://docs.amazonaws.cn/dms/latest/userguide/Welcome.html

aws RDS: https://docs.amazonaws.cn/AmazonRDS/latest/UserGuide/Welcome.html

aws Aurora: https://docs.amazonaws.cn/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html