阿里云的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的资源。