阿里云的rds的几个问题的探究

1. 阿里云的pg一键上云,其实是调用了pg_basebackup,这个功能不仅仅可以用在一键上云上,还能用在rds pg到rds pg的小版本升级上。

2. 阿里云的pg大版本升级过程:
(一)准备阶段:
2.1 界面发起大版本升级;
2.2 原实例snapshot(注,需要打开秒级备份功能,不然的话,非基于存储快照的pg_basebackup备份时间会比较长)用于产生目标实例master,业务无影响,这个步骤大约耗时1秒;
2.3 利用快照生产生产实例,业务无影响,这个步骤大约耗时6~9分钟;
2.4 以老版本形态,拉起目标实例Master,检查源端实例master到目标端实例master的同步状态;

(二)割接阶段:
2.5 源端实例设置成Read only,业务影响开始,这个步骤大约耗时2秒;
2.6 目标端实例matser promote成主库,业务影响继续,这个步骤大约5秒;
2.7 目标实例master pg_upgrade以link方式升级,业务影响继续,这个步骤大约6秒;
2.8 DNS切换,业务影响继续,这个步骤大约60秒,切换DNS后业务影响结束;

(三)后续阶段:
2.9 kill session,在源端,每分钟kill一次,一共kill 3次;
2.10 目标库收集统计信息;
2.11 界面显示升级完毕;(源端实例会以ReadOnly形态一直存在,除非手动发起删除)

3. 最近aws闹得沸沸扬扬的pg的版本升级,把之前各个历史版本的pg都下线了,要强制升级到一个新版本,是因为log_fdw的安全漏洞问题(https://blog.lightspin.io/aws-rds-critical-security-vulnerability)
这个漏洞关键步骤是
(1). create extension log_fdw
(2). ALTER FOREIGN DATA WRAPPER log_fdw NO VALIDATOR;
这样就不会去校验log_fdw的读取外部文件的路径了。因此可以去读取 几乎所有文件的路径的文件了
从postgres的配置文件:/rdsdbdata/config/postgresql.conf
到credentials的文件:/rdsdbdata/config/grover_volume.conf
再看到credentials的文件里面的内容是指向另外的一个文件:/tmp/csd-grover-credentials.json
这个文件里面就有aws内部调用的STS凭证了,aksk。
这个风险虽然很高,但是可控,因为create extension需要rds_superuser的权限。
而这个问题,阿里云不存在,因此阿里云禁止了rds_superuser 去alter log_fdw NO VALIDATOR的操作。

4. 阿里云sqlserver 扩磁盘,需要切换,影响业务的原因:
4.1. 原架构有partner_A和partner_B做mirror,来提供高可用,在partner_A为Principal server遇到硬件故障的情况下,会auto failover成mirror server。

(一)准备阶段:
4.2. 开始发起扩容请求。
4.3. 阿里云内部新建立partner_A的新镜像库(Partner_C),存储大小为需要扩容的目标大小。当前为Partner_A的mirror server,将来为新的Principal server。
4.4. 阿里云内部新建立partner_A的另外一个新镜像库(Partner_D),存储大小为需要扩容的目标大小。当前为Partner_A的mirror server,作为将来Partner_C的mirror server。
4.5. 待Partner_A和Partner_C和Partner_D 完成同步,数据同步没有lag。

(二)切换阶段:
4.6. 在维护窗口到来时,将Parneter_A和Partner_C进行切换。此时Partner_C变成Principal server,Partner_A是作为partner_C的mirror server。操作对外部客户不可见。
4.7. 修改SLB的连接指向,从Partner_A到指向Partner_C
4.8. kill掉在Partner_A上残留的连接。

(三)后续阶段:
4.9. 下线回收partner_A和partner_B的资源。

相关文章

发表回复

您的电子邮箱地址不会被公开。

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据