云数据库AWS Aurora(一)

最新推荐文章于 2024-07-20 20:04:43 发布

～千溪杂谈(随风而逝)～

最新推荐文章于 2024-07-20 20:04:43 发布

阅读量1k

点赞数 7

分类专栏：分布式系统与数据库理论文章标签：数据库 aws 云计算

本文链接：https://blog.csdn.net/wowowoc/article/details/137148568

版权

7 篇文章 0 订阅

订阅专栏

本文详细解析了AmazonAurora，一种兼容MySQL和PostgreSQL的AmazonWebServices(AWS)数据库服务，重点介绍了其6副本架构、高可用性和成本效益，以及与传统Quorum系统的区别。文章涵盖了AWS组件如EC2和EBS的应用，以及Aurora的写流程和读流程设计。

摘要由CSDN通过智能技术生成

背景

Amazon Aurora 是Amazon Web Services (AWS) 提供的一种关系数据库服务，它兼容并提供与MySQL和PostgreSQL相同的API。Aurora设计为云环境中的商业数据库，具备高性能、高可用性、低成本等特性。

首先介绍下AWS一些组件。

EC2（Elastic Compute Cloud）：AWS的一种云计算服务，EC2允许用户在云中虚拟化地运行应用程序，提供了可扩展的计算能力。特性：虚拟化计算资源（不同的实例包含不同CPU、内存、存储、网络）、随时启动或停止（灵活）并资源付费等。在一个服务器上，有一个VMM，还有一些EC2实例，其中每一个实例都出租给不同的云客户。每个EC2实例可以运行不同的操作系统，运行的不同的应用程序，比如Web服务、数据库。EC2使用的是本地盘，所以当数据库服务部署在EC2，假设EC2宕机了，本地盘无法访问

EBS (Elastic Block Store): 从EC2实例来看，EBS就是一个硬盘，实现中，EBS底层是一对互为副本的存储服务器。当EC2挂在一个EBS volume后，可以像操作普通磁盘一样操作，但是其实是网络请求到EBS服务器。其中EBS底层副本可以采用链式复制-Chain Replication的方式来复制：即写请求首先会写到第一个EBS服务器，之后写到第二个EBS服务器，然后从第二个EBS服务器，EC2实例可以得到回复。
基于EBS，EC2上的数据库有了可用性，当数据库所在的服务器挂了，可以启动另一个EC2实例，并为其挂载同一个EBS volume，再启动数据库。
基于EBS的数据库缺点：
（1）大量数据需要网络请求
（2）EBS的容错性, 两个副本往往部署同一个数据中心，如果整个数据中心（地震、火灾等）挂了，就没有可用能力了。

Aurora采用了6副本架构，共三个AZ（数据中心），每个AZ有两个副本。
区别于镜像MySQL（Amazon RDS）， Aurora只在网络上传输日志，其他都不传输，因此网络开销很小。日志只是增量，所以内容相比Page较少（当一个数据库要写本地磁盘时，它更新的是整个data page）
数据分片（Protection Group）：10GB一个副本，默认6副本，即存储在6台服务器上。Aurora需要发送一个Log条目时，它会查看Log所修改的数据，并找到存储了这个数据的Protection Group，并把Log条目只发送给这个Protection Group对应的6个存储服务器。存储服务器挂了后，需要尽快恢复副本，采用的策略是并行的 & 快速的在数百台服务器上恢复（假设有足够的带宽，存储服务器有100个分片（每个分片10G），可以以100的并发，并行的拷贝1TB的数据，这只需要10秒左右。如果只在两个服务器之间拷贝，正常拷贝1TB数据需要1000秒左右）
单写：写请求，只发送给一个数据库。（当然很多类似Aurora数据库后续也支持了多写架构）
多读：Aurora可以有多个只读数据库，读请求可以分担到这些只读数据库上

6副本只需要任意4个副本写成功即可（满足Quorum），可容忍两个服务器宕机。或者说单个AZ彻底异常，不影响写操作

读流程：当一个AZ和一个其他AZ的服务器挂了之后，读操作不受影响。
当客户端向只读数据库发送读请求，只读数据库需要知道哪些data page来处理这个读请求，之后直接从存储服务器读取这些data page，并不需要主数据库的介入。只读数据库向存储服务器直接发送读取page的请求，之后它会缓存读取到的page，这样对于将来的一些读请求，可以直接根据缓存中的数据返回。
只读数据库需要保证只应用commit的事务到自身缓存中，保证数据一致性

Quorum系统通常读写的数据都是相同的
数据库服务器写入的是Log条目，但是读取的是page（即数据，RO节点通过Log回放到Page）
数据库服务器可以避免触发Quorum Read（读多个存储服务器），因为日志可以有编号，可以知道哪个存储服务器有最新的日志，因此会挑选拥有最新Log的存储服务器，然后只向那个服务器发送读取page的请求；因此数据库服务器执行了Quorum Write，但是却没有执行Quorum Read，只读了一个副本，而不用读取Quorum数量的副本，效率更高
Aurora也有场景进行Quorum Read，比如当EC2中故障了，导致对应服务器挂掉了，在新启动一个EC2实例后，在进行故障恢复时。原因如下：

a) 数据库服务器故障，可能某些事务在执行过程中，并且已经写了日志，在恢复时候，需要通过Quorum Read的方式找到第一个缺失的Log序号，比如第一个副本有第101个Log条目，第二个副本有第102个Log条目，第三个副本有第104个Log条目，但是没有一个副本持有第103个Log条目，因此数据库服务器会给所有的存储服务器发送消息：丢弃103及之后的所有Log条目
b) 102及之前的Log会保留。但是这些会保留的Log中，可能也包含了未commit事务的Log，需要进行UNDO操作来撤回未commit事务的变更