空心|万字详文:腾讯数据库专家深度探索Amazon Aurora( 七 )


空心|万字详文:腾讯数据库专家深度探索Amazon Aurora图1-10 Aurora保障读可用图
在1.1节 , 曾经说过“主从节点可以位于不同的AZ(最多位于3个VPC , 需要3个AZ)但需要位于同一个Region内” 。 如表1-1所示 , AWS在全球提供的AZ个数尚有限 , 按其自身的说法部署一个Aurora需要三个AZ , 那么诸如只有2个AZ的Region如北京 , 尚不能得到较可靠的数据可用保障 。
空心|万字详文:腾讯数据库专家深度探索Amazon Aurora图1-10 Aurora保障读可用图
2.3 Aurora设计的优点
首先 , 存储层与事务管理分离 , 即ACID的D特性独立 , 使得存储有机会成为独立的服务而存在 , 便于跨数据中心时实现数据的容错(fault-tolerant)、自愈(self-healing service)[11]和快速迁移 。 一旦存储层具备了容错、自愈和可快速迁移特性 , 则对外提供服务就不用再担心数据的短暂或长久的不可用性 。 在数据为王的时代 , 此举能保护好最核心的财产 , 确保云数据库服务能持续不断地对外提供服务 , 这使得Aurora具备了云服务的弹性 。 此点在AWS看来 , 十分重要 。 有了这种需求 , 推动技术架构发生变化便水到渠成 。
服务的过程中 , 局部数据修复的能力 , 速度很快 。 数据库宕机后的恢复 , 速度也很快 。
Once thedatabase starts up it performs volume recovery in collaboration with thestorage service and as a result, an Aurora database can recover very quickly (generally under 10 seconds) even ifit crashed while processing over 100,000write statements per second.
服务中断后 , 最后的招数就是数据迁移加数据库引擎重新部署 , 而AWS的整个云系统具备了快速迁移数据的能力 , 这使得以存储为核心的云数据库有了超强的持久服务能力 。
Wemonitor and automatically repair faults as part of our service. A 10GB segment can be repaired in 10 seconds on a10Gbps network link. We would need to see two such failures in thesame 10 second window plus a failure of an AZ not containing either of thesetwo independent failures to lose quorum. At our observed failure rates, that’ssufficiently unlikely, even for the number of databases we manage for ourcustomers.
其次 , 存储层从高度耦合的数据库引擎中分离 , 降低了数据库引擎的复杂度 , 数据库组件的分离使得数据库部署适应巨量数据的分布式处理需求 。 这将进一步带动数据库引擎上层的语法分析、查询优化、SQL执行、事务处理等组件进一步的解耦 。
笔者认为 , 这是Aurora用实践为数据库架构技术的发展指出的可行方向 。 一个具有实践意义的分布式发展架构 , 总是最亮眼的 , 也总是具有指导意义的 。 存储与计算解耦 , 各种组件互相解耦 , 不断解耦...在此种思路下 , AWS已经走在发展万能数据库引擎的道路上(参见4.2节) 。
3.Aurora的事务处理
Aurora基于MySQL和InnoDB , 实现的是单点写的一主多从架构 , 所以在事务处理方面 , 没有大的变动 , 事务处理技术得到继承 。 整体上是依据SS2PL和MVCC技术实现了事务模型(参见《数据库事务处理的艺术 事务管理与并发控制》一书的10.3.3、10.3.4节)和并发控制(参见《数据库事务处理的艺术事务管理与并发控制》一书的第11、12章) 。
3.1 持久性
对于Aurora , 事务的ACID特性 , 只有D特性与MySQL和InnoDB有很大的不同 。 Aurora利用MySQL的Mini-transaction和LSN在存储节点构造数据页(基本过程参见2.1节) 。


推荐阅读