Amazon-Aurora关系型数据库详解课件

AmazonAurora关系型数据库详解为云计算而生的关系型数据库AmazonAurora关系型数据库详解为云计算而生的关系1议程Aurora特性Aurora技术架构迁移至AuroraAurora客户案例议程2议程Aurora特性Aurora技术架构迁移至AuroraAurora客户案例议程3A

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个数据副本数据持续备份到

S3实例故障转移小于3

秒通过VPC

进行网络级隔离，支持静态存储及传输时加密，集群中的备份、快照和副本自动加密无需担心硬件、软件补丁、设置、配置或备份等数据库管理任务。会自动持续监控并将其备份到

S3，可以实现精细的时间点恢复。兼容

MySQL

和

PostgreSQL

的关系数据库，为云打造。性能和可用性与商用数据库相当，成本只有1/10。Amazon Aurora的与众不同高性能4与M

YS

Q

L

写性能比较SysBenchWrite-Only

(writes/sec)DBSizeAmazon

AuroraMySQL1GB107,0008,40010GB107,0002,400100GB101,0001,5001

TB41,0001,200SysBenchOLTP

(writes/sec)ConnectionsAmazon

AuroraMySQL50 40,00010,000500 71,00021,0005,000 110,00013,000与MYSQL写性能比较SysBenchWrite-5与M

YS

Q

L

读性能比较与MYSQL读性能比较6Fourclientmachineswith1,000threads

eachWRITE

PERFORMANCEREAD

PERFORMANCESingleclientwith1,600

threadsMySQL

SysBenchR3.8XLwith32coresand244GB

RAM性能测试更多的测试可以看：/cn/blogs/china/aurora-test/?nc1=b_rpFourclientmachineswith1,007减少网络传输缓存计算和存储分离减少不必要工作

更少IO减少延迟优化锁机制批量处理提高效率异步处理如何实现高性能？数据库取决于IO网络存储依赖流量减少网络传输缓存计算和存储分离减少不必要工作 减少延迟优化锁8AWS

全球区域https://www.infrastructure.aws/AWS全球区域https://www.infrastruc9AWS

基础架构组件AWS基础架构组件10AWS

可用区(

A

Z

)

设计通过一个或多个数据中心，在基础架构层面进行完全隔离两个AZ之间相隔几十公里每个数据中心具有各自独立的电源系统高达10万台服务器的规模不同的数据中心之间通过高速网络进行连接通过访问infrastructure.aws

了解更多的AWS全球基础架构设施AWS可用区(AZ)设计通过一个或多个数据中心，在11AvailabilityZone

AAvailabilityZone

BBeijing

Region

北京区域Availability

Zone

可用区每个region区域至少有两个可用区每个可用区都由多个数据中心组成可用区之间地理与网络都是独立设计与运营可用区间网络延时保持在3ms以下可用区内延时保持在0.3ms以下跨可用区的高可用部署极低成本的城市圈级别的实时异地容灾方案AvailabilityZone

AAvailabilityZone

BNingxia

Region

宁夏区域AvailabilityZone

AAvailabilityAvailabilityZone12议程Aurora特性Aurora技术架构迁移至AuroraAurora客户案例议程13A

m

a

zo

n A

u

ro

r

a

体系结构(

横向扩展)AZ

1AZ

3PrimaryInstanceAmazonS3AZ

2ReplicaInstanceASYNC4/6

QUORUMDISTRIBUTED

WRITESReplicaInstanceLogging+

StorageSQLTransactionsCaching控制层面数据层面AmazonS3DynamoDBAmazon

SWFRoute

53将日志记录和存储层移入多租户，横向扩展为数据库优化的存储服务与EC2､VPC、DynamoDB、SWF、Route

53等其他AWS服务集成，用于控制层面的操作持续备份与S3集成，并具有11个9的持久性Amazon Aurora体系结构(横向14A

u

ro

r

a

只读副本的不同之处Log

RecordsBinlogDataDouble-Write

BufferFRMFiles,

MetadataPrimaryInstanceReplicaInstanceAmazonElasticBlockStore

(EBS)S3EBSmirrorEBSEBSmirrorPiTRSequentialwriteSequentialwriteMySQLWith

ReplicaAZ1 AZ2 AZ

1AZ

3PrimaryInstanceS3Amazon

AuroraAZ2ReplicaInstanceasync4/6

quorumDistributedwrites主要改进日志结构化存储对异常值的一致性容忍度显着提高网络I/O的使用效率Aurora只读副本的不同之处LogRecord15A

u

ro

r

a

存储节点的I/

O

处理PrimaryInstanceINCOMING

QUEUESTORAGE

NODE12346S3

BACKUP78UPDATEQUEUELOG

RECORDSACKPOINTINTIMESNAPSHOTGCDATABLOCKS

SCRUBCOALESCE5SORTGROUPPEER

TO

PEER

GOSSIP

HOTLOGPeerStorageNodes实际运行效果 ①

所有步骤都是异步的②

仅有步骤1与2处于前台延时过程中③

输入队列比MySQL少46倍④

有利于延时敏感型操作⑤

使用磁盘空间缓冲活动中的峰值I/O

控制流 接收记录并添加到内存队列中持久化日志记录并确认组织日志记录并鉴别日志中的缝隙通过Gossip协议填补对等节点中缝隙将日志记录合并到新版本的数据块中定期将日志和新块中转到S3定期垃圾回收旧块定期对块进行CRC校验Aurora存储节点的I/O处理Primary16A

m

a

zo

n A

u

ro

r

a 存储引擎概述数据在3

Availability

Zones中复制6份持续备份到Amazon

S3

(11个9的持久性)持续监视节点和磁盘并自动修复10GB

的区段作为修复和存储根据用量自动增长的基础，存储最大扩展到64

TBQuorum

system

读写;Quorummembership

变更不会阻塞写AZ

1AZ

2AZ

3Amazon

S3DatabaseNodeStorageNodeStorageNodeStorageNodeStorageNodeStorageNodeStorageNodeStorageMonitoringAmazon Aurora 存储引擎概述数据17可能问题?Segment

损坏

(磁盘)节点损坏(主机)AZ

损坏

(网络或数据中心)优化4outof6write

quorum3outof6read

quorumPeer-to-peerreplicationfor

repairsAZ

1AZ

2AZ

3SQLTransactionCachingA

m

a

zo

n 存储引擎容错AZ

1AZ

2AZ

3SQLTransactionCaching可能问题?优化AZ1AZ2AZ3SQLTransact18A

m

a

zo

n A

u

ro

r

a 只读副本可用性自动检测并替换失败的database

nodes自动检测并重启失败的database

processes只读副本在主节点故障时自动提升

(failover)客户可以指定fail-over

顺序AZ

1AZ

3AZ

2PrimaryNodePrimaryNodePrimaryDatabaseNodePrimaryNodePrimaryNodeReadReplicaPrimaryNodePrimaryNodeReadReplicaDatabaseandInstanceMonitoring性能客户程序可以将读流量指向只读副本读负载在多个只读副本间均衡Amazon Aurora 只读副本可用性自19支持15个只读副本集群读写与只读终端节点AvailabilityZone

1横向扩展读取性能AvailabilityZone

2AvailabilityZone

3ApplicationReadReplica

1自动添加或删除只读副本

自动故障转移ReadReplica

2MasterNodeShareddistributedstorage

volumeA

m

a

zo

n A

u

ro

r

a

—

扩展与高可用支持15个只读副本集群读写与只读终端节点Availabili20AppRunningFailure

DetectionDNS

PropagationRecoveryRecoveryDBFailureMYSQLDBFailureAURORA

WITHMARIADB

DRIVERFailure

DetectionDNS

Propagation5

-

6 s

e

cRecoveryAppRunning5

-

1

0 s

e

cA

u

ro

r

a

自动故障接管过程AppFailureDetectionDNSPropag21SEGMENT

SNAPSHOTLOGRECORDSRECOVERYPOINTSEGMENT

1SEGMENT

2SEGMENT

3TIMEA

u

ro

r

a

数据库备份与恢复并行为每个段定期拍快照，将重做日志流传输到S3存储桶持续进行备份，并不影响性能或可用性在还原时，从S3返回相应的段快照与重做日志流到存储节点以并行和异步方式应用重做日志流到段快照SEGMENTSNAPSHOTLOGRECORDSRE22传统数据库需要从last

checkpoint重放所有日志一般来说从checkpoints开始5分钟内在MySQL

和

PostgreSQL上是Single-threaded需要大量的disk

accessesAmazon

Aurora启动时无需重放，存储系统

事务感知底层存储由多个segment组成，不同segment有自己的重做日志应用日志操作是并行，分布和异步的Checkpointed

DataLogCrashatT0

requiresare-applicationof

theSQLinthelogsincelast

checkpointT0T0CrashatT0willresultinlogsbeingappliedtoeachsegmentondemand,inparallel,asynchronouslyA

m

a

zo

n A

u

ro

r

a 紧急崩溃恢复传统数据库AmazonAuroraCheckpointed23A

u

ro

r

a

只读副本自动伸缩技术MASTERREADREPLICAREADREPLICAREADREPLICASHAREDDISTRIBUTEDSTORAGE

VOLUMEREADER

END-POINT跨多个可用区最多可提升15个只读副本基于重做日志复制的副本低延时

-通常<10毫秒读取器端点具有负载平衡和自动缩放(CPU及连接数)AvailabilityZone

1AvailabilityZone

2AvailabilityZone

3Aurora只读副本自动伸缩技术READREP24克隆数据库而不复制数据瞬间创建一个数据库克隆仅在发生写入时复制数据(COW)

–当原始数据和克隆卷数据不同时应用场景克隆生产数据库以运行测试数据库重组为分析提供一个时间点快照，不影响生产环境PRODUCTION

DATABASECLONECLONECLONEDEV/TESTAPPLICATIONSBENCHMARKSPRODUCTIONAPPLICATIONSPRODUCTIONAPPLICATIONSA

u

ro

r

a

数据库克隆技术克隆数据库而不复制数据数据库重组PRODUCTIONDAT25存活 c

a

c

h

es将

cache

从数据库进程中分离出来数据库重启时Cache

可以依旧保持热度更快地恢复全量加载操作实例崩溃恢复+

可存活cache

=

更快速容易地从DB失败中恢复SQLTransactionsCachingSQLTransactionsCachingSQLTransactionsCachingCaching

process

和DB

process

分离开来并在数据库重启时保持

warm存活 caches将cache从数据库进程中SQ26数据回溯t0t1t2t3t4Rewindto

t1t0 t1 t2 t3 t4快速恢复用户的错误操作使用

Backtrack

允许您将数据库回退到以前的某个时间点，无需从备份还原，即使是大型数据库也只需要几秒钟时间。可以多次恢复，直到需要的时间点Rewindtot3InvisibleInvisible数据回溯t0t1t2t3t4Rewindtot1Rewi27仅为您使用的资源按秒付费A

u

ro

r

a

无服务器架构(

S

er

v

er

l

e

s

s

)Warm

CapacityPoolScalableDatabase

Capacity(Compute+

Memory)SharedDistributed

StorageServerless

是一种面向

Aurora

的按需扩展配置，数据库将根据您的应用程序的需求来自动启动、关闭以及纵向和横向扩展数据库容量。可在云中运行关系数据库，而无需管理数据库实例或集群。Application按需自动启停Database

Endpoint无服务器化、自动扩展仅为您使用的资源按秒付费Aurora无服务器架构(28议程Aurora特性Aurora技术架构迁移至AuroraAurora客户案例议程29A

u

ro

r

a

适用场景Mysql/PostgreSQL即使优化仍然遇到瓶颈优化索引优化SQL主从读写分离拆分数据库高并发读写，尤其写操作的负载很高需要快速恢复最小化读副本的延迟免去手动sharding或者使用sharding中间件带来的复杂性和运维成本Aurora适用场景Mysql/PostgreSQ30A

m

a

zo

n R

DS

迁移至A

u

ro

r

a

的不同场景同构数据库有一定的停机时间最小停机时间异构数据库有一定的停机时间最小停机时间详细过程可参考：/cn/blogs/china/every-scene-mysql-database-move-to-amazon-aurora/Amazon RDS迁移至Aurora31A

m

a

zo

n R

DS

迁移至A

u

ro

r

a创建RDS快照根据快照创建Aurora数据库应用程序开始使用Aurora数据库同构数据库有一定的停机时间Amazon RDS迁移至Aurora创32A

m

a

zo

n R

DS

迁移至A

u

ro

r

a创建Aurora只读副本把Aurora只读副本提升为主库应用程序开始使用Aurora数据库同构数据库最小停机时间Amazon RDS迁移至Aurora创33自建数据库迁移至A

u

ro

r

a为自建数据库创建备份把数据库备份上传到S3根据备份创建Aurora数据库应用程序开始使用Aurora数据库同构数据库有一定的停机时间自建数据库迁移至Aurora为自建数据库创建备份34自建数据库迁移至A

u

ro

r

a创建Aurora从库自建数据库与Aurora从库进行数据同步主从切换，使得Aurora从库变成新的主库应用程序开始使用Aurora数据库同构数据库，以MySQL为例有一定的停机时间自建数据库迁移至Aurora创建Aurora自建数据35自建数据库迁移至A

uro

r

a同构或者异构数据库最小停机时间迁移关键业务系统迁移数据仓库到Amazon

Redshift归档老数据升级小版本合并多个数据分片到Amazon

Aurora复制数据从而在云端分析数据从NoSQL迁移到SQL，或者从SQL迁移到NoSQL，或者从NoSQL迁移到NoSQLAmazon

RDSAmazon

RedshiftAmazon

AuroraAmazonDynamoDBAmazon

S3迁移自建数据库迁移至A