Amazon Aurora

云计算时代 关系型数据库如何实现进化？

谈及数据库，在 08 年以前基本上是以单机型数据库为主，比如大家耳熟能详的 Oracle，MySQL，PostgreSQL 等这样的单机数据库来支撑数据存储业务。但是随着互联网的蓬勃发展，接入到互联网的设备越来越多，数据量越来越大，并发处理需求越来越多，大家渐渐发现这种单机关系型数据库已经没有办法满足在互联网遇到的比如大数据存储、高并发等问题。于是，以 Google 为代表的一些互联网公司开始转向 NoSQL 这种分布式的数据库，这是一个牺牲掉关系的模型去追求可扩展性的方向。在过去的近十年来，是 NoSQL 蓬勃发展的一段时期。但是近几年来，大家发现我们很多的业务并没有办法直接以 NoSQL 的模型来生搬硬套。很多已有的业务 ,特别是对于一些传统行业，还有在座的各位遇到的通信领域的场景来说，历史遗留下来的程序都是以关系型数据库为基础的，所以大家发现很难把这些 Old-SQL 的东西放在一个分布式的场景来使用。那有没有办法把单机型的 SQL 的关系模型跟 NoSQL 所带来的分布式的能力结合在一起呢？其实这就是这两年来整个数据库行业的一个大的革命性方向—— NewSQL。

NewSQL 是指这样一类新式的关系型数据库管理系统，它针对 OLTP 实现读-写工作负载，追求提供和 NoSQL 系统相同的扩展性能，且仍然保持传统数据库支持的 ACID 特性。

NewSQL 数据库其典型代表有 Google Spanner , VoltDB , Clustrix , NuoDB 等， NewSQL 是既拥有传统 SQL 数据库血统，又能够适应云计算时代分布式扩展的产品，主要包括两类：拥有关系型数据库产品和服务，并将关系模型的好处带到分布式架构上；或者提高关系数据库的性能，使之达到不用考虑水平扩展问题的程度。前一类 NewSQL 包括 Clustrix 、 GenieDB 、 ScalArc 、 ScaleBase 、 NimbusDB ，也包括带有 NDB 的 MySQL 集群、Drizzle 等。后一类 NewSQL 包括 Tokutek 、 JustOne DB 。还有一些" NewSQL即服务"，包括Amazon的关系数据库服务、 Microsoft 的 SQL Azure、FathomDB 等。

Amazon Aurora 是 MySQL 的五倍性能

不过，NewSQL就一定是关系型数据库的发展方向吗？亚马逊AWS用自己的产品给出了不一样的答案，那就是Aurora。

Amazon Aurora通过将数据库引擎与为数据库工作负载构建的基于 SSD 的虚拟化存储层紧密集成，使性能大幅超过 MySQL，从而减少至存储系统的写入操作，最大程度降低锁竞争并消除数据库进程线程所产生的延迟。根据 SysBench 对 r3.8xlarge 实例进行的测试表明，Amazon Aurora 每秒提供超过 500,000 次选择和 100,000 次更新，是在同一硬件上运行相同基准的 MySQL 的 5 倍。

为什么阿里云要研发新一代的关系型数据库PolarDB ?

今年阿里云紧随亚马逊的步伐，自主研发了新一代关系型数据库 PoalrDB。PolarDB作为国内首个自主研发的通用云数据库，它拥有商业数据库一样的性能，但价格仅为前者的1/10，进一步降低用户的上云成本。作为云托管的关系型数据库，除了关系型数据库的核心特征之外，PoalrDB 更多的关注于如何提供满足用户业务需求的云服务，并且通过技术革新，不断进化，在提供更好的数据库计算力的同时，满足用户以下业务需求：上云成本、OLTP 性能、业务连续性、在线业务扩展、数据安全。

据悉，9月21日，PolarDB将推出的公测版本，和MySQL完全兼容，即现有 MySQL 应用程序和工具无需修改即可运行，
解决了存储扩展和qps扩展的问题，性能高，成本很低，同时是高可用三副本，共享存储架构。

细看PolarDB

今天不只是阿里云要做这样一款关系型数据库，而是所有的云计算厂商都不可避免的要经历这样一个阶段。那就是云计算时代传统IT计算力的重建和进化。PolarDB 并不是重复 Oracle， IBM 等的脚步，而是一种创新和技术的提升。

PolarDB 与 Aurora 设计理念如出一辙

产品架构上，阿里云 PolarDB 采用了与 Amazon Aurora 相同的设计哲学。都放弃了通用分布式数据库 OLTP 多路并发写的支持，采用一写多读的架构设计，简化了分布式系统难以兼顾的理论模型，又能满足绝大多数 OLTP 的应用场景和性能要求。

PolarDB 采用存储与计算分离的技术架构，同时可以支持更多的只读节点。主节点和只读节点之间是 Active-Active 的 Failover 方式，计算节点资源得到充分利用，由于使用共享存储，共享同一份数据，进一步降低了用户的使用成本，满足公有云计算环境下用户业务弹性扩展的刚性需求。

PolarDB 的设计思想有几个大的革新。一是通过重新设计特定的文件系统来存取 Redo log 这种特定的 WAL I/O 数据，二是通过高速网络和高效协议将数据库文件和 Redo log 文件放在共享存储设备上，避免了多次长路径I/O的重复操作，相比较 Binlog 这种方式更加巧妙。另外在 DB Server 设计上，采用 MySQL 完全兼容的思路，完全拥抱开源生态，从 SQL 的编译、性能优化器和执行计划等等都保留了传统关系型数据库的特色。并且针对 Redolog 的 I/O 路径，专门设计了多副本共享存储块设备。

我们知道，分布式数据库一直是数据库领域的热点，具有非常大的实现难度。不管是遵循 CAP 理论，还是 BASE 思想，通用的分布式关系型数据库基本上很难做到技术和商用的完美平衡。与 SQL 标准以及主流数据库兼容， OLTP ACID 事务 100% 支持， 99.99% 的高可用，高性能低延迟并发处理能力，弹性 Scale Up ， Scale out 可扩展性，备份容灾和低成本迁移等等，能够完美兼顾所有这些特点的商用关系型数据库还没有出现。

PolarDB 性能真的比 Aurora 高吗？

当年，记得 Aurora 刚刚出来的时候，业界有质疑的声音：“ Aurora会不会充其量就是一个翻版的 MySQL ？”今天，当阿里云全新一代 PolarDB 出来，会不会也会有质疑的声音。

据业内人士透露，阿里云这款数据库比 AWS Aurora 性能好太多，这是真的吗？如果是真的，那性能比 MySQL 好太多太多了，你服不服？青出于蓝而胜于蓝，不是不无道理。

我们来看看性能指标吧。业界通常用 SysBench 来测试，包括亚马逊的 Aurora 与 MySQL 的对比，而在阿里云内部是用用户典型场景和数据来对比 PolarDB和 RDS 的。

数据库的重新构想

老式关系数据库体系结构：

在过去的30-40年中，这种单一的关系数据库栈没有发生太大的变化。尽管存在用于扩展数据库的不同传统方法（例如，分片、无共享或共享磁盘），但所有这些方法都共享相同的基本数据库体系结构。它们都不能解决大规模的性能、弹性和故障范围的问题，因为紧密耦合的单体基本约束仍然存在。

为了解决关系数据库的局限性，我们通过将系统分解为基本的构建块来重新定义栈。我们认识到对 缓存和日志记录层 创新时机已经成熟。我们可以将这些层移动到专门构建的、可扩展、可自我修复、多租户，以及对数据库专门优化的存储服务中。当我们开始构建分布式存储系统时，Amazon Aurora 诞生了。

卸载REDO日志：日志即数据库

传统的关系数据库在页面中组织数据，当页面被修改时，它们必须定期刷新到磁盘。为了在故障时维护 ACID 语义，页面修改也记录在 REDO 日志记录中，REDO 日志记录以连续流的形式写入磁盘。虽然这种体系结构提供了支持关系数据库管理系统所需的基本功能，但它存在效率低下的问题。例如，一个逻辑写入会变成多个（最多五个）物理磁盘写入，从而导致性能问题。

数据库管理员试图通过减少页面刷新频率来解决写放大问题。这反过来又恶化了崩溃恢复持续时间的问题。刷新间隔越长，意味着用于重建正确页面从磁盘读取的 REDO 日志记录越多。这会导致恢复较慢。

在 Amazon Aurora 中，日志即数据库。数据库实例将 REDO 日志记录写入分布式存储层，存储层根据需要从日志记录构建页面。数据库实例从不需要刷脏页，因为存储层总是知道页面内容。这提高了数据库的性能和可靠性。由于消除了写放大，并且使用了可扩展的存储集群，写性能大大提高。

例如，与运行在类似硬件上的 Amazon RDS for MySQL 相比，Amazon Aurora MySQL 兼容版在 sysbench 基准测试中显示了5倍的写入 IOPS。数据库崩溃恢复时间大大缩短，因为数据库实例不再需要执行 REDO 日志回放。存储层负责 REDO 日志在读取时的页面生成，从而使新的存储服务不受传统数据库体系结构的约束，因此可以进一步进行创新。

基于单元的架构

正如我之前所说，一切都会出现故障。在大型系统中，组件会发生故障，并且经常发生故障，整个实例出现故障，网络故障可以隔离大量基础设施。更不常见的是，由于自然灾害，整个数据中心可能会变得孤立或瘫痪。在 AWS，我们处理故障，并且在问题发生之前依靠基于单元的体系结构来解决问题。

AWS 有多个地理区域（20个），在每个区域内，我们有多个可用区。利用多个区和区域，设计良好的服务可以在不影响服务可用性的情况下，在组件故障和更大的灾难中生存下来。Amazon Aurora 将所有写操作复制到三个区域，以提供更好的数据持久性和可用性。事实上，Aurora 可以在放弃数据可用性的情况下容忍整个区域的失败，并且可以从较大的故障中快速恢复。

然而，众所周知，复制是资源密集型的，那么，是什么使得 Aurora 能够在提供高性能的同时提供强大的数据复制呢？答案在于仲裁。

仲裁之美

一切都会出现故障。系统越大，出现故障的可能性就越大：网络链路、SSD、整个实例或软件组件。即使软件组件没有bug，它仍然需要定期重启进行升级。

传统的方法是阻塞 I/O，直到故障转移，并且在出现故障组件时以“降级模式”运行，这种方法在规模较大时存在问题。应用程序通常不能很好地容忍 I/O 中断。通过中等复杂的数学计算，可以证明，在大型系统中，随着系统规模的增大，降级模式下运行的概率接近1。然后，有一个真正令人讨厌的“灰色故障”问题，当组件没有完全失效，而是变慢时，就会出现这种问题。如果系统设计没有预见到这种降级，慢的组件会拖累整个系统的性能。

Amazon Aurora 使用仲裁来解决组件故障和性能下降的问题。写仲裁的基本思想很简单：写入尽可能多的副本，以确保仲裁读取总是找到最新的数据。最基本的仲裁示例是“三取二”：

Vw+Vr>VVw+Vr>V

Vw>V/2Vw>V/2

V=3V=3

Vw=Vr=2Vw=Vr=2

例如，您可能要执行三次物理写入，写入仲裁为2。在逻辑写入操作成功之前，您不必等待所有三个操作都完成。如果一次写入失败或速度慢，这是正常的，因为总体操作结果和延迟不会受到异常值的影响。这很重要：即使有什么东西坏了，写入也能成功而且速度很快。

简单的⅔仲裁允许您容忍整个可用性区域的故障。不过，这还不够好。虽然一个区域的故障是一个罕见的事件，但它不会降低其他区域中组件故障的可能性。使用 Aurora，我们的目标是可用性区域+1：我们希望能够容忍一个区域的丢失，再加上一个故障，而不会造成任何数据持久性丢失，并且对数据可用性的影响最小。我们使用 4/6 的仲裁来实现这一目标：

Vw+Vr>VVw+Vr>V

Vw>V/2Vw>V/2

V=6V=6

Vw=4Vw=4

Vr=3Vr=3

对于每个逻辑日志写入，我们发出六个物理副本写入，并考虑当其中四个写入完成时写入操作成功。在每个区域有两个副本的情况下，如果整个可用性区域发生故障，则写入仍将完成。如果某个区域出现故障，并且发生其他故障，仍然可以达到读取仲裁，然后通过快速修复恢复写入能力。

快速修复和追赶

数据复制有不同的方法。在传统存储系统中，数据镜像或擦除编码发生在整个物理存储单元的级别上，几个单元组合在一个 RAID 阵列中。这种方法使修复速度变慢。RAID 阵列重建性能受到阵列中少数设备功能的限制。随着存储设备越来越大，在重建过程中复制的数据量也会越来越大。

Amazon Aurora 使用了一种完全不同的复制方法，基于分片和扩展架构。Aurora 数据库卷逻辑上分为 10GB 逻辑单元（保护组），每个保护组以六副本复制到物理单元（段）。单个存储段分布在一个大型分布式存储中。当发生故障并取出一个段时，修复单个保护组只需要移动大约 10GB 的数据，这在几秒钟内完成。

此外，当必须修复多个保护组时，整个存储组都会参与修复过程。这提供了很高的带宽来快速完成整个修复。因此，如果区域故障后又出现另一个组件故障，对于给定的保护组，Aurora 可能会在几秒钟内失去写入仲裁。然而，一个自动启动的修复能够恢复高速可写性。换言之，Aurora 的储存会很快自我修复。

读取怎么样？仲裁读取代价很高，最好避免。客户端 Aurora 存储驱动程序跟踪哪些段的写入成功。它不需要在常规的页面读取上执行仲裁读取，因为它总是知道从何处获取页面的最新副本。此外，驱动程序跟踪读取延迟，并始终尝试从延迟最低的存储副本读取。唯一需要仲裁读取的情况是在数据库实例重新启动时进行恢复。初始的 LSN 标记必须通过询问存储节点来重建。

创新的基础

许多引人注目的新 Aurora 功能都直接由分布式自愈存储体系结构实现。举几个例子：

• 读可伸缩性：除了主数据库实例外，在 Aurora 的多个区域中最多可以提供15个读副本，以实现读可伸缩性和更高的可用性。读取副本使用与主机相同的共享存储。
• 连续备份和时间点恢复：Aurora 存储层连续透明地将 REDO 日志流备份到 Amazon S3。您可以执行时间点还原到配置的备份窗口中的任何时间戳。不需要计划快照创建，并且当最接近感兴趣时间的快照距离较远时，不会丢失任何事务。
• 快速克隆：Aurora 存储层可以快速创建卷的物理副本，而无需复制所有页面。页面最初在父卷和子卷之间共享，在修改页面时完成写入时的复制。克隆卷时没有重复成本。
• Backtrack：将数据库回退到特定时间点的快速方法，无需从备份中进行完全恢复。误丢了一张表？你可以用 Aurora Backtrack 来回退。

在 Aurora 存储引擎的基础上建立了更多的关系数据库创新。我们进入了关系数据库的新时代，而 Aurora 只是一个开始。客户的声音是最好的回应。Capital One、Dow Jones、Netflix 和 Verizon 等各行业的领导者都在将关系数据库工作负载迁移到 Aurora，包括 MySQL 和 PostgreSQL 兼容版本。

1 使用mysqldump实用程序创建数据库的转储，然后将该数据导入现有aurora mysql数据库集群

因为aurora mysql与mysql兼容，所以该过程与将mysql数据导入rds mysql的过程类似， 可参考文档。

其整体架构如下图所示：

1.1 安装并配置好mysql数据库

我在光环云裸金属服务器上部署了mysql数据库，具体部署过程略，可以百度。

1.2 创建mysql数据库的副本

1.2.1 设置复制选项

编辑文件/etc/my.cnf sudo vi /etc/my.cnf

更新[mysqld]字段如下：

[mysqld] log-bin=mysql-bin server-id=1

重启mysql服务 service mysqld restart

1.2.2 创建现有数据库的备份副本

上图中新建了一个数据库schema_xuyi，现在将schema_xuyi进行备份，执行如下命令：

mysqldump \
--databases  schema_xuyi \
--master-data=2  \
--single-transaction \
--order-by-primary \
-r backup.sql \
-u  local_user \
-p 

图中可见生成了备份文件backup_xuyi.sql

1.3 创建aurora mysql数据库

具体创建过程省略，注意与此前的mysql数据库版本尽量一致。

远程连接到aurora mysql数据库，其初始状态如下图：

1.4 使用mysql命令远程连接到aurora mysql数据库并导入此前的sql文件

执行命令：

mysql -h aurora-1-instance-1.cbgpcbkn8knw.us-east-1.rds.amazonaws.com -P 3306 -u admin -p

其中aurora-1-instance-1.cbgpcbkn8knw.us-east-1.rds.amazonaws.com部分是aurora mysql数据库的终端节点，连接成功

执行命令 source backup_xuyi.sql;

Workbench的刷新操作没找到，重新连接了一下aurora mysql数据库，可见其状态如下：

其中已经有了schema_xuyi的库，说明mysqldump导入成功，本次测试只是为了验证从外部mysql导入到aurora的过程，至此本次操作完成。

2 将完整备份文件和增量文件从数据库复制到S3存储桶，然后从这些文件还原aurora mysql数据库集群

参考文档：

2.1 准备工作

2.1.1 在本地服务器上安装percona

本地数据库版本是mysql5.7，建议percona版本为Percona XtraBackup 2.4

执行以下命令：

yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
yum install -y percona-xtrabackup-24.x86_64

从上图可见Percona-xtrabackup安装成功。

2.1.2 准许aurora mysql访问S3存储桶

在跟aurora mysql数据库相同的区域中创建一个存储桶

过程比较简单，省略。

创建IAM策略以访问S3资源

可以通过IAM控制台来创建相应的策略，具体过程省略，可以授予aurora 访问S3的所有权限。

创建IAM角色以允许aurora mysql访问AWS服务

具体创建角色的过程省略，可以参考文档：

如下图所示，创建了一个角色role_aurora_to_s3，并将上一步的策略附加到了该角色上。

将角色与aurora mysql数据库关联

具体操作过程见文档

如上图所示，已经将角色与aurora mysql数据库相关联。为了让角色生效还需要修改参数组，我们选择新建一个参数组

其中参数“aurora_load_from_s3_role”的值更新为前面所创建角色的ARN。

再修改数据库实例的数据库选项

应用修改，立即重启数据库。

2.2 备份要还原为aurora mysql的数据库的文件

2.2.1 准备工作

为了跟之前的数据库内容区别开来，特意新建了库schema_test,并在其中新建了一张表table_test，如下图所示：

2.2.2 使用percona xtrabackup创建备份

全量备份

xtrabackup --user=root --password=XY-zte110 --backup --target-dir=/root/backupfiles

可见在当前目录下生成了一个backupfiles目录，该类目下的内容如上图所示。

通过aws CLI将备份文件夹整个上传到s3存储桶（具体上传的过程省略），登录s3控制台可见

2.3 从S3存储桶还原aurora mysql数据库

登录aurora控制台，进入数据库页面

在数据库页面点击“从S3还原”， 引擎选项->aurora 版本->我们选择的是mysql5.7

点击“下一步”

下一步，进入数据库详细信息页面进行设置，具体内容与新建aurora实例的过程相似

下一步，配置高级设置

从这个配置的过程来看，跟创建一个新的aurora实例完全相同，由此可以断定aurora从s3还原实际上是重新起了一个aurora实例。最后点击“创建数据库”

确实是新生成一个数据库实例，耐心等待吧。

切换到数据库页面，可以看到有两个aurora实例

上图中的实例aurora-instance-xuyi-copy就是从s3还原出来的新的aurora实例，已经成功创建。现在远程到该实例查看数据库状况

从s3还原实际上是重新起了一个aurora实例。最后点击“创建数据库”

确实是新生成一个数据库实例，耐心等待吧。

切换到数据库页面，可以看到有两个aurora实例

上图中的实例aurora-instance-xuyi-copy就是从s3还原出来的新的aurora实例，已经成功创建。现在远程到该实例查看数据库状况

可见全量复制成功。 至此通过S3还原aurora数据库完成。

集群可能会产生费用

数据库免费试用链接及上手教程

你需要的教程这里都有，不仅有视频教程还有文档教程

文档教程分为初级中级与高级

• 操作需谨慎 误操作会导致费用产生