Cache Fusion: Extending Shared-Disk Clusters with Shared Caches

[mrdrivingduck]

P683.pdf

VLDB 2001...?

[mrdrivingduck]

Abstract and Introduction

Cache Fusion 是 Oracle RAC (Real Application Cluster) 的基本组件，能够将单机数据库系统扩展为 share-disk 的多节点集群。Cache Fusion 能够使节点之间通过网络互联发送消息共享易失 buffer，从而减少磁盘 I/O。

所谓 shared-disk 架构，是指所有节点能够直接访问所有磁盘的架构。核心组件：

• 服务器节点
• 网络连接
• 磁盘子系统

Oracle RAC 之所以叫这个名字，是因为这个架构不需要任何应用程序的变化。

在传统的 shared-disk 架构中，disk 是保证数据相干性的介质，如果一个节点需要请求正在另一个节点的 buffer pool 并且为 dirty 的 page，则需要等待另一个节点先将这一页写入存储，然后该节点再从存储上读取。但目前已经有了更多先进的硬件方便组件集群。Cache Fusion 使用网络而不是 disk 来作为节点之间交换数据的媒介，从而形成 shared-cache 的数据库集群架构。

[mrdrivingduck]

Overview of Real Application Clusters

一个 Oracler 实例：能够访问共享的数据文件集合的进程和内存的集合。RAC 集群内的每个实例都有自己 私有 的 redo 日志和 私有 的 buffer pool，所有节点的私有 buffer pool 共同组成了全局的 buffer pool。

为了维护全局 buffer pool 的数据相干性，需要被称为 GCS (Global Cache Service) 的资源控制机制。GCS 追踪所有缓存资源（数据 block）的 位置 和 访问模式。通过同步，可以做到同一时间只允许一个实例修改某个 buffer pool。

GCS 使用分布式架构，每个节点负责管理 GCS 的一部分。这样有几点好处：

1. 对 buffer 的 request 能够被均匀打散到所有节点
2. 当一个节点宕机时，只有对该节点上的 buffer 请求会暂时不可用

GCS 对 buffer pool 的分配考虑到了 access pattern 的因素。某个实例最频繁访问的资源，会更有可能被分配在这个实例进行管理。这样这个实例访问这个资源就是本地访问了。

由于 GCS 具有全局 buffer pool 的视角，假设一个实例想要 update 某个 block，GCS 将会把这个请求发送到目前持有这个 buffer 的实例上，这个实例会将这个 buffer 转移到发起请求的实例上，完成更新。GCS 将会更新这个 buffer 的持有者信息。

[mrdrivingduck]

3. Cache Fusion

Cache Fusion 指的是通过快速的网络传输在实例之间共享 buffer cache，从而形成一个集群视角的全局 buffer cache 的协议。分为两部分：

• Read-Sharing：查询另一个实例上的 buffer 的机制
• Write-Sharing：更新另一个实例上的 buffer 的机制

Cache Fusion Read-Sharing

这里利用到了 Oracle 的 CR (Consistent Read) 机制：CR 是一个基于版本的并发控制协议，读请求不用获取任何锁。Oracle 中的每一个事务都对应一个快照时间 SCN (System Change Number)，CR 保证事务内的所有读取结果与这个 SCN 一致。当事务对数据进行修改时，首先在 rollback segment 中记录下用于 undo 的信息；当事务读取数据时，CR 可以通过 undo 信息恢复出较早版本的 block（在内存中）。因此，一个读请求永远不需要等到写请求 commit 了才可以继续。

在 RAC 中，实例 A 请求实例 B 内存中的一份 buffer 时，不需要修改这个 buffer 的 ownership。实例 B 在内存中创建一个事务一致的 CR clone，然后通过网络发送到实例 A。

只有当请求的 block 不在任何实例的 buffer pool 中时，才会发生 disk I/O。该协议保证后续对这个 block 的其它读请求不再触发 disk I/O。

Cache Fusion Write-Sharing

写协议需要 GCS 的参与。当实例 A 想要更新某个 block 时，GCS 判断这个 block 位于实例 B 的 buffer pool 中。那么 GCS 将会通知实例 B 释放对这个 block 的拥有权，实例 B 在保存一份 copy（方便之后的读请求）后释放拥有权，并将其缓存的 block 发送到实例 A 上，即使 block 是 dirty 的。

如果 GCS 判断这个 block 不在任何节点的 buffer pool 内时，才会发生 disk I/O。

写协议的优势：在某一个 block 被写请求后，当前 copy 能够继续服务读请求；而不是一个节点的写请求将会 invalidate 所有的 block cache。

Cache Fusion 的读写协议保证 RAC 中的 disk I/O 次数与一个具有所有集群节点 buffer pool 大小之和的单机实例一致。

Efficient inter-node messaging

三个因素用于提升节点间的网络传输：

• 传输消息的延时：Cache Fusion 使用固定长度、固定格式的 message 来传输消息，从而便于快速生成和解析
• 参与一次请求的节点数量：最多三个，从而能够在集群规模增大时保持 scale
  • 请求 block 的节点
  • 持有 block 的节点
  • 记录 block 位置信息的节点
• 节点间同步的频率：自适应动态迁移，最频繁访问某个 block 的实例最终将负责记录这个 block 的位置信息，从而减少节点间同步的频率

[mrdrivingduck]

RAC support for DSS workloads

Oracle 使用基于集群的代价估算优化器，将负载放到集群上并行执行。考虑了：

• 集群拓扑
• 节点数量、节点 CPU
• 本地与远程执行的相对代价

一个减少远程执行代价的方法是使用 Function Shipping，将生成的 SQL 发送到远程去执行，这比 Data Shipping 会有更小的代价，因为网络传输的信息量变少了。

[mrdrivingduck]

Recovery in a RAC environment

RAC 架构下，只要有一个节点存活就可以保证集群的可用性。恢复的代价和故障节点的数量相关，而不与集群大小相关。因为只有故障节点的 redo log 需要被读取并 apply。

并行恢复机制利用所有存活节点并行恢复，能够在多个实例上并行化地读取 log 和 data block，减少恢复时间。