开发者学堂课程【企业运维训练营之数据库原理与实践课程 ：视频 -RDS 基础概念介绍（四）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1201/detail/18285
视频-RDS 基础概念介绍
七、课程回顾
本次训练的第一课课程就介绍到这里，现在做一下课程回顾。
1. 本次训练营的课程内容，目标和要求，在刚开始时候做了简单的介绍。
2. 了解云 RDS 数据库的这些特点，知道 RDS 数据库是一个关系型数据库。主要包含了 mysql、 postgresql 、sqlserver、 mariadb。在深度自研上，是对 RDSMySQL 和 RDS POSTGRESQL 做了深入研究的，内部把称为 ALISQL 和 ALIPG。会相应的发布一些 release note 的相关信息，可以在官方文档上做相应的关注。同时介绍了其技术特点，特别是有相应的全套解决方案。
3. 在产品系列上，有基础版，高级版，集群版和三节点企业版，在生产中不建议使用基础版，建议高可用、集群版和三节点企业版。如果在金融行业，数据要求比较高，可以使用三节点企业版。
4. 在基本概念上介绍了规格，网络和存储方面。
（1）规格有共享型、通用型和独享独占型。不同的类型支持的引擎也是不同的，共享型只支持 sqlserver，通用型支持四种引擎，独享也支持四种引擎。但是共享型和通用型可能会出现 cpu 争抢的情况，所以在核心业务系统上不建议使用这两种规格。
（2）在网络上分经典网络，专业网络。目前经典网络，已经处于下线的状态。专业网络，能够更好地保护的网络安全性，在业务上也可以按照不同的业务去合理拆分划分到不同的网络，做网络层隔离。网络拓朴上，业务访问 RDS 数据库的时候，是使用域名进行访问，访问会首先经过 SSD 再转发给后端。
（3）存储，有本地 SSD 盘和 SSD 云盘、ESSD 盘。SSD 云盘处于下线的过程。本地 SSD 盘具有物理备份 IO 延迟低的特性，但是当遇到需要跨机变配的时候可能时间比较长。ESSD云盘，很好的解决了本地盘弊端，但是相比较本地盘，可能 ESSD 盘 IO 延迟相对而言要长一点，后面未来规划 PL-X 系列可以很好解决这个问题，这一类产品能够满足在线迁移，在线扩容，增加只读时长比较短的特点。
5. 安全防护，按照事前防御和事后审计做介绍。事前防御，比如说白名单，账号密码，SSL 加密链接，还有对存储，TD 加密等都有相应的介绍。如果在平常使用中把事前防御做好，基本上能够杜绝绝大多数的意外情况。比如阿里云的子账号如果控制的合理，那么不存在出现AK，哪怕可能泄露，但是只有只读也无法去删除相应实例。事后审计重点是关于 SQL 洞察，可以进入操作实例的相关信息。但有一点补充的是，当实例发生异常进程异常退出，入crush，OM 这种异常退出的时候，那么相关的SQL是不能被记录到的。
6. RDS 数据库的整体架构概念，分成两个模型，一个是用业务通过 RDS 域名访问，在网络拓扑这做了相应的介绍。另外是通过控制台或者 API 访问链路。每个其实在 WEB 控制台，也是通过API请求定位 API 接口去访问相应系统。系统要注意的是有个 HA 探测系统，它是会定期的往系统表里面去写入相关数据来探测实例的可读写性，如果发生不可读写，物理节点宕机，或者说网络不可达了，那么可能在多次探测不可达或者不可用之后会发生相应的 HA 切换，会把 HA 相应的信息通知客户。当然如果是提前发现风险点，可能做一些主动 HA 切换，那么在刚才控制台讲解中，在事件那里是可以关注到相应的通知信息可以提前规划好相应的切换时间，避免对业务上带来的影响。
7. RDS 控制台介绍完了不再做进一步的介绍。
八、答疑
1.TDE 是表级别加密吗?
开启 TDE 加密，是可以细化到表级别的，但是这里面需要注意的是开启 TDE 之后动作是不可逆的，所以说如果一旦开启，想关闭目前来说是不行的。同时 TDE 加密是针对本地 SSD 盘的。然后云盘类型的 SSD 盘，ESSD 盘，是通过云盘来加密实践的。
2.大事务导致 HA 探测无法落盘会有什么影响？
其实是经常碰到一些客户做大事务的操作，对一个表可能一次性批量更新几百万的数据，或者一次性删除了几百万或者上千万的数据，有的可能更夸张删除上亿条数据。
当去落 binlog 的时候，可能之前提交的事务一直还在落 binlog，导致后续 ha 探测的相应行为它的 binlog 是无法落盘的，无法落盘会导致认为实例这时候是无法响应 ha 探测请求的，最终连续多次如果去探测都无法写入，那么会主动发起一次 ha 切换动作，对业务会造成连接散乱的影响。如果业务上又没有自动重连机制，这时候会导致业务上可能会出现较长时间的不可用。所以说之前提到，生产上一定要保证业务有重连机制。
3. 备份失败会有通知么？
备份失败，目前来说还没有相应的通知机制。可能后续也会去逐步完善这一块的功能，会尽量把备份失败的信息也做相应的透传。让客户能够提前感知到相应备份失败的情况，及时做相应的补救措施。
4. 内核版本升级会停止服务吗？
对于高可用版本，小版本的升级其实是一个滚动升级的过程，会先升级备实例，当备实例升级完之后，再去做一个ha切换，所以说影响时长大概在30秒内。切换完之后再对新的备节点，做相应的升级动作。所以说整体的影响时间是在ha切换的这一步有影响。当然也是建议做内核小版本升级的时候，可以把自己主动的指定一个切换时间。
5. Ha 时会主动向客户端发送 TCP 报文吗？
ha 动作本身是并不会去给客户端发送什么消息的。HA 过程其实首先是主备没有延迟的情况下，才能够去做相应的切换动作。如果高可用备库出现了延迟的情况，例如当做了一个大事务备节点出现延迟，这时候哪怕主节点不可用了，去探测到如果主备有延迟，其实也是不会去 ha 的。
当如果没有延迟真正去发送 ha，也是只会把请求从 a节点切换到的 b 节点，在过程中会断开 a 节点相应链接的过程，是不会给客户端主动发送相关的请求。这时候是客户端怎么去感知？是需要去捕获相应的连接异常之后做连接的重试机制。
6. 节点故障迁移是无感的吧？
目前对 RDS 来说，还是有感的过程。像刚才说到的，做大事务夯掉的情况下，此时 HA 去探测如果不可用，无法响应请求，那么从 a 节点切到 B 节点的时候会断开已有的链接，断开的过程其实对业务上是会有相应报错体现的，在相应的控制台会有 ha 切换日志，可以将应用的报错日志和 ha 切换日志去做比对，看一下报错是不是在ha切换时间之内，如果是那和这个是有关的。
7. 补充
关于大事务的部分，因为大事务很可能会导致备节点延迟，也有可能直接导致主节点夯掉。所以平常运维使用过程中一定要注意对大事务的管控。执行任何操作之前，一定要去评估相应的影响行数，如果要去做批量删除的操作，最好是一次性删除500或者1000条，不建议一次性删除太多，每次删除最好中间还是能够 SLEEP 一下，这样保证不要引起是节点夯掉或者说备库延迟太大。
在第三节课的时候，会介绍 DMS 数据管理工具。DMS 其实是有一个无所表结构变更的功能。内部原理其实是通过创建一个临时表，插入临时表，然后最后去追相应的 binlog。当延迟完全同步的时候会做 rename 的操作，期间也去主动的监测备库的延迟。
8. 大事务主节点挂掉，备节点是不会被 ha 选为主节点的对吧？这场景怎么修复？
通常情况下如果做大事务，导致了备库延迟的情况，那么这时候是没办法ha的，只能把是主节点给起修复启动起来这。
9. RDS 有 CDC 功能吗？
像 sqlserve 有一些特定的版本，比如标准版，集群版，在不同的版本上是有所谓的这种限制。有的版本是支持这种CDC 功能的。这里面是可以去查看相关的官方文档，有对相应的功能上做一些描述。这里面提到了 CDC，但是平常客户可能会用 DTS 来做数据订阅的功能，来做相应的消费日志的功能。
10. 可用区迁移
可用区迁移有时候可能会发起变配动作，可能当前实例所在的物理主机上已经没有足够的资源，或者说哪怕放大一点在可用区下面都没有相应的足够的资源完成变配的动作。这时候一般是通过两种情况，一种情况是可能提交相应的工单，然后到资源的同学评估，看一下有没有扩资源的能力，如果扩不了，可能会发起可用区的牵引，此时一种可能是 RDS 实例本身规格类型支持直接控制台上点一个可用区迁移的动作。另外一种可能是有些版本不支持这种可用区迁移这时候怎么办？那么也可以通过购买，在需要的可用区下购买一个新的，然后使用 DTS 工具去迁移到新实例上，但是这对于整体方案上来讲是比较是麻烦一点的，毕竟还涉及到配置 GTS 任务，还可能要去手动创建一些账号，因为目前 DTS 是不迁移账号信息的，所以说这里可能会需要额外带来动作。
11. RDS 选型
对于 RDS 选型，除了刚才提到的规格上，有共享型，通用型等。很多客户可能由于之前是对这种规格不太了解，选规格的时候只是去看价格，没有特别考虑到不同的规格上形态是怎样的，导致会出现问题。比如选通用型的规格，可能后续会受到资源竞争带来的业务影响。业务高峰期，突然出现一条平台执行不慢的一个 sql 突然执行比较慢，可能就是和规格有关系。此时可能会给客户合理建议，让客户是主动升级一下，比如从通用型升级到独享型来解决相关的问题。
在存储这一块也是需要去考虑的，目前来说是建议如果 ESSD 盘能够满足需求尽量考虑 ESSD 盘，毕竟遇到增加只读节点，或者说变配分离行为的时候，因为它是计算存储分离的架构，无论是扩计算资源，还是存储资源，这种扩资源的动作本身相对本地来说是快很多的。特别是如果存储使用量比较大，达到T级别，这时候可能去做扩容动作，在本地盘上会花几个小时，动作本身是没办法去做一个加速动作的，所以说前期的选型来说是特别重要的。
当然，选型也是建议去提前要做好压测，因为之前也讲到本地盘 IO 延迟会比较低一点，而 essd 盘相对来说会高一点。如果提前去压测知道业务的承载能力的情况下，可以通过去评估看更适合本地盘还是 ESSD 盘。
