amazon aurora · 什么是 amazon aurora ? 企业级云原生数据高端商业数据的速和...

© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.

AWS 中国（宁夏）区域由西云数据运营AWS 中国（北京）区域由光环新网运营

力从地起 - 揭秘 Amazon Aurora 底层存储

吕琳，AWS 数据库专家架构师

分会场四：数据库



议程

• 什么是 Amazon Aurora?

• 快速回顾: 数据库内部结构与构建 Amazon Aurora 的动力

• 云原生数据库架构

• 大规模持久性

• 性能

特性与演示

• 全局数据库

• 快速数据库克隆

• 数据库回溯



什么是 Amazon Aurora ?企业级云原生数据库

高端商业数据库的速度和可用性

开源数据库的易用性易用性和成本优势

兼容 MySQL 和 PostgreSQL

简单的按使用付费

以托管服务交付

Amazon Aurora



快速回顾: 数据库 B+ 数Root

Intermediate

Intermediate

Leaf 1 Leaf 2 Leaf 3 Leaf 4

Leaf 1 Leaf 2 Leaf 3 Leaf 4Root Intermediate

Intermediate



快速回顾: DO-REDO-UNDO 协议数据在 buffer-pool 中通过 DO/REDO/UNDO 操作在“原位” 修改

包含前像/后像的日志记录被存储到 write-ahead log (WAL)

DO

Log record

REDO

Log record

UNDO

Log record



快速回顾: 崩溃恢复

tf

Tx1

Tx2

Tx3

Tx4

Checkpoint

系统故障

持久性存储上的页面持久性存储上的日志记录

tf

tr tr系统恢复

Tx2 和 Tx3 通过 REDO 过程重放

Tx4 则通过 REDO/UNDO 过程回滚



快速回顾: 持久化所需的 IO持久化存储上的页面

写日志记录:

典型的几个 bytes

Torn page protection 写:

页面大小譬如 16KB

检查点写:

页面大小譬如 16KB

用户数据变化的大小<< I/O 大小 (32KB+)

数据库的一切都与 I/O 相关

持久化存储上的日志记录



传统数据库架构

数据库的一切都与 I/O相关

超过 40 年的设计原则• 提高 I/O 带宽• 减少I/O数量 !

SQL

Transactions

Caching

Logging

Compute

Attached storage



Amazon Aurora 的方式: 日志即数据库

蓝色页面 t5 可以通过 t1 到 t5 的日志来生成



Amazon Aurora 的方式: 将检查点工作下放到存储层

问题1:

解决办法:

问题2:

解决办法:



Amazon Aurora 的方式: 计算与存储分离

计算与存储有不同的生命周期

计算实例

• 损坏后被替换

• 停机节省费用

• 基于负载扩展、收缩

SQL

Transactions

Caching

Logging

Compute

Network storage

存储, 从另一个角度来说, 是长期的

为可伸缩性、可用性和持久性解耦计算和存储



Amazon Aurora 使用面向服务的体系结构

我们构建一个多租户，多附加的专门为数据库打造的日志结构分布式存储系统

Logging + storage

SQL

Transactions

Caching



Amazon Aurora 存储节点的 I/O 流① 接收日志记录放入内存队列并持久化② 通知数据库③ 组织日志并确认间隙④ 通过 Gossip 到 peers 补足间隙⑤ 合并日志记录形成新的页面⑥ 定期将日志和合并后的 page 放到 s3

⑦ 定期座垃圾回收，清理就页面⑧ 定期检查页面一致性

Log records

Database

instance

Incoming queue

Storage node

S3 backup

1

2

3

4

5

6

7

8

Update

Queue

ACK

Hot

log

Data

Pages

Continuous backup

GC

Scrub

Coalesce

Sort

Group

Peer-to-peer gossipPeer

storage

nodes

注意:

• 所有步骤都是异步的• 只有第一步和第二步会造成前端延迟



当规模达到一定程度，由于节点、磁盘和交换机的故障，会存在连续的独立故障。 Availability

Zone 1

Shared storage volume

Availability

Zone 2

Availability

Zone 3

Storage nodes with SSDs

XX

X

不相关且独立的故障

解决办法就是复制

一种常见的稻草人策略:

每个 AZ 复制一份，一共 3 分使用 quorums ，3 写 2 成功



还是可以保证二份拷贝

依然能维持 quorum

不会丢失数据

Availability

Zone 1


Availability

Zone 2

Availability

Zone 3


X

那么 AZ 故障会怎样?



当一个 AZ 故障时，另一个 AZ 的一个节点

故障

Availability

Zone 1


Availability

Zone 2

Availability

Zone 3


X

那么 AZ + 1 故障呢?

X 失去 2/3 拷贝

失去 quorum

数据丢失



复制 6 份，每个 AZ 有 2 份形成 quorum ，要求 6 写 4 成功

Availability

Zone 1


Availability

Zone 2

Availability

Zone 3


X

Aurora 可以容忍 AZ + 1 故障

X

如果面临AZ故障? 依然可以保证 4/6 拷贝保持可写

如果面临 AZ + 1 故障呢? 依然有 3 份拷贝不会有数据丢失通过幸存的 3 拷贝恢复损坏的拷贝恢复写能力



将数据分成 𝑛 个固定大小的段• 在一个 protection group (PG) 中对每个段复制 6 份

Amazon Aurora 使用段存储

在故障率以及修复时间之间平衡• 如果段太小，故障率过高• 如果段太大，则修复时间过长

选择在保证“足够快”修复的前提下的最大大小• 我们现在段大小是 10 GB , 因为我们可以在 1 分钟以内修复一个 10G 的段



使用 quorum sets 与 epochs 来• 通过 epoch 实现快速更改• 在成员变化时创建额外的 quorums

• 用多个 quorum 来快速逆转更改

A B C D E F

Epoch 1: 所有节点健康

A B C D E F

A B C D E G

Epoch 2: 节点 F 呈可疑状态; 第二个 quorum

group 被创建添加节点G; 两个 quorums 都是active

A B C D E F

A B C D E G

Epoch 3: 节点 F 被确认是不健康的; 新的包含节点 G 的 quorum group 是 active

快速和可逆的成员变化



Amazon Aurora I/O 概况MySQL with replica Amazon Aurora

Amazon EBS mirror

Amazon EBS mirror

AZ 1 AZ 2

Amazon EBSAmazon EBS

Primary

instance

Replica

instance

1

2

3

4

5

Amazon

S3

MySQL I/O profile for 30-min Sysbench run

• 780K transactions

• Average 7.4 I/Os per transaction

Aurora IO profile for 30-min Sysbench run

• 27M transactions: 35× more

• 0.95 I/Os per transaction (6× amplification): 7.7× less

Binlog Data Double-writeLog Frm files

ASYNC 4/6 QUORUM

Continuous backup

AZ 1

Primary

instance

Amazon

S3

AZ 2

Replica

instance

AZ 3

Replica

instance

1

1



读写吞吐量

200,000

170,000

9,536 5,592

0

50,000

100,000

150,000

200,000

250,000

Write

Aurora 5.7 Aurora 5.6 MySQL 5.7 MySQL 5.6

705,000 705,000

290,787 257,122

0

100,000

200,000

300,000

400,000

500,000

600,000

700,000

800,000

Aurora 5.7 Aurora 5.6 MySQL 5.7 MySQL 5.6

Write throughput Read throughput

Using Sysbench with 250 tables and 200,000 rows per table on R4.16XL

兼容 MySQL 的Amazon Aurora 比 MySQL 快 5 倍



全局物理复制Primary region Secondary region

1ASYNC 4/6 quorum

Continuous

backup

AZ 1

Primary

instance

Amazon

S3

AZ 2

Replica

instance

AZ 3

Replica

instance

Replication

server

Replication Fleet

Storage fleet

11

4

AZ 1

Replica

instance

AZ 2 AZ 3

ASYNC 4/6 quorum

Continuous

backup

Amazon

S3

Replica

instance

Replica

instance

Replication

agent

Replication Fleet

Storage fleet

3

3

2

① 主实例将日志记录并行发送到存储节点, 只读实例和复制服务器② 复制服务器将日志流发送到 secondary region 的复制代理③ 复制代理将日志并行发送给存储节点和只读副本④ 复制服务器可以从存储节点拉日志记录以弥补故障造成的间隙

高吞吐: 即使高达 150K writes/second 的负载; 复制对性能的影响也是微乎其微低复制延迟: 高负载下依然保持次秒级跨区域复制延迟快速恢复: 区域故障后 1 分钟以内即可承担全面读写



逻辑复制物理复制

0

100

200

300

400

500

600

0

50,000

100,000

150,000

200,000

250,000

seco

nd

s

QP

S

QPS Lag

0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00

4.50

5.00

0

50,000

100,000

150,000

200,000

250,000

seco

nd

s

QP

S

QPS Lag

逻辑复制 vs. 物理复制

全局复制性能



全局数据库Primary region (US West) Secondary region (US East)

1ASYNC 4/6 quorum

Continuous

backup

Primary

instance

Amazon

S3

Replication

server

Replication Fleet

Storage fleet

1

4

Replica

instance

ASYNC 4/6 quorum

Continuous

backup

Amazon

S3

Replication

agent

Replication Fleet

Storage fleet

3

3

2

持续插入持续读取



U S West(Writer)

U S East(Reader)

2019-11-28

07:48:15.614.1242019-11-28

07:48:15.725.479

Replication Lag ~110ms



快速数据库克隆

生成数据库拷贝而不会加倍数据库存储费用• 克隆的创建是即时的，因为它不需要深度复制

• 只有在写入造成初始和克隆后的数据不同时才会拷贝数据

Production database

Clone Clone

CloneDev/test

applications

Benchmarks

Production applications

Production applications

典型应用场景• 克隆生产数据库做测试

• 重组数据库

• 保存一个时间点快照做分析而不影响生产环境



数据库克隆: 怎么工作的?

Page

1

Page

2

Page

3

Page

4

源数据库克隆数据库

这两个数据库在共享的分布式存储系统上引用相同的页面

Page

1

Page

2

Page

3

Page

4

Page

1

Page

3

Protection group 1

Page

2

Page

4

Protection group 2

共享分布式存储



数据库克隆: 怎么工作的?

Page

1

Page

2

Page

3

Page

4

Page

5

源数据库克隆数据库

当数据库出现差异时，将向每个数据库适当地添加新页面，同时仍然引用两个数据库共有的页面

Page

1

Page

2

Page

3

Page

4

Page

5

Page

6

Page

1

Page

3

Page

5

Page

3

Page

5

Protection group 1

Page

2

Page

2

Protection group 2

共享分布式存储

Page

6

Page

4



数据库状态

• ~近 4000 万行• ~数据大小约 25GB



克隆



• 可以看到约 4000 万行• 但是克隆库只用了~ 0.1GB! (vs.

25GB)

数据库状态(克隆库)



• 更新约 1000 万行• 克隆库现在用了约

1.2 GB!空间 vs

25GB

数据库状态(克隆库)



数据库回溯

回溯是一种将数据库恢复到指定时间点而不用从备份还原的快速方法• 回退数据库以便将数据库从意外的 DML/DDL 操作中恢复出来

• 多次回退以确定所需的数据库状态时间点;例如，快速遍历模式变更而无需多次还原

t0 t1 t2

t0 t1

t2

t3 t4

t3

t4

回退到 t1

回退到 t3

Invisible Invisible



数据库状态(@07:05:07)

Table with ~ 10K rows

大约有 1 万行的表



数据库状态(@07:09:58)

• 添加一列• 添加两行

嗷!



开始回溯



开始回溯

07:06:00



数据库状态(回溯后)

好的正确的旧状态

添加的列和行消失



出版物

Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases. In SIGMOD 2017

Amazon Aurora: On Avoiding Distributed Consensus for I/Os, Commits, and Membership Changes. In SIGMOD 2018



我们希望您在这里找到感兴趣的内容！

也请帮助我们完成投票打分和反馈问卷。

欲获取关于 AWS 的更多信息和技术内容，可以通过以下方式找到我们：

感谢参加 AWS INNOVATE 2020 在线技术大会

微信订阅号：AWS 云计算（awschina）

新浪微博：https://www.weibo.com/amazonaws/

视频中心：http://aws.amazon.bokecc.com/

更多线上活动：https://aws.amazon.com/cn/about-aws/events/webinar/

微信服务号：AWS Builder 俱乐部（amazonaws）

抖音：亚马逊云计算（抖音号：266052872）

博客：https://aws.amazon.com/cn/blogs/china/

AWS 中国账户注册

AWS 全球账户注册

amazon aurora · 什么是 amazon aurora ? 企业级云原生数据 高端商业数据 的速 和...

Documents

amazon aurora · 什么是 amazon aurora ? 企业级云原生数据高端商业数据的速和...