空心|Aurora，万字详文：腾讯数据库专家深度探索Amazon( 五 ) 目录

鉴于以上几点，备机数据获取和更新的这个细节，算是个谜。
“Caching”如果确实分为两层，在存储层提供从日志中恢复成为数据页的形式而被缓冲，则主备系统之间应该没有必要再传输日志数据，对于备机而言，直接从统一的存储层的“Caching”中获取数据即可。
与此相关的一个问题是：为什么备机节点，可以多达15个呢？难道仅仅是应对读负载吗？或者，作为故障转移的目标，需要这么多备机做备选吗？这又是一个谜。
1.3其他组件
从图1-1中可以看到，物理备份和恢复的数据，是直接存储在AmazonS3 ，即SimpleStorageService上。物理备份和恢复的模块功能被从事务引擎中剥离到了存储层。
从图1-3和1-4中可以看到，日志信息的持久化存储，也是落在了S3上。
S3是AWS提供的对象存储服务。 S3提供了高耐久性、高可扩展性以及安全的解决方案来备份和归档用户的关键数据。在云服务中，数据库提供商业逻辑的支撑， S3提供了数据的持久存储支撑。其作用不可小视。
另外，论文提及了heatmanagement、OSandsecuritypatching、softwareupgrades等特性，对于创造极高的云数据库服务能力很有帮助，本文不再展开讨论，请参阅论文和相关资料。
2.Aurora的存储架构
存储层的设计和实现，体现了“thelogisthedatabase” ，其含义是日志中包含了数据的信息，可以从日志中恢复出用户的数据，所以数据不一定必须再独立存储一份。而数据库的核心不仅是数据，保障数据的拥有ACID特性的事务和提供便捷查询的SQL语句、对以数据为基础提供商业的交易服务更是必不可缺失，所以更精确的说， “thelogisthedata” ，日志就是数据也许更为合适。在笔者看来，数据库的价值不仅在数据，还在数据库的相关技术，尤其在现代巨量数据下、完备的数据库理论下，对以分布为要求的数据库架构提出新的工程实践挑战。 Aurora就是走在这样的实践道路上的楷模。
2.1存储层的工作
如图1-8所示，主机PrimaryRWDB写出的REDO日志（MySQL生成的日志带有LSN ， LogSequenceNumber ，单调递增的日志顺序号）信息发送到六个SotrageNode中的每一个SotrageNode上的时候，只存在一个同步瓶颈点，就是图中标识为?之处，这是Aurora的一个核心设计点，尽量最小化主节点写请求的延时。在存储节点，传输来的日志进入一个队列等待被处理。
之后日志被快速持久化到物理存储设备，并立刻给主机一个回应。这是标识为?的处理过程，这个过程极其简单，没有额外的操作，因而速度会很快，这样能够满足如上所说的“尽量最小化主节点写请求的延时”的设计理念。 ?和?之后的其他操作，都是异步操作，不影响系统的整体性能。这样当主机PrimaryRWDB收到六个SotrageNode中的四个节点的ACK后，就认为日志成功写出，可以继续其他工作了
?所做的工作，是对持久化了日志做处理，如排序/分组等操作作用在日志上，以便找出日志数据中的间隙，存在间隙的原因是多数派写日志的机制下，少数派可能丢失日志从而导致日志不连贯。
?所做的工作，就是从其他存储节点（6个存储节点构成一个PG ，即ProtectionGroup ，每个节点是一个segment ，存储单位是10G ，位于一个数据中心中。 6个存储节点每2个位于一个AZ ，共分布于3个AZ）中，通过Gossip协议，来拉取本节点丢失的日志数据，以填充满所?发现的日志间隙。在?和?的过程中，能发现所有的副本中：相同的、连续的日志段是哪一部分，其中最大的LSN被称为VCL（VolumeCompleteLSN）。