Amazon Aurora HA 和 DR 全球弹性设计模式 (DAT442)

场次笔记

Aurora 的性能方法

添加副本以提高性能

• 将读取流量卸载到副本，减少对主写入器的影响。
• 通过将副本专用于特定工作负载（例如分析），允许隔离嘈杂的邻居。
• 最多可以添加 15 个副本以进行细粒度的性能管理。
• 存储扩展：
• Aurora 中的存储容量和性能自动扩展，无需手动配置。
• 实例缩放：
• 可以添加各种大小的实例（例如 16XL、8XL、4XL）以进行故障转移和性能管理。
• DB 实例具有弹性，可从 0 扩展到 256 个 Aurora 容量单位。
• 故障转移层被定义为根据大小和容量管理实例故障转移顺序。
• 弹性实例有助于管理工作负载峰值，而不会产生长期成本影响。

挑战：Aurora 中的连接管理

• 管理与多个实例的连接，尤其是识别用于事务的写入节点。
• 技术：
• 池化并限制每个 DB 实例的连接，避免重新连接。
• 驱动框架：
• 像 Spring 和 JDBC 这样的标准实践可能无法有效地处理集群数据库。

Aurora 端点

写入端点

• 始终指向当前写入节点，确保事务路由一致。
• 读取端点：
• 指向使用 DNS 循环进行粗略负载平衡的读取操作的实例池。
• 自定义端点：
• 为特定用例（例如分析）创建自定义端点的选项。

AWS Advanced Wrapper Drivers

快速驱动程序

• 增强的驱动程序对集群状态有深入的了解，有助于更快的故障转移。
• RDS Proxy：
• 用于管理连接和减少故障转移时间的附加工具。
• 插件：
• 增强型故障转移、读写分离、蓝绿部署。

多区域弹性

• 挑战：在某个区域发生故障或网络中断时确保业务连续性。
• 解决方案：在另一个区域维护一个副本，以最小的成本保持最新状态，并将其用于各种目的。
• Aurora Global Database 的多区域弹性：
• Aurora Global Database 允许 AMS 和 APG 最多有 10 个辅助区域。
• 内部复制服务器处理区域之间的异步物理复制。
• 不涉及头节点，避免了与逻辑复制相关的性能。
• 配置及优点：
• 区域 A：具有副本和存储的主要区域。
• Region B：初始具有存储的辅助区域，可以添加只读实例以供本地读取。
• 不对称配置是可能的；次要区域中的实例不需要与主要区域匹配。
• RPO 延迟通常约为 1 秒，具体取决于区域对距离。
• 全局端点和故障转移：
• 全球端点管理主要区域标识。
• 如果区域 A 发生故障，将管理故障转移到区域 B，但异步复制可能会导致数据丢失。
• 使用 Route 53 数据平面重新指向全局端点以实现快速重定向。
• 切换：
• 当两个区域都健康时执行切换。
• 区域 A 被告知停止成为主要区域，区域 B 成为主要区域。
• 允许在区域之间快速过渡而不会造成中断。
• 切换过程：
• 将特殊日志记录（标记日志记录）插入到日志记录流中。
• 另一端识别标记并在指定的日志时间成为主端。
• 同时，区域 A 不再是主要区域，从而确保干净的切换。
• 结果为零 RPO 和非常低的 RTO（大约 30 秒）。

维护和升级

• 需要版本升级（例如，PostgreSQL 16 到 PostgreSQL 17）和 OS 补丁。
• 自我管理的系统需要停机、用于回滚的快照、兼容性测试和性能测试。
• Aurora 提供完全托管和自动化的次要版本和补丁升级体验。
• 现在可以进行滚动操作系统升级，从而提高可用性。
• 维护操作可以在指定窗口内定义或由Aurora自动管理。
• AWS Health Dashboard 提供维护通知。
• 强烈建议选择自动化维护。
• AWS Organization的升级推出政策：
• 新功能可管理开发、QA 和生产环境中多个 DB 集群的升级。
• 简化 DB 集群队列生命周期管理的自动化。
• 允许基于 AWS 组织中多个资源的标签设置升级策略。
• 例子：
• 标记为 Prod 的资源最后升级；开发资源首先升级。
• 默认行为：其次升级没有可识别标签的资源。
• 升级部署涉及将策略分配给资源、确定升级顺序以及在维护时段内分批进行。
• 如果在维护时段内检测到问题，可以灵活地停止升级。
• 就地升级：
• 对于不兼容开源的重大升级，会进行就地升级。
• 涉及创建数据库集群的克隆、升级克隆以及测试应用程序。
• 验证后，克隆将被丢弃，升级将应用于生产集群。
• 蓝绿部署：
• 针对重大升级、架构更改或静态参数更改的更灵活的方法。
• 涉及创建新环境（绿色），同时使用逻辑复制保持旧环境（蓝色）同步。
• 允许在将升级推广到生产环境之前在绿色环境中测试升级。
• 切换会重命名资源以保持一致性，只需一分钟即可完成。
• 蓝绿部署现已可用于跨多个区域的全球数据库。
• Aurora、APG和AMS特点总结：
• 添加副本以提高可用性并启用故障转移。
• 使用 AWS Advanced Rapid Drivers 实现更顺畅的故障转移过程。
• 全球数据库可确保多达 10 个次要区域的持久性和可用性。
• 低延迟本地区域读取并简化了全局端点的端点管理。
• 托管和自动化的集群范围升级、快速克隆以及用于维护的蓝绿部署。

Aurora DSQL简介

• Amazon Aurora DSQL 是最快的无服务器分布式 SQL 数据库，适用于始终可用的应用程序。 Aurora DSQL 提供最快的多区域读写。它使客户能够通过零基础设施管理和零停机维护轻松扩展以满足任何工作负载需求。
• 结合了最好的关系数据库、分布式数据库架构和无服务器服务。
• 旨在运行复杂的查询、横向扩展并提供按使用付费的定价。
• DSQL架构概述：
• 与在 EC2 上运行的自管理 PostgreSQL 进行比较。
• DSQL 每个连接使用一个查询处理器，类似于 PostgreSQL 后端进程。
• 读取查询直接发送到 DSQL 存储引擎。
• 写入操作将缓冲在查询处理器的内存中，直至提交。
• 提交后，事务将发送到 Adjudicator 进行并发控制，然后发送到 Journal 以获得持久性，并复制到至少 2 个 AZs。
• Journal用于更新存储，类似于传统的PostgreSQL。
• DSQL是主动-主动服务，允许任何连接随时读取或写入数据。
• 查询处理器 (QP) 可以在不同的主机或可用区域上运行。
• DSQL 的可用性：
• 如果数据库节点发生故障，查询处理器 (QP) 会检测到故障并将流量转移到运行状况良好的副本。
• 副本可以位于相同或不同的可用区。
• 由于重试，飞行中的操作可能会出现延迟小幅增加的情况。
• DSQL持续备份数据并自动替换故障节点。
• 替换节点连接到 Journal 以追赶最新数据。
• 流量将转移回本地副本以获得最佳性能。
• 并发控制和持久性：
• Adjudicator 负责并发控制和冲突解决。
• 单个 Adjudicator 无需网络协调即可快速解决冲突。
• 其他可用区中保留备用 Adjudicator，用于故障转移。
• 发生故障时，备用 Adjudicator 通过领导者选举协议选出新的领导者。
• 查询处理器向新的领导者 Adjudicator 重试进行中的提交。
• 该过程是无缝的，不需要应用程序执行任何操作。

DSQL 中的高可用性

• DSQL 的设计没有单点故障。
• 双活架构提供开箱即用的高可用性。
• DSQL 旨在自动扩展以处理不断增加的负载。
• 并发控制协议：
• DSQL 使用乐观并发控制，假设事务很少发生冲突。
• 冲突会导致序列化失败错误并要求客户端重试事务。
• 应用程序应该处理重试和乐观并发控制问题。
• 建议构建辅助函数或将处理合并到最低应用程序层中。
• 避免不必要的冲突：
• 设计应用程序时尽量减少不必要的冲突，从而减少重试。
• 更新不同行的事务可以同时提交而不会发生冲突。
• 内部分片和扩展：
• DSQL 自动在内部进行分片，以应对 Adjudicator 和 Journal 上增长的负载。
• 查询处理器直接提交到适当的分片。
• 优化的两阶段提交确保跨多个分片的原子事务。
• DSQL 通过使新节点在线并跨副本进行负载平衡来自动横向扩展。
• DSQL 中的副本始终保持高度一致，从而实现无缝扩展。
• DSQL 的一致性：
• DSQL通过基于时间的同步协议确保强一致性。
• 使用 EC2 时间同步服务提供微秒级精确的时间戳，并使用 Clockbound 库来纠正测量误差。
• 保证线性化时间戳始终位于任何先前提交的时间戳之后。
• 存储层在返回数据行前等待 Journal 更新，以确保一致性。

两阶段提交 (2PC) 协议概述

• 2PC 是一种分布式系统协议，确保事务中的所有参与者一起提交或中止。
• 它由两个阶段组成：准备和提交/中止。
• 第一阶段：准备阶段：
• 协调器向所有参与节点发送“准备”请求。
• 每个参与者执行事务的工作，获取必要的锁，并将“准备好的”记录写入其事务日志。
• 参与者将“是”或“否”票发送回协调员。

第 2 阶段：提交/中止阶段

如果所有参与者都投“是”

• 协调者将“提交”记录写入其日志，并向所有参与者发送“提交”消息。
• 参与者提交事务、释放锁并向协调者发送确认。
• 如果任何参与者投“反对”票：
• 协调者将“中止”记录写入其日志，并向所有参与者发送“中止”消息。
• 参与者回滚事务并释放所有锁定。
• 关键考虑因素： 原子性：
• 2PC 保证事务是原子的，要么在所有节点上完成，要么在所有节点上完全失败。
• 一致性：
• 确保多个节点之间的数据一致性，但可能会因阻塞和等待决策而影响可用性。
• 故障处理：
• 包括从故障中恢复的机制；协调器故障可能会导致需要手动干预的“不确定”状态。

DSQL 中的连接管理

• 与 DSQL 的连接由会话路由层管理。
• 确保连接的快速可用性，即使在网络事件导致波动期间也是如此。
• 维护一个可供立即使用的查询处理器 (QP) 热池。
• 当请求连接时，DSQL 从池中分配可用的 QP。
• 处理连接失败：
• 如果发生连接失败，应用程序必须检测失败并重试。
• 乐观并发控制部分的重试处理程序对于此目的很有用。
• 应用程序应该针对连接错误实现重试逻辑，以保持可用性。
• 与存储和 Adjudicator 故障不同，连接失败后应用程序必须自行重新连接。
• DSQL 强制连接的最大生命周期为 1 小时，以鼓励正确的连接管理。
• 连接管理的最佳实践：
• 使用客户端连接池库（例如，Java C3PO）进行健康检查和最大连接期限。
• DSQL 本质上包含连接池，从而不需要服务器端池（例如 PG Bouncer、RDS Proxy）。
• 建议连接到同一可用区中的 QP 以降低延迟。
• 如果当前可用区不可用，DSQL 会自动故障转移到健康可用区。

DSQL 中的多区域集群

• DSQL支持多区域集群，即在两个区域创建集群，并指定第三个区域作为见证区域。
• 见证区域持有 Journal 的副本，以支持应对区域故障的基于法定人数的协议。
• 应用程序可以跨区域保持活动状态，两个区域都能够处理读取和写入。
• 基于仲裁的协议
• 是分布式系统中使用的一种方法，通过要求最少数量的参与节点（仲裁）在操作被认为有效之前就该操作达成一致来确保数据一致性、容错性和可靠性。
• S3 基于仲裁的协议：
• 在分布式系统中，“法定人数”是指“组成会议所需的最少成员数量”。
• Quorum机制是一种投票算法，用于保证Amazon S3等分布式存储系统中的数据冗余和一致性。
• 核心概念和术语：
• 阅读法定人数（Vr）：阅读投票的最低数量
• Write Quorum (Vw)：最小写入投票数
• 总票数（五）
• 工作原理：
• 假设分布式系统中有V个数据副本。
• 为了保证数据的一致性，读写操作必须获得节点确认的“法定人数”。
• 核心规则：
• Vr + Vw > V：保证同一数据不会同时读写，避免读写冲突。
• Vw > V / 2：确保串行数据修改，防止两个写操作同时修改数据。
• 调整Vr和Vw可以让系统在读写性能之间取得平衡。
• 关于Amazon S3：
• Amazon S3在2020年宣布所有GET、PUT、LIST操作都具有强一致性。
• 写入的数据可以立即读取为最新版本，简化大数据工作负载。
• S3通过其架构保证高持久性和可用性，该架构在至少三个可用区存储数据副本。

处理区域故障

• 如果发生区域故障（例如，区域 B 发生故障），见证区域会帮助消除故障的歧义，并投票将故障区域排除在法定人数之外。
• DSQL 自动重新配置 Journal 以排除故障区域，确保集群在正常区域（区域 A）中保持可用。
• 没有数据丢失，并且事务继续复制到至少一个其他 AWS 区域。
• 当故障区域（区域 B）重新上线时，DSQL 会检测到它，将其更新到最新状态，并恢复多区域配置。
• 推荐模式：在两个区域中与集群一起部署应用程序以实现主动冗余。
• 主动冗余的好处：
• 在多个区域中与集群一起部署应用程序可提供低延迟和应用程序功能的持续验证。
• 使用全局端点（例如，Route 53 DNS 记录）将流量引导至最近的可用健康区域。
• 使用全局端点处理区域故障：
• 当区域出现故障时，数据不会丢失，DNS会自动将流量引导至健康区域。
• 持续验证可确保健康区域正常运行。
• DSQL维护：
• DSQL 是一项完全托管的服务，无需客户进行维护。
• 查询进程定期替换为更新版本，确保最新的 OS、安全补丁、性能改进和功能。
• 客户无需执行任何维护任务。
• 要点：
• Aurora提供三种引擎：PostgreSQL、MySQL、DSQL。
• 所有引擎均提供 3 AZ 开箱耐用性。
• 扩展选项有所不同：APG 和 AMS 扩展用于写入，扩展用于读取； DSQL 提供免提自动缩放功能。
• 多区域考虑：APG和AMS允许测试故障转移而不会丢失数据； DSQL支持跨区域双活。
• 所有引擎都通过自动安全更新和次要版本升级提供轻松维护。