TDSQL MySQL 版（TDSQL for MySQL）是部署在腾讯云上的一种反对主动程度拆分、Shared Nothing 架构的分布式数据库。TDSQL MySQL 版 即业务获取的是残缺的逻辑库表，而后端会将库表平均的拆分到多个物理分片节点。

程度分表

概述

程度拆分计划是 TDSQL MySQL 版 的根底原理，它的每个节点都参加计算和数据存储，且每个节点都仅计算和存储一部分数据。因而，无论业务的规模如何增长，咱们仅须要在分布式集群中一直的增加设施，用新设施去应答增长的计算和存储须要即可。

通过如下视频，您能够理解程度拆分的过程与原理：https://cloud.tencent.com/doc…

程度切分

程度切分（分表）：是依照某种规定，将一个表的数据扩散到多个物理独立的数据库服务器中，造成“独立”的数据库“分片”。多个分片独特组成一个逻辑残缺的数据库实例。

惯例的单机数据库中，一张残缺的表仅在一个物理存储设备上读写。

分布式数据库中，依据在建表时设定的分表键，零碎将依据不同分表键主动散布到不同的物理分片中，但逻辑上依然是一张残缺的表。

在 TDSQL MySQL 版 中，数据的切分通常就须要找到一个分表键（shardkey）以确定拆分维度，再采纳某个字段求模（HASH）的计划进行分表，而计算 HASH 的某个字段就是 shardkey。HASH 算法可能根本保证数据绝对平均地扩散在不同的物理设施中。

写入数据（SQL 语句含有 shardkey）

1. 业务写入一行数据。
2. 网关通过对 shardkey 进行 hash。
3. 不同的 hash 值范畴对应不同的分片（调度零碎事后分片的算法决定）。

4. 数据依据分片算法，将数据存入理论对应的分片中。
   

   数据聚合

数据聚合：如果一个查问 SQL 语句的数据波及到多个分表，此时 SQL 会被路由到多个分表执行，TDSQL MySQL 版 会将各个分表返回的数据依照原始 SQL 语义进行合并，并将最终后果返回给用户。

留神：
执行 SELECT 语句时，建议您在 where 条件带上 shardKey 字段，否则会导致数据须要全表扫描而后网关才对执行后果进行聚合。全表扫描响应较慢，对性能影响很大。

读取数据（有明确 shardkey 值）

1. 业务发送 select 申请中含有 shardkey 时，网关通过对 shardkey 进行 hash。
2. 不同的 hash 值范畴对应不同的分片。

3. 数据依据分片算法，将数据从对应的分片中取出。

   读取数据（无明确 shardkey 值）

4. 业务发送 select 申请没有 shardkey 时，将申请发往所有分片。
5. 各个分片查问本身内容，发回 Proxy。
6. Proxy 依据 SQL 规定，对数据进行聚合，再回答给网关。
   

读写拆散

性能简介

当解决大数据量读申请的压力大、要求高时，能够通过读写拆散性能将读的压力散布到各个从节点上。
TDSQL MySQL 版 默认反对读写拆散性能，架构中的每个从机都能反对只读能力，如果配置有多个从机，将由网关集群（TProxy）主动调配到低负载从机上，以撑持大型应用程序的读取流量。

基本原理

读写拆散根本的原理是让主节点（Master）解决事务性增、改、删操作（INSERT、UPDATE、DELETE），让从节点（Slave）解决查问操作（SELECT）。

只读账号

只读帐号是一类仅有读权限的帐号，默认从数据库集群中的从机（或只读实例）中读取数据。
通过只读帐号，对读申请主动发送到备机，并返回后果。

弹性扩大

概述

TDSQL MySQL 版 反对在线实时扩容，扩容形式分为新增分片和现有分片扩容两种形式，整个扩容过程对业务齐全通明，无需业务停机。扩容时仅局部分片存在秒级的只读或中断，整个集群不会受影响。

扩容过程

TDSQL MySQL 版 次要是采纳自研的主动再平衡技术保障自动化的扩容和稳固。

新增分片扩容

1. 在 TDSQL MySQL 版控制台 对须要扩容的 A 节点进行扩容操作。
2. 依据新加 G 节点配置，将 A 节点局部数据搬迁（从备机）到 G 节点。
3. 数据齐全同步后，A、G 节点校验数据库，存在一至几十秒的只读，但整个服务不会进行。

4. 调度告诉 proxy 切换路由。
   

   现有分片扩容

   基于现有分片的扩容相当于更换了一块更大容量的物理分片。

阐明：
基于现有分片的扩容没有减少分片，不会扭转划分分片的逻辑规定和分片数量。

1. 按须要降级的配置调配一个新的物理分片（以下简称新分片）。
2. 将须要降级的物理分片（以下简称老分片）的数据、配置等同步数据到新分片中。

3. 同步数据实现后，在腾讯云网关做路由切换，切换到新分片持续应用。
   

   相干操作

分布式数据库由多个分片组成，如您须要将现有 TDSQL MySQL 版 实例的规格降级到更高规格，请参见 降级实例。

强同步

背景

传统数据复制形式有如下三种：

1. 异步复制：利用发动更新申请，主节点（Master）实现相应操作后立刻响应利用，Master 向从节点（Slave）异步复制数据。
2. 强同步复制：利用发动更新申请，Master 实现操作后向 Slave 复制数据，Slave 接管到数据后向 Master 返回胜利信息，Master 接到 Slave 的反馈后再应答给利用。Master 向 Slave 复制数据是同步进行的。

3. 半同步复制：利用发动更新申请，Master 在执行完更新操作后立刻向 Slave 复制数据，Slave 接管到数据并写到 relay log 中（无需执行）后才向 Master 返回胜利信息，Master 必须在承受到 Slave 的胜利信息后再向应用程序返回响应。

   存在问题

当 Master 或 Slave 不可用时，以上三种传统数据复制形式均有几率引起数据不统一。

数据库作为零碎数据存储和服务的外围能力，其可用性要求十分高。在生产零碎中，通常都须要用高可用计划来保证系统不间断运行，而数据同步技术是数据库高可用计划的根底。

解决方案

MAR 强同步复制计划是腾讯自主研发的基于 MySQL 协定的并行多线程强同步复制计划，只有当备机数据齐全同步（日志）后，才由主机给予利用事务应答，保障数据正确平安。

原理示意图如下：

在应用层发动申请时，只有当从节点（Slave）返回信息胜利后，主节点（Master）才向应用层应答申请胜利，以确保主从节点数据完全一致。
MAR 强同步计划在性能上优于其余支流同步计划，具体数据详情可参见 强同步性能比照数据。次要特点如下：

一致性的同步复制，保障节点间数据强一致性。
对业务层面齐全通明，业务层面无需做读写拆散或同步强化工作。
将串行同步线程异步化，引入线程池能力，大幅度提高性能。
反对集群架构。
反对主动成员管制，故障节点主动从集群中移除。
反对主动节点退出，无需人工干预。
每个节点都蕴含残缺的数据正本，能够随时切换。
无需共享存储设备。