Amazon Aurora Product Thinking

Cloud Computing

Aurora: Log is database

最小化网络IO

企业级商业关系型数据库，满足高可用性，性能和拓展性，云服务托管

1. 性能和可扩展性:

  • 低抖动高吞吐量
  • 一键式计算扩展
  • 存储自动扩展
  • Amazon Aurora 低延迟只读副本

2. 可靠性:

  • 实例监控和修复
  • 包含 Aurora 副本的多可用区部署
  • 容错和自我修复型存储
  • 自动、连续、增进式备份和时间点恢复
  • 数据库快照

3. 安全性:

  • 网络隔离
  • 资源级权限
  • 加密

4. 可管理性:

  • 易于使用
  • 轻松迁移
  • 监控和指标
  • 自动执行软件修补
  • 数据库事件通知

5. 开源项目 低成本高可用

产品优点：

  1. 高可用性，比传统MySQL速度快，移植方便
  2. 自动故障修复
  3. 稳定备份和快照恢复
  4. warm restart，cache热备份：Aurora 会用内存页面缓存中存储的已知常用查询页面预加载缓冲池。这样，缓冲池便无需从正常的数据库使用“预热”，从而提高性能。

设计优点：

  1. 剥离基于SSD存储层，独立容错修复能力，高可靠的存储保证SLA免于性能波动和网络故障干扰
  2. Log is data，redo只写入存储层，减小网络IO，提高瓶颈（Mysql则需要协会脏数据页，redolog，binlog，双写文件，metadata）
  3. cache和redo，备份委托给存储层异步执行，及时回复以及warm cache

系统架构：

  1. 完全兼容Mysql用户可以不修改任何代码直接使用api
  2. 可完全脱管的数据库，具有多变的选择和可用性。
  3. 持久服务能力，跨数据中心 容错，自愈（局部数据修复能力，数据库宕机恢复），快速迁移
    • 副本数 V=6，读多数派 Vr=3，Vw=4
    • 分片限制为10GB，6个副本，万兆以太网修复时间低于10s。
  4. 多节点和恢复时数据一致性
  5. 类似Shared Disk Parallel(SDP)架构，只在主节点写，避免分布式并发控制协议。相较于sharding或分布式，将事物层和储存层剥离，将cache和redo放入储存层中
  6. 事务流程：

    • 写：单个master

      • 写多个副本，构造redo日志，但不修改buffer的数据页
      • 由储存层负责将redo日志批量持久化到磁盘，并给master发送ACK（4/6），此后储存层可异步进行后续步骤：
        • 整理日志，补充遗漏（集群中点对点的gossip协议），保证节点一致性
        • 合并步骤，将log转化为数据页
        • 将数据块备份到S3
        • 垃圾回收，清理过时的log和数据页
        • 校验数据块，自动回复坏数据

    • 读：

      • 保证缓冲区内LSN（最新修改操作log记录）大于VDL（持久化位点）的数据页被置换
      • 保证页面所有修改持久化到log，并在缓冲区没有数据页时可构造出当前的VDL页面
      • 如何保证读操作读到最新数据？
        1. 将重放操作组件将LSN ≤ VDL的日志记录应用到相应的数据页产生最新版本的数据；
        2. 读操作的时候将旧版本数据页与delta更新（日志记录）进行合并
      • 系统只有在故障恢复重启的时候会采用多数派读的方式来确定系统的VDL。正常情况下，读操作并没有采用多数派读的方法。Aurora给读操作指派一个读位点（read point），代表着读请求产生时刻的VDL。系统维护着对应存储节点的SCL，知道哪些节点可以满足当前的读操作。

    • 事务提交：

      • 异步成组提交
      • 线程将事物提交到列表，记录commit LSN，无需等待
      • 后台进程将log批量发送到存储层，主实例收到4/6个对应批次的ACK后推移VDL
      • 后台线程检查提交队列，成批提交LSN小于VDL的事务

    • 恢复：

      • 恢复由存储层负责，并行异步分布式redo，不同的segment上按需重放