开发者学堂课程【企业运维训练营之数据库原理与实践课程 ：视频 -RDS 基础概念介绍（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1201/detail/18285
视频-RDS 基础概念介绍
三、RDS 数据库相关基本概念介绍
下面介绍一下的 RDS 实例的规格，包括共享规格、通用规格，还有独享规格，共享型只支持 SQL server 引擎。从图中可以看到每个实例，独享被分配到的内存和存储资源的。与同一物理机上的其他共享规格实例共享的 cpu 资源，所以说可能存在 cpu 竞争的关系，适用于对成本有要求，但是对稳定性要求较低，需要 SQL server 高可用保障业务的可用性的这种场景，可以用这种共享型。
在通用型上支持四种引擎，从图中也可以看到是分本地盘和云盘的，对于这种本地盘也存在 cpu 的一个竞争关系，然后云盘也存在 cpu 和内存的竞争关系的，此时需要强调云盘规格的这种实例，因为云盘是基于 AN ES 部署形态,基于的这种形态是在一台 ECS 上,ECS 本身其实是需要自己开下一部分内存的，所以说平常在今年六月份之前，在监控上在实例的内存使用率上是没有去刨除系统本身开销这一部分内存，所以说会导致有些客户看到内存使用率没有达到100%，可能会出现一些 OEM 的场景，然后在六月份，已经对 RDS 内存监控上已经做了相应的一个修正，能够及时感知到，想要强调的是在通用型上有资源复用的情况，可能会导致资源争抢，平时如果对业务稳定性要求高，不要采用这种共享型和通用型的这种实例。
在独享型上也是支持四种引擎的，是完全独享 cpu 和内存这样不会造成资源征用的竞争的关系，这种独享是用于对性能稳定性要求较高的这种场景。对于每一种架构，提供了多种规格，无论是基础版还是高可用版，集群版还是三节点版都提供了各种各样的规格，规格平常可能传统意义上更加关注于 cpu 和内存是几核几 G 的，或者说关注的再多一点，可能会关注到 IOPS 存储中。这里对于云盘的实例，想特别强调，除了所说的 IOPS 能力，还有一个 IO 带宽的一个限制，是 IO 带宽又和存储空间大小是相关的。会按照的存储的大小去计算IO带宽的大小，当 IO 可能存在瓶颈，所以说有可能一个是 IOPS 达到瓶颈了，或者是 IO 带宽达满了，这其实是一个木桶原理了。无论是这两种哪一种达满，都会导致实例是出现 IO 方面的一个瓶颈。平常需要留意一下，目前来说对外，在 IOPS 上，可以通过 IOPS 使用率上来观察。如果有些这时候怀疑可能是 IO 带宽达满，目前来说，在前端还没有展示相关的一个监控能力，如果怀疑,可以提交相应的工单来咨询帮您确认一下，这是关于 IO 带宽需要特别提到的。
介绍完了 RDS 规格是重点强调的是说独享型，是独占资源，这样能够保证稳定性要求。所以说在生产业务中尽量的用这种独享型的实例是比较好的。
介绍完规格，现在来介绍一下是网络。网络是分为经典网络和专用网络的。如图所见，经典网络采用的是三层隔离，所有的网络实例，其实是共用的一个基础网络，不同的用户之间的金融网络，其实网络上是通的。对RDS实例来说，只能通过依靠白名单和账号密码做安全防护。安全性上来说，其实可以明显的感觉到是相对是比较低的，所以目前来说，今年网络已经停止新购了，VPC 专业网络也不太支持从专业网络切换到经典网络，对经典网络的RDS实例，也建议升级到专业网络上面来。
VPC 网络是所谓的虚拟专业网络，是采用两层隔离的，相对经典网络而言，具有更高的安全性和灵活性。可以看到是不同的 VPC 之间其实都是相对隔离的一个环境，所以说可以根据不同的业务类型，按产品划分到不同的 VPC 网络，来保证网络上的安全性。
然后今天上完这两个网络类型，现在再介绍一下的 RDS 一个网络拓扑的一个情况，在 RDS 网络拓扑上，当一台 ecs部署的程序发起连接时。首先会通过 DNS 解析 RDS 的域名，域名会解析到 RDS 前端的 SLB 上，然后再转发给后端的 RDS 组实例。
或者如果 RDS 实例开通了读写分离功能会有相应的代理，有代理的情况下，ACP 会先转发给代理，再由代理转发给后端的 RDS 主库，或者说只读重库实现一个是读写分离功能。
同时还会有单可用区部署架构和多可用区部署架构，当购买可用区实例的时候，需要注意一点，ECS 和 SLB 和 RDS主库，这里面有可能会跨地域了，例如 ECS 在可用区 Y，然后 SLB 和 RDS 主库又在可用区 X，这时候其实就是跨机房了，跨机房会由于物理距离的增加可能会存在网络延迟增加的情况，一般来说是跨机房的时候，延迟三毫秒以内，都是比较正常的。这部分需要重点关注的就是跨城区访问的问题。
另外，关于 RDS 的域名，就是程序访问的时候，需要使用域名地址，不建议使用域名解析三层的 VIP 进行访问，因为实例变配，有可能会导致底层的 VIP 发生了变化，这时候如果用域名去访问，可能会出现访问连接不到的情况。所以说在生产上建议使用域名去访问，而且要保证应用上有一个自动重连的一个机制，比如 RDS 主库和存库，如果发生 HID 切换，这时候 SLB 会把重新解析请求转发给之前的存库，这时候之前的连接会断开，如果 ECS 上面部署的程序，如果不能自动重连，会导致业务影响时长被拉长，所以要使用域名连接，同时要保障程序具有自动重连的机制。
在生产中也观察到有些客户可能对域名在本地做了本地解析，这时候也是不行的，尽量不要去做本地解析，比如写在etc hosts 文件里面，可能会导致底层VIP变了之后，还是解析到不同的是域名上和不同的 IP 上，会导致问题。这是关于网络的这块的一个介绍。
现在来介绍一下存储，云 RDS 数据库，存储也是经历了从本地 SSD 盘到 SSD 云盘到 ESSD 云盘的这么一个发展历程。ESSD 云盘，又经历了PL1，PL2 ,PL3的迭代。PL1，PL2 ,PL3，数字越大，相应的性能也越好，在未来也会有ESSD 云盘 PL-X 这种系列，这个和本地的IO延迟基本上可以持平，对于未来这块是有规划的。
目前来说，SSD云其实已经在今年下半年，在推动下线的过程中，如果还有 SSD 云盘的实例，建议主动升级到 ESSD云盘。因为 SSD 盘其实不支持这种在线扩容，所以说升级到 ESSD 硬盘也是有好处的。
然后再介绍一下本地 SSD 盘，其实就是本地磁盘和数据库引擎，MY SQL 等是部署在同一个节点在同一台主机上面，在所有的存储类型中，IO 延迟是最低的，性能是最好的。当做变配存储的时候，需要考虑当资源不足时，需要发生跨机迁移。跨机迁移的迁移时间和存储大小相关，存储使用量越大，那么跨机迁移时间越长。如果本地有资源变配比较快。所以本地 SSD 盘变配，也并非变配时间很长，需要评估本机是不是有足够的资源，如果没有资源，可能会发生跨机变配，时间可能会比较长了。如果在变配的过程中，不知道此次变配是本机变配还是跨机变配，可以提供相应的工单咨询，帮您确认。
无论是 SSD 云盘还是 ESSD 云盘，都采用了分布式存储架构的弹性快存储设备，实现了计算节点和存储分离的架构，但是会导致 IO 延迟，相对于本地盘来说有比较多的增加。在 ESS 增强云盘上，相比较本地云盘本地延迟低，但是对于 RDS MYSQL 和 MariaDB TX，可以支持在线升级秒级扩容方案，对业务上是无感的，对于 RDS SQL Server，也是可以小到分钟级的。所以说，这是采用 ESSD 云盘的一个独到的优势。另外，用到几T存储空间大小的时候，比如需要去增加一个只读实例，这时候，如果是本地盘去增加一个只读实例也是需要拷贝存量数据，然后再追增量的binlog，此时相对而言也是比较久的。而 在 ESSD 云盘上，采用云盘的方式，去增加尺度节点可能也只需半个小时，无论是2T还是4T，时间相对于本地盘都会短很多。
在备份上，ESSD 云盘还是云盘，只能快照备份，快照备份是无法去下载备份文件，例如做本地恢复是没办法的，这也是其局限性。物理备份的好处是可以去下载物理备份文件，做本地恢复。
四、云 RDS 数据库安全
数据库存储一个公司的核心数据，如果数据库安全做不好，数据库存在潜在的风险，接下来会把安全方面把分为事前防御和事后审计这两个方面来讲。
在事前防御这方面，提供数据库账号密码的防护，RDS 数据库上的账号，又分为高权账号和普通账号。高权账号，只能通过控制台或者 API 方式创建，并且高权账号并不是普通自建数据库上所理解的最高权限。比如在 MY SQL 上，并不等同于 root local host，或者说在 SQL SERVER 并不等于 SA 这种权限，在云上数据库高权掌控只是可以断开其任意非内置账号的数据库链接或者说通过它可以创建普通账号。但是在业务管控上，建议把高权账号只授予某一个组去管理，并不要让更多的人去使用高权账号。业务上不建议去使用高权账号，而是去创建一个普通的账号，然后合理授权，按照最小化授权的方式来进行使用。经常提到的所谓的跑路，就是由于账号权限授权过大导致的。
白名单安全组，定义了哪些 IP 或者安全主类的 ECS 来访问的 RDS，这也所谓定义的访问源，也是很重要的。需要避免白名单和安全组开放过大，导致变相的 RDS 过多的暴露客户端面前，造成安全隐患。
比如在生产不建议把白名单设置成0.0.0.0/0，虽然访问是便捷了，但是从安全性的角度来说，其实是不建议的，会造成访问没有限制的情况。
SSL 密连接，是应用程序通过 SSL 加密链接来访问 RDS 数据库。有时会遇到一些客户场景被黑了，此时可能会通过抓包的形式分析程序中链接数据库的账号，然后分析数据库发的一些 SQL，同时通过一些特征提取，数据库账号会被暴力破解，或者说通过 SQL 注入方式危害数据库的安全，通过 SSL 加密链接，可以保证所谓的程序到 RDS 之间的链路是安全的，但是这里要注意强调：开通 SSL 加密链接的时候，也是会造成是在 RDS 上访问链路的开销有所增加。
在存储加密上，对云盘的实例可以使用 SSD 云盘的存储加密。对于本地盘的实例，可以开启 TDE 来实现表级别的加密。存储加密可以保证数据备份即使泄露别人也无法解密，可以保护数据安全。
最后，在平常的管理云上数据库资源或者其它资源时，因为在阿里云账号上分为主账号和子账号，主账号拥有全部账号的权限，首先要保护好主账号，在子账号上，可以利用 RAM 授权，让特定的人管理特定的资源。比如对于 DBA 团队，可以创建子账号，授予管理 RDS 的权限，对于业务运维团队，授予 ECS 等资源的权限。当然这里也要管控好，是否只要只读权限，还是说可以具有删除实例，或者说创建实例的权限，都可以去具体定义 RAM 授权来完成相应的管控。
在事后审计方面，提供 SQL 洞察日志的审计，还有云监控告警，控制台操作审计和日志管理的能力。在 SQL 洞察的方面，所有的操作记录尤其对于需要追溯这些情况是特别有用的，这里无论执行成功还是失败的 SQL 都可以记录，例如SQ L等待超时了，也可以把超时执行失败的 SQL 给记录下来。但是这里需要强调一点，是当 RDS 实例本身，如果出现了这种 OM，或者说踩到 bug 发生 crash 的时候，MY SQL 进程异常退出，这时候 SQL 还来不及去写入审计日志时，这样的 SQL 不会被记录的。也是经常有些客户提问，使用 OM，为什么相应的 SQL 没有被记录到的这种场景。
云监控告警，是当出现 cpu 达满，或者发生了 HA 等，可以收到相关的告警信息来及时的去介入了解相关情况。控制台操作审计，其实是审计在控制台上操作记录，是针对主账号子账号，在控制台的操作相关信息。这里需要留意，当去开通子账号的时候，是否给其分配一个 AK，如果分配了 AK 就需要去合理管控好子账号。有时会遇到一些客户，可能用 AK来做一些自动化的一些管理工作，可能会把相关的代码上传，这时候可能会被别有用心的人扫描到代码里面使用的 AK，导致 AK 泄露之后出现实例被删的情况。
在日志管理方面，提供的错误日志，慢日志，高可用主备份切换日志，这些也是作为一个辅助的能够了解实际运行情况日志，来协助管理数据库。
五、云 RDS 数据库整体架构概览
上图中的代理可选其实分两条线，第一条线是应用程序来访问，是通过域名来访问，在刚才的网络拓朴已经讲过。另外一条线路，是通过 WEB 控制台或者 API 接口来发送相应的一些指令给数据库完成相关的操作，这里面是把请求发送给后端的消息中心，消息中心再把对应的请求发送给对应的模块，再有对应的模块把相关的信息获取到之后再反馈给客户端-调用方。
例如要去访问一个慢日志，通过控制台查看慢日志，或者说通过 API 查看慢日志，把 API 请求发送给消息中心之后，会从日志系统里面去捞取相关的时间段的日志信息，然后返回给客户端。此时需要重点提醒的是，关于HA控制系统。HA 探测系统，会定期的去探测后端部署在节点上实例的可用性，在连续多次探测都不可达或者不可访问的时候，会下发一个相应的任务完成一个 HA 的切换。像在 RDS mysql 上，在 MYSQL 库下面有个 HA health 切口表里面会定期的，一般会15秒往表里面去写入一条数据，探测数据库的读写性是不是可写的，如果不可写，会发生相应切换。这里面有一种场景是节点，比如物理主机宕机了，或者说有可能是提交了一个大事务导致在刷盘的时候，导致HA探测写的这一条语句无法落盘，这时候也是会影响HA探测的，所以说一般在生产业务中也要避免这种大事务的操作。
在线迁移系统，也可以强调一下，比如 DBNodeA 和 DBNodeB 是两个一主一备的实例，当备节点不可用的时候，在线迁移系统会定期检测每个实例可用性，当发现一个不可用，会发起一个在线迁移，例如一个节点主机宕机了，那么会从节点 A 迁移到节点 B 上来，想要始终保证所谓的高可用系统，都要有一主一备的这两个实例来提供高可用的能力，这就是在线迁移系统。在线迁移，去做变配的时候，也是通过系统去做相应的动作。
备份系统，是按照每个实例设置的一个备份频率，定期的去备份相应的实例数据，一般来说无论是快照备份还是物理备份，都是首先选择备节点来做备份，当然备节点由于大事务导致主从延迟很大的时候，会去选择主节点来完成相关的备份。
另外需要注意的是，例如 RDS MYSQL中，当去选择相应的备份时间时，在备份时间段可能是业务低峰期，而一般来说一些运维操作，例如增加表制度这种也会放在这种业务低峰期去做执行，此时需要注意，有可能在执行 DDL 变更这种操作时，会导致备份失败。DDL 变更做完的时候如果发现备份失败了，也可以主动尝试发起临时备份任务去保证当天的有备份文件，当后续需要去做快速恢复的时候，可以去寻找最近的备份，在备份最近的时间点备份会有一个最近的备份文件。通过这一整套系统，可以保证 rds 数据库的稳定性和安全性。
