# 1. Aurora Limitless 如何通过分片数据库（transaction router、shard group）实现写入水平扩展？跨分片事务与分布式 JOIN 有哪些限制？ A 所有分片组共享同一个数据库实例，无法独立扩展 B Transaction Router 根据分片键将语句路由到对应 shard group，实现写入水平扩展 ✓ 正确答案 C 跨分片事务与分布式 JOIN 没有任何限制，性能与单表一致 D 分片键只在建表时可选，不参与实际路由
# 2. Amazon Aurora DSQL 如何通过时间同步服务（类 TrueTime 的跨区时钟）实现跨区域强一致与多区域主动-主动？其事务延迟主要来自哪里？ A 它依靠单主选主机制保证跨区域强一致 B 它使用类 TrueTime 的高精度时钟系统，通过时间戳排序与跨区协调实现多区域主动-主动强一致 ✓ 正确答案 C 事务延迟主要来自本地磁盘写入，与跨区网络无关 D 多区域模式下只能有一个区域执行写操作
# 3. Aurora 的 quorum 读写（4/6 与 3/6）与隔离故障域的设计 A 写 quorum 是 3/6，读 quorum 是 4/6 B 读写 quorum 不需要相交，靠读副本上的时间戳判断 C 6 个副本分布在 3 个可用区，每个 AZ 2 个副本；写需 4/6、读需 3/6，读写集合必相交保证强一致 ✓ 正确答案 D 一个 AZ 故障会导致 2 个副本失效，系统无法继续写入
# 4. Aurora 的存储层故障恢复与段（segment）重建 A 段重建需要停机，否则无法进行 B 存储层把数据分为 10GB 的段，每个段 6 副本；副本不足时后台从健康副本增量重建，不阻塞读写 ✓ 正确答案 C 段重建只能从主实例发起，不能独立进行 D 段副本数不足时读写会立即中断
# 5. Aurora 与传统 MySQL 在主从复制上的本质差异 A 两者的复制机制完全相同，都基于 binlog B Aurora 把 redo 日志发送到共享存储层，副本共享同一份存储并从存储读取数据，而非回放 binlog ✓ 正确答案 C Aurora 只读副本需要从主实例下载并重放 binlog D 传统 MySQL 的复制延迟一定低于 Aurora
# 6. Aurora 本地写入转发（Local Write Forwarding）如何把只读副本上的写请求转发到主实例处理？适用场景与一致性/延迟注意事项是什么？ A 它让只读副本直接执行写操作并持久化到副本本地 B 它把发往只读副本的写请求转发到主实例执行，并回传结果，适用于读多写少且读写混合的场景 ✓ 正确答案 C 它要求应用必须区分读写端点，否则无法使用 D 转发写入不会产生额外延迟，性能与直连主实例相同
# 7. Aurora 的「Log is Database」架构，只写 redo 日志到存储层 A 主实例只发送 redo 日志到存储层，由存储层应用日志并生成数据页，从而大幅减少网络 IO ✓ 正确答案 B 主实例把完整的数据页发送到存储层持久化 C 存储层不维护数据，只维护日志 D 该架构不适用于持久化，重启后数据会丢失
# 8. Aurora 的 6 副本（3 AZ × 2）与 quorum 读写 A 6 个副本全部放在同一个 AZ，以保证低延迟 B 写需 4/6、读需 3/6，读写 quorum 必然相交，可容忍单个 AZ 故障 ✓ 正确答案 C 写 quorum 是 5/6，读 quorum 是 1/6 D 6 副本只用于提高读性能，不参与一致性
# 9. Aurora 计算与存储分离带来的只读副本扩展优势 A 新增只读副本需要从主实例复制全量数据并追日志 B 存算分离后无法添加只读副本 C 只读副本必须各自维护一份独立的数据副本 D 所有计算节点共享同一份存储，新增只读副本无需复制数据，能快速横向扩展读能力 ✓ 正确答案
# 10. Aurora 的并行查询与列存副本（Aurora Parallel Query） A 它只优化写入性能，对分析查询没有帮助 B 它把扫描/聚合下推到存储节点并行执行，并可用列存副本加速分析查询 ✓ 正确答案 C 列存副本与行存数据实时完全同步，没有任何延迟 D 并行查询只适用于单节点的本地扫描
# 11. Aurora 的存储层，6 副本跨 3 AZ、日志驱动复制与快速恢复？ A 恢复需要重放大量 WAL 日志，耗时较长 B 快速恢复依赖主实例本地磁盘的 redo 日志 C 存储层只维护一份数据副本，崩溃后无法恢复 D 日志已提前持久化到 6 副本，恢复时只需对齐日志位点并读取已应用数据，路径短、RTO 低 ✓ 正确答案
# 12. Aurora 故障转移的流程（检测、切换、应用重连）与 RTO 组成 A RTO 由故障检测、角色提升、存储日志对齐、应用重连等环节组成，共享存储使新主无需复制数据即可快速接管 ✓ 正确答案 B 故障转移时新主需要从旧主复制全量数据，耗时很长 C 故障转移后应用无需任何处理即可继续使用旧连接 D 故障检测是即时完成的，不占 RTO
# 13. Aurora Serverless v2 的 ACU 弹性伸缩机制 A 系统按负载在 Min ACU 与 Max ACU 间自动调整容量，一个 ACU 约等于 2GB 内存及对应资源 ✓ 正确答案 B ACU 完全固定，无法自动伸缩 C v2 与 v1 一样必须通过代理层访问 D 扩容需要停机维护
# 14. Aurora 的 Backtrack 与快速克隆（Copy-on-Write） A Backtrack 需要重建整个数据库才能回滚 B 快速克隆必须完整复制所有数据，耗时较长 C Backtrack 用于把集群快速回滚到过去时间点，Clone 基于 Copy-on-Write 实现瞬间创建 ✓ 正确答案 D Clone 创建后与原库完全隔离，无法共享未修改的数据
# 15. Aurora 的副本读取与故障恢复，多可用区部署？ A 存储 6 副本和计算节点跨多个 AZ 分布，副本故障时提升新主后即可从共享存储快速恢复 ✓ 正确答案 B 所有副本都强制放在同一个 AZ C 只读副本不能跨 AZ 读取 D AZ 故障会导致存储 quorum 永久不满足，系统瘫痪
# 16. Aurora 与自建 MySQL 的兼容性，协议、复制与迁移路径？ A Aurora 使用专有协议，应用必须重写驱动 B 自建库迁移到 Aurora 必须完全停机，无法在线迁移 C Aurora 不支持 binlog，无法与自建 MySQL 复制 D Aurora 高度兼容 MySQL 协议与 SQL，可用 mysqldump、DMS 等工具迁移，并支持 binlog 复制 ✓ 正确答案
# 17. Aurora Serverless 与容量自动伸缩？ A 系统按负载在 Min/Max ACU 间自动伸缩，按实际用量计费，v2 支持秒级连续伸缩 ✓ 正确答案 B 容量完全固定，只能手动调整 C 伸缩必须停机，无法在线进行 D v1 与 v2 的伸缩能力完全相同
# 18. Aurora 的跨区域复制（Global Database）与灾备切换 A 次级区域只能读，不能用于灾备切换 B 主区域通过存储层日志复制到次级区域；计划内 Switchover RPO 为 0，故障 Failover 的 RPO 取决于复制延迟 ✓ 正确答案 C 跨区域复制延迟一定为 0 D 灾备切换后应用无需任何调整即可继续访问
