背景

云上的RDS，给DBA带来了很多方便，但是也存在由于其自身的bug问题，导致影响到业务对于数据库的使用。本篇文章主要是分享一些采坑的过程，还有避免的方法。

一、升降级维护时间

随着业务的拓展，当使用的RDS实例出现资源不够时，需要对RDS实例进行升降级操作，此时，可以选择两种切换方式（切换过程均会有30秒内的闪断，需要进行重连）：
1. 在数据迁移结束之后进行切换
2. 在维护时间进行切换（维护时间可以由用户自己设定）

注意事项

若选择“在维护时间切换”，则可以选择应用低峰期，进行切换。
1. 偶然情况：
数据迁移结束后，若新的RDS实例或者当前实例有报错（报错信息为阿里云内部信息，不会展示给用户），那么需要阿里云运维人员进行干预。
此种情况下，切换会顺延至下一个运维时间
.
.
2. 联想 –选择“在数据迁移结束之后进行切换”
通过1中的偶然情况，即存在需要人为干预的报错。那么切换方式选择“ 在数据迁移结束之后进行切换 ”的时候，可能会出现很严重的情况：
1. 人为干预的时间不确定
2. 数据完全同步的时间不确定
由于可能会出现的以上的情况，均会导致在业务高峰期切换，后果可想而知。

所以，请选择“在维护时间进行切换！！！”

二、半同步复制

阿里云RDS的高可用版本，主库对应着一个备库（备库的日志、监控、报警等信息不会展示给客户），并且默认使用的是半同步复制，rpl_semi_sync_master_timeout默认为10秒，并且rpl_semi_sync_master_timeout不能直接修改（需要联系阿里云技术支持进行修改）。

业务影响

由于使用的是半同步复制，所以当出现 备库不可用 或者 主备间网络异常 的时候：
（此时半同步复制链路报错：Waiting for semi-sync ACK from slave）
1. 会出现业务的变更sql不能提交的情况！
2. 由于主备间的网络等监控和报错信息，不提供给用户，所以不能及时预警
3. 业务在sql执行超时时，通常会进行重试，会导致连接突增
4. 业务突增，全都在等待rpl_semi_sync_master_timeout超时，导致资源消耗增大，CPU使用率升高

紧急处理

在主库的连接数上涨时，收到报警。此时：
1. 查看连接情况，都在等待从库相应
2. 切换同步方式为：异步复制
处理结束后，正常，查看从库（从库为业务使用的只读实例，备库为HA使用）正常，所以排查为备库的原因。反馈给阿里云的技术支持人员，得到回复为：

日志上面的确记录了退化，但是当前记录的日志没有完整的记录这个退化的原因。能看到的是备库没有给返回ACK，所以物理机间的内网质量波动可能性更大。这里我也让研发团队尝试加下这里的关于退化的日志，后续能够更准确的判断

问题规避

对于出现的问题，阿里云表示没有打印出现问题的原因，只是给出了规避方案。

方案一：使用异步复制

根据异步复制的流程，主库上的提交不用等待备库的ACK，所以可以进行规避。
弊端：
1. 异步复制不等待从库响应即可提交，所以当主库宕机时，可能出现提交的事务未在备库上执行，切换后会出现数据不一致的情况

由于有时候会需要进行主备切换，并且不排除主库可能会宕机的情况，所以不予采用！！！

方案二：减小rpl_semi_sync_master_timeout

默认rpl_semi_sync_master_timeout=10秒，所以等待超时时间较长，若此时并发很高，可能会导致等待时间延长。所以缩短超时时间，这样可以在更短的时间内超时，自动使用异步复制进行同步。