DFV架构

• 数据功能虚拟化(Data Function Virtualization)
  • 块、对象、文件
  • 数据库
  • 大数据
• 弹性
  • 单个资源池中具备数干个节点
  • 线性扩展(容量/性能)
  • EB级别的容量，一台设备中具有 100亿个对象
  • 跨区域复制，跨越AZ EC
• 架构解析：
  • DFV底层可部署在公用云、私用云上；
  • 采用Key、value形式存储；
  • 通过索引加上数据访问；
  • 对存储对象进行抽象：因此可以存储块、文件、对象，从而可以部署数据库、大数据业务。

GaussDB(for MySQL)的架构

• 四个主要的模块
  • SQL：提交事务，基于MySQL 8.0，100%兼容
  • SAL(Storage Abstraction Layer)：数据分片、故障恢复、远程数据存储
  • Log Stores：持久化Redo Log
  • Page Stores：持久化Page
• 特点
  • 海量数据存储：支持互联网业务的大数据量，128TB存储；
  • 分布式高扩展：自动化分库分表，或非分库分表，应用透明；
  • 高可用性：支持跨AZ、跨Region容灾；
  • 高可靠性：跨AZ部署，数据多副本；
  • 超低成本：1/10的商用数据库成本；

Log Store：Redo在DFV上的存储与访问

• Log Store负责持久化Log；
• Log存储对象采用PLOG对象
  • Block存储对象：一个PLOG有大小限制(64MB)
  • Append-only：追加存储方式
  • 多副本：默认3副本，Write强一致(All)、Read任何一个副本(Any)
  • 惟一ID标示：24-byte
• 多副本：对于write，采用强一致提交方式：所有副本都成功后，事务才可以提交；对于read，任何一个副本成功则成功。

Page Store：Page的DFV上的存储、访问

• Page Store负责持久化Page和SQL读page
• Page存储的对象为Slice
  • Slice：彼此独立、10GB大小限制
  • 唯一标示：48byte
  • Slice多副本存储：副本之间可彼此同步数据
• 多副本：Slice的replication采用N=3，W=1，R=3的leaderless replication策略，只要SAL等到了其中1个slice副本的响应，那么对应的write buffer即可释放并重用。

单AZ和多AZ部署

• 单AZ部署
  • 3副本：副本在不同节点
  • Log Store：3副本全部持久化，事务才可提交；从任何一个副本即可读取数据；
  • Page Store：3副本任何一个持久化，即成功；副本之间可进行同步数据；
• 多AZ部署
  • 6副本：每个AZ包含两个副本
  • Log Store：6个副本，对于写需要4个成功写入，对于读需要3个副本有效；
  • Page Store：6副本任何一个持久化，即成功；副本之间可进行同步数据；

Log Store恢复

• 临时故障
  • Log Store变为Read-only模式，不会有新的请求，该节点设为临时故障状态；
  • 恢复后，不需要Recovery，丢失数据可从其他副本拉取；
• 永久故障
  • 故障节点从集群中剔除，该节点上所丢失的数据，会通过其他副本上进行重构；

Page Store恢复

• 临时故障
  • 场景1：故障期间无法接收新数据，故障恢复上线后，通过同步协议，将缺失的slice数据，从其他副本中获取；
• 永久故障
  • 场景2：处于临时故障15分钟后，该节点会被标记为永久故障，从集群中剔除，并在其他节点上重建该节点的数据。处于重建状态的副本刚开始时候是没有任何数据的，但是该节点可以接受新的Write log请求，但无法提供Read page的业务。只有当重建出所缺失的数据后，该节点就可以提供读写服务。