1、Amazon Aurora关系型数据库详解为云计算而生的关系型数据库议程Aurora特性Aurora技术架构迁移至AuroraAurora客户案例议程Aurora特性Aurora技术架构迁移至AuroraAurora客户案例A m a zo n A u ro r a 的与众不同高性能和高可扩展性高可用性和高耐用性高度安全完全托管5 倍于标准 MySQL 的吞吐量3 倍于PostgreSQL 的吞吐量性能相当而成本仅为商用DB的1/10 可以跨3个AZ,最多 15 个可读副本 存储自增长，单实例可达 64TB可用性高于 99.99%具有容错及自我修复能力跨3个AZ复制6个数据副本数据持续备份到
2、S3实例故障转移小于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,000
3、1,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 PERFORMANCE Single client with 1,600 threadsMySQL SysBenchR3.8XL with 32 cores and 244 GB RAM性能
4、测试更多的测试可以看：https:/amazonaws- 全球区域https:/www.infrastructure.aws/AWS 基础架构组件AWS 可用区( A Z ) 设计通过一个或多个数据中心，在基础架构层面 进行完全隔离两个AZ之间相隔几十公里每个数据中心具有各自独立的电源系统高达10万台服务器的规模不同的数据中心之间通过高速网络进行连接通过访问infrastructure.aws 了解更多的AWS 全球基础架构设施AvailabilityZone AAvailability Zone BBeijing Region 北京区域Availability Zone 可用区可用区每个re
5、gion区域至少有两个可用区每个可用区都由多个数据中心组成可用区之间地理与网络都是独立设计与运营可用区间网络延时保持在3ms以下可用区内延时保持在0.3ms以下跨可用区的高可用部署极低成本的城市圈级别的实时异地容灾方案Availability Zone AAvailability Zone BNingxia Region 宁夏区域AvailabilityZone A议程Aurora特性Aurora技术架构迁移至AuroraAurora客户案例A m a zo n A u ro r a 体系结构( 横向扩展)AZ 1AZ 3PrimaryInstanceAmazon S3AZ 2Replica
6、InstanceASYNC 4/6 QUORUMDISTRIBUTED WRITESReplica InstanceLogging + StorageSQLTransactionsCaching控制层面数据层面AmazonS3DynamoDBAmazon SWFRoute 53将日志记录和存储层移入多租户，横向扩展为数据库 优化的存储服务与EC2 VPC、DynamoDB、SWF、Route 53等其他AWS服务集成，用于控制层面的操作持续备份与S3集成，并具有11个9的持久性A u ro r a 只读副本的不同之处Log RecordsBinlogDataDouble-Write Buffe
7、rFRM Files, MetadataPrimary InstanceReplica InstanceAmazon Elastic Block Store (EBS)S3EBSmirrorEBSEBSmirrorPiTRSequential writeSequential writeMySQL With ReplicaAZ 1AZ 2AZ 1AZ 3Primary InstanceS3Amazon AuroraAZ 2Replica Instanceasync 4/6 quorumDistributed writes主主要要改进改进 日志结构化存储 对异常值的一致性容忍度 显着提高网络I/O
8、的使用效率A u ro r a 存储节点的I/ O 处理PrimaryInstanceINCOMING QUEUESTORAGE NODE12346S3 BACKUP78UPDATE QUEUELOG RECORDSACKPOINT IN TIME SNAPSHOTGCDATABLOCKS SCRUBCOALESCE5SORT GROUPPEER TO PEER GOSSIPHOTLOGPeer Storage Nodes实际运行效果 所有步骤都是异步的 仅有步骤1与2处于前台延时过程中 输入队列比MySQL少46倍 有利于延时敏感型操作 使用磁盘空间缓冲活动中的峰值I/O 控制流 接收记录并
9、添加到内存队列中持久化日志记录并确认组织日志记录并鉴别日志中的缝隙 通过Gossip协议填补对等节点中缝隙 将日志记录合并到新版本的数据块中 定期将日志和新块中转到S3定期垃圾回收旧块定期对块进行CRC校验A m a zo n A u ro r a 存储引擎概述数据在3 Availability Zones中复制6份持续备份到Amazon S3 (11个9的持久性)持续监视节点和磁盘并自动修复10GB 的区段作为修复和存储根据用 量自动增长的基础，存储最大扩展 到64 TBQuorum system 读写;Quorum membership 变更不会阻塞写AZ 1AZ 2AZ 3Amazon
10、S3Database NodeStorage NodeStorage NodeStorage NodeStorage NodeStorage NodeStorage NodeStorage Monitoring可能问题?Segment 损坏 (磁盘)节 点 损 坏 ( 主 机 ) AZ 损坏 (网络或数据中心)优化4 out of 6 write quorum3 out of 6 read quorumPeer-to-peer replication for repairsAZ 1AZ 2AZ 3SQLTransactionCachingA m a zo n 存储引擎容错AZ 1AZ 2AZ
11、3SQLTransactionCachingA m a zo n A u ro r a 只读副本可用性可用性 自动检测并替换失败的database nodes 自动检测并重启失败的database processes 只读副本在主节点故障时自 动提升 (failover) 客户可以指定fail-over 顺序AZ 1AZ 3AZ 2PrimaryNodePrimaryNodePrimary Database NodePrimaryNodePrimaryNodeRead ReplicaPrimaryNodePrimaryNodeRead ReplicaDatabase and Instance
12、Monitoring性能性能 客户程序可以将读流量指向只读副本 读负载在多个只读副本间均衡 支持15个只读副本 集群读写与只读终端节点Availability Zone 1横向扩展读取性能Availability Zone 2Availability Zone 3ApplicationRead Replica 1 自动添加或删除只读副本 自动故障转移Read Replica 2Master NodeShared distributed storage volumeA m a zo n A u ro r a 扩展与高可用AppRunningFailure DetectionDNS Propaga
13、tionRecoveryRecoveryDBFailureMYSQLDBFailureAURORA WITH MARIADB DRIVERFailure DetectionDNS Propagation5 - 6 s e cRecoveryApp Running5 - 1 0 s e cA u ro r a 自动故障接管过程SEGMENT SNAPSHOTLOG RECORDSRECOVERY POINTSEGMENT 1SEGMENT 2SEGMENT 3TIMEA u ro r a 数据库备份与恢复 并行为每个段定期拍快照，将重做日志流传输到S3存储桶 持续进行备份，并不影响性能或可用性
14、在还原时，从S3返回相应的段快照与重做日志流到存储节点 以并行和异步方式应用重做日志流到段快照传统数据库传统数据库需要从last checkpoint重放所有日志一般来说从checkpoints开始5分钟内在MySQL 和 PostgreSQL上是Single-threaded需要大量的disk accessesAmazon Aurora启动时无需重放，存储系统 事务感知底层存储由多个segment组成，不同segment有自己的重做日志应用日志操作是并行，分布和异步的Checkpointed DataLogCrash at T0 requiresa re-application of the
15、 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 n A u ro r a 紧急崩溃恢复A u ro r a 只读副本自动伸缩技术MASTERREAD REPLICAREAD REPLICAREAD REPLICASHARED DISTRIBUTED STORAGE VOLUMEREADER END-POINT 跨多个可用区最多可提升15个只读副本
16、 基于重做日志复制的副本低延时 - 通常10毫秒 读取器端点具有负载平衡和自动缩放(CPU及连接数)Availability Zone 1Availability Zone 2Availability Zone 3克隆数据库而不复制数据瞬间创建一个数据库克隆仅在发生写入时复制数据(COW) 当原始数据和克隆卷数据不同时应用场景克隆生产数据库以运行测试数据库重组为分析提供一个时间点快照，不影 响生产环境PRODUCTION DATABASECLONECLONECLONEDEV/TEST APPLICATIONSBENCHMARKSPRODUCTION APPLICATIONSPRODUCTION
17、APPLICATIONSA u ro r a 数据库克隆技术存活 c a c h es 将 cache 从数据库进程中分离出来 数据库重启时Cache 可以依旧保持热度 更快地恢复全量加载操作 实例崩溃恢复+ 可存活cache = 更快速容易地从DB失败中恢复SQLTransactionsCachingSQLTransactionsCachingSQLTransactionsCachingCaching process 和DB process 分离开来并在数据库重启时保持 warm数据回溯t0t1t2t3t4Rewind to t1t0t1t2t3t4快速恢复用户的错误操作使用 Backtra
18、ck 允许您将数据库回退到以前的某个时间点，无需从备份还原，即使是大型数据 库也只需要几秒钟时间。可以多次恢复，直到需要的时间点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 n R DS 迁移至A u ro r a 的不同场景 同构数据库 有一定的停
20、机时间 最小停机时间 异构数据库 有一定的停机时间 最小停机时间 详 细 过 程 可 参 考 ： https:/ mysql-database-move-to-amazon-aurora/A m a zo n R DS 迁移至A u ro r a创建RDS快照根据快照创 建Aurora数据 库应用程序开 始使用Aurora 数据库 同构数据库 有一定的停机时间A m a zo n R DS 迁移至A u ro r a创建Aurora只读副本把Aurora只读 副本提升为 主库应用程序开 始使用Aurora 数据库 同构数据库 最小停机时间自建数据库迁移至A u ro r a为自建数 据库创建
21、备份把数据库 备份上传 到S3根据备份创建Aurora数 据库应用程序开始使用Aurora数 据库 同构数据库 有一定的停机时间自建数据库迁移至A u ro r a创建Aurora从库自建数据 库与Aurora 从库进行 数据同步主从切换， 使得Aurora 从库变成 新的主库应用程序开始使用Aurora数据 库 同构数据库，以MySQL为例 有一定的停机时间自建数据库迁移至A uro r a 同构或者异构数据库 最小停机时间 迁移关键业务系统 迁移数据仓库到Amazon Redshift 归档老数据 升级小版本 合并多个数据分片到Amazon Aurora 复制数据从而在云端分析数据 从No
22、SQL迁移到SQL，或者从SQL迁移到NoSQL，或者从NoSQL迁移到NoSQLAmazon RDSAmazon RedshiftAmazon AuroraAmazon DynamoDBAmazon S3迁移AWS S c h em a Co n ver s io n To o l转换你的数据仓库把你的数据仓库，包括Oracle, SQL Server, Netezza, Greenplum, Vertica或Teradata，转换为 Amazon Redshift 转换Amazon AuroraAmazon Redshift转换你的数据库把你的数据库，包括Oracle, SQL Serve
23、r, 或者DB2 LUW，转换为 PostgreSQL, MySQL, or Amazon AuroraMySQL PostgreSQLPostgreSQL 异构数据库和Aurora之间的差异问题客户端客户端应用程序用户应用程序用户AWSInternetVPN启动复制实例连接到源数据库和目标数据库选择table、schema或数据库使用 AWS DMS 创建表、 加载数据并使其保持同步可随时将应用程序切换到目标自建数据库迁移至A uro r aAWS DMS 同构或者异构数据库 最小停机时间议程Aurora特性Aurora技术架构迁移至AuroraAurora客户案例A u ro r a 客户AWS top 100客户中的3/4使用AuroraAWS增长最快的服务A u ro r a 技术要点回顾 专为云环境设计（Cloud Native） 实现计算与存储分离 核心观念 - 日志即数据库 全面兼容MySQL与PostgreSQL引擎 与AWS服务无缝对接(IAM、S3 Lambda、Kinesis) 各种迁移到Aurora的方式，满足不同的迁移需求THANK YOU !
