你和云的距离只缺数据库服务器的一场大火

前言

        【一切都会运行在云端】云时代早已来临，现在越来越多的企业从自己维护基础设施转移到公有（或者私有）云上， 带来的好处也是无需赘述的，极大降低了 IaaS 层的运维成本，对于数据库层面来说的，以往需要很强的 DBA 背景才能搞定弹性扩容高可用什么的高级动作，现在大多数云服务基本都或多或少提供了类似的服务。但是，这个但是就重要了，谁也不知道“意外”哪一天会到来，本地服务器做的再好的架构也抗不住一场“大火”，让我们看看Amazon 是怎么通过一代代的最佳实践，将自己的容灾备份能力变的越来越可靠；

为什么我们要做“防火”

       企业的数据库就好比人的大脑的记忆系统，没有了数据库就没有了记忆系统。但是数据的安全性不是万无一失的，随着企业信息化的发展，对于核心数据的安全需求也就越来越大，数据容灾备份就是为了在遭遇灾害时能保证信息系统能正常运行，帮助企业实现业务连续性的目标，备份是为了应对灾难来临时造成的数据丢失问题。

MySQL如何实现 Crash Recoverable Transaction

       对于一个简单的数据库模型，数据库运行在单个服务器上，在硬盘上存储了数据的记录，或许是以B-Tree方式构建的索引。所以有一些data page用来存放数据库的数据，其中一个存放了X的记录，另一个存放了Y的记录。每一个data page通常会存储大量的记录，而X和Y的记录是page中的一些bit位。在硬盘中，除了有数据之外，还有一个预写式日志（Write-Ahead Log，简称为WAL）。预写式日志对于系统的容错性至关重要。在服务器内部，有数据库软件，通常数据库会对最近从磁盘读取的page有缓存。

      当你在执行一个事务内的各个操作时，例如执行 X=X+10 的操作时，数据库会从硬盘中读取持有X的记录，给数据加10。但是在事务提交之前，数据的修改还只在本地的缓存中，并没有写入到硬盘。我们现在还不想向硬盘写入数据，因为这样可能会暴露一个不完整的事务。

      为了让数据库在故障恢复之后，还能够提供同样的数据，在允许数据库软件修改硬盘中真实的data page之前，数据库软件需要先在WAL中添加Log条目来描述事务。所以在提交事务之前，数据库需要先在WAL中写入完整的Log条目，来描述所有有关数据库的修改，并且这些Log是写入磁盘的。

       如果数据库成功的将事务对应的操作和commit日志写入到磁盘中，数据库可以回复给客户端说，事务已经提交了。而这时，客户端也可以确认事务是永久可见的。

       接下来有两种情况。

       如果数据库没有崩溃，最终数据库会将cache中的数值写入到磁盘对应的位置。所以数据库写磁盘是一个lazy操作，它会对更新进行累积，每一次写磁盘可能包含了很多个更新操作。这种累积更新可以提升操作的速度。

       如果数据库在将cache中的数值写入到磁盘之前就崩溃了，这样磁盘中的page仍然是旧的数值。当数据库重启时，恢复软件会扫描WAL日志，发现对应事务的Log，并发现事务的commit记录，那么恢复软件会将新的数值写入到磁盘中。这被称为redo，它会重新执行事务中的写操作。

       这就是事务型数据库的工作原理的简单描述，同时这也是一个极度精简的MySQL数据库工作方式的介绍，MySQL基本以这种方式实现了故障可恢复事务;

关系型数据库（Amazon RDS）的容灾备份

       在MySQL基础上，结合Amazon自己的基础设施，Amazon为其云用户开发了改进版的数据库，叫做RDS（Relational Database Service）。RDS是第一次尝试将数据库在多个AZ之间做复制，这样就算整个数据中心挂了，你还是可以从另一个AZ重新获得数据而不丢失任何写操作。

       对于RDS来说，有且仅有一个EC2实例作为数据库。这个数据库将它的data page和WAL Log存储在EBS，而不是对应服务器的本地硬盘。当数据库执行了写Log或者写page操作时，这些写请求实际上通过网络发送到了EBS服务器。所有这些服务器都在一个AZ中。

       每一次数据库软件执行一个写操作，Amazon会自动的，对数据库无感知的，将写操作拷贝发送到另一个数据中心的AZ中,

       在RDS的架构中，每一次写操作，例如数据库追加日志或者写磁盘的page，数据除了发送给AZ1的两个EBS副本之外，还需要通过网络发送到位于AZ2的副数据库。副数据库接下来会将数据再发送给AZ2的两个独立的EBS副本。之后，AZ2的副数据库会将写入成功的回复返回给AZ1的主数据库，主数据库看到这个回复之后，才会认为写操作完成了。

       RDS这种架构提供了更好的容错性。因为现在在一个其他的AZ中，有了数据库的一份完整的实时的拷贝。这个拷贝可以看到所有最新的写请求。即使AZ1发生火灾都烧掉了，你可以在AZ2的一个新的实例中继续运行数据库，而不丢失任何数据。

Aurora 数据分片（Protection Group）

       为了能支持超过10TB数据的大型数据库。Amazon的做法是将数据库的数据，分割存储到多组存储服务器上，每一组都是6个副本，分割出来的每一份数据是10GB。所以，如果一个数据库需要20GB的数据，那么这个数据库会使用2个PG（Protection Group），其中一半的10GB数据在一个PG中，包含了6个存储服务器作为副本，另一半的10GB数据存储在另一个PG中，这个PG可能包含了不同的6个存储服务器作为副本。

       因为Amazon运行了大量的存储服务器，这些服务器一起被所有的Aurora用户所使用。两组PG可能使用相同的6个存储服务器，但是通常来说是完全不同的两组存储服务器。随着数据库变大，我们可以有更多的Protection Group。这里有一件有意思的事情，你可以将磁盘中的data page分割到多个独立的PG中，比如说奇数号的page存在PG1，偶数号的page存在PG2。如果可以根据data page做sharding，那是极好的。

       Sharding之后，Log该如何处理就不是那么直观了。如果有多个Protection Group，该如何分割Log呢？答案是，当Aurora需要发送一个Log条目时，它会查看Log所修改的数据，并找到存储了这个数据的Protection Group，并把Log条目只发送给这个Protection Group对应的6个存储服务器。这意味着，每个Protection Group只存储了部分data page和所有与这些data page关联的Log条目。所以每个Protection Group存储了所有data page的一个子集，以及这些data page相关的Log条目。

        如果其中一个存储服务器挂了，我们期望尽可能快的用一个新的副本替代它。因为如果4个副本挂了，我们将不再拥有Read Quorum，我们也因此不能创建一个新的副本。所以我们想要在一个副本挂了以后，尽可能快的生成一个新的副本。表面上看，每个存储服务器存放了某个数据库的某个某个Protection Group对应的10GB数据，但实际上每个存储服务器可能有1-2块几TB的磁盘，上面存储了属于数百个Aurora实例的10GB数据块。所以在存储服务器上，可能总共会有10TB的数据，当它故障时，它带走的不仅是一个数据库的10GB数据，同时也带走了其他数百个数据库的10GB数据。所以生成的新副本，不是仅仅要恢复一个数据库的10GB数据，而是要恢复存储在原来服务器上的整个10TB的数据。我们来做一个算术，如果网卡是10Gb/S，通过网络传输10TB的数据需要8000秒。这个时间太长了，我们不想只是坐在那里等着传输。所以我们不想要有这样一种重建副本的策略：找到另一台存储服务器，通过网络拷贝上面所有的内容到新的副本中。我们需要的是一种快的多的策略。

        Aurora实际使用的策略是，对于一个特定的存储服务器，它存储了许多Protection Group对应的10GB的数据块。对于Protection Group A，它的其他副本是5个服务器。或许这个存储服务器还为Protection Group B保存了数据，但是B的其他副本存在于与A没有交集的其他5个服务器中，

       假设有足够多的服务器，这里的服务器大概率不会有重合，同时假设我们有足够的带宽，现在我们可以以100的并发，并行的拷贝1TB的数据，这只需要10秒左右。如果只在两个服务器之间拷贝，正常拷贝1TB数据需要1000秒左右。

       这就是Aurora使用的副本恢复策略，它意味着，如果一个服务器挂了，它可以并行的，快速的在数百台服务器上恢复。如果大量的服务器挂了，可能不能正常工作，但是如果只有一个服务器挂了，Aurora可以非常快的重新生成副本。

总结

传统企业上云，灾备先行

       数据显示，目前已有超过千万个数据库迁移到各大云平台上。到2023年，全球3/4的数据库都将运行在云上。传统企业上云已势不可挡，有数据显示，中国企业的上云意愿高达84%。曾经在很长一段时间内，企业上云最主要的障碍就是安全性。安全涉及的范围非常广泛，灾备就是其中重要的一环。

云灾备的特点

       结合云计算、云存储的特性，云灾备具备多方面的优势∶

A.节约-投入低

无须一次性采购高额的硬件投入，也无须面对因为采购硬件所带来的设备寿命、利旧、再采购等硬件生命周期管理问题。

B.高效-资源服务化

结合了云计算的特点提供了多租户平台、弹性扩容的功能，实现了云灾备资源的服务化。

C.部署灵活-敏捷运维

部署简单、运维方便、随时演练，运维人员可专注于整个IT系统的分层灾备的设计和规划上，并利用弹性的云灾备资源进行分层、分阶段部署。

D.多系统-适应混合IT架构

对于物理机、虚拟机、云主机，本地数据库、云数据库，长期并存的混合IT架构，可以通过云灾备进行集中管理，全面保护。

E.安全-继承传统灾备技术优势

部分云灾备解决方案继承了传统灾备解决方案在数据一致性、业务连续性和数据安全性方面的特点。

中国在灾备市场发展趋势预测

A.云灾备将成为主流

       云存储的发展将进一步刺激云灾备的发展。有预测显示，目前全球数据量以每两年翻一番的速度增长，到2023年全世界需要管理的数据将达到1000ZB（1ZB约为1000亿TB）。

       云计算、大数据等新技术和应用为该领域提供了新的发展机遇，云计算的核心思想是将大量资源统一管理和调度，向用户提供按需服务。基于云计算技术，灾难恢复系统成本更低，恢复速度也更快。

B.灾备将成为信息安全工作的重中之重

       信息安全是国家安全的重要组成部分，已经上升到政治安全、经济安全、领土安全等并驾齐驱的战略高度，金融、能源、电力、通信、交通等各关键领域、关键部门的关键信息基础设施是经济社会运行的神经中枢，是信息安全的重中之重，也是可能遭到重点攻击的目标，因此相关的灾备系统一定要尽快落实到位，作为数据安全的最后一道防线，灾备工作需要肩负的责任重大。云安全方面，需要不断提升对云计算核心软硬件的自主研发能力;提高企业自身信息安全防护意识，灾难恢复是信息安全保障的最后一道防线，当数据丧失可用性和可控性时，仍可通过灾难恢复技术挽救回来。

C.灾备不再是一个业务而是一个生态

        以往单一的灾备技术已经发展成一个集信息存储、信息传输、数据安全等多个方面于一体的综合性IT技术，同时，不同的灾备技术也必须依赖更高维度的生态系统管理予以有效整合。

       灾备安全生态（DR Total Solution Ecological，DR-TSE）理念是以更高的维度建立一个完善的灾备体系，以生态的角度去看待原本点状的灾备部署，充分发挥每一个模块的效用，使任何一种灾备方式都不仅仅是针对某一个数据、某一个应用进行的，而是涵盖在整个业务逻辑中进行，从而实现线上、线下的使用快速方便，软件、硬件、SaaS的交付模式齐全完备，容错、容灾、备份灵活共存，共享、迁移和演练随时随地进行，本地、异地、云端灾备式任意构建，数据库、文件、流媒体全面支持，各类国产、进口、云上、云下单操作系统无缝兼容，由此形成合力，真正做到灾备及高效的业务连续性管理。全生态灾备技术将大受欢迎!

福利

亚马逊云科技专为开发者们打造了多种学习平台：

1. 入门资源中心：从0到1 轻松上手云服务，内容涵盖：成本管理，上手训练，开发资源。AWS入门_AWS入门使用教程_AWS云计算资源-AWS云服务

2. 架构中心：亚马逊云科技架构中心提供了云平台参考架构图表、经过审查的架构解决方案、Well-Architected 最佳实践、模式、图标等。AWS架构中心部署说明_AWS云架构白皮书-AWS云服务

3. 构建者库：了解亚马逊云科技如何构建和运营软件。Amazon Builders' Library

4. 用于在亚马逊云科技平台上开发和管理应用程序的工具包：aws工具下载_aws开发工具_资源下载-AWS云服务