1 云数据库回答什么问题：托管责任边界
订单已经写进数据库，应用服务器却坏了，换台机器通常还能继续服务；数据库磁盘坏了，若没有可靠副本和可恢复备份，业务记录可能随之消失。S22 已经介绍表、事务、索引、连接和备份，本课接着回答部署问题：这些能力由谁持续维护，应用怎样连接，出故障以后怎样恢复。云数据库不是另一套 SQL，而是把数据库引擎及其运行环境的一部分运维工作交给平台。
AWS RDS、华为云 RDS 等服务都可作为托管关系型数据库的例子。具体引擎、版本和服务等级各异，但判断方法相同：逐项看责任边界。平台通常负责底层主机、磁盘故障处置、受支持版本的补丁编排、备份管道和服务事件通知；用户负责数据模型、SQL、应用事务、账号权限、容量判断以及恢复后的业务验收。“平台有自动备份”不等于“平台知道哪笔订单才正确”。
对照自建更容易看清。数据库运行在自己维护的云主机上时，操作系统补丁谁打，打完是否重启，磁盘满了谁扩容，备份任务失败谁收到告警，都需要团队安排。托管以后，这些动作中的一部分成为产品能力，但维护窗口仍要选择，版本升级兼容性仍要验证，告警接收人仍要配置。不要把“有人执行补丁”误读成“补丁对业务绝无影响”。
假设团队只有 2 名后端工程师，业务需要全天保存订单。自建方案不能只计算 1 台虚拟机的价格，还要计入值守、备份存放、恢复工具和演练时间。托管方案的价值在于减少重复维护，让团队把精力投入数据正确性；它并不保证任意 SQL 都快，也不会自动修复应用重复扣款。选型时要比较完整责任和可验证能力，而不是只比较同样核数的月费。
可以把交付清单分成平台证据与应用证据。平台证据包括支持的引擎版本、备份保留配置、高可用方式和事件记录；应用证据包括连接池配置、账号用途、幂等键以及恢复校验结果。任何无法明确归属的项目都值得补上负责人。例如备份任务由平台执行，而“恢复出的订单总额是否与支付记录相符”必须由业务团队确认。
2 网络放置：私网访问、安全组与域名入口
数据库应放在 VPC 私网中，由应用通过私网访问。C9、C10、C11 建立的网络与访问控制直觉在这里继续适用：用户请求先到入口层，再到应用，最后才到数据库。C12 已经收束的入口层承担公网流量接入，数据库不应再次成为面向互联网的入口。开发者临时操作也应走受控运维通道，而不是为了方便给数据库长期开放公网地址。
假设应用属于安全组 app-sg，数据库属于 db-sg。数据库入站规则只允许 app-sg 访问所需端口，例如某个 MySQL 兼容实例的 3306。这里允许的是符合平台规则语义的应用网卡来源，不是“知道账号密码的人”。还需核对路由、子网网络控制及应用出站规则；安全组允许不会替你补齐错误路由。若服务不支持引用源安全组，再按其能力使用明确的私网来源范围，并记录维护方式。
应用连接串应使用服务提供的数据库域名。域名背后可能映射当前主库地址，切换后由平台更新；把解析出的 IP 固定到配置中，就绕开了这层间接关系。服务域名也不意味着旧连接会自动搬家：既有 TCP 连接仍可能失效，应用必须关闭坏连接、重新解析并建立连接。DNS 缓存时长和客户端行为要纳入验证，不能只在控制台看到新主库就宣布恢复。
私网解决可达范围，TLS 解决传输保护和服务端身份校验，数据库账号解决进入引擎后的权限，它们分别承担不同责任。连接时按服务要求启用 TLS，验证证书链与主机名；不要为了排障永久关闭校验。可以按产品支持情况用 IAM 鉴权连库，账号与权限细节留到 C15。静态加密及 CMEK 的选择参照 C6、C42，本课只记录需求和配置证据。
最小连通性验收应从真实应用运行位置执行：确认域名解析结果属于预期私网路径，再确认端口可达，最后完成 TLS 和数据库登录。运维电脑能够连接，不能证明应用容器能够连接；同样，端口能通也不能证明账号有权访问目标库。按层拆开证据，可以避免把所有“连接失败”都归到密码错误。
3 高可用：主备、切换与应用重试
高可用部署常把主库和备用节点放在同一区域的不同可用区。主库处理业务写入，备用节点接收复制数据；平台检测主库异常后，按服务机制将备用节点提升为主库，并调整服务入口。不同服务也可能采用共享存储或其他架构，因此应查清实际故障范围和复制语义，不能只凭“多 AZ”标签推导所有保证。
从应用视角看，切换中会经历连接断开、请求超时和短暂无法建连。RTO 是恢复服务所需时间的目标，RPO 是允许损失的数据时间跨度，两者回答不同问题。课堂可以用切换持续 30–120 秒作为观察窗口的教学区间，但这不是某朵云的 SLA，也不是本课实测结果。实际恢复还包括检测、提升、入口更新，以及应用重新连接的时间。
例如教学时间线设定 10:00:00 主库失联，10:00:20 平台开始提升备用节点，10:00:50 入口指向新主库，10:01:05 应用恢复稳定写入。数据库入口恢复用了 50 秒，应用恢复用了 65 秒。若团队只观察控制台事件，就漏掉了客户端多花的 15 秒；验收时应同时记录平台事件和应用成功率，明确恢复是从哪个时刻到哪个时刻。
应用需要带退避与抖动的有限重试，连接池需要识别失效连接并补建。假设应用把请求总等待预算设成 8 秒，而故障窗口持续 65 秒，那么部分请求会失败，这是预期内的降级结果。不能为追求“自动恢复”让所有请求无限等待，否则线程、连接与上游队列会一起堆积。应让用户得到明确结果，并允许之后查询订单状态或重试业务操作。
尤其要区分连接重试与业务写入重试。应用发送创建订单后连接断了，可能是事务尚未提交，也可能是已提交但响应没有返回。直接再插入会生成重复订单；可使用同一业务请求号和唯一约束，使重复提交返回已有结果。涉及支付时还要核对外部状态。重连只能恢复通信，幂等设计才能处理提交结果不确定的问题。
切换也不等于同步复制，更不自动等于零丢数。若备用节点使用异步复制，主库确认的最近写入可能尚未到达备用节点。即使采用同步机制，也需核对产品的确认条件及故障假设。讨论可靠性时，应同时写出复制模式、预期 RTO、可接受 RPO 和应用恢复方式，避免只写“高可用”就结束设计。
4 备份与恢复：自动快照、PITR 与 RPO
高可用处理节点不可用，备份处理需要找回过去数据的问题。误删语句通常会通过复制到达备用节点，因此备用节点健康不代表还能找回删除前的订单。自动备份通常包含周期性的基础备份或快照；支持 PITR 的服务还保留连续日志，恢复时先加载可用基础备份，再重放日志到选定时间点。平台如何实现可能不同，用户需要确认的是可恢复范围与限制。
备份保留 7 天意味着历史材料按策略保留，并不等于 RPO 是 7 天。若只有每天 02:00 的快照，故障发生在当天 17:00，最近快照距离故障已有 15 小时；若存在完整日志，且最新可恢复时间为 16:58，则相对 17:00 的实际恢复缺口为 2 分钟。这里的日志可用时刻只是算例，不能据此推导任何服务固定有 2 分钟 RPO。
RPO 目标必须通过备份频率、日志完整性与日志上传时效来支撑。PITR 页面通常会显示最早和最晚可恢复时间，选择恢复点应以该范围为准。保留期延长可以让更早的误删仍有机会恢复，却不能自动缩短最新日志的落后时间。日志出现缺口时，也不能简单把缺口之后的时间都视为可恢复，需要依据服务实际给出的连续可恢复区间判断。
演练必须真正恢复到新实例，而不只是检查“备份成功”。例如 14:20 发现误删，确定误删事务提交于 14:17:30，就应选择其之前且处于可恢复范围内的时间点。若选 14:18，删除可能已经被重放；若随意选 14:00，又会少掉更多正常订单。恢复完成后先校验订单编号、明细、金额和状态，再决定提取数据还是安排整体切换，不能直接把旧副本覆盖到生产。
恢复耗时也要计入计划。假设恢复任务运行 25 分钟，业务核对再用 15 分钟，则数据找回至少需要 40 分钟，不能把“可恢复到 10 分钟前”理解成“10 分钟内恢复完”。记录所选时间点、时区、任务编号、实例就绪时刻及校验结论，才能重复演练并比较变化。数据量增长后，过去的小库恢复耗时也未必仍然成立。
删除保护用于降低误删实例的风险，备份保留和误删恢复窗口则决定删后还有哪些补救路径。它们通常是不同配置，且释放实例时的备份处理规则可能不同。上线前应确认最终备份、自动备份是否随实例释放而删除，以及谁负责审批释放。不能用删除保护代替备份，也不能认为开启 PITR 后可以无条件撤销任何删除动作。
5 规格、存储与参数：容量从哪来
数据库容量至少要分开看计算、内存、存储容量和存储性能。CPU 影响并发计算能力，内存影响缓存与会话开销，磁盘空间决定能放多少数据，IOPS 与吞吐约束数据读写速度。很多托管产品允许计算和存储分别扩展，但具体档位、重启要求、在线调整限制及存储性能绑定关系各异。选型时不能把“还有空闲空间”当作“磁盘性能足够”。
先估连接数，再选规格，比先买最大规格更有依据。假设应用当前有 6 个实例，每个连接池上限为 20，就可能占用 120 个连接；扩容到 12 个实例后，池上限总和变成 240。若再为后台任务和运维预留 30 个连接，连接预算就是 270。需结合引擎限制、规格限制和稳定负载测试确认余量，不能只查看当前空闲时的连接数。
max_connections 只是允许连接的上限，不会凭空增加处理能力。每条连接及其活动查询都可能消耗内存和调度资源。把上限从 200 改到 1000，可能让原本快速失败的拥塞变成全面变慢。连接池也不是越大越好：应观察活跃连接、池等待、查询时长与内存，在应用扩容时重新核算总预算。短事务完成后及时归还连接，可以减少无意义占用。
存储规划同样要写出假设。例如当前业务数据和索引合计 80 GB，净增长每天 2 GB，预计 30 天后约为 140 GB。若希望达到分配容量的 70% 时就扩容，按同一口径计算至少需要 140÷0.7＝200 GB。这个估算尚未覆盖增长波动和引擎临时空间，应另留余量，并核实日志、临时文件以及备份分别计入哪类容量与费用。
IOPS 指每秒 I/O 操作数，吞吐关注每秒传输的数据量。大量小随机读可能先碰到 IOPS 瓶颈，较大连续读可能先碰到吞吐限制；CPU 不高也可能出现存储排队。若报表运行时读延迟明显上升，应把数据库等待、磁盘指标和任务时间线对齐，再判断是隔离报表、调整存储性能还是增加计算资源。索引与 SQL 的基础判断沿用 S22，本课不展开调优教程。
参数组应采用可追踪的变更流程：记录原值、目标值、理由、生效方式和回退办法。有些参数动态生效，有些需要重启，有些受引擎版本限制。先在相近环境验证，再安排维护窗口，并在变更后观察连接错误、内存和延迟。不要同时改规格、连接池和多个引擎参数，否则即使结果变好，也很难判断原因；变坏时更难可靠回退。
6 只读副本与读写分离直觉
只读副本用来承担读取，例如报表、统计和允许稍晚更新的列表。它通过复制获取主库数据，常存在延迟。高可用备用节点的主要目标是故障接管，只读副本的主要目标是分担读负载；某些产品组合了相关能力，但不能默认“有备用节点就有可查询的只读入口”，也不能默认任意只读副本都承担自动切换。
设订单在 12:00:00 写入主库，副本在 12:00:03 才应用这条记录。用户下单后立刻跳转详情页，如果详情查询落到副本，就可能显示“订单不存在”。这时主库没有损坏，是读取路径未满足写后立即可见的要求。订单确认、支付状态核对等关键读取可以回主库；允许延迟的历史列表或日报则可以使用副本。具体路由由应用或所选中间层明确实现。
报表隔离也有边界。只读副本拥有自己的计算资源，可以减少报表对主库的直接查询竞争，但仍会承担复制与自身查询压力。重查询可能让副本延迟增加，主库的复制工作也并非免费。应监控复制延迟、查询耗时和副本资源，并为报表设置合理并发与超时。若“今日销量”最多允许落后 30 秒，延迟超过阈值时可提示数据更新时间或暂停刷新，避免静默展示过期数字。
读写分离不是把所有 SELECT 都发给副本。事务内依赖刚写入结果的读取、涉及库存判断的读取，都需要按一致性要求设计。给每类读取标注“必须最新”或“允许滞后多久”，比仅按语句类型路由更实用。副本异常时是否回退主库也要评估容量，否则大批报表突然回流，可能拖慢原本健康的交易请求。
7 常见坑：公网裸奔连库、把切换当零丢数、备份未演练
将 3306 对 0.0.0.0/0 放行，会让任何互联网来源都有机会尝试连接。即使设置了密码，也扩大了扫描、口令攻击和配置失误的影响面。纠正动作是收回公网路径，让应用经私网访问，并按实际来源收窄规则。安全组、TLS 和账号权限需要共同成立；不能因为其中 1 层存在，就放弃其他层的约束。
另一个常见错误是方案写“故障自动切换，因此订单绝不丢失”，实际却使用异步复制。正确做法是将复制方式与业务可接受的数据损失明确对应，并通过服务文档、配置和演练确认边界。即使教学切换在 65 秒后恢复，也只能说明该场景下的恢复表现，不能外推出所有故障都在同样时间完成，更不能据此证明零丢数。
备份从未演练时，团队往往连恢复出来的实例要放在哪个网络、由谁登录检查都没准备好。直到事故才发现可恢复时间不包含目标、账号不可用或校验方法缺失，恢复承诺就失去了依据。应提前准备新实例的访问路径、校验样本及业务核对人，并记录完整耗时。备份任务成功只能证明管道完成了某步，恢复演练才能证明当前流程可用。
连接串写死 IP，会让应用在切换后继续访问旧位置；只读延迟被误判成主库损坏，则可能引发无必要的重启与切换。遇到两类现象时，先检查应用实际使用的入口和连接状态，再比较主库、副本的数据与时间线。运维动作应由证据驱动，避免用重启掩盖网络、路由或一致性设计的问题。
8 案例：订单库上云托管的最小可靠部署
某订单系统有 6 个应用实例，交易写入需要及时确认，运营每天运行统计报表。团队选择同一区域的多 AZ 托管关系型数据库，主库经私网服务域名连接，db-sg 只允许 app-sg 访问数据库端口。应用启用 TLS 和连接池，每个实例池上限暂设 20；计算规格由测试决定，并为扩容到 12 个应用实例时的连接预算重新验算。
业务数据和索引现有 80 GB，按每天净增 2 GB 制定容量告警与扩容计划。自动备份保留 7 天，开启 PITR，记录可恢复范围；启用删除保护并核实实例释放后的备份规则。只读副本供运营报表使用，订单创建后的确认查询走主库。账号分开承担应用写入、报表读取和运维职责，权限细节交给 C15。
可靠性目标不能直接从开关名称抄来。团队先把 120 秒内恢复稳定写入设为本次演练验收目标，明确它不是服务 SLA；数据损失目标则依据复制模式和已确认的服务保证单独定义。监控至少覆盖应用错误率、连接池等待、数据库连接数、存储余量、复制延迟和备份失败，告警必须有人接收。平台负责补丁执行机制，团队负责维护窗口和升级后的应用验证。
切换验收在隔离演练环境进行，通过服务支持的故障注入或切换操作模拟“主库被杀掉”的效果，持续提交带唯一业务请求号的测试订单。记录故障发生、平台提升、入口变化以及应用恢复时刻，核对是否在目标内恢复，并检查重复订单和结果不确定的请求。托管环境通常不能直接操作主机进程，应使用产品提供的演练能力。
恢复验收则指定演练开始时刻之前 10 分钟为目标，预先确认该时间落在连续可恢复范围内。在目标前后各写入可识别测试订单，再模拟误删，恢复到独立实例。校验目标前已提交订单存在、目标后订单不应被重放，并抽查金额和明细；同时记录恢复与核对总耗时。通过后保留报告，清理演练实例，避免测试数据混入生产或持续产生费用。
这个最小部署的交付物应是一组能复查的证据：私网与安全组关系、服务域名、备份保留和日志配置、复制模式、切换时间线、恢复任务及数据校验记录。仅截取“运行中”“备份成功”的控制台状态，不能代替应用层验收。后续业务增长时，沿用这些指标判断需要增加连接预算、存储性能或报表资源，而不是凭感觉整体升配。
9 排查案例：连不上、切换后应用报错、恢复点不对
路径 A：新应用部署后连接超时。先从出错的应用实例解析数据库服务域名，确认使用的是预期私网入口，再检查应用与数据库所在网络的路由，以及 db-sg 入站是否引用了正确的 app-sg。某次部署可能换用了新安全组，旧规则虽然仍显示“允许应用”，实际却没有覆盖新网卡。保留安全组引用、关联对象与 DNS 解析结果，才能解释为何旧实例能连而新实例不能。
端口可达后再观察 TLS 握手和登录错误。证书主机名不匹配应核对连接域名与证书信任配置，认证失败应核对账号及凭据版本，权限不足应检查目标库与授权范围。把超时、证书失败和权限错误分开，可以减少盲目改规则。证据记录中隐藏密码和令牌，只保留必要错误码、时间及来源环境。
路径 B：平台显示切换完成，应用仍持续报错。将故障事件时间线与应用日志对齐：若 10:00:50 服务入口已更新，10:01:30 仍在连接旧 IP，就检查是否写死地址、DNS 缓存过久或连接池没有淘汰旧连接。若新连接已成功而交易仍失败，继续检查连接池耗尽、请求超时预算和重试策略；不要把平台完成切换的时刻直接等同于业务恢复。
例如日志显示同一请求号在故障前发送写入，故障后再次提交，最终只查到 1 笔订单，这支持幂等处理在该案例中有效。若查到 2 笔，应检查业务唯一约束和请求号传递。若结果仍不确定，则通过主库及关联业务记录核对状态。重试日志本身不能证明原事务回滚，也不能证明数据已经丢失。
路径 C：恢复出的数据与预期不符。先写清目标事件、提交时间和时区，再查看恢复任务实际选择的时间点。设误删发生于 14:17:30，而任务选择 14:18，删除后的状态本来就会被恢复出来；若想恢复 8 天前数据但只保留 7 天，则目标已超出保留范围。还要检查是否在备份窗口外缺少可用基础备份，或日志存在缺口，不能仅凭每日快照时间推断 PITR 必然可达。
假设界面显示最晚只能恢复到 14:12，而目标为 14:17，就需要调查日志可用性与任务状态，不能把选点强行改成 14:17。保留可恢复区间、基础备份状态、日志缺口提示和 restore 任务时间点，再与业务样本比对。若恢复点确实不可达，应明确能找回的数据边界，并按业务记录核对缺失部分；反复执行相同恢复任务不会补齐缺失日志。
放进方案里
本系统采用托管关系型数据库，主要理由是将底层主机维护、受支持补丁编排、硬件故障处置及备份管道交由平台承担，减少团队持续值守负担。应用团队继续负责数据模型、事务正确性、连接管理、容量判断和恢复验收。方案需记录引擎版本、维护窗口、平台服务边界及各项告警负责人，避免把托管理解为无人运维。
数据库部署于 VPC 私网，经服务域名连接，数据库安全组仅允许应用安全组访问所需端口。应用启用 TLS 并验证证书。采用同一区域多 AZ 高可用部署，明确复制模式和可接受数据损失；以业务恢复时间衡量切换，本次演练目标为 120 秒内恢复稳定写入，实际目标需由测试与服务能力共同确认。应用使用有限重试、失效连接淘汰及业务幂等机制。
自动备份保留 7 天并开启 PITR，持续检查可恢复区间与日志状态；RPO 按备份和日志能力确认，不以保留天数替代。启用删除保护，核实释放实例后的备份规则。定期恢复到新实例，校验目标时间点订单、金额及明细，并记录恢复和业务核对耗时，指定报告归档与异常处理负责人。
初始容量按现有数据、每天增长和扩容提前量估算，连接预算覆盖应用实例数、连接池上限及后台任务。监控 CPU、内存、连接等待、存储余量和读写延迟，再决定扩计算还是存储性能。只读副本承接允许延迟的报表，关键写后读取走主库，并设置复制延迟告警。静态加密及 CMEK 需求参照 C6、C42，账号最小权限与 IAM 参照 C15；实例、副本、存储和备份费用在 C16 中统一核算。
10 小结：数据层就绪，下一步身份与成本（C15/C16）
云数据库把部分基础运维交给平台，应用仍要负责连接、事务与数据验收。私网决定访问路径，高可用缩短故障中断，备份与 PITR 提供历史恢复能力；规格和只读副本则要按连接、容量、性能及一致性要求选择。
离开本课前，应能解释：备用节点为何挡不住误删，保留 7 天为何不代表 RPO 是 7 天，切换完成为何应用还可能报错，以及下单后为何不宜立即从延迟副本确认结果。下一步到 C15 明确账号与 IAM 边界，再到 C16 将可靠性选择换算成可持续承担的费用。