江苏龙网

  1. 首页 > 人文 > >

空心|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） 。


推荐阅读


上一篇：几品飞车|互联网分层架构的本质

下一篇：三好先森|RC 发布，基于AntV的权限管理系统，CatchAdmin