Amazon Aurora关系型数据库详解

1、Amazon Aurora关系型数据库详解为云计算而生的关系型数据库议程Aurora特性Aurora技术架构迁移至AuroraAurora客户案例议程Aurora特性Aurora技术架构迁移至AuroraAurora客户案例A m a zo nA u ro r a 的与众不同高性能和高可扩展性高可用性和高耐用性高度安全完全托管5 倍于标准 MySQL 的吞吐量3 倍于PostgreSQL 的吞吐量性能相当而成本仅为商用DB的1/10 可以跨3个AZ,最多 15 个可读副本 存储自增长，单实例可达 64TB可用性高于 99.99%具有容错及自我修复能力跨3个AZ复制6个数据副本数据持续备份到 S

2、3实例故障转移小于3 秒通过VPC 进行网络级 隔离，支持静态存储 及传输时加密，集群 中的备份、快照和副 本自动加密无需担心硬件、软件补丁、 设置、配置或备份等数据 库管理任务。会自动持续 监控并将其备份到 S3，可 以实现精细的时间点恢复。兼容 MySQL 和 PostgreSQL 的关系数据库，为云打造。性能和可用性与商用数据库相当，成本只有 1/10。与M YS Q L 写性能比较SysBench Write-Only (writes/sec)DB SizeAmazon AuroraMySQL1 GB107,0008,40010 GB107,0002,400100 GB101,0001

3、,5001 TB41,0001,200SysBench OLTP (writes/sec)Connections Amazon AuroraMySQL5040,00010,00050071,00021,0005,000110,00013,000与M YS Q L 读性能比较Four client machines with 1,000 threads eachWRITE PERFORMANCEREAD PERFORMANCESingle client with 1,600 threadsMySQL SysBenchR3.8XL with 32 cores and 244 GB RAM性能测试更

4、多的测试可以看：/cn/blogs/china/aurora-test/?nc1=b_rp减少网络传输缓存计算和存储分离减少不必要工作更少IO减少延迟优化锁机制批量处理提高效率异步处理如何实现高性能？数据库取决于IO网络存储依赖流量AWS 全球区域https:/www.infrastructure.aws/AWS 基础架构组件AWS 可用区( A Z ) 设计通过一个或多个数据中心，在基础架构层面 进行完全隔离两个AZ之间相隔几十公里每个数据中心具有各自独立的电源系统高达10万台服务器的规模不同的数据中心之间通过高速网络进行连接通过访问infrastructure.aws 了解更多的AWS 全

5、球基础架构设施AvailabilityZone AAvailability Zone BBeijing Region 北京区域Availability Zone 可用区每个region区域至少有两个可用区每个可用区都由多个数据中心组成可用区之间地理与网络都是独立设计与运营可用区间网络延时保持在3ms以下可用区内延时保持在0.3ms以下跨可用区的高可用部署极低成本的城市圈级别的实时异地容灾方案Availability Zone AAvailability Zone BNingxia Region 宁夏区域AvailabilityZone A议程Aurora特性Aurora技术架构迁移至Auror

6、aAurora客户案例A m a zo nA u ro r a 体系结构( 横向扩展)AZ 1AZ 3PrimaryInstanceAmazon S3AZ 2Replica InstanceASYNC 4/6 QUORUMDISTRIBUTED WRITESReplica InstanceLogging + StorageSQLTransactionsCaching控制层面数据层面AmazonS3DynamoDBAmazon SWFRoute 53将日志记录和存储层移入多租户，横向扩展为数据库 优化的存储服务与EC2VPC、DynamoDB、SWF、Route 53等其他AWS服务集成，用于控

7、制层面的操作持续备份与S3集成，并具有11个9的持久性A u ro r a 只读副本的不同之处Log RecordsBinlogDataDouble-Write BufferFRM Files, MetadataPrimary InstanceReplica InstanceAmazon Elastic Block Store (EBS)S3EBSmirrorEBSEBSmirrorPiTRSequential writeSequential writeMySQL With ReplicaAZ 1AZ 2AZ 1AZ 3Primary InstanceS3Amazon AuroraAZ 2Re

8、plica Instanceasync 4/6 quorumDistributed writes主要改进日志结构化存储对异常值的一致性容忍度显着提高网络I/O的使用效率A u ro r a 存储节点的I/ O 处理PrimaryInstanceINCOMING QUEUESTORAGE NODE12346S3 BACKUP78UPDATE QUEUELOG RECORDSACKPOINT IN TIME SNAPSHOTGCDATABLOCKS SCRUBCOALESCE5SORT GROUPPEER TO PEER GOSSIPHOTLOGPeer Storage Nodes实际运行效果 所

9、有步骤都是异步的 仅有步骤1与2处于前台延时过程中 输入队列比MySQL少46倍 有利于延时敏感型操作 使用磁盘空间缓冲活动中的峰值I/O 控制流 接收记录并添加到内存队列中持久化日志记录并确认组织日志记录并鉴别日志中的缝隙 通过Gossip协议填补对等节点中缝隙 将日志记录合并到新版本的数据块中 定期将日志和新块中转到S3定期垃圾回收旧块定期对块进行CRC校验A m a zo nA u ro r a存储引擎概述数据在3 Availability Zones中复制6份持续备份到Amazon S3 (11个9的持久性)持续监视节点和磁盘并自动修复10GB 的区段作为修复和存储根据用 量自动增长的

10、基础，存储最大扩展 到64 TBQuorum system 读写;Quorum membership 变更不会阻塞写AZ 1AZ 2AZ 3Amazon S3Database NodeStorage NodeStorage NodeStorage NodeStorage NodeStorage NodeStorage NodeStorage Monitoring可能问题?Segment 损坏 (磁盘)节 点 损 坏 ( 主 机 ) AZ 损坏 (网络或数据中心)优化4 out of 6 write quorum3 out of 6 read quorumPeer-to-peer replica

11、tion for repairsAZ 1AZ 2AZ 3SQLTransactionCachingA m a zo n存储引擎容错AZ 1AZ 2AZ 3SQLTransactionCachingA m a zo nA u ro r a只读副本可用性自动检测并替换失败的database nodes自动检测并重启失败的database processes只读副本在主节点故障时自 动提升 (failover)客户可以指定fail-over 顺序AZ 1AZ 3AZ 2PrimaryNodePrimaryNodePrimary Database NodePrimaryNodePrimaryNodeR

12、ead ReplicaPrimaryNodePrimaryNodeRead ReplicaDatabase and Instance Monitoring性能客户程序可以将读流量指向只读副本读负载在多个只读副本间均衡支持15个只读副本集群读写与只读终端节点Availability Zone 1横向扩展读取性能Availability Zone 2Availability Zone 3ApplicationRead Replica 1自动添加或删除只读副本 自动故障转移Read Replica 2Master NodeShared distributed storage volumeA m a

13、zo nA u ro r a 扩展与高可用AppRunningFailure DetectionDNS PropagationRecoveryRecoveryDBFailureMYSQLDBFailureAURORA WITH MARIADB DRIVERFailure DetectionDNS Propagation5 - 6s e cRecoveryApp Running5 - 1 0s e cA u ro r a 自动故障接管过程SEGMENT SNAPSHOTLOG RECORDSRECOVERY POINTSEGMENT 1SEGMENT 2SEGMENT 3TIMEA u ro r

14、 a 数据库备份与恢复并行为每个段定期拍快照，将重做日志流传输到S3存储桶持续进行备份，并不影响性能或可用性在还原时，从S3返回相应的段快照与重做日志流到存储节点以并行和异步方式应用重做日志流到段快照传统数据库需要从last checkpoint重放所有日志一般来说从checkpoints开始5分钟内在MySQL 和 PostgreSQL上是Single-threaded需要大量的disk accessesAmazon Aurora启动时无需重放，存储系统 事务感知底层存储由多个segment组成，不同segment有自己的重做日志应用日志操作是并行，分布和异步的Checkpointed Da

15、taLogCrash at T0 requiresa re-application of the SQL in the log since last checkpointT0T0Crash at T0 will result in logs being applied to each segment on demand, in parallel, asynchronouslyA m a zo nA u ro r a紧急崩溃恢复A u ro r a 只读副本自动伸缩技术MASTERREAD REPLICAREAD REPLICAREAD REPLICASHARED DISTRIBUTED STO

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

17、BENCHMARKSPRODUCTION APPLICATIONSPRODUCTIONAPPLICATIONSA u ro r a 数据库克隆技术存活c a c h es将 cache 从数据库进程中分离出来数据库重启时Cache 可以依旧保持热度更快地恢复全量加载操作实例崩溃恢复+ 可存活cache = 更快速容易地从DB失败中恢复SQLTransactionsCachingSQLTransactionsCachingSQLTransactionsCachingCaching process 和DB process 分离开来并在数据库重启时保持 warm数据回溯t0t1t2t3t4Rewin

18、d to t1t0t1t2t3t4快速恢复用户的错误操作使用 Backtrack 允许您将数据库回退到以前的某个时间点，无需从备份还原，即使是大型数据 库也只需要几秒钟时间。可以多次恢复，直到需要的时间点Rewind to t3InvisibleInvisible仅为您使用的资源按秒付费A u ro r a 无服务器架构( S er v er l e s s )Warm CapacityPoolScalable Database Capacity(Compute + Memory)Shared Distributed StorageServerless 是一种面向 Aurora 的按需扩展配置

19、，数据库将根据您的应用程序的需求来自动启动、 关闭以及纵向和横向扩展数据库容量。可在云中运行关系数据库，而无需管理数据库实例或集群。Application按需自动启停Database Endpoint无服务器化、自动扩展议程Aurora特性Aurora技术架构迁移至AuroraAurora客户案例A u ro r a 适用场景Mysql/PostgreSQL即使优化仍然遇到瓶颈优化索引优化SQL主从读写分离拆分数据库高并发读写，尤其写操作的负载很高需要快速恢复最小化读副本的延迟免去手动sharding或者使用sharding中间件带来的复杂性和运维成本A m a zo nR DS 迁移至A u

20、 ro r a 的不同场景同构数据库有一定的停机时间最小停机时间异构数据库有一定的停机时间最小停机时间详 细 过 程 可 参 考 ： /cn/blogs/china/every-scene- mysql-database-move-to-amazon-aurora/A m a zo nR DS 迁移至A u ro r a创建RDS快照根据快照创 建Aurora数据 库应用程序开 始使用Aurora 数据库同构数据库有一定的停机时间A m a zo nR DS 迁移至A u ro r a创建Aurora只读副本把Aurora只读 副本提升为 主库应用程序开 始使用Aurora 数据库同构数据库最

21、小停机时间自建数据库迁移至A u ro r a为自建数 据库创建 备份把数据库 备份上传 到S3根据备份创建Aurora数 据库应用程序开始使用Aurora数 据库同构数据库有一定的停机时间自建数据库迁移至A u ro r a创建Aurora从库自建数据 库与Aurora 从库进行 数据同步主从切换， 使得Aurora 从库变成 新的主库应用程序开始使用Aurora数据 库同构数据库，以MySQL为例有一定的停机时间自建数据库迁移至A uro r a同构或者异构数据库最小停机时间迁移关键业务系统迁移数据仓库到Amazon Redshift归档老数据升级小版本合并多个数据分片到Amazon Aurora复制数据从而在云端分析数据从NoSQL迁移到SQL，或者从SQL迁移到NoSQL，或者从NoSQL迁移到NoSQLAmazon RDSAmazon Red