版本日期:2024.03(最新版本以腾讯云官网产品文档为准,本链接为2024年3月版)
版权声明
本文档著作权归腾讯云计算(北京)有限责任公司(以下简称“腾讯云”)单独所有,未经腾讯云事先书面许可,任何主体不得以任何方式或理由使用本文档,包括但不限于复制、修改、传播、公开、剽窃全部或部分本文档内容。
本文档及其所含内容均属腾讯云内部资料,并且仅供腾讯云指定的主体查看。如果您非经腾讯云授权而获得本文档的全部或部分内容,敬请予以删除,切勿以复制、披露、传播等任何方式使用本文档或其任何内容,亦请切勿依本文档或其任何内容而采取任何行动。
免责声明
本文档旨在向客户介绍本文档撰写时,腾讯云相关产品、服务的当时的整体概况,部分产品或服务在后续可能因技术调整或项目设计等任何原因,导致其服务内容、标准等有所调整。因此,本文档仅供参考,腾讯云不对其准确性、适用性或完整性等做任何保证。您所购买、使用的腾讯云产品、服务的种类、内容、服务标准等,应以您和腾讯云之间签署的合同约定为准,除非双方另有约定,否则,腾讯云对本文档内容不做任何明示或默示的承诺或保证。
弹性扩展
概述
TDSQL MySQL版 支持在线实时扩容,扩容方式分为新增分片和现有分片扩容两种方式,整个扩容过程对业务完全透明,无需业务停机。扩容时仅部分分片存在秒级的只读或中断,整个集群不会受影响。
扩容过程
TDSQL MySQL版 主要是采用自研的自动再均衡技术保证自动化的扩容和稳定。
新增分片扩容
- 在 TDSQL MySQL版控制台 对需要扩容的 A 节点进行扩容操作。
- 根据新加 G 节点配置,将 A 节点部分数据搬迁(从备机)到 G 节点。
- 数据完全同步后,A、G 节点校验数据库,存在一至几十秒的只读,但整个服务不会停止。
- 调度通知 proxy 切换路由。
现有分片扩容
基于现有分片的扩容相当于更换了一块更大容量的物理分片。
基于现有分片的扩容没有增加分片,不会改变划分分片的逻辑规则和分片数量。
- 按需要升级的配置分配一个新的物理分片(以下简称新分片)。
- 将需要升级的物理分片(以下简称老分片)的数据、配置等同步数据到新分片中。
- 同步数据完成后,在腾讯云网关做路由切换,切换到新分片继续使用。
相关操作
分布式数据库由多个分片组成,如您需要将现有 TDSQL MySQL版 实例的规格升级到更高规格,请参见 升级实例。
强同步
背景
传统数据复制方式有如下三种:
- 异步复制:应用发起更新请求,主节点(Master) 完成相应操作后立即响应应用,Master 向从节点(Slave)异步复制数据。
- 强同步复制:应用发起更新请求,Master 完成操作后向 Slave 复制数据,Slave 接收到数据后向 Master 返回成功信息,Master 接到 Slave 的反馈后再应答给应用。Master 向 Slave 复制数据是同步进行的。
- 半同步复制:应用发起更新请求,Master 在执行完更新操作后立即向 Slave 复制数据,Slave 接收到数据并写到 relay log 中(无需执行) 后才向 Master 返回成功信息,Master 必须在接受到 Slave 的成功信息后再向应用程序返回响应。
存在问题
当 Master 或 Slave 不可用时,以上三种传统数据复制方式均有几率引起数据不一致。
数据库作为系统数据存储和服务的核心能力,其可用性要求非常高。在生产系统中,通常都需要用高可用方案来保证系统不间断运行,而数据同步技术是数据库高可用方案的基础。
解决方案
MAR 强同步复制方案是腾讯自主研发的基于 MySQL 协议的并行多线程强同步复制方案,只有当备机数据完全同步(日志)后,才由主机给予应用事务应答,保障数据正确安全。
原理示意图如下: 在应用层发起请求时,只有当从节点(Slave)返回信息成功后,主节点(Master)才向应用层应答请求成功,以确保主从节点数据完全一致。 MAR 强同步方案在性能上优于其他主流同步方案,具体数据详情可参见 强同步性能对比数据。主要特点如下:
- 一致性的同步复制,保证节点间数据强一致性。
- 对业务层面完全透明,业务层面无需做读写分离或同步强化工作。
- 将串行同步线程异步化,引入线程池能力,大幅度提高性能。
- 支持集群架构。
- 支持自动成员控制,故障节点自动从集群中移除。
- 支持自动节点加入,无需人工干预。
- 每个节点都包含完整的数据副本,可以随时切换。
- 无需共享存储设备。
实例架构
InnoDB引擎
数据库审计功能重构升级中,敬请期待;在此期间数据库新购实例不再开放审计功能。
实例架构 | 定义 | 节点 | 特点 |
|---|---|---|---|
标准版(一主一从) | 每个分片提供主从双活部署的高可用架构 | 两个节点:一个 Master 节点,一个 Slave 节点 | 支持从机只读 一主一从架构从机只读仅可用于轻量只读任务,请避免大事务等较高负载任务,影响从机备份任务及可用性。 故障后节点自动恢复 默认监控采样粒度:5分钟/次 最大可配备份时长:7天 操作日志备份:7天 支持数据库审计,审计日志存储15天,规则配置个数暂无限制 |
标准版(一主二从) | 每个分片提供主从多活部署的高可用架构 | 三个节点:一个 Master 节点,两个 Slave 节点 | |
金融定制版(一主一从) | 每个分片提供主从双活部署的高可用架构 | 两个节点:一个 Master 节点,一个 Slave 节点 |
|
金融定制版(一主二从) | 每个分片提供主从多活部署的高可用架构 | 三个节点:一个 Master 节点,两个 Slave 节点 |
TDStore 引擎
- TDStore 实例分为集群版和基础版两种:
- 集群版:由多个(≥3个)节点构成,以三副本 Raft 集群的形态提供高性能可用的数据库服务,适用于企业生产环境。
- 基础版:由单个节点构成,以较低的成本提供完整的数据库功能,适用于个人用户。
基础版实例创建后可以通过控制台升级为集群版实例;集群版实例创建后不可以降级为基础版实例。
- TDStore 实例内的节点分为对等架构和分离架构两种:
- 对等架构:计算层 SQL Engine 与数据层 TDStore 合并在一个物理节点中,减少硬件节点数量和跨节点通信,从而降低成本并提高性能。
- 分离架构:计算层 SQL Engine 与数据层 TDStore 分别在不同的物理节点中。
TDStore 引擎介绍
TDStore 是腾讯云全自研的金融级新敏态引擎,该引擎可以有效解决对于客户业务发展过程中业务形态、业务量的不可预知性,适配金融敏态业务。
TDStore 引擎特性
高度兼容 MySQL 语法
TDSQL TDStore 引擎版计算节点基于 MySQL 8.0 实现,除个别受限的系统操作,TDStore 可以100%兼容原生 MySQL 语法。单机 MySQL 的业务可以无损迁移到 TDStore 上,真正实现对业务应用无入侵。
存储计算分离/独立弹性伸缩
TDStore 采用计算和存储分离的原生分布式的架构设计,计算层和存储层的节点均可根据业务需求独立弹性扩缩容,而且无须额外的人工运维干预,实现扩缩容过程对业务零感知。
- 计算层采用多主架构,而且每个计算节点均可读写,用户可以随着业务量的增长而弹性扩展计算节点,单实例可支撑千万级 QPS 流量,帮助用户轻松应对突如其来的业务峰值压力。
- 对于存储层资源,用户也可以随着业务数据量的增长而弹性扩展存储节点。数据在不同节点之间的迁移、均衡、路由变更等操作均由 TDStore 实例内部自洽完成。
云原生的管控系统
TDStore 的管控部分采用了云原生的方式,借助云原生的能力,能够快速且方便地管理 TDStore 实例,免除了繁琐的物理机上架,配置等资源管理运维操作,同时也无需关心资源的使用率情况,即买即用,支持高效弹性扩缩容。
原生 Online DDL 支持
TDStore 支持原生 Online DDL 操作,用户在业务运行过程中,有动态更改表结构的需求时,无须依赖如 pt 或 ghost 等外部工具组件,直接使用原生 MySQL DDL 语句便可完成。
TDStore 覆盖 MySQL 原生可支持的 instant 类型 DDL 操作,并且对于大部分类型(除涉及主键外的)DDL,均能以不阻塞业务的正常 DML 请求下完成。同时,TDStore 的 Online DDL 可以在多个计算节点之间保持一致性,不同表对象的 Online DDL 可以并行执行。
完整分布式事务支持
TDStore 以原生分布式的架构完整支持事务 ACID 特性,默认的事务隔离级别为快照隔离级别(Snapshot Isolation),支持全局一致性读特性,整体事务并发控制框架基于 MVCC + Time-Ordering 的方式实现。
分布式事务协调者由分布式存储层节点担任,而当存储节点在线扩容遇到数据分裂或切主等状态变更的场景时,TDStore 均可实现不中断事务,将底层数据状态的变更对事务请求的影响降到最低,从而做到无感知的集群扩缩容。
低成本海量存储
TDStore 存储层基于 LSM-Tree + SSTable 结构存放和管理数据,具有较高的压缩率,能有效降低海量数据规模下的存储成本。对于一些数据行重复度较大的业务场景,对比 InnoDB 存储引擎,TDStore 版最高可实现高达20倍的压缩率,单实例可支撑 EB 级别的存储量。
TDStore 引擎架构
计算节点 SQLEngine
SQLEngine 是计算节点,负责接收和响应客户端的 SQL 请求。SQLEngine 基于 MySQL 8.0 实现,完全兼容原生 MySQL 语法,从原生 MySQL 迁移过来的业务在使用时无须对业务语句进行任何改造。
SQLEngine 采用无状态化的设计方式,节点本身不保存任何用户数据,并将多线程框架替换为协程框架,与集群内的 TDStore 节点进行交互。
一个实例内可以包含多个 SQLEngine 节点,节点之间彼此独立,均可读写。
存储节点 TDStore
TDStore 是存储节点,负责用户数据的存储。它是一个基于 Multi-Raft 协议实现的分布式存储集群。
Region 是 TDStore 存储和管理数据的最小单位,以及 TDStore 节点之间进行数据复制同步的单位,一个 Region 代表一段左闭右开的数据区间,每个 Region 包含一主 N 备的多个副本,不同副本分散在不同的 TDStore 节点上。客户端对某一行数据的访问,在经过 SQLEngine 编码后,会将请求发送到对应的 TDStore 上对应的 Region 上。
在分布式事务中,TDStore 承担协调者的角色,由 Region 的 Leader 副本进行响应。
管控节点 TDMC
TDMC 为管控节点集群,负责实例内部的资源管控调度,以及全局唯一性的数据资源的管理。
- 在资源调度方面,TDMC 主要负责根据 TDStore 心跳上报的信息,对 Region 下发进行分裂、切主、合并、迁移等任务,同时向 SQLEngine 提供最新的全局的 Region 路由信息。
- 在数据管理方面,TDMC 主要负责向计算和存储节点提供全局唯一且严格递增的事务时间戳,用以实现数据多版本管理以及可见性的判断。另外,MC 还负责管理 MDL 锁、系统变量参数等等。
地域和可用区
InnoDB 引擎
公有云 腾讯云目前提供多个可选地域,TDSQL MySQL版 支持的地域和可用区可在 TDSQL MySQL版 购买页 查看。
金融云 针对金融行业监管要求定制的合规专区,具有高安全,高隔离性的特点;已认证通过的金融行业客户可提工单申请使用专区,详见 金融专区介绍。
TDStore 引擎
内测阶段,目前支持公有云华南(广州)、华北(北京)、华东(上海)地域。暂不支持金融云。




