AWS Aurora关系型数据库介绍

1、AWS Aurora关系型数据库介绍技术创新，变革未来议 程Aurora特性Aurora技术架构应场景和客户案例Amazon Aurora的与众不同高性能和高可扩展性高可性和高耐性高度安全完全托管5 倍于标准 MySQL 的吞吐量3 倍于PostgreSQL 的吞吐量性能相当成本仅为商DB的1/10 可以跨3个AZ,最多 15 个可读副本 存储增，单实例可达 64TB可性高于 99.99%具有容错及我修复能 跨3个AZ复制6个数据副本 数据持续备份到 S3实例故障转移于3 秒通过VPC 进络级 隔离，持静态存储及 传输时加密，集群中的 备份、快照和副本动 加密需担硬件、软件补丁、设置、配置或备

2、份等数据库管理任务。会动持续监控 并将其备份到 S3，可以实 现精细的时间点恢复。兼容 MySQL 和 PostgreSQL 的关系数据库，为云打造。性能和可性与商数据库相当，成本只有 1/10。与MYSQL写性能较SysBench Write-Only (writes/sec)DB SizeAmazon AuroraMySQL1 GB107,0008,40010 GB107,0002,400100 GB101,0001,5001 TB41,0001,200SysBench OLTP (writes/sec) Connections Amazon AuroraMySQL5040,00010,0

3、0050071,00021,0005,000110,00013,000与MYSQL读性能较Four client machines with 1,000 threads eachREAD PERFORMANCESingle client with 1,600 threadsMySQL SysBenchR3.8XL with 32 cores and 244 GB RAMWRITE PERFORMANCE性能测试减少络传输缓存计算和存储分离减少不必要作更少IO减少延迟优化锁机制提高效率异步处理如何实现高性能？ 批量处理 数据库取决于IO络存储依赖流量EU-WEST (Ireland)ASIA P

4、AC(Tokyo)ASIA PAC(Singapore)US-WEST (N. California)US-EAST (Virginia)US-WEST (Oregon)GOV CLOUDASIA PAC (Sydney)ASIA PAC(Beijing)EU (Frankfurt)ASIA PAC (Seoul)ASIA PAC(Mumbai)OhioUKNXMontrealSOUTH AMERICA (Sao Paulo)全球18个 Region 区域 （低延时，高覆盖，多运营商接）ParisAWS全球区域Availability Zones 可区： 多数据中组成的同城灾备AWS全球可区A

5、vailability Zone AAvailability Zone BBeijing Region 北京区域Availability Zone 可区每个region区域少有两个可区每个可区都由多个数据中组成可区之间地理与络都是独设计与运营可区间络延时保持在3ms以下可区内延时保持在0.3ms以下跨可区的高可部署极低成本的城市圈级别的实时异地容灾案Amazon Aurora体系结构( 横向扩展)Primary InstanceAmazon S3AZ 1AZ 2AZ 3Replica InstanceASYNC4/6 QUORUMDISTRIBUTED WRITESReplica Instan

6、ceLogging + StorageSQLTransactionsCaching控制层数据层Amazon S3DynamoDBAmazon SWFRoute 53将志记录和存储层移多租户，横向扩展为数据库优 化的存储服务与EC2VPC、DynamoDB、SWF、Route 53等其他AWS服务集成，于控制层的操作持续备份与S3集成，并具有11个9的持久性Aurora只读副本的不同之处Log RecordsBinlog DataDouble-Write Buffer FRM Files, MetadataMySQL With ReplicaAZ 1AZ 2Primary InstanceRep

7、lica InstanceAmazon Elastic Block Store (EBS)S3EBSmirrorEBSEBSmirrorPiTRSequential writeSequential writeAZ 1AZ 3Primary InstanceS3Amazon AuroraAZ 2Replica Instanceasync 4/6 quorumDistributed writes主要改进志结构化存储对异常值的致性容忍度显着提高络I/O的使效率Aurora存储节点的I/O处理LOG RECORDSPrimary InstanceINCOMING QUEUESTORAGE NODES3

8、 BACKUP12345678UPDATE QUEUEACKHOT LOGDATAPOINT IN TIME SNAPSHOTGCBLOCKSSCRUBCOALESCESORT GROUPPEER TO PEER GOSSIPPeer Storage NodesI/O 控制流接收记录并添加到内存队列中 持久化志记录并确认组织志记录并鉴别志中的缝隙 通过Gossip协议填补对等节点中缝隙 将志记录合并到新版本的数据块中 定期将志和新块中转到S3定期垃圾回收旧块定期对块进CRC校验实际运效果 所有步骤都是异步的 仅有步骤1与2处于前台延时过程中 输队列MySQL少46倍 有利于延时敏感型操作 使磁

9、盘空间缓冲活动中的峰值Amazon Aurora 存储引擎概述数据在3 Availability Zones中复制6份持续备份到Amazon S3 (11个9的持久性)持续监视节点和磁盘并动修复10GB 的区段作为修复和存储根据量动增的基础，存储最扩展到64 TBQuorum system 读写;Quorum membership 变 更 不 会 阻 塞写AZ 1AZ 2AZ 3Amazon S3Database NodeStorage NodeStorage NodeStorage NodeStorage NodeStorage NodeStorage NodeStorage Monitor

10、ing可能问题?Segment 损坏 (磁盘)节点损坏(主机)AZ 损坏 (络或数据中)AZ 1AZ 2AZ 3SQLTransactionCachingAmazon存储引擎容错SQLTransaction优化4 out of 6 write quorum3 out of 6 read quorumAZP1eer-to-peAZer2 replicatAioZ n3 for repairsCachingAmazon Aurora只读副本可性动检测并替换失败的database nodes动检测并重启失败的database processes只读副本在主节点故障时 动提升 (failover)客户

11、可以指定fail-over 顺序AZ 1AZ 3AZ 2Primary NodePrimary NodePrimary Database NodePrimary NodePrimary NodeRead ReplicaPrimary NodePrimary NodeRead ReplicaDatabase and Instance Monitoring性能客户程序可以将读流量指向只读副本读负载在多个只读副本间均衡持15个只读副本动故障转移集群读写与只读终端节点横向扩展读取性能ApplicationRead Replica 1动添加或删除只读副本 Read Replica 2Master Nod

12、eShared distributed storage volumeAmazon Aurora 扩展与高可App RunningFailure DetectionDNS PropagationRecoveryRecoveryDBFailureMYSQLApp RunningFailure DetectionDNS PropagationRecoveryDBFailureAURORA WITH MARIADB DRIVER5-6sec 5-10sec Aurora动故障接管过程SEGMENT SNAPSHOTLOG RECORDSSEGMENT 1SEGMENT 2SEGMENT 3TIMEAu

13、rora数据库备份与恢复RECOVERY POINT并为每个段定期拍快照，将重做志流传输到S3存储桶持续进备份，并不影响性能或可性在还原时，从S3返回相应的段快照与重做志流到存储节点以并和异步式应重做志流到段快照传统数据库需要从last checkpoint重放所有志般来说从checkpoints开始5分钟内在MySQL and PostgreSQL上是Single-threaded需要量的disk accessesAmazon AuroraCheckpointed DataLogCrash at T0 requiresa re-application of the SQL in the lo

14、g since last checkpointT0T0启动时需重放，存储系统transaction-aware底层存储不管是否恢复阶段都会持续志合并操作是并，分布和异步的Crash at T0 will result in logs being applied to each segment on demand, in parallel, asynchronouslyAmazon Aurora紧急崩溃恢复Aurora只读副本动伸缩技术MASTERREAD REPLICAREAD REPLICAREAD REPLICASHARED DISTRIBUTED STORAGE VOLUMEREADER

15、 END-POINT基于重做志复制的副本低延时 - 通常10毫秒读取器端点具有负载平衡和动缩放(CPU及连接数)Availability Zone 1Availability Zone 2跨多个可区最多可提升15个只读副本Availability Zone 3克隆数据库不复制数据瞬间创建个数据库克隆仅在发写时复制数据(COW) 当原 始数据和克隆卷数据不同时应场景克隆产数据库以运测试数据库重组为分析提供个时间点快照，不影响 产环境PRODUCTION DATABASECLONECLONECLONEDEV/TEST APPLICATIONSBENCHMARKSPRODUCTION APPLICA

16、TIONSPRODUCTION APPLICATIONSAurora数据库克隆技术存活caches 将 cache 从数据库进程中 分离出来数据库重启时Cache 可以 依旧保持热度更快地恢复全量加载操作 实例崩溃恢复+ 可存活cache = 更快速容易地从DB失败中恢复SQLTransactionsCachingSQLTransactionsCachingSQLTransactionsCachingCaching process 和DB process 分离 开来并在数据库重启时保持 warm数据回溯可以多次恢复，直到需要的时间点t0t1t2t0t1t2t3t4快速恢复户的错误操作使 Bac

17、ktrack 允许您将数据库回退到以前的某个时间点，需从备份还原，即使是型数据 库也只需要秒钟时间。t3t4Rewind to t1Rewind to t3InvisibleInvisible跨区域副本容灾提升replica 到master实现容灾不同地区的客户 离数据更近轻松迁移当任何的实例故障，应零停机 更 快 速 的 写 性 能更强的扩展能Aurora多主节点(Multi-Master) NEW! ApplicationRead/Write Master 1Shared distributed storage volumeRead/Write Master 2当任何的AZ故障，应零停机

18、Read/Write Master 3通过使Amazon Aurora Multi-Master，可以在多个可区中创建多个读取/写主实例。应程序就可以在集群的多个数据库实例中读取和写数据，就像目前可以在只读副本中读取样。横向扩展读/写性能按需动启停服务器化、动扩展仅为您使的资源按秒付费Aurora服务器架构 (Serverless) Warm Capacity PoolApplicationDatabase EndpointScalable Database Capacity (Compute + Memory)Shared Distributed StorageNEW! Serverless

19、 是种向Aurora 的按需扩展配置，数据库将根据您的应程序的需求来动启动、关闭以及纵向和横向扩展数据库容量。可在云中运关系数据库，需管理数据库实例或集群。Aurora全球同库跨区域多主节点HEAD NODESHEAD NODESLOCAL PARTITIONREMOTE PARTITIONMULTI-AZ STORAGE VOLUMEREGION 1本地写、低延时乐观锁并发控制 - 没有分布式锁管 理器与全局锁管理协议LOCAL PARTITIONREMOTE PARTITIONMULTI-AZ STORAGE VOLUMEREGION 2分层冲突处理 - 主节点、存储节点, 可区、区域级别

20、仲裁，当或低冲突 级别时性能近线性扩展NEW! AWSRDS主要特性对FeatureAuroraMySQLMariaDBPostgreSQLOracleSQL ServerVPCHigh AvailabilityInstance ScalingEncryptionRead Replicas15555N/AN/ACross RegionN/AN/AMax Storage64 TB16 TB16 TB16 TB16 TB16 TBScale StorageAuto ScalingProvisioned IOPSN/A30,00030,00030,00030,00020,000Largest InstanceR4.16XLR4.16XLR416XLR4.16XLR4.16XLR4.16XLAurora适场景Mysql/PostgreSQL即使优化仍然遇到瓶颈优化索引优化SQL主从读写分离拆分数据库高并发读写OLTP优势明显千万级以上表需拆分需要快速恢复Aurora最佳实践遵循关系型数据库的优化原则如果没有Mysql或者跨区域复制需求，禁binlog未知负载或者不经常的场景，使Serverless必要时使动扩展增强监控Cloud Watch监控安全实践IAM户最权限安全组只允许内部应服务器访问禁从公访