使用AWS DMS 升级Postgre 10到12

Postgre 是经常被用到的关系型数据库,本文将详细介绍在AWS云端升级Postgre版本的方案

为什么需要升级?

新的数据库版本有新的功能特性,AWS和开源团队对于每个特定的版本提供有限时间的技术支持,超过技术支持时间后,没有技术支持将会造成安全及系统风险,所以为了避免潜在的风险,需要在当前版本停止支持之前升级到比较新的版本.

每个版本对应的官方维护时间 PostgreSQL: Versioning Policy 

升级方案选择

升级方案主要分为两类, in place 和 out of place,顾名思义,升级原有数据库或者在新建的数据库上进行升级.

经过一番调研,整理出了以下几种升级的方式:

1.使用AWS DMS,升级到10.18 升级到12.7

优点

1.AWS官方提供的数据迁移工具,具有一定的稳定性

2.迁移方案对于读应用没有downtime

3.不修改原有数据库,容易回滚

缺点

1.需要修改所有连接到数据库的连接地址

2.aws 官方文档显示,不支持升级到最新的13.3版本

2.使用AWS postgre自带升级工具,将当前的10.18版本升级到13.3版本

优点

1.可以升级到最新的13.3版本

2.只需要简单的修改cloudformation或页面操作即可完成修改

缺点

1.需要一段时间的downtime,时间会随着数据库存储数据量的增大而变长

3.手动dump当前10.18版本的数据,restore到13.3最新版本

优点

对于读应用没有downtime

缺点

1.备份时间根据数据量增大

2.手动备份运维

3.需要修改数据库连接配置

因为当前需要升级的数据库还有线上用户正在使用,为了保证线上的用户还能够正常的访问,所以采用了第一种方式进行升级.

DMS数据流转图

DMS(database migration service): 数据迁移服务,是AWS提供的一个免费的帮助用户将数据库迁移上云的工具.

从图中可以看到,DMS包含了一个Replication instance, Replication task, source endpoint, Target endpoint

Source Endpoint用来连接源数据库

Target Endpoint用来连接目标数据库

Instance 用来执行具体的迁移任务

升级过程

1.创建一整套新版本的数据库的基础设施,更新新创建数据库的配置

可以使用cloudformation 或者页面操作完成即可,不在赘述.

2.更改数据库配置

 将 PostgreSQL 数据库作为AWS DMSsource - AWS Database Migration Service
将 PostgreSQL 数据库作为 AWS Database Migration Service 的目标 - AWS Database Migration Service

文档中详细列出了原数据库和目标数据库需要进行的配置,建议使用英文的文档,中文的文档大部分为机翻,而且实时性可能不高,不建议阅读.

根据上边的文档,总结了以下的流程

1)修改原始库的默认配置

• rds.logical_replication=1
• wal_sender_timeout=0
• shared_preload_libraries=pglogical

2)配置CDC(change data capture)

CDC保证了旧数据库的修改能够同步在新库中

创建新插件及验证插件是否创建成功

create extension pglogical;

select * FROM pg_catalog.pg_extension

创建copy slot

SELECT * FROM pg_create_logical_replication_slot('copy_slot', 'pglogical');  

创建copy node

SELECT pglogical.create_node(node_name := 'node', dsn := 'dsn_name');     

创建两个 copy set

select pglogical.create_replication_set('copy_slot', true, false, false, true);

select pglogical.create_replication_set('icopy_slot', false, true, true, false);                                  
 

3)手动dump原数据库的数据格式

经过验证,如果使用DMS自带的表结构同步功能会存在一些问题,所以需要手动的同步数据库的表结构

pg_dumpall -h hostname_of_db -g -U postgres -f db_roles.sql --no-role-password
pg_dump -h hostname_of_db  -n 'your_namespace' -U postgres -s your_schema > schema.sql

3.DMS相关配置

1)创建DMS instance

这里相当于创建了一个带有DMS迁移服务的EC2实例,在DMS页面上创建即可,创建的时候需要注意,能够访问到源数据库和目标数据库,否则后边的步骤中将会出现连接不到数据库的错误.

2)创建endpoint

需要对于源数据库和目标数据库分别创建一个endpoint.

3)创建task

创建task的步骤中,涉及到的配置项比较多,其中主要的配置项需要注意的有以下几点:

 "Target table preparation mode" 由于咱们上边手动导出了数据库结构,并且手动导入了新的数据库,这里选择Do nothing 即可.

"Premigration assessment"  开启验证,在Dev环境进行测试的时候,对于该选项打钩,会将当前数据表结构与新的数据库的兼容性进行比较,生成详细的结论放在S3中,这里需要配置S3相关的访问权限.由于Dev环境已经进行过响应的验证,生产环境中没有重复进行该验证.

 "Enable CloudWatch logs" 打开日志记录,建议打开,出现错误的时候,方便进行排查.

4.开启同步任务

配置完以上步骤之后,便可以开始执行任务,执行的过程中,在对应的task任务中会有每一张表执行的具体过程,实际使用的过程中,单表100GB的数据,大概需要10个小时左右能够同步完成.

5.数据验证

1) 检查所有表的行数是否一致

select count(*) from table_name ;

2) 为每张表手动设置SEQUENCE的值

SELECT setval('table_name_id_seq', coalesce(max(id), 0)) FROM table_name;

3) 检查数据库总大小

select pg_size_pretty(pg_database_size('database_name'));

4) 检查每张表的数据量大小

SELECT 
table_schema || '.' || table_name 
AS table_full_name, pg_size_pretty(pg_total_relation_size('"' ||table_schema || '"."' || table_name || '"')) AS size
FROM 
information_schema.tables where table_schema = 'public'
ORDER BY
    pg_total_relation_size('"' || table_schema || '"."' || table_name || '"')
DESC limit 1000;

5)检查表数量是否一致

select count(*) from information_schema.tables where table_schema = 'public';

5.服务迁移

将依赖当前数据库项目中所有数据库配置修改为新的数据库.

6.最终验证及资源清理

查看依赖数据库的上游的系统状态是否正常.

依次删除 DMS task, DMS endpoint, DMS instance, old DB, 删除old DB的时候需要进行备份,防止出现意外是能够进行回滚.