文档

概述

更新时间:

PolarDB MySQL版推出了全局一致性(高性能模式)服务。PolarTrans事务系统利用提交时间戳技术CTS和RDMA网络,在内核层面提供全局一致性(高性能模式)服务,保证发往集群任意副本的读请求都可以获得强一致性的结果。本文档介绍了全局一致性(高性能模式)服务的使用限制、技术原理、开启方式以及性能数据。

版本要求

若要开启全局一致性(高性能模式),PolarDB MySQL版集群版本需为以下版本之一:

  • 8.0.2版本且内核小版本需为8.0.2.2.19及以上。

  • 8.0.1版本且内核小版本需为8.0.1.1.29及以上。

  • 5.7版本且内核小版本需为5.7.1.0.26及以上。

说明

如何确认集群版本,请参见查询版本号

注意事项

  • Serverless集群的所有只读节点默认开启全局一致性(高性能模式)。

  • 全球数据库网络GDN中的从集群的只读节点不支持开启全局一致性(高性能模式)。

  • 全局一致性(高性能模式)与Fast Query Cache功能兼容。若此前全局一致性(高性能模式)打开了MTT优化功能,当同时开启Fast Query Cache功能和全局一致性(高性能模式)功能时,全局一致性(高性能模式)的MTT优化功能将失效。Fast Query Cache功能详情请参见Fast Query Cache

背景信息

在原有的PolarDB一主多备数据库架构中,RO节点默认提供最终一致性读取功能。物理复制和共享存储技术可以有效的降低RO节点延迟,但不能保证发往RO节点的只读请求读取到RW节点上最新写入的数据。在一些对数据延迟比较敏感的金融行业和游戏行业中,RO节点延迟读取会造成业务逻辑的一致性问题。强一致性读

如上图所示,多个业务之间通过微服务框架进行解耦。服务A写入数据后,产生一条数据写入成功的消息通过MQ通知到服务B。服务B通过消费消息感知到数据写入成功,随后下发读请求进行数据读取,进行下一步的业务流转。在只能提供最终一致性读的情况下,无论是A服务还是B服务,在进行数据读取时,都无法保证读取到步骤1中最新写入的数据,从而给上层业务带来数据一致性问题。此前面对这种使用场景,只能将只读请求转发到RW节点上,以保证写后读的数据一致性。

全局一致性(高性能模式)技术方案

PolarTrans利用CTS技术和RDMA网络,在纯内核层面提供RO节点强一致性读服务,从而保证始终能看到RW和RO节点最新的数据,提供了集群维度的强一致性读能力。

PolarDB在开启PolarTrans功能后,RW节点上每个读写事务提交时,都会赋予一个时间戳,表示事务提交的时间。这个时间可以是逻辑时间戳,也可以是一个和物理时间绑定的混合逻辑时间戳。同时,RW节点会把事务id和提交时间戳CSN记录到Redo Log中,RO节点通过回放Redo Log构建出完整的事务状态。

RO强一致性读SQL执行过程如下:

  1. 客户端发起查询;

  2. RO节点通过RDMA one-side remote read获取RW节点当前最大提交时间戳;

  3. RO节点根据RW节点的最大提交时间戳构建强一致性只读视图,并等到RO节点事务状态回放到相应位点;

  4. RO节点根据强一致性读视图判断数据可见性,给客户端返回结果。

强一致性读

在全局一致性(高性能模式)中,RO节点通过RDMA one-side remote read获取RW节点上当前最新的提交时间戳,用于计算当前的事务延迟情况,构建强一致性读视图等。全局一致性(高性能模式)在实现上结合大量的并发优化手段,多线程之间的查询结果可能会进行复用,从而降低remote read次数和开销,使事务状态同步过程的时间消耗控制在2%以内。

细粒度的写入追踪(MTT)

为了在RO节点上实现强一致性读功能,RO节点首先需要获取RW节点上当前的最大时间戳,然后等待RO节点上的日志回放至该时间戳后,才可以处理读请求。然而实际操作中,RO节点在等待日志回放时,可能当前请求的数据已经是最新的,并不需要再等待日志回放。为了避免这些不必要的等待时间,全局一致性(高性能模式)使用了更加细粒度的修改追踪机制。即在RW节点上维护三层修改信息:全局的最新修改的时间戳、表级的时间戳以及页面(Page)级别的时间戳。MTT的核心是从多个层级来追踪RW节点的数据写入状态,并且能够进行Page粒度延迟检测。RO节点在处理请求时,首先获取RW节点上的全局时间戳,如果全局时间戳不满足强一致性读需求,则会进一步获取当前所访问的表的时间戳。如果仍然不满足要求,继续进一步检查需要访问的对应页面的时间戳是否满足要求。只有当页面时间戳仍然比RO节点上日志回放时间戳大时,RO节点才需要等待日志回放。

image

全局一致性(高性能模式)和全局一致性

PolarDB一共提供了四种一致性级别:最终一致性、会话一致性、全局一致性和全局一致性(高性能模式),可以满足在不同场景下对一致性级别的要求。

其中,全局一致性(高性能模式)是对原有全局一致性级别的升级,具有比全局一致性更严格的强一致性要求。因此,若您的业务追求更强的一致性,更推荐全局一致性(高性能模式),具体如下:

  • 对于PolarDB MySQL版5.7、8.0.1和8.0.2版本,若追求严格强一致性,更推荐全局一致性(高性能模式)。

  • 对于PolarDB MySQL版5.6版本,若追求严格强一致性,由于该版本暂不支持全局一致性(高性能模式),可选择全局一致性

说明

关于如何开启全局一致性,请参见开启全局一致性

如何开启全局一致性(高性能模式)

登录PolarDB控制台,在目标集群的基本信息页面的数据库节点区域,选中需要开启全局一致性(高性能模式)功能的只读节点,单击开启全局一致性开启SCC

说明
  • 开通只对新连接生效。

  • 为只读节点开启全局一致性(高性能模式)后,其余和此只读节点在同一个集群地址下的没有开启全局一致性(高性能模式)的其他节点,其一致性级别将自动切换为会话一致性,具体请参见会话一致性

性能对比

  • 测试环境

    一个规格为8核32 GB的PolarDB MySQL版8.0版本集群版

  • 测试工具

    Sysbench

  • 测试数据量

    25张表,每张表250000行数据。

  • 测试结果及说明

    • RDMA性能损耗

      在RO节点无延迟的情况下,通过对比开启/关闭全局一致性(高性能模式)功能,可以计算出通过RDMA获取RW节点当前最大事务版本号过程中的性能损耗。如下图所示,全局一致性(高性能模式)开启后,RDMA的性能损耗可以控制在2%以内。RDMA性能损耗

    • 全局一致性(高性能模式)只读性能对比

      在常规的写入压力下,RO节点存在一定的延迟。由于强一致性读需要进行事务状态获取以及校验,所以对RO节点峰值只读性能存在一定的影响。但经过优化后的全局一致性(高性能模式)技术方案,可以将这一影响范围控制在20%以内,同时RO节点可以提供无异于RW节点的强一致性读体验。强弱一致性读性能

    • 全局一致性(高性能模式)集群混合读写性能对比

      全局一致性(高性能模式)提供的严格强一致性读能力,在读写混合场景中,全局一致性(高性能模式)对RW节点的写入性能完全没有影响,并且可以通过集群地址将更多的只读请求分发到RO节点进行处理,从而提升集群整体的混合读写吞吐能力。下图展示了不同模式下Sysbench oltp_read_write的性能,其中RW表示将所有的请求都发往RW节点。全局一致性(高性能模式)在高并发场景下,性能是RW模式的1.7倍左右。SCC集群混合读写性能

    • 全局一致性(高性能模式)RO读扩展性能

      在读写比例较高的场景中,比如Sysbench标准的oltp_read_write,通过扩展RO节点可以进一步提升集群的性能。更重要的是,扩展RO节点相对于现阶段的升配操作来说更加友好,无需进行集群切换,也不会产生访问中断。强一致性读集群整体性能

    • 全局一致性(高性能模式)高规格集群性能

      通过MTT技术对全局一致性(高性能模式)进行优化后,即便在高并发写入压力下,全局一致性(高性能模式)依然可以在很大程度上提升集群的性能。如下图所示,在包含1个RW节点和1个RO节点的集群中,通过Sysbench 512并发对集群进行oltp_read_write压力测试,开启全局一致性(高性能模式)后的集群性能为RW模式的1.7倍。如果写入压力继续增大,通过扩展RO节点(1RW+2RO)可以将集群性能提升到百万级QPS。混合读写性能(88 CORE)