复制表

复制表是 OceanBase 数据库中的一种特殊表。这种表可以在任意一个“健康”的副本上读取到数据的最新修改。对于写入频率较低、对读操作延迟和负载均衡要求较高的用户来说，复制表是一种理想的选择。

什么是复制表

复制表与普通表的主要区别体现在读副本是否可以支持读最新数据。普通表的副本只可以执行弱一致性读请求，读旧版本数据；复制表的副本可以支持强一致性读，读最新版本数据。

当用户创建一个复制表时，当前租户的所有 OBServer 节点上都会创建一个复制表的副本。其中，一个副本会被选为 Leader，负责接受写请求，而其余副本只能接受读请求。

所有副本需要向 Leader 汇报状态，主要是副本的回放进度，即数据同步的进度。通常情况下，Follower 的回放进度会略落后于 Leader，只要落后的幅度没有超过固定的阈值，Leader 就会认为副本处于“健康”状态，能够快速回放 Leader 上的修改。当 Leader 认为某个副本在一定时间内保持“健康”后，会授予 Follower 一段时间的 Lease。简单来说，Leader 在接下来的时间里“信任” Follower 会保持“健康”状态，并能够提供强一致性读服务。在此“信任”期内，Leader 会在每次提交复制表事务前确认 Follower 的回放进度。只有当 Follower 回放出本事务的修改后，Leader 才会向用户报告事务提交成功。在此情况下，用户可以在“健康”的 Follower 上读取到刚刚提交的事务的修改，前提是该 Follower 的回放进度已追赶到事务提交时的状态。

为什么需要复制表

“一写多读”是数据库中较为常见的一种部署方式，即一个节点处理所有写操作，然后将逻辑日志异步同步到其他读节点，如 Amazon Aurora。这种部署方式的好处在于可以将读压力分散到多个节点，提高容灾能力，并且与客户端物理距离较近的节点的读延迟会更低。

在 OceanBase 中，通常采用弱一致性读加多副本的方式来实现这种需求，其中一个副本（Leader）提供写服务和即时的强一致性读，而其他 Follower 则可以读取到较旧的已提交数据。弱一致性读是在异步复制的数据同步方式下的一种常见选择，Leader 在写入时不需要关注 Follower 的数据回放进度，Follower 则可以提供一致的旧版本数据读取。

然而，在某些场景下，用户的写入频率很低，对写入操作的延迟并不敏感。相对而言，这些用户更加关注读操作的延迟和负载均衡，并希望能及时读取到最新数据。复制表功能就是为了满足这种需求而设计的，在牺牲少量事务提交性能的前提下，复制表可以在任何一个“健康”的 Follower 上读取到最新数据。这里所提到的“健康”是指 Follower 与 Leader 之间的网络通畅、回放进度差距不大。

复制表在 V3.x 版本与 V4.x 版本的差异

复制表功能在 OceanBase 数据库 V3.x 版本上已经存在，而在 V4.x 版本中，由于 OceanBase 数据库的架构发生了较大变化，V4.x 版本的复制表适应了单机日志流的新架构，引入了基于分区的可读版本号校验以及基于日志流的 Lease 授予机制，以保证强一致性读的正确性。

此外，V4.x 版本的复制表功能完善了切主时不终止事务的能力。在用户或负载均衡发起 Leader 切换时，未提交的复制表事务不会像 V3.x 版本那样无法继续，而是可以在切主后继续执行。与 V3.x 版本相比，V4.x 的复制表功能在写事务性能和容灾能力方面都有所提升，副本宕机对读操作的影响更低。