深入探索兼容MySQL的Amazon Aurora方案

1、深入探索兼容MySQL的Amazon Aurora方案AWS 数据库服务专为满足您的所有应用程序需求而构建DynamoDBNeptuneRDSAuroraCommunity CommercialTimestreamQLDBElastiCache关系键 - 值文档内存图时间序列分类账DocumentDBAmazon Aurora与 MySQL 和 PostgreSQL 兼容的关系数据库，专为云而打造 性能和可用性与商业数据库相当，成本只有其 1/10高可用性和持久性容错、自我修复能力的存储; 跨 3 个可用区复制 6 份数据; 持续备份到 S3完全托管由RDS托管: 无需担心硬件预置、 软件修补

2、、设置、配置或备份高度安全网络隔离,动/静态数据加密高性能和可扩展性5 倍标准 MySQL 的吞吐量、 3 倍标准 PostgreSQL 的吞吐量; 可扩展多达15个只读副本Aurora客户采用情况AWS有史以来增长速度最快的服务在前百大AWS客户当中，有四分之三选择使用Aurora性能存储应用程序应用程序应用程序SQL事务缓存日志记录SQL事务缓存日志记录SQL事务缓存日志记录SQL事务缓存日志记录SQL事务缓存日志记录SQL事务缓存日志记录存储存储存储存储相同的整体式堆栈分布式共识算法表现不佳传统分布式数据库堆栈Amazon Aurora: 横向扩展、分布式架构MasterReplicaR

3、eplicaReplica主共享存储卷副副SQL事务缓存SQL事务缓存SQL事务缓存不再需要妥协！AZ1AZ2AZ3写入性能读取横向扩展可用区+1容错机制即时数据库重做恢复将Log机制推送至存储层4/6写入仲裁与本地跟踪二进制日志数据双写入日志FRM文件写入类型MYSQL副节点EBS镜像EBS镜像AZ 1AZ 2Amazon EBS主实例副实例1Amazon ElasticBlock Store (EBS)2345AZ 1AZ 3主实例AZ 2副实例同步4/6仲裁分布式写入副实例Amazon S3AMAZON AURORAMySQL I/O配置运行Sysbench 30分钟780K个事务每事务

4、7.4次I/O27,378K个事务 每事务0.95次I/O达到前者的35倍 仅为前者的1/7.7Aurora IO配置运行Sysbench 30分钟Amazon S3MySQL 与 Amazon Aurora 的I/O配置差异A u r o r a 存储节点的I / O 处理Primary InstanceINCOMING QUEUESTORAGE NODES3 BACKUP12345678UPDATE QUEUELOG RECORDSACKHOTLOGDATA BLOCKSPOINT IN TIME SNAPSHOTGCSCRUBCOALESCESORT GROUPPEER TO PEER

5、GOSSIPPeer Storage Nodes所有步骤都是异步的仅有步骤1与2处于前台延时过程中 输入队列比MySQL少46倍有利于延时敏感型操作使用磁盘空间缓冲活动中的峰值实际运行效果IO 流 接收记录并添加到内存队列中 持久化日志记录并确认 组织日志记录并鉴别日志中的缝隙 通过Gossip协议填补对等节点中缝隙 将日志记录合并到新版本的数据块中 定期将日志和新块中转到S3 定期垃圾回收旧块 定期对块进行CRC校验写入与读取吞吐量AuroraMySQL 的速度可达MySQL的5倍050,000100,000150,000200,000250,000MySQL 8.0MySQL 5.6Aur

6、ora 5.60100,000200,000300,000400,000500,000600,000700,000800,000MySQL 8.0MySQL 5.6Aurora 5.6MySQL 5.7Aurora 5.7MySQL 5.7Aurora 5.7写入吞吐量读取吞吐量在R4.16XL实例上运行Sysbench处理250份表，每份表包含20万行负载条件下的性能变化1210864200600100200300400500时间以秒为单位SysBench OLTP（只写）工作负载与250张表，每表20万行，采用R4.16XL实例Amazon Aurora 一致性提升200倍写入响应时间（秒

7、）Amazon Aurora MySQL 5.6 on EBS数据加载数据加载索引构建索引构建0100200300500600700800MySQLAmazon Aurora400运行时间（秒）10张Sysbench表，每张表10M行，采用R4.16XL实例批量数据加载性能A u r o r a M yS Q L 数据加载速度相当于M yS Q L 的2 . 5 倍页面缓存更新Aurora 主节点30% 读取70% 写入Aurora副节点100% 新读取共享多可用区存储MySQL 主节点30% 读取70% 写入MySQL副节点30% 读取70% 写入单线程二进制日志数据卷数据卷读取横向扩展使用

8、完整的变更逻辑相同的写入工作负载独立存储以物理方式使用delta变更不向副节点写入共享存储MYSQL 读取扩展AMAZON AURORA 读取扩展“在MySQL当中，我们看到复制延迟达到近12分钟。从实际应用的角度来 看，这显然是种近乎荒谬的情况。利用Aurora，4个副本的最大读取延迟从 未超过20毫秒。”Binlog Replica Lag (sec.)Aurora物理复制延迟（毫秒）Aurora逻辑复制延迟（秒）Amazon AuroraMySQL 逻辑与物理复制延迟SysBench OLTP(只写)10 GiB工作负载，250份表，每表20万行不再被迫妥协！恢复时间与写入性能并行、分布

9、式处理让处理更接近数据减少缓冲池污染数据库节点存储节点下推预测聚合结果降低查询延迟并行查询众所周知的决策支持基准我们对Aurora的并行查询功能进行了测试，并发现性能提升效果非常显著。具体来说，我们得以将实例类型从r3.8xlarge降低至r3.2xlarge。对于这一用例，并行查询代表着巨大的性能进步。云数据架构师Jyoti Shandil20 x0 x40 x60 x80 x120 x100 xQ1Q2Q3Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11 Q12 Q13 Q14 Q15 Q16 Q17 Q18 Q19 Q20 Q21 Q22减少查询响应时间峰值加速约120倍超过10倍加速

10、：22项查询中的8项并行查询性能结果并行查询性能结果可用性与持久性“可用区+1”容错机制为什么？在大规模集群体系中，故障总会出现可用区故障是一种“命中注定”AZ 1AZ 2AZ 3可用区 故障时的 仲裁中断2/3读取2/3 写入AZ 1AZ 2AZ 3可用区故障 时仲裁仍可 继续起效3/6读取4/6写入如何实现？6份副本，每可用区2份2/3仲裁无法满足需求持续备份并行保存每个分区的定期快照，将重做日志引流至Amazon S3持续执行备份，且不影响性能或可用性水平在还原时，将对应的分区快照与日志流检索至存储节点将日志流应用于并行与异步分区快照分区快照日志记录恢复点分区1分区2 分区3时间数据库回

11、溯从意外DML或DDL操作中回溯回溯不具有破坏性，您可以多次回溯以找寻正确的时间点t0t1t2t0t1t2t3回溯机制代表将数据库恢复至某一时间点，而无需使用备份资源t4t3t4回溯至t1回溯至t3不可见不可见即时崩溃重做恢复传统数据库重放自上次检查点之后的日志在单线程中慢速重放检查点数据重做日志在T0上发生的崩溃，需要重 新应用自上一次检查点保存 后重做日志中的SQLT0T0AmazonAurora无需检查点无需重放启动准备在T0上发生崩溃后，重做日志能够以并行、异 步方式按需应用于各个分区在多可用区内最多可提供15份可升级的只读副本 副节点与主节点共享存储不丢失数据可配置故障转移顺序主节点

12、读取副节点读取副节点读取副节点共享分布式存储卷读取副节点与快速故障转移全局复制更快的灾难恢复速度与数据位置强化AuroraGlobalDatabase针对全球分布式应用程序而设计的高性能数据库单个 Amazon Aurora 数据库跨越多个 AWS 区域基于存储的复制，典型延迟小于 1 秒不会影响数据库的性能写主节点在一个区域，读副本在其它区域跨区域灾难恢复为全球化应用提供低延迟的快速本地数据读取主区域从区域应用程序存储存储复制延时 1s可管理性性能洞察能力仪表板显示数据库负载操作简单支持拖放等直观操作强大 可通过放大进行深入观察 确定性能瓶颈来源按首要SQL分类按主机、用户、等待事件等分类

13、可调节时间范围小时、天、周、月最高保留近2 年数据；免费保留近7 天数据最大vCPUCPU瓶颈SQL等待/高CPU简化管理自动存储扩展，最高64 TB自动实现重新条带化、镜像修复、热点管 理以及加密最高64 TB读取端点具有负载均衡功能读取端点自动规模伸缩定制化读取端点主节点读取 副节点读取 副节点读取副节点共享分布式存储卷读取端点读取端点#2应用场景（不影响生产环境）克隆生产数据库以运行测试执行密集工作负载，如生成月度报表克隆数据库而不复制数据瞬间创建一个数据库克隆仅在发生写入时复制数据(COW) 当原始数据和克隆卷数据不同时生产数据库克隆克隆克隆应用开发/测试密集工作负载生产系统生产系统Aurora数据库克隆技术Amazon AuroraServerless . .自动响应您的应用程序负载在10 秒以内实现容量规模伸缩新实例默认配备w a r m 缓冲池多租户代理具有高可用性区域可用区1App共享分布式存储卷多租户NLB/数据库代理层Aurora实例warm池监控服务工作原理其在实践当中如何起效？0500100015002000250010130250370490610730850970109012101330145