共计 2660 个字符，预计需要花费 7 分钟才能阅读完成。
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）
- 业务写入一行数据。
- 网关通过对 shardkey 进行 hash。
- 不同的 hash 值范畴对应不同的分片（调度零碎事后分片的算法决定）。
数据依据分片算法，将数据存入理论对应的分片中。
数据聚合
数据聚合：如果一个查问 SQL 语句的数据波及到多个分表，此时 SQL 会被路由到多个分表执行，TDSQL MySQL 版 会将各个分表返回的数据依照原始 SQL 语义进行合并，并将最终后果返回给用户。
留神：
执行 SELECT 语句时，建议您在 where 条件带上 shardKey 字段，否则会导致数据须要全表扫描而后网关才对执行后果进行聚合。全表扫描响应较慢，对性能影响很大。
读取数据（有明确 shardkey 值）
- 业务发送 select 申请中含有 shardkey 时，网关通过对 shardkey 进行 hash。
- 不同的 hash 值范畴对应不同的分片。
数据依据分片算法，将数据从对应的分片中取出。
读取数据（无明确 shardkey 值）
- 业务发送 select 申请没有 shardkey 时，将申请发往所有分片。
- 各个分片查问本身内容，发回 Proxy。
- Proxy 依据 SQL 规定，对数据进行聚合，再回答给网关。
读写拆散
性能简介
当解决大数据量读申请的压力大、要求高时，能够通过读写拆散性能将读的压力散布到各个从节点上。
TDSQL MySQL 版 默认反对读写拆散性能，架构中的每个从机都能反对只读能力，如果配置有多个从机，将由网关集群（TProxy）主动调配到低负载从机上，以撑持大型应用程序的读取流量。
基本原理
读写拆散根本的原理是让主节点（Master）解决事务性增、改、删操作（INSERT、UPDATE、DELETE），让从节点（Slave）解决查问操作（SELECT）。
只读账号
只读帐号是一类仅有读权限的帐号，默认从数据库集群中的从机（或只读实例）中读取数据。
通过只读帐号，对读申请主动发送到备机，并返回后果。
弹性扩大
概述
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 强同步计划在性能上优于其余支流同步计划，具体数据详情可参见 强同步性能比照数据。次要特点如下：
一致性的同步复制，保障节点间数据强一致性。
对业务层面齐全通明，业务层面无需做读写拆散或同步强化工作。
将串行同步线程异步化，引入线程池能力，大幅度提高性能。
反对集群架构。
反对主动成员管制，故障节点主动从集群中移除。
反对主动节点退出，无需人工干预。
每个节点都蕴含残缺的数据正本，能够随时切换。
无需共享存储设备。
